Identity resolution ломается не в CDP, а в схеме: 5 проверок до запуска

Identity resolution ломается не в CDP, а в схеме: 5 проверок до запуска

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

Первый фильтр — стабильность ключей. Email меняется, телефон тоже, device_id живёт своей жизнью. Если в качестве master-key выбрать нестабильный атрибут, то вы сами создадите дубли и потом будете “чистить” их через сегменты и ручные таблицы.

Второй фильтр — события привязки. Логин, регистрация, checkout, подписка должны писать link-события одинаково и без пропусков. Если часть фронта шлёт user_id, а часть — только cookie, CDP начнёт собирать разные деревья для одного человека. Третий фильтр — окно склейки: не объединяйте профили только потому, что совпал один контакт; нужен набор правил и приоритетов 🔧

Четвёртый фильтр — обратимость. Любая склейка должна быть объяснима: почему профиль объединили, какой source победил, какой идентификатор был заменён. Иначе reverse-ETL разнесёт грязь по CRM, почте и рекламным аудиториям.

Если коротко: сначала проектируйте правила identity, потом подключайте каналы. Иначе CDP будет не источником истины, а фабрикой дорогих дублей.