Что видят проверки pre-bid и post-bid в programmatic и какие выводы из них можно делать?

Чем pre-bid отличается от блокировки при показе и от post-bid?

В дополнении 2020 года к стандарту по обнаружению и фильтрации невалидного трафика (IVT) MRC делит методы по моменту, когда принимается решение. Ранние (up-front) срабатывают по условиям, известным во время сделки: рекламный запрос блокируют или запрос на ставку оставляют без ответа. Такое отсечение может случиться и между запросом и отдачей объявления, его MRC называет pre-serve. Поздние (back-end) применяют, когда сделка уже прошла, по оценке задним числом.

Те же три режима есть в проверке окружения рекламы, и для неё они разобраны на странице о brand safety. Здесь речь о невалидном трафике.

Что видит проверка до ставки?

Только сам запрос. Формат, в котором биржа рассылает покупателям запросы на показ, задаёт OpenRTB 2.6 организации IAB Tech Lab, и поле page там описано как адрес страницы, где показ будет, то есть показа ещё нет. Рядом стоят домен сайта или идентификатор приложения в магазине, строка user agent, IP-адрес, ближайший к устройству, рекламный идентификатор устройства, ID продавца и цепочка посредников schain. Эти значения заполняют продавец и биржи до того, как реклама где-либо открылась. Как сверить ID продавца и цепочку с файлами площадок и чего эти файлы не доказывают, показано в разборе ads.txt и sellers.json.

Биржа может добавить к запросу и метрики места: объект Metric в OpenRTB 2.6 нужен, чтобы помочь с решением о ставке, например средней недавней видимостью или CTR, а источник значения подписывают, и если это сама биржа, то словом EXCHANGE. Это оценка по прошлому трафику места, а не замер показа, которого ещё нет.

От ставки DSP отказывается молча, пустым ответом HTTP 204, или с кодом причины. В списке кодов OpenRTB есть «известный веб-краулер» (3), «подозрение на нечеловеческий трафик» (4), «заблокированный издатель или сайт» (7), «авторизация ads.txt недоступна» (11) и «нарушение авторизации ads.txt» (12). Код говорит бирже, почему ставки не было, но не подтверждает, что запрос был невалидным.

Пределы такого решения MRC описывает прямо. Ранние методы фильтрации в целом вероятностные: по истории трафика и эвристикам они оценивают, насколько вероятно, что запрос на ставку невалиден. Поздние могут быть детерминированными и опираться на телеметрию отдельного показа. Отсюда риск, что вердикт вынесен по неполным или урезанным данным. Исключение MRC делает для списков, которые собраны поздними методами, например перечней известных ботов и пауков: если ранний метод держится на таком списке, его можно считать детерминированным.

Какая часть простых проверок вообще доступна по запросу, видно по стандарту АРИР (Ассоциации развития интерактивной рекламы) по GIVT, июнь 2025 года. Краулеров там классифицируют только по User Agent со списком самого верификатора, и строка user agent в запросе есть. Недействительный размер размещения, 0x0 или 1x1, считается и для заданного, и для загруженного на стороне клиента размера: первый виден в запросе, второй только при показе. Клики без показов и повторные клики в рамках одного показа по определению видны лишь после событий.

Что видит блокировка при показе?

Ставка выиграна, объявление отдаётся, а вместе с ним загружается код проверки. Он уже работает в том браузере или приложении, где открылась реклама, и по заранее заданным критериям может не дать объявлению появиться. MRC относит такую блокировку, как и отказ от ставки, к ранним методам и называет их общую цену: заметное отсечение в большинстве случаев подсказывает источнику трафика, на чём он попался, и без новых исследований способ со временем слабеет. Источник может подогнать трафик под фильтр A/B-тестами, и риск выше, когда продавец пользуется одним сервисом ранней проверки. Сервисы блокировки для programmatic и то, чем их роль отличается от счёта показов, сравнены в материале о выборе между защитой от скликивания и верификацией показов.

