Privacy Sandbox ломает не таргетинг, а привычку полагаться на один идентификатор
Ключевая ошибка в интеграциях — искать «замену third-party cookie» как один API. В post-cookie стекe это набор механик: Topics для контекстных интересов, Protected Audience для аукциона без раскрытия аудитории, Attribution Reporting для измерения конверсий, CHIPS для изоляции cookie по топ-уровню.
Для SSP и DSP важно разделить сигналы по месту использования:
— до биддинга: контекст, first-party данные, consent;
— в аукционе: cohort/interest-сигналы только если они доступны в текущем браузере;
— после конверсии: агрегированная атрибуция вместо user-level path.
Если смешать эти слои в одном пайплайне, получите дубли, пустые key-value и ложные отчеты.
Интеграция обычно ломается в трёх местах: не проверяют, какой сигнал реально доступен в браузере; не ставят fallback на first-party context; ждут от новых API привычной точности user-level ремаркетинга. В programmatic это лечится не «магией», а явным routing: отдельная ветка для bidding, отдельная — для measurement, отдельная — для fallback.
Практика простая: сначала опишите, какой decision принимает каждый сигнал, потом маппьте его в OpenRTB/Prebid слой, и только после этого трогайте UX баннера и consent flow. Если архитектура собрана правильно, post-cookie стек не заменяет ваш pipeline, а только меняет источник входных данных.
AdTech Pulse — SSP / DSP / OpenRTB
@adtech_pulse_aff
Privacy Sandbox ломает не таргетинг, а привычку полагаться на один идентификатор
Этот пост опубликован в Telegram-канале AdTech Pulse — SSP / DSP / OpenRTB. Подписаться можно по ссылке: @adtech_pulse_aff.