Identity resolution ломают не event'ы, а слабые правила склейки профиля

Identity resolution ломают не event'ы, а слабые правила склейки профиля

Если у вас один и тот же человек живёт как guest, email-user и app-user — CDP не “угадает” его магически. Склейка держится на источниках идентификатора и приоритетах: login_id, email_hash, phone_hash, device_id, cookie_id. Без этого один заказ уходит в один профиль, возврат — в другой, а LTV и сегменты начинают врать.

Что обычно должно быть в правилах:
— какой ID считается первичным;
— какие связи разрешены: deterministic только, или ещё probabilistic;
— как долго живёт anonymous-профиль;
— что делать при конфликте: merge, overwrite, keep both.

Самая дорогая ошибка — склеивать по любому совпадению. Один общий email на семью, один девайс у менеджера, пересечение по телефону в CRM — и вы получаете “суперпрофиль” из чужих покупок, писем и отказов. После этого ретаргет бьёт мимо, а триггеры в lifecycle-цепочках начинают сыпать не тем людям.

Проверка простая: берёте 20 реальных кейсов и вручную смотрите цепочку идентификаторов от первого визита до оплаты. Если в логике есть дыры, сначала чините схему событий и правила merge, а уже потом настраивайте activation в CRM и ads. Иначе любая CDP будет просто красивым слоем поверх мусора.