Поэтому MRC описывает и другой вариант: запрос на ставку заранее помечают как невалидный, но всё равно исполняют, и показ выходит. Источник ничего не замечает, а исключение показа видно в отчёте. В шаблоне официального запроса на разбор расхождений MRC перечисляет поля данных: проанализированные и измеримые показы, отфильтрованные или заблокированные отдельно по GIVT, SIVT и блокировкам проверки (ad verification), и короткое объяснение причины, например бот-лист, подозрительная активность пользователя, список исключённых слов или контента. Заблокированный показ и показ, признанный невалидным, стоят там разными строками.

Что видит проверка после показа?

Данные самого показа: где он прошёл, отрисовалось ли объявление, было ли оно на экране и какие события за ним последовали. Отсюда то, чего в запросе нет: повторные клики, клики без показов, фактический домен и приложение. В обновлении 2024 года MRC советует измерителям SIVT по возможности получать данные запроса, оценивать, насколько им можно верить, и сопоставлять объявленные в них домен, поддомен или ID приложения с местом, где реклама на самом деле вышла. Как такое расхождение читается в отчёте по доменам, показано в разборе подмены домена и сайтов-призраков.

Слабое место проверки после показа одно: показ уже куплен. Ещё MRC замечает, что невалидные события проходят через данные измерителя и вычищаются на поздних этапах, и это усложняет отчётность. Зато поздние методы источнику почти не видны и реже выдают ему, как его нашли.

Результат такой проверки работает на будущие закупки. С 2024 года MRC требует от измерителей SIVT показывать долю невалидной активности по доменам, поддоменам и ID приложений, с минимальными порогами объёма против обратной разработки, чтобы пользователь данных сам решал через списки исключений или разрешённых мест, где показывать рекламу. Блокировать площадку целиком без указания пользователя стандарт не обязывает.

Можно ли заменить проверку после показа проверкой до ставки?

Целиком нельзя, если речь о стандарте MRC, по которому проверяют измерителей. Поздние методы обнаружения и фильтрации обязательны для соответствия, а измеритель, который применяет ранние, обязан сочетать их с поздними. Если ранний метод встаёт на место одного из обязательных поздних, измеритель должен на данных показать, что он работает не хуже, держать позднюю телеметрию для постоянной проверки и периодически обновлять доказательства, доступные аудиту. Ранние методы MRC не запрещает, но и не требует. Включать их в аудит аккредитации по IVT он настоятельно советует, а если они прямо меняют отчётные цифры, требует. Вместе ранние и поздние методы, по MRC, могут работать особенно хорошо.

Обнаружение до ставки не равно фильтрации измеренного. Отказ от ставки решает, что не покупать, а фильтрация после показа решает, что из купленного считать валидным, и первое не отменяет второго.

Отраслевая программа TAG (Trustworthy Accountability Group) Certified Against Fraud в редакции 11.0 (июль 2026 года) требует от участников, чтобы все монетизируемые события, которые проходят через них, будь то показы, клики или конверсии, проверялись на GIVT и SIVT по признанному стандарту. Фильтрацию по спискам опасных доменов и приложений участник ставит до ставки или после неё на свой выбор, если под неё попадают все такие события; списки при этом применяют и к текущим, и к будущим сделкам.

Что куплено и за что платят на каждом этапе?

Почему середина таблицы зависит от договорённости, объясняет OpenRTB 2.6. Уведомление о выигрыше только сообщает DSP, что она победила в аукционе, и, по спецификации, не обязательно означает доставку объявления, его видимость или то, что показ подлежит оплате. Уведомление об оплате (поле burl) биржа вызывает, когда выигравшая ставка становится оплачиваемой по её собственной политике, обычно после доставки или просмотра. Раздел спецификации о подсчёте оплачиваемых событий советует сторонам заранее договориться, что считать таким событием и на каком техническом основании его считать.

Какие выводы можно делать из каждого отчёта?

Последнюю оговорку MRC делает сам. Фильтрация одного GIVT по определению неполная, даже поиск SIVT не проверяет, что у экрана был человек, а невалидной бывает и деятельность людей, например мотивированных выполнять действия за награду. Поэтому называть трафик после фильтрации «человеческим» MRC считает неверным, а другие подписи, например «валидный», допускает только по согласованию с ним в каждом случае.

