Пиксель, JS-обёртка или SDK: что видит каждый уровень измерения рекламы?

Чем пиксель, JS-код, SDK и серверное событие отличаются друг от друга?

Уровни различаются тем, кто исполняет замер и в какой момент.

Уровни складываются, а не исключают друг друга: пиксель на показ часто стоит и там, где работает код, а переход считает отдельная ссылка. MRC (Media Rating Council) в стандарте по невалидному трафику 2020 года требует от измерителя различать, какие сигналы собирают SDK, скрипты и пиксели, и подтверждать данными, как работает каждый способ в каждой среде. Если при каком-то способе части обычных полей нет, это ограничение раскрывают клиенту и по возможности считают. Показы, по которым о валидности решить нельзя, идут в отчёт как неизвестные: их не записывают ни в валидные, ни в невалидные.

Что видит каждый уровень?

Строка о видимости у пикселя требует пояснения. В VAST 4.3, стандарте ответа рекламного сервера видеоплееру, для передачи видимости есть элемент ViewableImpression: рекламный сервер даёт адреса, которые плеер вызывает, когда показ оказался видимым, невидимым или неопределённым. Когда именно их вызывать, зависит от стандарта видимости, который реализовал плеер, а поддерживать сам элемент плеер не обязан. В VK Рекламе видимость для стороннего счётчика включают галочкой «Учитывать видимость показов», и пиксели на доступные события VK готовит сама; чьё правило при этом решает, что показ видим, справка не уточняет. В обоих случаях измеритель получает чужой вывод, поэтому стоит узнать, по какому правилу он сделан. Почему процент видимости без доли измеримых показов мало что говорит, объясняет материал об измеримости.

С доменом своя оговорка. По спецификации W3C Referrer Policy браузер по умолчанию отправляет на чужой домен в заголовке Referer только адрес сайта, без пути к странице, а полный адрес передаёт, лишь когда запрос идёт на тот же домен с тем же протоколом и портом. Пиксель, вызванный из фрейма рекламного сервера, получит в заголовке домен этого фрейма. MRC относит полный адрес страницы или приложения, где показана реклама, к полям, которые измеритель собирает там, где это возможно, и для этого ему обычно нужны макросы площадки или код на странице.

Для поиска ботов уровни различаются числом сигналов. Простой невалидный трафик (GIVT), по MRC, находят списками и стандартными проверками параметров: трафик известных дата-центров, роботы и краулеры, user-agent не браузера, страницы, загруженные браузером заранее, которые человек так и не открыл. Почти всё нужное для этого уже лежит в запросе, и MRC перечисляет поля, которые измеритель собирает по возможности: время, IP-адрес (при прокси и серверной вставке ещё X-Forwarded-For), полный user-agent, cookie или идентификатор устройства, адрес страницы или приложения, заголовки предзагрузки. Для сложного невалидного трафика (SIVT), по MRC, нужны продвинутая аналитика и сверка многих сигналов. Стандарт АРИР (Ассоциации развития интерактивной рекламы) по SIVT называет среди них необычные распределения по IP-адресам, частоте и скорости реакции, которые строятся и по запросам пикселя, а также характеристики устройства и окружения, признаки средств автоматизации и телеметрию взаимодействия с рекламой, а их собирает код на устройстве. Классификация, по тому же стандарту, одна для всех сред, различается набор доступных сигналов, а перечень сред и событий, которые поддерживает верификатор, раскрывается в его методологии.

Чем JS-код рядом с креативом отличается от обёртки креатива?

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

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

У обёрток есть своя история. В VAST 4.3 IAB Tech Lab напоминает, что верификаторы долго запускали код проверки через VPAID, потому что в видео другого способа выполнить код в момент показа не было. В итоге за отрисовку креатива отвечал верификатор, а несколько VPAID-обёрток для сбора данных подряд складывались в хрупкую цепочку посредников, которая заметно задерживала отрисовку страницы. Поэтому в VAST 4 код измерения вынесен в отдельный элемент AdVerifications. VAST-обёртка (Wrapper) при этом осталась перенаправлением: она отсылает плеер к другому серверу и может добавить свои адреса отслеживания, то есть пиксели, но не код.

Что код может проверить на экране, перечисляет стандарт АРИР о том, как измерять видимость (вышел в декабре 2025 года): площадь креатива, пересечённую с видимой областью окна, активность вкладки через Page Visibility API, а где позволяют среда и способ размещения, ещё и скрытие креатива CSS-свойствами visibility и display, прозрачность и то, лежит ли он поверх других элементов. Основным методом в браузере стандарт называет Intersection Observer API, запасным getBoundingClientRect() с обработкой прокрутки и изменения окна. Руководство MRC 2015 года требует проверять положение рекламы не реже раза в 100 миллисекунд для баннеров и раза в 200 миллисекунд для видео. Пиксель ничего из этого не наблюдает: когда запрос отправлен, его работа закончена.

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

Что добавляет SDK в приложении?

В мобильном браузере видимость, по руководству MRC 2016 года, обычно удаётся измерить одним JavaScript, кроме части случаев с фреймами с другого домена. Внутри приложения обычно нужен SDK или API, а от SDK MRC требует контроля версий и полной, точной, защищённой от изменения передачи данных. Тогда же MRC писал, что общего отраслевого SDK нет и что открытый единый SDK был бы полезен. В 2018 году IAB Tech Lab в рекомендациях для OpenRTB называл Open Measurement SDK новым инструментом для замера видимости. Его встраивает разработчик приложения или поставщик рекламного SDK, а теги измерителей получают сигналы через интерфейс OMID.

