Privacy Sandbox для SSP/DSP: 6 полей, которые ломают matching и атрибуцию

Privacy Sandbox для SSP/DSP: 6 полей, которые ломают matching и атрибуцию

Ключевая ошибка — ждать, что sandbox заменит cookie один-в-один. В programmatic меняется не один сигнал, а связка: идентификатор, контекст, consent, storage и отчетность. Если хотя бы один слой не согласован, растут расхождения между bid request, click/cookie sync и post-impression логикой.

Проверьте интеграцию по чек-листу:
— ID: есть ли fallback на first-party и hashed login-based идентификаторы
— Context: передается ли page/app context без потери жанра, URL и placement
— Consent: одинаково ли читаются TCF/GPP/локальные флаги на стороне SSP и DSP
— Storage: не полагается ли логика на third-party write/read
— Measurement: не смешиваются ли attributed conversions и modeled conversions
— Dedup: есть ли единый ключ для склейки web, in-app и server-to-server событий

Для байера главный риск — переоценить reach и undervalue частоту. Для паблишера — потерять наполняемость, если слишком жестко резать сигналы до того, как настроены альтернативные идентификаторы и contextual таргетинг. Поэтому сначала сравнивают fill, win rate и match rate, потом уже меняют правила оптимизации.

Если у вас есть one-pager по интеграции, держите его как контракт между продуктом, dev и трейдингом: какие сигналы обязательны, какие optional, где fallback, и кто отвечает за деградацию качества. Именно такая схема переживает пост-cookie переход без сюрпризов.