Как согласовать тест двух верификаторов на одной кампании, чтобы результаты можно было сравнить?

Почему сравнивать можно только одни и те же показы?

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

• Один креатив, два кода. Коды обоих измерителей стоят в одном объявлении, баннере или видеоответе, а не в соседних копиях креатива.
• Одинаковые форматы и среды. Баннеры сравнивают с баннерами, видео с видео. Руководство MRC по видимым показам 2015 года велит давать статистику десктопного браузера, мобильного браузера и приложений раздельно, так же сводят и итоги теста.
• Код на всех показах выборки. Стандарт MRC по невалидному трафику (редакция 2020 года) разбирает случай, когда клиент ставит тег только на часть показов: выборку тогда делает сам клиент, а измеритель обязан такие случаи выявлять и раскрывать. Размещения, куда второй код поставить не удалось, выносят в отдельную строку.
• Сплошной замер или выборка у измерителя. Совместное руководство MRC и IAB 2012 года о том, как проводить верификацию, предлагает раскрывать по каждому проекту, какая доля кампании поддалась проверке, а при выборке ещё её размер, период и погрешность. Если один верификатор меряет каждый показ, а другой выборку, это записывают до сравнения.

Кто ставит коды и что разрешают рекламные системы?

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

Оба кода должны срабатывать на одном событии. В Adfox ссылка сторонней системы из поля «Ссылка на промерочный пиксель» вызывается при отрисовке баннера, но её можно повесить и на событие «Видимый показ, 2 сек». Если тег одного верификатора стоит на отрисовке, а другого на видимом показе, они считают разное по определению; как устроен счёт самого сервера, объясняет разбор рекламного сервера и независимой проверки.

Что разрешают системы по своим справкам и спецификациям на 23 октября 2026 года:

Где в Директе пиксель на показ недоступен, сказано в разборе отчёта «Недействительный трафик», макросы и события аудит-пикселя VK собраны в инструкции по его подключению. В видео с VAST 4.1 есть идентификатор AdServingId, по которому один показ находят в данных разных систем; он описан в материале о проверке видеорекламы.

Как убедиться, что оба кода срабатывают?

Проверку начинают до старта, но отдельно от данных теста. Стандарт MRC по невалидному трафику относит к невалидному трафику тестирование тегов издателями, агентствами и рекламодателями, если его много, и разрешает исключать такие показы при подтверждении, например по выделенным IP-адресам или отдельным ID кампаний. Проверочные показы делают в тестовой кампании или помечают, а дни настройки в сравнение не берут.

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

Что проверить в эту точку:

1. У каждого верификатора есть события по всем размещениям выборки, пустых строк нет.
2. Показы каждого верификатора по размещениям сопоставимы со счётом рекламной системы: резкий провал в одном месте обычно значит, что тег там не стоит или не срабатывает.
3. Креативы и размещения, добавленные после старта, получили оба кода.
4. В видео нет запросов verificationNotExecuted. По VAST 4.3 причина 1 значит, что площадка не узнала или не допустила код измерителя, 2 что плеер не поддерживает его технологию, 3 что ресурс не загрузился или упал с ошибкой.
5. Каждый верификатор письменно ответил, меряет ли он объявления, где уже стоит чужой тег. Руководство MRC 2015 года разрешает их не мерить, но требует раскрыть это и по возможности оценить последствия, потому что такая практика сбивает сверку.

В формальном разборе расхождений MRC ставит тот же первый шаг: до обмена данными измеритель проверяет, правильно ли размечены объявления и сайты. Любое расхождение в тесте разумно начинать с тегов, а не с методики.

Какие условия сравнения записать до старта?

Каждую метрику сравнивают только при одинаковом определении и одинаковой базе.

Видимость. Правила MRC и АРИР близки, но не совпадают. MRC допускает мерить не сам креатив, а его контейнер, если это не даёт существенной разницы, а при заметном масштабировании считать долю пикселей по площади отмасштабированного объявления. Стандарт АРИР обрезку и масштабирование не допускает, а при несовпадении размеров места и креатива показ видимым не засчитывается. Один баннер может оказаться видимым у одного измерителя и невидимым у другого, поэтому стандарт видимости вписывают в условия явно.

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

Часовой пояс. Руководство IAB и MRC 2017 года требует полностью раскрывать часовой пояс отчёта, считает желательным, чтобы площадки и рекламные серверы умели строить отчёты в едином поясе для сопоставления разных измерителей, и для отчётов вне США советует GMT. Почему дни в разных поясах не сходятся, видно из шести причин расхождений.

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

