Кросс-девайс атрибуция через server-side ID: как не потерять пользователя между устройствами

Кросс-девайс атрибуция через server-side ID: как не потерять пользователя между устройствами

Если у пользователя один и тот же email/phone/логин встречается на сайте, в приложении и в CRM, server-side ID становится опорной точкой для склейки. Без него вы видите три разрозненных пути: клик на десктопе, возврат с мобайла и покупку из другого браузера.

Рабочая схема такая:
— на входе нормализуете идентификатор: lowercase, trim, E.164 для телефона;
— хешируете SHA-256 до отправки в CAPI / Events API;
— связываете event_id, external_id, fbp/fbc и internal_user_id в серверной таблице;
— не используете один ID как единственный ключ: нужен набор сигналов, иначе матчинг будет рваться.

Критичный момент — дедупликация и окна связи. Если один и тот же purchase пришёл из web, app и server, у всех событий должен быть общий event_id или строгая логика приоритета. Иначе вы не «улучшите атрибуцию», а просто задвоите конверсии.

Проверьте ещё два места: login/session stitching в момент авторизации и мэппинг CRM ID → analytics ID. Именно там обычно теряются цепочки между устройствами. Если сервер видит пользователя раньше клиента, сохраняйте first_seen и last_seen отдельно.

Практика простая: сначала стройте таблицу соответствий ID, потом уже под неё подключайте CAPI, app events и warehouse. Когда серверный ключ стабилен, кросс-девайс отчётность перестаёт зависеть от cookies и становится воспроизводимой.