Identity resolution ломается не в CDP, а в трекинге: 5 мест, где теряются связи

Identity resolution ломается не в CDP, а в трекинге: 5 мест, где теряются связи

Если user_id, email и device_id живут в разных событиях без единой логики, CDP не «склеит магию» — она просто унаследует мусор. Identity resolution работает только когда вы заранее решили, какой идентификатор главный, в каком событии он появляется и когда его можно считать стабильным.

Проверьте базовые правила:
• один canonical ID для CRM и активации;
• отдельная логика для anonymous → known;
• не менять identity в середине сессии;
• не полагаться на email как на единственный ключ;
• хранить link events, а не только итоговый профиль.

Самая частая ошибка — отправлять в activation уже «собранный» профиль, не сохранив путь склейки. Через месяц никто не сможет объяснить, почему один и тот же человек то новый, то существующий, то дубликат. Для reverse-ETL это особенно больно: плохая склейка превращает сегменты в лотерею.

Ещё одна ловушка — разные системы видят одного человека по-разному. В аналитике он anonymous, в CRM — known, в рекламном кабинете — hashed email. Если не прописать mapping между этими состояниями, вы получите красивую дашборд-ложь и кривую персонализацию.

Правило простое: сначала схема идентичности, потом CDP. Иначе любой «умный» стек будет аккуратно масштабировать вашу путаницу.