С двумя отчётами о невалидном трафике одной кампании нужна осторожность. MRC предупреждает, что ранние методы могут приводить к расхождениям с измерителем, который проверяет только после показа. То, что отсекли до ставки, до счёта после показа не доходит, так что доли из двух отчётов относятся к разным объёмам и напрямую не сравниваются. Поэтому применение ранних методов MRC велит раскрывать полностью, вместе с оценкой их влияния на отчётные цифры: число запросов, ставок, блокировок и показов по видам IVT, где оно известно. Если измеритель не видит, как его ресурсы использует рекламный сервер, платформа или сеть, он должен хотя бы периодически оценивать это влияние и сообщать о нём в общем виде.

У отчёта по кампании MRC требует три уровня с такими заголовками: Gross, совсем без фильтрации; Net, после фильтрации GIVT; и, если измеритель ищет сложный трафик, Total Net, после фильтрации SIVT. Если часть трафика заблокирована раньше и в валовые цифры не вошла, пользователи данных должны об этом знать, а существенный объём таких исключений надо посчитать и раскрыть. Видимость, вовлечённость, аудиторию и атрибуцию, включая конверсии, MRC разрешает приводить только после фильтрации, на уровнях Net или Total Net, но не Gross.

Как проверки до ставки и после показа работают вместе?

Через списки. Проверка после показа находит площадки и приложения с невалидным трафиком, их вносят в исключения, и на следующем флайте эти списки срабатывают уже до ставки. Это тот случай, когда ранний метод, по MRC, можно считать детерминированным, и обоснований он требует меньше, чем вероятностный. Стандарт АРИР по SIVT (август 2026 года) единых алгоритмов, порогов и обязательных списков не устанавливает, но требует от верификатора раскрывать в методологии роль списков и баз, например доменов и бандлов, и порядок их обновления и повторной проверки. Применяется он к событиям, по которым у верификатора хватает данных, и в перечне таких событий рекламные запросы стоят рядом с показами, кликами и конверсиями.

Рекламные системы тоже совмещают оба режима. По справке Яндекс Директа на 21 октября 2026 года прежний антифрод в кампаниях в РСЯ и Поиске работал задним числом, по поведению пользователя после перехода, а теперь первым этапом идёт блокировка до показа объявления: объявления не показываются, когда система уверена, что имеет дело с ботом или мошенником. Подозрительный клик проверяет капча, а то, что всё-таки дошло до сайта, разбирает многоуровневая фильтрация, и число отсеянных событий в отчёте может со временем меняться. Пиксель стороннего измерителя на показ Директ позволяет поставить в медийных кампаниях двух видов, аукционных и с фиксированной ценой за тысячу показов, через менеджера Яндекса или поддержку. В справке VK Рекламы верификации показов отведена статья об аудит-пикселях: внешний счётчик событий ставят в группе объявлений кампании «Узнаваемость и охват», и он считает суммарную статистику группы. Статьи об антифроде и фильтрации трафика до показа в навигации справки VK Рекламы на ту же дату не нашлось.

Что спросить у DSP, агентства и измерителя?

DSP или агентству:

1. Какие проверки стоят до ставки: чьи списки и модели и по каким полям запроса они решают?
2. Сколько запросов, ставок, блокировок и показов отсеяно за период и по каким причинам?
3. Попадает ли отклонённое и заблокированное в валовые цифры вашего отчёта?
4. Какое событие считается оплачиваемым: выигрыш, отдача объявления, отрисовка или видимый показ?
5. Как места из отчёта после показа попадают в списки исключений и как часто эти списки пересматривают?

Измерителю:

1. Вы только измеряете после показа или ещё и блокируете? Если блокируете, видны ли такие показы отдельной строкой?
2. Есть ли в отчёте уровни Gross, Net и Total Net?
3. Сверяете ли вы заявленные в запросе домен и приложение с фактическими?
4. Можно ли получить долю невалидного трафика по доменам и приложениям, чтобы собрать исключения на следующий флайт?
5. Если вы применяете ранние методы, как раскрываете их влияние на цифры отчёта?

Опора: дополнение MRC 2020 года к стандарту по невалидному трафику и промежуточное обновление 2024 года, OpenRTB 2.6 с руководством по внедрению и список причин отказа от ставки из OpenRTB 3.0, требования TAG Certified Against Fraud 11.0, стандарты АРИР по GIVT и SIVT, справки Яндекс Директа и VK Рекламы, открытые 21 октября 2026 года.