CDP не спасает, если у вас кривой event-схематоз и мёртвая identity graph
CDP покупают ради «единого профиля», а получают склад мусорных событий. Если не задать правила именования, обязательные поля и типы данных, через 2–3 месяца в системе окажутся purchase, Purchase и order_completed как три разных события. Дальше ломается сегментация, атрибуция и любые триггеры.
Что должно быть в базе:
— стабильный event taxonomy: одно действие = одно имя
— обязательные свойства: user_id, anonymous_id, timestamp, source
— единые справочники для country, currency, product_id, channel
— понятная логика merge: когда anonymous становится known, кто кого склеивает
Identity resolution — это не магия, а набор правил. Если склеивать профили по email без контроля, можно объединить двух разных людей после семейной почты или ошибочного ввода. Если же тянуть только device_id, потеряете связность между вебом, приложением и CRM. Нужен баланс: жёсткие ключи, приоритеты, журнал merge-операций.
Activation тоже часто ломают сами. В reverse-ETL нельзя слать в рекламные и CRM-каналы «сырой» профиль без фильтрации: сначала нормализация, дедупликация, проверка свежести, потом синк. Иначе CDP превращается в дорогой ретранслятор ошибок 🧩
Если хотите, чтобы CDP работала годами, начинайте не с интеграций, а с контракта на события и правил склейки профиля.
CDP & Data для D2C
@cdp_data_desk
CDP не спасает, если у вас кривой event-схематоз и мёртвая identity graph
Этот пост опубликован в Telegram-канале CDP & Data для D2C. Подписаться можно по ссылке: @cdp_data_desk.