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

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

Если user виден в web, app и CTV, один и тот же cap нельзя считать по разным ключам. Нужен общий keyspace: uid, household_id, device_graph_id или связка через server-side profile. Иначе один человек получит 3–5 показов на каждом канале и вы увидите «нормальный» frequency report вместо дублей.

Технически cap делается на трёх слоях:
— pre-bid: отсекаем уже exhausted users до запроса в bidder;
— decisioning: храним счётчик в low-latency store с TTL по окну cap;
— post-impression: атомарно инкрементим счётчик после win notice / impression ping.

Критично выбрать семантику окна: rolling 24h, calendar day, campaign lifetime или session cap. Для cross-platform чаще нужен rolling window, иначе midnight reset даёт ложный refresh. TTL должен совпадать с логикой отчётности, а не с удобством backend-команды. ⏱️

Если нет стабильного ID, cap строят через probabilistic graph, но тогда обязательно вводят confidence threshold и fallback: лучше недокапить, чем перекапить premium inventory. Для publisher-side stack полезно держать отдельные caps на advertiser, campaign, creative и household.

Практика простая: сначала нормализуйте идентификатор, потом окно, потом атомарность записи. Пока эти три слоя не совпали, cross-platform frequency capping будет выглядеть как working setup и давать утечки в delivery.