UID 2.0 в арбитражном стеке — не замена CAPI, а слой для связки first-party идентификаторов

UID 2.0 в арбитражном стеке — не замена CAPI, а слой для связки first-party идентификаторов

UID 2.0 полезен там, где у вас есть собственная аудитория: login, подписка, CRM-база, повторные визиты. Он не «чинит» потерянные клики сам по себе, а помогает передавать единый идентификатор между сайтом, DSP и партнёрами в форме, пригодной для матчинг-сценариев.

Что важно в стеке:
— соберите consent и нормальный first-party flow до хеширования;
— храните исходный user ID отдельно от рекламных хешей;
— используйте UID 2.0 вместе с email_hash/phone_hash, а не вместо них;
— закладывайте fallback: fbp/fbc, click_id, external_id, server IP/UA.

Где он даёт эффект: ретаргет по логин-аудитории, частотный контроль между площадками, связка web ↔ app ↔ CRM, более стабильный матчинг в системах, где ID принимается как входной сигнал. Где не даёт: холодный трафик без first-party базы, лендинги без авторизации, кампании, завязанные только на post-click атрибуцию.

Анти-кейс простой: если пытаться строить UID 2.0 как единственный ключ, вы упрётесь в покрытие. Правильная схема — сначала нормализовать first-party данные, потом добавить UID 2.0 как дополнительный идентификатор в маршрутизации и deduplication.

Итог: UID 2.0 в арбитраже нужен не «для замены cookies», а для усиления стека там, где у вас уже есть собственный идентификатор пользователя.