Как считать уникальных клиентов при нескольких аккаунтах

В сервисе рассылок 120 тысяч профилей, в магазине 108 тысяч аккаунтов, а аналитик сообщает о 94 тысячах клиентов. Ни одно число нельзя признать ошибочным, пока не определено, что именно считают. Различия могут возникать из-за гостевых покупок, нескольких аккаунтов, объединения дублей и разных периодов активности.

Уникальный клиент — не самостоятельная техническая единица. Это результат выбранного правила учёта. Можно считать аккаунты, подтверждённых людей, покупателей с заказами или контакты, доступные для рассылки. Эти показатели отвечают на разные вопросы.

Начать стоит со словаря сущностей и воспроизводимого расчёта. Иначе после очередной склейки профилей конверсия улучшится на бумаге, хотя поведение покупателей не изменится.

Назовите единицу в каждом отчёте

Аккаунт — учётная запись в конкретной системе. Профиль — собранные сведения о клиенте в CRM. Контакт — адрес или номер, по которому можно связаться. Человек — реальный участник отношений, которого система узнаёт только в пределах доступных подтверждений.

Постоянный внутренний ID позволяет сохранять связь между записями при обновлении контактов. Например, Twilio Segment описывает модель, в которой несколько внешних идентификаторов сопоставляются одному постоянному идентификатору профиля. Это механизм продукта; качество результата зависит от правил и исходных данных.

В названии метрики пишите единицу и условие: «покупавшие аккаунты за сентябрь», «профили с подтверждённым email», «клиенты после подтверждённого объединения». Слово «уникальные» без этих уточнений оставляет главный вопрос открытым.

Не объявляйте неизвестное число людей точным

Если человек оформил два гостевых заказа с разными контактами и нет проверяемой связи, точное объединение может быть невозможно. Не стоит заменять отсутствие данных догадкой только ради одного красивого числа.

Для управленческого отчёта можно показывать наблюдаемую единицу — например, аккаунт покупателя — и отдельно объём неопределённости: сколько заказов не связано с аккаунтом, сколько пар ожидает подтверждения. Оценку числа людей, если она строится моделью, обозначают именно оценкой и описывают её ограничения.

Не используйте совпадение email как универсальное решение. Общий адрес способен одновременно склеить разных людей и не найти одного человека, использующего два адреса.

Зафиксируйте правила и версию сопоставления

Нужна таблица связей между исходными аккаунтами и выбранным клиентским ID. Для каждой связи храните источник, основание, время действия и версию правила. Это позволяет воспроизвести расчёт и понять, почему число клиентов изменилось.

Для отчётов выберите одну из двух политик. Первая пересчитывает прошлые периоды по текущим подтверждённым связям. Вторая сохраняет опубликованные значения на дату отчёта. Обе могут быть полезны, но смешивать их в одной линии динамики без пояснения нельзя.

Условный пример изменения знаменателя

За месяц 100 аккаунтов совершили 150 заказов. После подтверждённого объединения десяти пар аккаунтов осталось 90 клиентских ID. Число заказов не изменилось. Среднее стало 150 / 90 = 1,67 заказа вместо 150 / 100 = 1,5 заказа на единицу учёта.

Это изменение определения клиента, а не доказательство роста повторных покупок. Если в прошлом месяце оставили расчёт по аккаунтам, сравнение создаст искусственный прирост. Нужно либо пересчитать оба периода одинаково, либо обозначить разрыв методики.

Также проверьте заказы. Если в двух источниках оказался один и тот же заказ с общим order ID, устранение дублей заказов — отдельная операция. Объединение клиентов не должно само по себе удалять разные реальные покупки.

Сверяйте наборы записей

Совпадение итогового числа не гарантирует одинаковый состав. В двух системах может быть по 90 клиентов, но десять из них будут разными. Поэтому сравнивают списки идентификаторов и причины включения, а не только итоговую строку.

Разбейте расхождения: другой период, часовой пояс, статус заказа, задержка данных, различие связей между аккаунтами, исключённые тестовые записи. Для каждого расхождения сохраните пример клиента, на котором можно пройти весь расчёт.

Особое внимание нужно экспериментам. Если после назначения групп два аккаунта объединились в одного человека, он может оказаться одновременно в тесте и контроле. Правило обработки таких случаев задают в дизайне эксперимента; нельзя произвольно переносить участников после получения результата.

Не меняйте единицу между числителем и знаменателем

Допустим, за месяц зарегистрировались 100 аккаунтов. После объединения они соответствуют 90 подтверждённым клиентским ID. Из них купили 18. Делить 18 людей на 100 аккаунтов и называть результат конверсией клиентов некорректно: в числителе и знаменателе разные единицы.

Для расчёта по клиентским ID получится 18 / 90 = 20 процентов, если условия когорты после объединения определены однозначно. Для расчёта по аккаунтам нужно заново получить число купивших аккаунтов. Оно не обязательно равно 18.

Сложность возникает, если два аккаунта зарегистрированы в разные месяцы. Определите, к какой когорте относится объединённый клиент: например, по первому подтверждённому аккаунту в рамках выбранной модели. Сохраните это правило вместе с версией расчёта; иначе пересчёт истории будет незаметно менять и состав когорт.

Договоритесь о публикуемом показателе

В паспорте метрики укажите единицу, период, статусы заказов, версию сопоставления, политику пересчёта истории и владельца. Рядом с основным числом показывайте долю записей, которые пока нельзя уверенно сопоставить.

Приёмка проста: другой аналитик получает те же исходные данные и воспроизводит число по описанию. Если для этого требуется устное объяснение автора, определение пока недостаточно точное.

Источники

Twilio Segment. Identity Resolution Overview. Документация Unify. Раздел Technical highlights. Проверено 22.09.2026.