UID 2.0 полезен не всем: где он реально помогает, а где только усложняет стек
UID 2.0 — это не «замена всем идентификаторам», а один из вариантов first-party ID для связки показов и конверсий. В арбитражном стеке он имеет смысл там, где есть стабильный логин, согласие на передачу хэша и понятный путь от клика до события. Без этого UID превращается в ещё один nullable field в схеме.
Практически его стоит рассматривать в таких местах:
— веб-продукты с авторизацией и регулярными возвратами;
— подписки, где пользователь часто входит в аккаунт;
— экосистемы с одним и тем же ID между сайтами/приложениями.
Если у вас короткий цикл покупки, много анонимного трафика и конверсия часто происходит без логина, ROI от внедрения UID 2.0 обычно слабый. Для таких кейсов чаще полезнее довести до ума fbp/fbc, event_id, email_hash, phone_hash и server-side IP/UA. UID 2.0 не чинит плохую базовую разметку.
Главная ошибка — пытаться подать UID 2.0 как универсальный match key везде. Правильнее хранить его как отдельный слой identity, не смешивая с рекламными ключами, и тестировать прирост на конкретных событиях: login, subscribe, purchase. Если прироста нет в match rate или deduplication, в проде ему делать нечего.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
UID 2.0 полезен не всем: где он реально помогает, а где только усложняет стек
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.