<b>Identity resolution ломается не в CDP, а в вашей схеме ключей и событий</b>
Если у вас email, phone, user_id и cookie живут отдельно — CDP не “магически” соберёт человека. Он склеит только то, что вы сами дали: стабильный primary key, понятные alias-события и одинаковые правила записи везде.
Для D2C-стека минимальный набор такой:
— anonymous_id до логина;
— user_id после авторизации;
— email/phone как traits, а не как ключи;
— событие identify только при реальном появлении новой связи.
Если identify вызывается на каждом чихе, вы получаете мусорные дубли и ложные связи.
Самая частая ошибка — менять идентификатор по пути: в вебе один формат, в CRM другой, в app третий. Тогда одна и та же персона распадается на несколько профилей, а reverse-ETL начинает лить сегменты в рекламу с перекосом. Ещё хуже — когда один device_id используют как замену человеку: это работает только до первой переустановки, очистки cookie или смены устройства.
Проверка простая: возьмите 10 реальных пользователей и руками пройдите их путь от первого визита до покупки. Если у одного человека больше двух профилей, а у двух разных людей один профиль — у вас проблема не в attribution, а в identity graph.
Сначала нормализуйте ключи и события, потом уже стройте сегменты и активацию. Иначе вы автоматизируете путаницу, а не customer data.
CDP & Data для D2C
@cdp_data_desk
<b>Identity resolution ломается не в CDP, а в вашей схеме ключей и событий</b>
Этот пост опубликован в Telegram-канале CDP & Data для D2C. Подписаться можно по ссылке: @cdp_data_desk.