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

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

Если cap должен работать между web, in-app и CTV, сначала фиксируйте: какой key считаем единицей пользователя — UID2, RampID, device graph, MAID или свой first-party ID. Без этого вы получите три независимых счётчика, а не один глобальный лимит.

Техническая схема простая:
— central store с TTL на уровне user_key + campaign_id + creative_id;
— atomic increment перед отдачей bid/ad decision;
— окно агрегации отдельно от окна cap: 1h, 24h, 7d не смешивать в один counter;
— fallback logic для unknown IDs: либо no-cap, либо conservative cap, но не «примерно тот же пользователь».

На стороне Prebid/SSP cap лучше считать до аукциона только для собственных direct-кампаний или deal-логики. Для open auction корректнее делать post-auction enforcement в ad server/decision engine, иначе потеряете fill на коллизиях identity. Для in-app и CTV нужен shared store, а не локальный cache SDK — иначе sync развалится при смене устройства.

Обязательная проверка: дедупликация событий показа, idempotency key на impression, и единый timezone/clock skew policy. Иначе один и тот же показ попадёт в cap дважды или «не попадёт» вообще.

Если cap cross-platform нельзя связать по identity, честнее ограничивать его на уровне канала, а не обещать глобальный контроль там, где у вас нет общего user key.