Блокировка. Если один из верификаторов в той же кампании ещё и блокирует трафик до показа, по MRC его результаты расходятся с результатами тех, кто проверяет только после показа, а заблокированный объём меняет и числитель, и знаменатель видимости. В тесте либо не блокирует никто, либо заблокированное показывают отдельно; см. разбор pre-bid и post-bid.

Почему два честных измерителя всё равно дают разные числа?

Даже при общей выборке и одинаковых правилах цифры разойдутся, и стандарты говорят об этом прямо.

Сама АРИР в 2025 году решила выпустить бенчмарки только по невалидному трафику и среди причин отказа от видимости назвала разночтения в трактовке документов MRC и IAB. Её стандарт по видимости декабря 2025 года задаёт единую трактовку видимого показа ради сопоставимости отчётности, и в волне бенчмарков марта 2026 года видимость вернулась. Но средние по рынку в тесте не судья: сравнивают два отчёта об одних и тех же показах.

Какой разрыв объясним методикой, а какой требует разбора?

Нормы расхождения именно между двумя верификаторами в документах MRC, IAB и АРИР, на которые опирается эта страница, нет. Цифра на этот счёт есть только в порядке разбора расхождений из стандарта MRC по невалидному трафику: существенным там считается расхождение больше 5% затронутой метрики, а к относительному порогу можно добавить сумму в деньгах, чтобы не разбирать статистически незначимое. Это граница, после которой расхождение разбирают, а не мерило качества верификатора. Её, порог из договора или свой порог стороны теста записывают до старта. Порог сверки основного и второго счёта из типовых условий медиазакупок IAB разобран в материале о расхождениях по ссылке выше.

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

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

Какие критерии результата записать до старта?

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

Что сравниваем. Показы, доли GIVT и SIVT, видимость, измеримость и доля показов с решением об IVT, по каждой среде и размещению выборки. Метрики, которые меряет только один верификатор, в сравнение не входят.

Какой вывод следует из какого исхода.

Кто разбирает расхождения. Назовите владельца теста на стороне рекламодателя или агентства, контакт у каждого верификатора и срок ответа. Для формального разбора MRC советует согласовать срок, ориентир около 30 дней, и различает три исхода: стороны согласны без изменений, согласны с изменениями и раскрытием или не согласны. Первая ступень у MRC неформальная, и совет ожидает, что большинство расхождений снимается разговором на ранних данных. Если по итогам теста понадобится разговор с площадкой, пригодится инструкция по письму площадке.

Что зафиксировать письменно?

Условия удобно собрать в один протокол, который каждая сторона подтверждает письмом:

1. Цель теста, вопрос, на который он отвечает, и то, на что он не отвечает.
2. Кампания, креативы, размещения, форматы и среды в выборке; что исключено и почему.
3. Кто ставит коды и на какое событие, как подключён каждый верификатор (пиксель, JS-код, элемент Verification в VAST, SDK), сплошной у него замер или выборочный; журнал правок.
4. Определение показа, правила видимости (MRC 2015 года или АРИР 2025 года), классы невалидного трафика и трактовка пограничных сигналов.
5. Период, часовой пояс, дни настройки вне сравнения и дата, на которую оба отчёта фиксируют для сравнения.
6. Метрики, их знаменатели и разрезы: размещение, домен или приложение, устройство, среда, день.
7. Порог, после которого начинается разбор, кто его ведёт и в какие сроки отвечают стороны.
8. Какие данные каждый верификатор передаёт и кому, что можно показать второй стороне и площадке.
9. Как площадку предупредили о втором измерителе: руководство MRC и IAB 2012 года советует указывать верификацию в заказе на размещение или других документах кампании, а видеоплеер по VAST вправе не запустить незнакомый код проверки.

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

Опора, все источники открыты 23 октября 2026 года: совместные документы MRC и IAB о проведении верификации (февраль 2012) и о счёте показов для десктопа (октябрь 2017) и цифрового видео (июнь 2018), руководство MRC о видимых рекламных показах (август 2015), стандарт MRC по выявлению и фильтрации невалидного трафика (июнь 2020) и памятка MRC от апреля 2024 года, спецификация VAST 4.3 и страница IAB Tech Lab об Open Measurement SDK, три стандарта АРИР (видимость, GIVT, SIVT) и её сообщение о бенчмарках за 2025 год, справки Яндекс Директа о пикселях и интеграциях верификаторов, справка Adfox о пикселях сторонних систем и справка VK Рекламы об аудит-пикселях.