Frequency capping cross-platform ломается не в DSP, а в identity stitching и окнах синхронизации
Если один и тот же юзер видит креатив в web, in-app и CTV, local cap на стороне канала почти всегда даёт утечку. Нужен единый счетчик на уровне decisioning layer, где к одному audience key привязываются события impressions, clicks и conversions.
Базовая схема:
— key: UID2 / RampID / first-party id, а если его нет — stable device graph id
— storage: KV с TTL, разбитый по campaign_id + user_key + window
— sync: online write после win notice, batch reconcile для delayed logs
— policy: отдельные caps по channel, geo и creative group, а не один глобальный лимит
Критичные ошибки:
— считать только cookie в browser: app и CTV выпадут из контроля
— обновлять счетчик на win bid, а не на confirmed impression
— не учитывать dedup по event_id: ретраи логов раздувают cap
— держать разные окна в разных системах без общего clock source
Если нужен строгий cross-platform cap, делайте server-side счетчик и версионируйте policy вместе с audience key. Иначе вы ограничите не частоту контакта, а только видимость ошибки.
Programmatic Deep — RTB и header bidding
@programmatic_deep
Frequency capping cross-platform ломается не в DSP, а в identity stitching и окнах синхронизации
Этот пост опубликован в Telegram-канале Programmatic Deep — RTB и header bidding. Подписаться можно по ссылке: @programmatic_deep.