Privacy Sandbox в programmatic: 4 вещи, которые нужно проверить в интеграции
В post-cookie мире ломаются не ставки, а предположения. Если у вас в цепочке SSP → DSP → bidder всё ещё есть ожидание «пользователь = стабильный ID», начинаются расхождения в таргетинге, частотке и атрибуции.
— Проверяйте, где именно в запросе живёт сигнал: page-level context, first-party ID, cohort-like API, consent string. Не смешивайте их в один «анонимный юзер».
— Для auctions заранее разделяйте контекстный инвентарь и инвентарь с адресуемостью: разные правила по floor, frequency capping и reporting.
— Логируйте, какой сигнал был доступен на bid request и какой реально использован bidder’ом: без этого дебаг превращается в угадайку.
— Валидацию делайте на уровне цепочки: browser → publisher → SSP → DSP. Если один слой режет сигнал, downstream уже не восстановит его 🧩
Главная ошибка — строить фолбэк как «если нет ID, просто продолжим как раньше». Нужен явный decision tree: что делаем при отсутствии user signal, что при ограниченном consent, что при чисто контекстном показе.
Если у вас нет схемы деградации, privacy-safe интеграция быстро превращается в набор исключений. Лучше один раз описать матрицу сигналов и использовать её в каждом bidder / adapter / wrapper.
AdTech Pulse — SSP / DSP / OpenRTB
@adtech_pulse_aff
Privacy Sandbox в programmatic: 4 вещи, которые нужно проверить в интеграции
Этот пост опубликован в Telegram-канале AdTech Pulse — SSP / DSP / OpenRTB. Подписаться можно по ссылке: @adtech_pulse_aff.