<b>Privacy Sandbox: 6 вещей, которые нужно проверить в DSP и SSP до отключения cookie</b>
Если у вас есть user matching, frequency capping или атрибуция на уровне пользователя, проверьте, где именно они завязаны на third-party cookies. В Privacy Sandbox часть сигналов уходит в Topics, Protected Audience и Attribution Reporting, а значит старые цепочки «id → audience → bid → conversion» надо разбирать по слоям.
1) Идентификатор. Отделите login-based ID, first-party cookie и device signals. Не смешивайте их в одной логике выбора аудитории.
2) Аукцион. Проверьте, умеет ли bidder жить без стабильного кросс-сайтового user graph.
3) Частота. Перенесите frequency capping на first-party или server-side хранилище.
4) Отчётность. Сравните postback, агрегированные конверсии и event-level логи: они дадут разные срезы.
Для SSP отдельный риск — слишком агрессивный падение fill rate, если demand всё ещё ждёт старый user sync. Для DSP — переоценка reach: без кросс-сайтовой связки одно и то же лицо будет выглядеть как несколько разных пользователей.
Лучший чек-лист простой: найдите все места, где cookie используются не как транспорт, а как источник истины. Именно их и надо переделывать первыми.
AdTech Pulse — SSP / DSP / OpenRTB
@adtech_pulse_aff
<b>Privacy Sandbox: 6 вещей, которые нужно проверить в DSP и SSP до отключения cookie</b>
Этот пост опубликован в Telegram-канале AdTech Pulse — SSP / DSP / OpenRTB. Подписаться можно по ссылке: @adtech_pulse_aff.