Frequency capping ломается не в UI, а в stitch-id, TTL и разных источниках импрессий
Если cap живёт отдельно в DSP, отдельно в SSP и ещё в ad server, вы считаете не frequency, а три несвязанных счётчика. Для cross-platform нужен единый ключ: user_id, household_id или устойчивый graph-id. Если его нет — cap будет работать только внутри одного канала и легко обходиться переходом web → in-app → CTV.
Технически схема обычно такая:
— событие impression летит в event stream с ключом и timestamp;
— сервис cap хранит окно: per user / per campaign / per creative;
— на bid request или ad request идёт lookup: можно ли ещё показывать;
— ответ должен учитывать timezone, device class и reset window.
Критичные точки поломки:
• разные TTL для cookies, MAID и login-based ID;
• дубли импрессий без dedupe key;
• race condition между impression и следующим bid request;
• несинхронные окна cap в паблишерском и DSP-слое ⚙️
Если нужен стабильный cap, делайте его stateful вне медиасервера: Redis/KeyDB для online-check, Kafka/queue для ingest, а в логах храните idempotency key. Иначе любой ретрай, delayed win notice или server-side prerender дадут лишний показ.
Итог простой: cross-platform cap — это не правило в интерфейсе, а согласованный state machine на уровне идентичности, времени и дедупликации.
Programmatic Deep — RTB и header bidding
@programmatic_deep
Frequency capping ломается не в UI, а в stitch-id, TTL и разных источниках импрессий
Этот пост опубликован в Telegram-канале Programmatic Deep — RTB и header bidding. Подписаться можно по ссылке: @programmatic_deep.