CDP ломают не фичи, а грязная схема событий и дубли в identity

CDP ломают не фичи, а грязная схема событий и дубли в identity

CDP покупают ради трёх вещей: собрать события из сайта, приложения и CRM; склеить одного человека из разных идентификаторов; раздать аудитории в email, push, ads и support. Если в одном месте user_id, в другом phone_hash, а в третьем вообще пусто — activation превращается в лотерею.

Перед внедрением проверьте базу:
— есть ли единый словарь событий и обязательных свойств
— как строится identity graph: email, phone, device_id, customer_id
— кто источник правды для профиля: CRM, billing или продуктовая БД
— как удаляются дубли и обрабатываются merge/unmerge
— что происходит с anonymous-пользователем до логина

Частая ошибка — начинать с дашбордов и сегментов, а не со схемы. В итоге маркетинг видит “новых”, продукт — “старых”, а CRM шлёт одно и то же письмо дважды. CDP тут не спасает: она лишь быстрее разнесёт мусор по всем каналам.

Если нужен рабочий старт, фиксируйте 10–15 ключевых событий, один identity-ключ как primary и правила на merge. Всё остальное можно достраивать потом; передавать в activation надо только те поля, в которых вы уверены.