<b>Кросс-девайс атрибуция ломается там, где client-side видит только один экран</b>

<b>Кросс-девайс атрибуция ломается там, где client-side видит только один экран</b>

Когда пользователь начал путь на телефоне, а купил с ноутбука, Pixel и GA4 часто собирают два отдельных фрагмента. Server-side ID нужен не для «магии», а чтобы связать события в один контур: login_id, hashed email, customer_id, CRM user_id — если они реально стабильны между сессиями.

Базовый паттерн такой:
— на сайте генерируете first-party identifier и кладёте в cookie;
— при логине маппите его на внутренний user_id;
— в sGTM прокидываете этот ID в CAPI / Enhanced Conversions / аналитику;
— при всех дальнейших событиях используете один и тот же ключ.

Важно не путать ID для атрибуции и PII. Email и phone хешируются, а сам server-side ID должен быть бессмысленным токеном без прямой расшифровки. Иначе вы строите не трекинг, а лишний риск. Ещё один частый провал — разные ID в разных поддоменах, из-за чего кросс-девайс склейка разваливается на уровне источника.

Проверка простая: один и тот же пользователь должен получать одинаковый server-side ID после авторизации, а события Purchase / Lead должны уходить с тем же идентификатором и в вебе, и в сервере. Если ID меняется при каждом визите, у вас нет атрибуции, есть набор несвязанных хитов.

Практика одна: сначала стабилизируйте identity layer, потом уже оптимизируйте EMQ и deduplication.