Почему CDP проваливается не на выборе вендора, а на схеме идентичности

Почему CDP проваливается не на выборе вендора, а на схеме идентичности

Я часто вижу одну и ту же ошибку в проектах по Customer Data Platform: командa долго сравнивает фичи, а потом удивляется, что данные «не склеиваются», сегменты расходятся, а маркетинг не доверяет витрине.

Мой вывод простой: CDP ломается не на загрузке данных, а на том, **как вы описали человека**.

Если у вас нет жёсткой схемы идентичности, платформа превращается в дорогой агрегатор событий. Она честно собирает клик, покупку, визит, открытие письма — но не понимает, это один и тот же клиент или три разных сигнала из разных систем. Для marketing ops это обычно выглядит так:
— в CRM один контакт,
— в e-mail-платформе второй,
— в веб-аналитике третий,
— в коллтрекинге четвёртый.

И дальше начинается ручная магия, которую невозможно масштабировать.

В 2026 году это особенно болезненно. Когда performance всё сильнее уходит в privacy-first атрибуцию, а last-click теряет вес, качество identity layer становится базовой инфраструктурой, а не «проектом по данным». Без этого нельзя нормально считать инкрементальность, строить retention-цепочки и связывать маркетинг с выручкой в логике RevOps.

Из практики: в одном B2B-внедрении у нас было 14 источников и 9 вариантов ключа пользователя. После нормализации identity и правила приоритета для email, phone и customer_id число «уникальных» профилей сократилось на 18%. Это не потеря базы — это очистка дублей. Зато сегменты перестали гулять, а аудитории для коммуникаций стали повторяемыми.

Я бы проверял CDP не вопросом «что она умеет», а вопросом:
**можем ли мы за 5 минут объяснить, почему два события принадлежат одному клиенту?**

Если ответ расплывчатый — внедрение ещё не началось, даже если договор уже подписан.

По этой же теме советуем @RetentionPaid