<b>Pre-bid filtering: где именно в цепочке рождается решение о fraud</b>

<b>Pre-bid filtering: где именно в цепочке рождается решение о fraud</b>

Проблема не в одном «антифроде», а в нескольких точках отсечения. До аукциона обычно смотрят на sellers.json, ads.txt/app-ads.txt, domain/app bundle, device/geo mismatch, invalid traffic сигналы, а также на качество supply path. Если флаг ставится поздно, вы уже платите за мусорный bid stream.

Разделяйте уровни:
— Supply-level: режем заведомо плохие площадки, резолвы домена, невалидные bundle ID, подозрительные resellers.
— Request-level: фильтруем по IP/UA/device, spoofing, аномальным частотам запросов, consent/IFA пустым там, где это не бьёт по логике инвентаря.
— Auction-level: понижаем участие там, где bid request выглядит чисто, но path слишком длинный или source не бьётся с inventory owner.

Ключевая ошибка — смешивать блокировку и скоринг. Блокировка нужна для жёстких нарушений, скоринг — для серых зон, где полезнее урезать bid rate, чем убивать fill. Иначе антифрод начинает ломать нормальный трафик, особенно в long-tail инвентаре.

Практика для Prebid/GAM простая: держите отдельные правила на уровне SSP, publisher-side filtering и post-bid verification. Тогда можно понять, где именно падает quality: в source, в request или уже в ответе bidder.

Ищите fraud не «в целом по стеку», а по точке принятия решения: чем раньше отсечение, тем меньше waste и меньше ложных банов.