Third-party cookies ломаются не в браузере, а в вашей архитектуре идентификации

Third-party cookies ломаются не в браузере, а в вашей архитектуре идентификации

Если у вас один и тот же user_id живёт в cookie, пикселе, логе SSP и CRM, отказ от third-party cookie бьёт по связке целиком. Первая ошибка — держать cookie как единственный key для frequency capping, атрибуции и сегментации.

Проверьте цепочку:
— где создаётся ID;
— где он матчится с publisher/user graph;
— где TTL у идентификатора короче, чем окно конверсии;
— что происходит при отсутствии cookie: fallback на first-party, hashed email, contextual, cohort.

Для DSP и SSP важен не сам факт потери cookie, а деградация в каждом шаге OpenRTB: меньше матчинга, слабее дедупликация, хуже контроль частоты, больше расхождение между impression и conversion logs. Отдельно проверьте, не завязан ли таргетинг на client-side события, которые не переживают ограничение доступа к storage.

Минимальный чек-лист для интеграции: first-party ID на своём домене, server-side sync, явный приоритет источников идентичности, раздельные стратегии для prospecting и retargeting, мониторинг доли unmatched traffic.

Если у вас есть план миграции, начинайте не с замены cookie, а с инвентаризации всех мест, где она используется как “истина”.