<b>Pre-bid filtering: где именно в цепочке решается, пустить ли трафик в аукцион</b>

<b>Pre-bid filtering: где именно в цепочке решается, пустить ли трафик в аукцион</b>

Fraud-решение не живёт в одном месте. В нормальном стеке фильтрация расползается по трём уровням: до отправки bid request, на уровне SSP/Exchange и уже в post-bid верификации. Если смотреть только на один слой, легко перепутать GIVT с техническим шумом или пропустить SIVT, который проходит через слишком мягкий pre-bid rule set.

На практике pre-bid фильтруют по сигналам: ads.txt / sellers.json, domain/app consistency, geo/device mismatch, подозрительный user-agent, аномальный supply chain, пустые referrer’ы, кривой bundleId / app-ads.txt. Это не “антифрод-модуль”, а gatekeeper: он решает, попадёт ли impression в bid stream вообще. Чем раньше отсечёте мусор, тем меньше платите за лишние bid responses и меньше раздуваете отчётность.

Важно не смешивать роли: publisher-side wrapper может резать трафик по качеству инвентаря, SSP — по своим риск-скорингам, DSP — по bid shading, частоте и IVT-сигналам, а vendor вроде IAS/MOAT — подтверждать уже после факта. Если все решения свалены в один отчёт, вы не увидите, где именно теряется win rate и кто реально заблокировал supply.

Рабочая схема простая: логируйте причину отклонения на каждом хопе, держите отдельные правила для домена, app, device и seller chain, а спорные сегменты выносите в отдельный allowlist/denylist review. Тогда можно быстро понять, это плохой supply, слишком агрессивный фильтр или ошибка в атрибуции инвентаря.

Итог: pre-bid filtering нужен не для “максимального банна”, а для точного разделения шума, риска и нормального inventory.