CRM-аналитика
Почему число клиентов в CDP, BI и интернет-магазине не совпадает
Время чтения: 4 мин
Уровень материала: Для экспертов
Содержание
В CDP 120 тысяч клиентов, в BI 94 тысячи, в магазине ещё одно число. Совещание быстро превращается в поиск «правильной системы». Но разные продукты часто считают разные объекты: профили, зарегистрированные аккаунты, покупателей или получателей рассылок.
Сверка числа клиентов — это приведение данных к общему определению и объяснение оставшихся расхождений на уровне ID. CDP объединяет клиентские данные и делает их доступными другим системам; BI собирает данные для анализа. Название системы не определяет автоматически, кого она считает клиентом.
В документации Twilio Segment рекомендуется использовать устойчивый уникальный пользовательский ID. Email и имя пользователя могут меняться, поэтому не подходят на роль неизменного идентификатора. Даже при правильном ID нужны одинаковые границы аудитории и дата среза.
Согласуйте предмет сверки
Начните с одного проверяемого вопроса, например: «Сколько известных покупателей с хотя бы одним завершённым невозвращённым заказом было на 31 августа?». Не пытайтесь одной цифрой описать и размер маркетинговой базы, и число покупателей.
Зафиксируйте, что происходит с гостями, тестовыми профилями, объединёнными аккаунтами и удалёнными данными. Укажите правила по статусам заказа, возвратам, часовому поясу и моменту обновления. Если один отчёт уже включает сегодняшнюю загрузку, а другой ещё нет, несовпадение ожидаемо.
Пройдите от определения к множеству ID
| Этап | Результат проверки |
|---|---|
| Единица | Покупатель, аккаунт, профиль или адрес — выбран один объект |
| Граница времени | Общий срез и понятное время последней загрузки |
| Правила включения | Статусы, возвраты, тестовые записи, известность клиента |
| Идентификатор | Общее поле или проверенная таблица соответствия |
| Состав | ID только в первой, только во второй и в обеих системах |
| Причины | Размеченные категории расхождений с владельцами исправления |
Агрегированная цифра нужна в конце. В начале выгрузите минимально необходимый список ID и признаков включения. Сравнение множеств найдёт случаи, когда одинаковые итоги скрывают разных клиентов: тысяча пропущенных записей и тысяча лишних взаимно компенсируются.
Как выглядит объяснимая разница
Условный пример. В CDP 120 тысяч профилей. Из них 20 тысяч — анонимные профили без связанного покупателя, 5 тысяч — дополнительные профили уже известных людей, 3 тысячи — тестовые записи. Для этого примера категории заранее проверены и не пересекаются. После приведения к определению остаётся 92 тысячи покупателей.
В реестре магазина 94 тысячи. Проверка ID показывает, что 2 тысячи подходящих покупателей не попали в последнюю загрузку CDP. Получается понятный мост: различие объектов учёта объясняет 28 тысяч записей, задержка загрузки — ещё 2 тысячи.
Нельзя механически вычитать такие категории, если они пересекаются. Один тестовый профиль может одновременно быть дублем. Каждой исключаемой записи назначают одну причину по согласованному приоритету либо рассчитывают объединение множеств без повторного вычитания.
Не объединяйте профили ради красивого итога
Общий телефон может принадлежать семье, а один email — обслуживать несколько сотрудников компании. Автоматическая склейка по такому признаку иногда уменьшает счётчик и одновременно ухудшает данные.
У таблицы соответствия ID должны быть происхождение связи, время действия и правило разрешения конфликтов. Особенно важны вход и выход из общих устройств, смена контакта и отмена ошибочного объединения. Сверка помогает обнаружить проблему идентификации, но не даёт оснований считать любое совпадение доказательством одного человека.
Смена правил склейки также может изменить исторические показатели. Отчёт по текущему состоянию профилей и отчёт «как было известно на дату» решают разные задачи. Выбор должен быть явным.
Превратите разовую сверку в контроль
Храните итог по согласованной аудитории, число несовпадающих ID и распределение причин. Для каждой причины назначьте допустимый срок: штатная задержка обмена и неизвестная потеря заказов требуют разных действий.
После исправления пересоберите показатели, которые зависели от дефекта: повторные покупки, сегменты, охват и экспериментальные результаты. Пропущенный покупатель влияет не только на одну строку дашборда.
Рабочая цель сверки — не заставить все экраны показывать одинаковую цифру. Нужно, чтобы различия, предусмотренные определениями, объяснялись, а ошибки передачи и расчёта обнаруживались до использования данных в решениях.
Источники
Twilio Segment. Best Practices for Identifying Users. Twilio Segment Documentation. Проверено 23.09.2026.