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

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

Если пользователь кликает рекламу с телефона, а покупает с ноутбука, fbp/fbc и client_id часто живут в разных браузерах. Server-side ID нужен как мост: не вместо consent и не вместо пикселя, а как first-party ключ, который одинаково попадает в CRM, sGTM и CAPI.

Минимальный паттерн:
— при логине/лиде создаём user_key из внутреннего customer_id или email;
— нормализуем значение: trim, lowercase, phone в E.164;
— хешируем SHA-256 до отправки наружу;
— raw ID держим только в backend/CRM;
— один и тот же external_id передаём в Pixel, CAPI и Events API.

В sGTM важно не генерировать новый ID на каждый hit. Client должен читать ID из auth-сессии, server cookie или payload от backend. Если ID появился после логина, связывайте последующие события, но не «дописывайте» его задним числом без понятного правила атрибуции.

Проверка: доля событий с external_id, совпадение event_id для dedup, EMQ по Purchase/Lead, разрыв между logged-in и guest checkout.

Вывод: кросс-девайс начинается не в рекламном кабинете, а в модели идентификаторов. Один стабильный first-party ID лучше набора случайных cookies.