Identity resolution ломается не в CDP, а в плохом наборе ключей и правил склейки

Identity resolution ломается не в CDP, а в плохом наборе ключей и правил склейки

Если у вас нет единого правила, кто такой user, customer, lead и device, CDP быстро превращается в склад дубликатов. Базовый набор ключей обычно такой: email, phone, user_id, device_id, order_id. Но важен не список сам по себе, а приоритет: какой ключ главный, какой вспомогательный, и что делать, если они конфликтуют.

Самая частая ошибка — склеивать всё подряд по любому совпадению. Так вы получаете «чужие» покупки, сломанные сегменты и ретаргет по людям, которые уже давно не те. Второй провал — считать email вечным идентификатором: один человек может иметь несколько ящиков, а один ящик — нескольких владельцев в семье или в команде.

Рабочая схема обычно простая: сначала deterministic match по сильным ключам, потом аккуратный merge по цепочке событий. Если confidence ниже порога — не объединяйте профили, а храните связь как candidate link. Отдельно фиксируйте правила для guest checkout, смены устройства, офлайн-покупок и возвратов. 🧩

Перед запуском проверьте три вещи: есть ли поле источника истины, можно ли откатить merge, и как система ведёт себя при конфликте атрибутов. Если эти ответы мутные, activation будет врать даже при идеальном трекинге. Сначала опишите правила склейки на бумаге, потом уже тащите их в CDP.