UID 2.0 в арбитражном стеке: где он помогает, а где просто съедает время

UID 2.0 в арбитражном стеке: где он помогает, а где просто съедает время

UID 2.0 нужен не «для галочки», а когда у вас есть first-party flow: логин, подписка, lead form, checkout. Тогда токен можно связать с событием и использовать как стабильный идентификатор между рекламной платформой, CDP и sGTM.

Что обычно внедряют:
— capture UID на стороне формы/аккаунта и передача в server-side endpoint;
— маппинг UID ↔ internal user_id в защищённом хранилище;
— отправка в CAPI/Events API только там, где это поддержано схемой;
— отдельная логика для deduplication, чтобы UID не заменял event_id.

Где UID 2.0 полезен:
— меньше потерь, чем у cookie, если пользователь авторизуется;
— проще связывать конверсии между устройствами;
— удобен для чистки дублей в long conversion window.

Где он не спасает:
— если у вас нет логина или устойчивого first-party идентификатора;
— если UID живёт только в браузере и не уходит в server-side;
— если его пытаются использовать как замену email_hash/phone_hash в CAPI.

Правило простое: UID 2.0 — это слой identity, а не трекинг-магия. Сначала стройте нормальный event_id, server-side передачу и hash-based match keys, а UID добавляйте как усилитель там, где есть реальный авторизованный пользователь.