<b>Privacy Sandbox ломает не таргетинг, а старую привычку мерить аудиторию по одному идентификатору</b>
В post-cookie интеграции ключевой вопрос не «чем заменить cookie», а какие сигналы реально доступны в цепочке SSP → DSP → браузер. Для программатик-стека это обычно 4 слоя: контекст страницы, first-party данные, агрегированные API браузера и server-side события. Если смешать их без правил, матчинг и атрибуция начинают дублировать сами себя.
Проверьте, что у вас разделены:
— идентификация пользователя и измерение конверсии;
— decisioning в DSP и отчётность в аналитике;
— запросы на уровне pageview и on-device сигналы;
— инвентарь, где можно использовать contextual, а где нужен чистый fallback без персонализации.
Для интеграции важно не искать один «универсальный» endpoint. Лучше строить fallback-цепочку: сначала first-party контекст и consented signals, затем агрегированные браузерные механики, затем чистый contextual bidding. Тогда SSP не теряет запрос, а DSP не переоценивает качество трафика из-за отсутствия ID.
Главная ошибка — пытаться сохранить старую user-level логику и просто подставить новый источник сигнала. В post-cookie мире выигрывает не тот, у кого больше данных, а тот, у кого аккуратнее разведены source of truth, окна атрибуции и правила дедупликации.
AdTech Pulse — SSP / DSP / OpenRTB
@adtech_pulse_aff
<b>Privacy Sandbox ломает не таргетинг, а старую привычку мерить аудиторию по одному идентификатору</b>
Этот пост опубликован в Telegram-канале AdTech Pulse — SSP / DSP / OpenRTB. Подписаться можно по ссылке: @adtech_pulse_aff.