Identity resolution ломает всю CDP, если строить его на одном email и надежде

Identity resolution ломает всю CDP, если строить его на одном email и надежде

В D2C и арбитраже у одного человека обычно несколько следов: браузер, app, CRM, support, покупки, подписки. Если не собрать их в один профиль, вы получите дубли, кривую атрибуцию и «мертвые» сегменты, которые невозможно активировать.

Базовая схема простая: у события должен быть стабильный anonymous_id до логина, user_id после логина и набор внешних ключей — email_hash, phone_hash, loyalty_id, order_id. Связывать профили нужно не по одному полю, а по правилам приоритета: login > payment > verified contact > device. Иначе один и тот же человек распадется на три сущности.

Главные грабли:
— не менять user_id при каждом новом источнике данных;
— не склеивать профили только по email, если email не подтвержден;
— не затирать старый identity link без audit trail;
— не давать reverse-ETL пушить в CRM «полупрофили» без проверки качества.

Проверка должна ловить три вещи: коллизии, дубли и orphan events. Если событие не привязалось ни к одному профилю — это не «нормальная потеря», а будущий мусор в отчетах и триггерах. Лучше сначала настроить merge rules и дедупликацию, потом уже строить аудитории и автоматизации.

Если identity resolution не объясняется на одной странице схемы, команда почти наверняка будет чинить его уже после того, как сломает retention и ремаркетинг.