Почему CDP ломается не на интеграциях, а на определении «кто такой клиент»

Почему CDP ломается не на интеграциях, а на определении «кто такой клиент»

Я много раз видел одну и ту же ошибку: команда покупает CDP, настраивает коннекторы, тащит события из сайта, приложения, CRM и email-сервиса — а потом удивляется, почему сегменты расходятся, триггеры дублируются, а отчёты спорят друг с другом.

Проблема почти никогда не в платформе. Проблема в том, что до внедрения не зафиксирован **единичный клиентский идентификатор** и правила склейки профиля.

Если у маркетинга один email, у CRM другой customer_id, у продуктовой аналитики третий user_id, а у саппорта вообще внешний номер обращения, CDP начинает не «собирать единую картину», а производить компромиссы. В итоге marketing ops получает не операционную систему данных, а красивый слой поверх хаоса.

Мой практический ориентир простой: если на старте проекта у команды нет ответа на три вопроса, внедрение уже буксует:
— какой идентификатор считается главным;
— в какой момент аноним превращается в известного клиента;
— кто владелец правил дедупликации и объединения профиля.

Однажды я видел внедрение, где после объединения источников база «уникальных клиентов» просела на 18%. Для бизнеса это выглядело как ошибка. На деле это была первая честная цифра: платформа убрала двойные профили, гостевые записи и мусор из разъехавшихся систем. После этого пересобрали сегменты, и триггерные сценарии перестали стрелять в одного и того же человека по три раза.

В 2026 году это особенно важно: когда last-click теряет вес, а server-side-атрибуция, MMM и incrementality требуют чистых данных, CDP без нормальной модели идентичности превращается в дорогую витрину.

Мой вывод жёсткий: **внедрение CDP надо начинать не с интеграций, а с контракта на идентичность**. Всё остальное — вторично.

— @CDProomRu