Identity resolution ломают не ID-шники, а грязные правила склейки событий и людей

Identity resolution ломают не ID-шники, а грязные правила склейки событий и людей

В CDP identity resolution — это не «угадать, кто есть кто», а аккуратно собрать один профиль из кусков: anonymous_id, user_id, email, phone, device_id. Если правило слишком агрессивное, вы склеите разных людей в один профиль и испортите сегменты, триггеры и атрибуцию.

Базовый набор правил обычно такой:
— сначала deterministic match: login, email, phone;
— потом приоритет источника: CRM > app > web > ad click;
— отдельно хранить identity graph, а не переписывать сырой event stream;
— не склеивать по имени, городу или IP как по основному ключу.

Самая дорогая ошибка — backfill без контроля. Когда вы догружаете историю, старые anonymous события внезапно «переезжают» к новому user_id, и ретеншн, LTV и цепочки welcome-сценариев начинают врать. Поэтому для каждого правила нужен флаг confidence и журнал: почему профиль был объединён, когда, по какому ключу.

Проверка простая: возьмите 20 реальных профилей, вручную разберите, где у человека один девайс, где несколько, где shared email или общий телефон. Если схема не переживает такой тест, она сломается на масштабе.

Сначала проектируйте не склейку, а границы ошибки: что можно объединять, а что лучше оставить двумя профилями, чем испортить всю activation-логику.