Frequency capping cross-platform ломается не в DSP, а в идентичности и окне синхронизации

Frequency capping cross-platform ломается не в DSP, а в идентичности и окне синхронизации

Если у вас web, in-app и CTV живут отдельно, cap превращается в три разных счётчика. Без общего ключа пользователя вы ограничиваете показы только внутри канала, а не на уровне всей воронки. Поэтому сначала фиксируйте identity graph: deterministic ID, fallback-ключ, TTL и правило, кто считается одним пользователем.

Технически схема простая:
— единый cap-store с атомарным increment/read;
— ключ счёта: user_id + campaign_id + geo + device_class;
— окно: rolling 24h, dayparting или lifetime, но одно на весь стек;
— синхронизация через server-side endpoint, а не только в client-side SDK.

Главная ошибка — ставить cap на стороне источника трафика и считать, что он переживёт ретаргетинг, SSP-роутинг и повторный заход с другого устройства. Если нет общего storage layer, делайте двухуровневую модель: local cap для мгновенного отсечения и global cap для финального решения в auction/bidder logic. Иначе вы либо недокрутите reach, либо начнёте каннибализировать частоту в самых дорогих сегментах.

Проверяйте ещё одну вещь: дедупликацию событий. Impression, render и win notice не должны увеличивать frequency одинаково. Иначе cap «съедается» на уровне логов, а не реальных показов.

Если cap нельзя собрать в один контур, хотя бы нормализуйте ключи и окна. Иначе cross-platform frequency capping остаётся не ограничением частоты, а набором несвязанных локальных правил.