Что тег узнаёт через OMID, зависит от режима доступа. В режиме limited код проверки работает в изолированной среде и знает о рекламе только косвенно: размер и положение приходят событиями geometryChange. В режиме full у кода есть прямой доступ к элементу видео или блоку, где отрисован креатив. В событиях геометрии есть доля рекламы на экране и список причин, по которым она видна не целиком: приложение свёрнуто (backgrounded), реклама вне экрана (viewport), перекрыта (obstructed), обрезана контейнером (clipped), скрыта или прозрачна (hidden), у окна нет фокуса, не подключено устройство вывода (noOutputDevice), реклама идёт в режиме «картинка в картинке». Элементы, которые приложение объявило дружественными перекрытиями, OM SDK из расчёта видимости исключает, а их число передаёт в событии.

Ограничения OM SDK IAB Tech Lab перечисляет сам: brand safety и поиск фрода выполняет тег измерителя, своей логики для них в SDK нет, и рекламный идентификатор устройства SDK не получает. Против подделки устройств предложена аттестация: приложение или плеер подтверждает через OM SDK, что устройство настоящее, а измеритель может проверить это независимо. Соседние стандарты задачу OM SDK не решают. MRAID это общий набор команд для HTML5-рекламы в приложениях, и MRC не считает MRAID 2.0 самостоятельным способом замера видимости. Интерактивный креатив SIMID заперт в собственной песочнице и, как сказано в спецификации, задачи проверки решать не может: их отдали OMID. Как OMID и SIMID пришли на смену VPAID в видео, разобрано в материале о проверке видеорекламы.

Что видит серверное событие?

Серверное событие приходит не с устройства зрителя, а с сервера: сервиса вставки рекламы в видеопоток (SSAI), рекламного сервера площадки или системы, которая передаёт показы выгрузкой. MRC в стандарте 2020 года описывает это так: когда рекламу вшивают в поток на сервере, плеер иногда вовсе не отправляет трекинг, у сервиса склейки нет доступа к cookie, и события вместо плеера может слать он сам, но такие события бывают неполными и не всегда отвечают требованию, чтобы их инициировало устройство. А раз все запросы приходят с одного IP-адреса, фильтры невалидного трафика могут их отсеять. Измеритель, по тому же стандарту, должен учитывать, что прокси и дата-центры в такой доставке дают ложные срабатывания, и считать неизвестным то, что не доказано как невалидное.

Видимость сервер измерить не может, потому что не видит экрана. Руководство MRC 2015 года напоминает, что видимый показ сначала должен отвечать требованиям к засчитанному показу, в том числе быть посчитан на стороне клиента. Поэтому про каждое серверное событие стоит выяснить, что за ним стоит: сигнал, пойманный на устройстве и переданный дальше, или решение самого сервера. Подделку таких событий стандарты выделяют отдельно: MRC относит SSAI spoofing и фальсификацию событий измерения (показа, видимости, клика, конверсии) к сложному невалидному трафику, стандарт АРИР по SIVT ставит SSAI spoofing и SDK spoofing в категорию манипуляций с инвентарём и измерениями. Какие заголовки и макросы должен добавлять сервер склейки, чтобы измеритель узнал устройство, показано в разборе измерения на Smart TV.

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

Что спросить у измерителя?

1. Каким способом вы подключены на каждом размещении: пиксель, JavaScript рядом с креативом, обёртка креатива, OMID, серверная интеграция? Записан ли способ замера в данных по каждому показу? Стандарт АРИР по видимости советует такие сведения собирать.
2. Какие поля вы получаете на каждом уровне, каких обычно не хватает и где это раскрыто в описании методики?
3. Где ваш код меряет сам креатив, а где только контейнер или фрейм, и чем подтверждено, что это не искажает видимость?
4. Видимость вы измеряете своим кодом или получаете готовое событие от площадки или плеера? Если готовое, по какому правилу оно засчитано?
5. Как часто код проверяет положение рекламы и учитывает ли прозрачность, скрытие стилями и перекрытие другими элементами?
6. В приложениях: в каком режиме доступа OMID (limited или full) приходят ваши данные, сохраняете ли вы причины невидимости и число дружественных перекрытий?
7. Что происходит с показами, по которым на этом уровне нельзя решить, валидны ли они: они стоят в отчёте как неизвестные?
8. Как защищены ваш код и передача данных от подмены и перехвата?
9. Если на креативе уже стоит тег другого измерителя, мерите ли вы такие показы и как это видно в отчёте?
10. Какие серверные события вы принимаете и отделены ли они в отчёте от событий, пришедших с устройства?

Опора: обновлённый в 2020 году стандарт MRC по невалидному трафику, руководство MRC по видимости для десктопа (2015) и для мобильных сред (2016), стандарт АРИР по видимости 2025 года и стандарт АРИР по SIVT 2026 года, спецификации IAB Tech Lab OMID 1.5, VAST 4.3, SIMID, OpenRTB 2.6 и AdCOM 1.0, материалы IAB Tech Lab об Open Measurement SDK (страница стандарта, описание возможностей и ограничений, рекомендации для OpenRTB), спецификация W3C Referrer Policy, две статьи справки Яндекс Директа (пиксели и интеграции верификаторов) и статья справки VK Рекламы про аудит-пиксели. Все документы открыты 22 октября 2026 года, пересказ сверен с их текстом.