Frequency capping cross-platform ломается там, где identity не склеен на уровне request path

Frequency capping cross-platform ломается там, где identity не склеен на уровне request path

Если cap нужен между web, app и CTV, одного cookie/localStorage мало. Нужен единый ключ: user_id из login graph, UID2/RampID, или хотя бы внутренний stable ID, который маппится на все устройства. Без этого каждый канал считает частоту отдельно, а пользователь видит одно и то же крео в разных поверхностях.

Техническая схема обычно такая: на входе bid request нормализуется в один user bucket; на edge или в backend лежит counter store с TTL; before-bid проверка решает, можно ли вообще отдавать impression. Для низкой латентности используют Redis / KeyDB / Aerospike, а для длинного горизонта — отдельный event log, чтобы не терять счетчики при рестарте.

Критичные детали:
— cap считается по атрибутам campaign + creative + geo + device class;
— окно cap и reset policy должны быть одинаковыми во всех каналах;
— учет показов нужен не только по win notice, но и по render/visible impression, иначе счетчик врёт;
— для offline sync держите idempotency key, иначе ретраи раздуют frequency.

Отдельная ловушка — delay между impression и обновлением counter. Если проверка делается только после показа, вы уже успеете перелить пользователя. Поэтому лучше: pre-bid read, post-impression write, периодическая reconciliation по логам. Иначе frequency capping превращается в постфактум-отчет, а не в control plane.

Итог простой: cross-platform cap работает только там, где identity, storage и event semantics собраны в одну цепочку. Если один слой выпадает, частота расползается по каналам, а вы оплачиваете лишние показы.