<b>Identity resolution ломается не в матчинге, а в грязной схеме событий и дублях ключей</b>

<b>Identity resolution ломается не в матчинге, а в грязной схеме событий и дублях ключей</b>

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

Правила, которые спасают стек:
— один primary key на профиль, остальные — secondary identifiers;
— событие может приходить без user_id, но не без стабильного anonymous_id;
— merge делаем только по детерминированным связкам, а не по “похожим” данным;
— после login/checkout нужен явный link между anonymous и known user, иначе история расползётся.

Самая дорогая ошибка — разрешить нескольким системам создавать “нового клиента” по одному и тому же человеку. Тогда CRM, CDP и аналитика начинают спорить, кто владелец профиля, а атрибуция превращается в лотерею. Ещё один частый косяк: менять формат идентификатора на стороне отправителя без миграции старых событий.

Проверка должна быть скучной: один и тот же человек открывает сайт, логинится, делает заказ, возвращается с нового устройства — профиль должен слиться в один, а не плодить три сущности. Если это не проходит на тестовых сценариях, на проде будет только хуже.

Сначала зафиксируйте правила идентичности, потом подключайте активацию. Иначе вы просто ускорите распространение мусора по всем системам.