Как измеряют рекламу на Smart TV: SSAI, идентификатор устройства, охват без cookie и что не видит пиксель?

Почему на Smart TV нельзя рассчитывать на cookie и JavaScript?

В браузере зрителя узнают по cookie, а код измерителя выполняется рядом с рекламой. На телевизоре обе опоры ненадёжны. Руководство IAB Tech Lab по идентификатору для рекламы на OTT-платформах (2018 год) объясняет: Smart TV, приставки и другие подключённые устройства слишком разные, чтобы можно было рассчитывать на привычный учёт через cookie, а без такого учёта один креатив может доставаться одному зрителю чаще, чем задумано. Спецификация VAST 4.3 добавляет, что при серверной вставке у сервиса склейки нет доступа к cookie, на которых держится трекинг с устройства. Об ограничениях JavaScript и SDK и о средах CTV, которые обычными средствами не измерить, MRC пишет в руководстве 2021 года; что это значит для доли измеримых показов, разобрано на странице об измеримости показов.

Насколько ограничения жёсткие, решает платформа. HTML5-версию видеорекламного SDK Яндекса, по документации для разработчиков, можно подключить в приложениях на webOS, Tizen и VIDAA и в WebView на Android TV. MRC в том же руководстве отмечает, что SSAI-инвентарь крупных платформ, как правило, допускает измерение по сигналам с устройства. Поэтому общий ответ «на телевизоре код не работает» неточен: всё решают приложение, плеер и способ вставки.

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

Чем клиентская вставка рекламы (CSAI) отличается от серверной (SSAI)?

При клиентской вставке плеер на телевизоре сам запрашивает рекламу по VAST, проигрывает ролик и отправляет трекинг: запросы по ссылкам показа и событий идут с устройства зрителя. При серверной вставке ролик вшивает в видеопоток промежуточный сервер, и плеер получает контент и рекламу одним потоком. VAST 4 поддерживает такую склейку как раз для устройств, которые не умеют исполнять и отслеживать рекламу привычным способом. Что при этом происходит с трекингом, показывает поле ssai в запросе на показ по протоколу OpenRTB 2.6:

Для измерения главный здесь последний столбец. Во втором варианте трекинг по-прежнему уходит с телевизора, и измеритель видит его адрес и user-agent. В третьем запросы шлёт сервер склейки за плеер, и VAST 4.3 предупреждает: раз весь трекинг приходит с одного IP-адреса, для получателя такие отчёты похожи на невалидный трафик. Как мошенники пользуются этим, выдавая себя за сервер вставки, видно из схем фрода на телевизорах.

Кто отправляет трекинг-события при SSAI и когда засчитывается показ?

Если события отправляет сервер, VAST 4.3 требует слать их одновременно с соответствующими моментами воспроизведения, а недостающие данные устройства, например user-agent, передавать в заголовках или другим способом. Кто именно отправил запрос, сообщает макрос [SERVERSIDE] из списка макросов VAST:

• 0: запрос отправило устройство без посредника;
• 1: сервер отправил его от имени устройства и по его сигналу;
• 2: сервер отправил его за другой сервер, за неизвестную сторону или по своему решению.

Ещё один макрос, [SERVERUA], в котором сервер называет себя, MRC в руководстве 2021 года считает полезным для распознавания SSAI.

Правило счёта задаёт руководство MRC по цифровому видео 2018 года: показ засчитывается по запросу, который инициировало устройство. Считать показы на сервере в момент отдачи контента нельзя, а передавать на сервер сигнал, пойманный на устройстве, можно. Руководство 2021 года переносит правило на CTV: показ засчитывается, когда ролик загрузился и начал воспроизводиться после старта потока и буферизации, а события, которые сервер склейки шлёт за плеер, этому требованию могут не отвечать. Если устройство о показе сообщить не может, VAST 4.3 допускает, что сервис склейки отчитается о нём при отправке ролика в поток или по итогам всей сессии; что потом происходит на экране, сервису уже не подконтрольно, и считать показ по возможности должен плеер. Google Ad Manager, например, при отправке событий с сервера (server-side beaconing) по своей справке считает метрики потока по оценкам и называет трекинг через SDK в плеере более точным.

Площадки задают и свои правила. Яндекс Директ, по справке на 16 октября 2026 года, считает показ видеорекламы на Connected TV состоявшимся, когда ролик шёл две секунды и не меньше половины площади плеера всё это время была в видимой зоне экрана; справка ссылается на стандарты IAB и MRC. Внешний пиксель такое условие проверить не может, об этом ниже.

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

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

Когда запрос приходит прямо с телевизора, IP-адрес и user-agent измеритель видит в самом запросе. Когда запрос шлёт сервер, данные устройства нужно передать явно. VAST 4.3 требует от сервиса склейки добавлять к запросам трекинга заголовки X-Device-IP и X-Device-User-Agent, а при наличии ещё X-Device-Referer, X-Device-Accept-Language и X-Device-Requested-With; X-Forwarded-For оставлен только для совместимости и считается устаревшим. Значения в заголовках должны совпадать с данными исходного запроса на рекламу. Руководство IAB Tech Lab по IFA просит издателей при серверной вставке передавать дальше и идентификатор, и флаг ограничения отслеживания. Те же сведения могут прийти в самой ссылке через макросы VAST, которые заполняет отправитель запроса:

