Identity resolution ломается не в CDP, а на уровне правил: вот где обычно теряют деньги

Identity resolution ломается не в CDP, а на уровне правил: вот где обычно теряют деньги

Если у вас один и тот же человек живёт в 3–5 идентификаторах, CDP не «склеивает магически». Она просто применяет правила: email, phone, customer_id, device_id, cookie. Ошибка почти всегда в том, что порядок приоритета не описан, а разные команды начинают мерить одного пользователя по-разному.

Самая частая схема провала:
— email на сайте, phone в CRM, device_id в приложении
— гостевой checkout без стабильного customer_id
— merge по «похожим» атрибутам вместо жёстких ключей
— ручные правки в профиле без audit trail
В итоге один человек получает дубликаты, а другой — чужие покупки и триггеры.

Нормальная база для identity resolution такая: сначала определяете authoritative IDs, потом правила слияния, потом правила разъединения. У профиля должен быть один «главный» идентификатор, а остальные — только ссылки. Иначе reverse-ETL начнёт лить в CRM мусор, а маркетинг будет считать фроды там, где их нет.

Проверка простая: возьмите 20 реальных цепочек и прогоните их через схему руками. Если один и тот же клиент после login, purchase и support-ticket получает разные профили — у вас не проблема в CDP, у вас не определены правила истины.