3 проверки, без которых third-party cookies ломают сегментацию и атрибуцию

3 проверки, без которых third-party cookies ломают сегментацию и атрибуцию

Если cookie-логика в DSP/SSP начала «плыть», сначала проверь не таргетинг, а цепочку идентификаторов. Типовые точки отказа:
— cookie читается только в first-party контексте, а матчинг ожидали как в third-party;
— домен выставления и домен чтения не совпадают по атрибутам cookie;
— в запросе есть redirect-цепочка, но id теряется на одном из hop’ов.

Дальше смотри на поток OpenRTB: какой id реально уходит в bid request, как он маппится на user-sync и не подменяется ли на уровне обмена. Для валидации полезно сравнить: raw request, cookie-sync, auction log и postback/конверсию. Если хотя бы один слой использует другой namespace, атрибуция распадается без ошибки в логах.

Ещё одна частая ловушка — ожидание, что один и тот же cookie будет одинаково доступен в webview, браузере и embedded окружениях. На практике это разные контексты с разной политикой хранения и доступа. Поэтому сегменты лучше строить не на «наличии cookie вообще», а на явно проверяемом идентификаторе с fallback-логикой.

Если коротко: сначала инвентаризируй, где именно живёт идентификатор, потом проверь, как он проходит sync и auction, и только после этого трогай алгоритмы таргетинга.