Из этих макросов обязателен только [LIMITADTRACKING], остальные необязательны. Если значение неизвестно, вместо него ставят -1, если известно, но не передаётся по правилам площадки, -2. Поддерживать весь актуальный список макросов, по VAST CTV Addendum 2024, не обязательно, хотя партнёры могут потребовать отдельные макросы. Поэтому набор данных у каждой интеграции свой, и узнать его стоит до запуска. В программатик-закупке те же сведения идут в запросе OpenRTB: ближайший к устройству IP-адрес, user-agent, идентификатор для рекламы и признак ограничения отслеживания.

Как считают охват и частоту без cookie?

Вместо cookie зрителя обозначает идентификатор для рекламы (IFA). По руководству IAB Tech Lab 2018 года это уникальное значение, рекомендуемый формат UUID, и его нельзя строить на аппаратном номере, MAC-адресе, IMEI или IP-адресе. Вместе с ним передают тип идентификатора и флаг ограничения отслеживания. Зритель может сбросить IFA, и тогда появится новый, не связанный со старым; если он ограничил отслеживание, настоящий IFA не передаётся, а площадка может прислать сессионный. В 2023 году руководство объявлено устаревшим, а список типов перенесён в расширение OpenRTB: dpid (выдан устройством), ppid (издателем), sspid (рекламной платформой продавца, SSP) и sessionid (сессионный или синтетический, с коротким сроком жизни). Схема повторяет мобильные идентификаторы IDFA и AAID, и как они ведут себя в приложениях, показано на странице о фроде в in-app.

От идентификатора зависит, что в отчёте называется зрителем:

Людей ни одна из этих единиц напрямую не показывает, а на телевизоре разрыв заметнее: перед одним экраном могут сидеть несколько человек. Поправки на совместный просмотр MRC в стандарте кросс-медийного измерения 2019 года допускает только строгие, проверяемые и с заметной долей данных, собранных о людях напрямую. Яндекс Директ в справке о рекламе на Connected TV (на 16 октября 2026 года) называет охватом число уникальных пользователей с учётом их показов на смартфонах, планшетах и компьютерах, считает его на выборке и предупреждает о возможном небольшом расхождении с фактом; среднюю частоту там получают делением просмотров на охват.

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

Что видит внешний пиксель и чего не видит?

Пиксель в VAST это адрес в элементе показа или события ролика. По спецификации VAST 4.3 исторически это картинка 1×1, но может быть и скрипт; измеритель считает обращения к адресу, а площадка обязана обратиться к нему в нужный момент и не обязана ничего делать с ответом. Значит, внешний пиксель знает ровно то, что пришло в запросе:

Код верификатора, в отличие от пикселя, выполняет сам плеер через элемент AdVerifications; чем такой код отличается от трекинга, объясняет отдельный материал. Если плеер код не выполнил, VAST 4.3 требует отправить событие verificationNotExecuted с причиной: код отклонён площадкой, не поддерживается плеером или не загрузился. Так пропуск замера хотя бы становится виден. Распознать выключенный экран во всех случаях пока трудно, и MRC не делает это обязательным. О непрерывном воспроизведении, когда серии с рекламой идут подряд без участия зрителя, пиксель узнает, только если плеер передаст значение 7 в макросе [PLAYBACKMETHODS]; такое значение появилось в VAST 4.3.

Что спросить у площадки до запуска?

1. Где вставляется реклама в каждом размещении: в плеере телевизора или на сервере, и какое значение ssai стоит в запросах OpenRTB?
2. С чего уходят показ и события ролика: с устройства или с сервера склейки? Какие макросы заполняются: [SERVERSIDE], [SERVERUA], [PLAYBACKMETHODS]?
3. Если трекинг идёт с сервера, передаёт ли он X-Device-IP и X-Device-User-Agent и совпадают ли они с данными запроса на рекламу?
4. Какой идентификатор приходит в [IFA], какого он типа (dpid, ppid, sspid, sessionid) и что приходит, когда зритель ограничил отслеживание?
5. В какой момент засчитывается показ: при начале воспроизведения на устройстве, при отправке ролика в поток или по итогам сессии?
6. Выполняет ли плеер код верификатора из AdVerifications и шлёт ли verificationNotExecuted, когда не выполняет?
7. В чём площадка считает охват: в устройствах, домохозяйствах или людях, по всем данным или на выборке?
8. С какой задержкой приходят события и что происходит с теми, что пришли после конца кампании?

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

Ответ построен на документах, просмотренных 16 октября 2026 года: руководства MRC по цифровому видео (2018), по OTT, CTV и SSAI (2021) и стандарт кросс-медийного измерения (2019), спецификации IAB Tech Lab VAST 4.3 с макросами и CTV Addendum 2024, OpenRTB 2.6 и расширение ifa_type, руководство IAB Tech Lab по IFA на OTT-платформах, стандарт АРИР по измерению видимости, справки Яндекс Директа и Google Ad Manager, документация видеорекламного SDK Яндекса.