UID 2.0 полезен не всем: где он реально закрывает дыру в арбитражном стеке
UID 2.0 — это не замена пикселю и не «новый ID для всего». В арбитражном стеке он работает там, где есть свой first-party контур и понятный consent: логин, подписка, приложение, личный кабинет, удержание. Для холодного трафика без идентифицируемого пользователя он почти бесполезен.
Что обычно делают неправильно:
— пытаются отправлять UID 2.0 вместо всех user_data;
— смешивают его с сырыми PII без нормализации;
— ждут, что он сам поднимет атрибуцию в Meta/Google.
Правильный паттерн такой: UID 2.0 хранится как отдельный идентификатор в CRM/CDP, а в sGTM уходит только после проверки разрешения и только в те каналы, где он действительно принимается. Параллельно всё равно остаются fbp/fbc, click_id, IP, UA и event_id для дедупликации.
Если стек построен на подписке, iGaming, приложении или повторных покупках, UID 2.0 помогает связать показы, клики и конверсии между сессиями и устройствами лучше, чем один лишь cookie-контур. Если же у вас одностраничный лендинг без логина, эффект будет минимальным.
Практика простая: внедряйте UID 2.0 как дополнительный key в identity graph, а не как «серебряную пулю». Тогда он усиливает CAPI и server-side трекинг, а не ломает его.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
UID 2.0 полезен не всем: где он реально закрывает дыру в арбитражном стеке
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.