Identity resolution ломается не в CDP, а в схеме: 5 ошибок, которые склеивают чужие люди

Identity resolution ломается не в CDP, а в схеме: 5 ошибок, которые склеивают чужие люди

Если у вас есть email, phone, device_id и customer_id, это ещё не “единый профиль”. Склейка работает только когда у каждого идентификатора понятна роль: что считается первичным, что временным, а что вообще нельзя использовать как ключ.

Самые частые провалы:
— телефон используют как главный ключ, хотя он меняется и переходит между людьми;
— anonymous_id живёт отдельно от logged-in user_id, и путь пользователя рвётся;
— один и тот же email создаёт несколько профилей из-за разных источников;
— события приходят без стабильного timestamps, и merge-логика выбирает не тот профиль.

Нормальная схема начинается с правил, а не с тулзы: определите source of truth для customer_id, задайте приоритет идентификаторов, опишите дедупликацию и TTL для anonymous-данных. И отдельно проверьте, что merge можно откатить или хотя бы отследить, иначе одна плохая интеграция испортит всю базу. 🧩

Перед запуском прогоните 3 сценария: гостевой визит → логин, смена устройства, повторная регистрация на тот же email. Если в каждом из них профиль остаётся тем же человеком, а не “сборной солянкой”, identity resolution у вас хотя бы не вредит.