<b>Frequency capping cross-platform ломается не в DSP, а на уровне identity, sync и storage</b>

<b>Frequency capping cross-platform ломается не в DSP, а на уровне identity, sync и storage</b>

Если cap должен работать между web, in-app и CTV, одного cookie/pixel мало. Нужен единый key: UID2, RampID, ID5 или собственный graph, а рядом — deterministic rules для fallback. Иначе один и тот же пользователь будет считаться разными анонимами в каждом канале.

Технически схема обычно такая:
— request-time: на входе в bidder/SSP считаем effective user key и кладём в request context
— decision-time: перед bid/serve проверяем cap в low-latency store
— delivery-time: пишем impression event в общий event bus и обновляем счетчик

Важно разделять scope: per-campaign, per-creative, per-device, per-household. Ошибка — хранить один глобальный counter: тогда mobile и desktop начинают взаимно «душить» частоту, а ретаргетинг теряет объём.

Хранилище должно быть быстрым и предсказуемым: Redis cluster, key-value с TTL, либо streaming join через Kafka/Flink. Для online-check нужен O(1) lookup, для reconciliation — батчевый пересчёт по логам. Обязательно закладывайте окна дедупликации и защиту от race condition между bid win и impression.

Если cap не склеен между платформами, вы видите красивый reach, но получаете переэкспозицию. Начинайте не с правил частоты, а с идентичности, схемы ключей и точки, где именно фиксируется факт показа.