Smart TV в вашей DSP или SSP: что меняется и что строить самим

Реклама на Smart TV (CTV) — это видеореклама, которая идёт на подключённых к интернету телевизорах, обычно в рекламной паузе из нескольких роликов внутри стримингового приложения. Чтобы работать с ней, DSP или SSP, построенная для баннеров на сайтах и в приложениях, должна измениться в четырёх местах. Bid request описывает целую рекламную паузу, а не одно рекламное место. Реклама приходит в виде ответа VAST — XML-документа, который указывает на видеофайлы. Многие ТВ-приложения не могут запрашивать и отслеживать рекламу так, как это делает браузер, поэтому рекламу в поток вставляет сервис сшивания. Тогда рекламные запросы, а часто и трекинговые вызовы от имени телевизора отправляет этот сервис, так что устройства приходится идентифицировать, а показы считать по-другому. Ставки на рекламные паузы и поддержку VAST стоит встроить в собственную платформу. Сшивание — дело паблишера или сервиса, созданного для этой работы.

Чем отличается реклама на Smart TV?

На сайте рекламный запрос обычно просит одно объявление для одного места, а браузер загружает это объявление и сообщает о показе. На телевизоре зритель смотрит передачу в стриминговом приложении, а реклама идёт паузами, как в эфирном телевидении. IAB Tech Lab — организация, которая развивает протокол торгов OpenRTB, — называет такую паузу ad pod: один или несколько роликов, которые «проигрываются подряд внутри потока видео- или аудиоконтента».

Спецификация OpenRTB 2.6 от IAB Tech Lab описывает версию 2.6 как ту, что «вводит ad pods для CTV-сделок». Статья опирается на эту спецификацию и на руководство IAB Tech Lab по её внедрению (по состоянию на 2 ноября 2026 года, как и остальные источники в этой статье).

Как рекламная пауза приходит в bid request?

В OpenRTB 2.6 пауза приходит в bid request как один или несколько объектов показа (impression), и объекты показа с одинаковым podid относятся к одной паузе. Руководство по внедрению описывает три вида пауз:

• Структурированная: продавец заранее задаёт число мест, их порядок и длительность каждого, и каждое место — отдельный объект показа
• Динамическая: продавец задаёт общую длительность и максимальное число роликов, но не их количество и не длительность каждого, и вся пауза может прийти одним объектом показа
• Гибридная: часть паузы фиксирована, а часть динамическая

Большинству баннерных платформ никогда не приходилось читать такие поля:

• poddur — общее число секунд, которое рекламодатели могут заполнить в динамической паузе, и maxseq — наибольшее число роликов, которое она может вместить
• rqddurs — список точных длительностей роликов. Спецификация говорит, что это поле предназначено для прямого эфира, «где неточная длительность рекламы приводила бы к нежелательному „мёртвому эфиру“»
• slotinpod — поле, которое показывает, может ли продавец гарантировать первое или последнее место, и podseq — позиция паузы в передаче
• mincpmpersec — floor-цена за секунду рекламного времени для динамической части паузы

Каждая ставка указывает длительность своего ролика в поле dur. В руководстве по внедрению также сказано, что покупателям «следует ожидать, что окончательную сборку ad pod выполняет продавец». Если вы отправляете несколько ставок на одну паузу, продавец может использовать любое их число, от ни одной до всех, и смешать их с роликами других покупателей.

Отправляйте с каждой ставкой домен рекламодателя (adomain) и идентификатор креатива (crid). Спецификация называет оба среди атрибутов, которые используются «для проверки качества рекламы или соблюдения ограничений паблишера».

Для DSP рекламные паузы меняют логику ставок. Баннерный биддер оценивает по одному показу за раз. CTV-биддер должен выбрать, какие из его роликов укладываются в оставшееся время паузы, и назначить им цену за секунду, а какие из них продавец оставит, он не контролирует.

Что должен содержать ответ VAST?

Видеореклама доставляется по VAST, который IAB Tech Lab описывает как «универсальную XML-схему для показа рекламы в цифровых видеоплеерах». На её странице о VAST, последний раз обновлённой в июле 2024 года, новейшей версией указана VAST 4.3 от декабря 2022 года. В репозитории VAST 4.x от IAB Tech Lab на GitHub есть и VAST 4.4; в заметке мейнтейнера там сказано, что она выпущена 22 июля 2026 года. VAST 4.4 добавляет CTV-форматы, такие как реклама при паузе и реклама в режиме заставки. Цитаты ниже взяты из VAST 4.3.

В июле 2024 года IAB Tech Lab также опубликовала дополнение для CTV, которое переносит идентификатор креатива и mezzanine-файл из VAST 4 в более старые VAST 2 и 3. В дополнении сказано, что эти ранние версии «до сих пор доминируют на рынке».

На телевизоре важнее всего две части VAST:

• Mezzanine-файл — «необработанный видеофайл высокого качества», из которого системы паблишера делают версию для каждого экрана. VAST 4.3 говорит, что mezzanine-файл «обязателен при реализациях со сшиванием рекламы» и что сервис сшивания может отклонить ответ без него
• UniversalAdId — идентификатор, который сопровождает креатив из системы в систему. VAST 4.3 требует его для линейной рекламы, то есть той, что идёт внутри передачи, а дополнение добавляет его в VAST 2 и 3 как расширение. По нему сервисы сшивания определяют, конвертировали ли они уже этот креатив

В процессе сшивания, который описывает VAST 4.3, креатив, которого сервис ещё не видел, нужно конвертировать, прежде чем его можно будет показать, поэтому в паузе вместо него идёт другой ролик. VAST 4.3 отмечает, что первая загрузка mezzanine-файла «может занять несколько часов». AWS описывает то же правило для MediaTailor, своего облачного сервиса, который вшивает рекламу в потоки: «Если реклама ещё не перекодирована под параметры контента, MediaTailor пропустит её вставку», а ролик подготавливается к следующему запросу.

Поэтому новый креатив может упустить первые возможности показа на каждом сервисе сшивания. Согласно VAST 4.3, креативу, изменённому любым образом, следует присваивать новый идентификатор. Не меняйте идентификатор, пока сам креатив не меняется, чтобы каждый сервис сшивания конвертировал его только один раз.

Для кода верификации VAST 4.3 рекомендует Open Measurement (OMID) и высказывается «решительно против использования VPAID» — более старого способа запускать код внутри видеорекламы. В качестве замены VPAID для интерактивной рекламы он называет SIMID. VAST 4.3 держит интерактивный код отдельно от видеофайла, чтобы плееры, работающие с сервисом сшивания, могли воспроизвести видео, даже если не могут выполнить код. Убедитесь, что каждый ТВ-креатив работает как обычное видео.

Что меняется, когда сервер вшивает рекламу в поток?

Многие ТВ-приложения не могут запрашивать и отслеживать рекламу так, как это делает браузер. VAST 4.3 описывает альтернативу — серверную вставку рекламы (server-side ad insertion, SSAI), или сшивание рекламы (ad stitching). Приложение запрашивает поток у сервиса сшивания, сервис запрашивает рекламу у ad-сервера, и ролики вшиваются в контент, так что зритель получает «единый непрерывный поток».

OpenRTB 2.6 добавляет в объект показа поле ssai, которое говорит, какая часть сшивания и трекинга происходит на сервере. Его значения идут от «всё на стороне клиента» до «всё на стороне сервера». В промежуточном случае видео сшивается на сервере, а трекинговые пиксели отправляет устройство. Значение по умолчанию, 0, означает, что статус неизвестен, поэтому запрос без этого поля ничего не говорит ни в ту, ни в другую сторону.

Когда рекламные запросы и трекинговые вызовы приходят с сервера, кажется, что у многих зрителей один IP-адрес. VAST 4.3 предупреждает: «Для ad-сервера, который получает данные трекинга, отчёты похожи на недействительный трафик». Он говорит, что провайдеры сшивания должны передавать IP-адрес и user agent устройства в двух заголовках, X-Device-IP и X-Device-User-Agent, вместе со своими трекинговыми запросами и что эти значения должны совпадать с теми, что были в исходном рекламном запросе.

Для вашей платформы это означает:

• Когда трафик идёт через сервис сшивания, берите данные устройства из этих заголовков и из bid request. IP-адрес, который к вам подключается, в этом случае принадлежит сервису сшивания, поэтому не используйте его как адрес устройства
• Спрашивайте продавца о любом серверном трафике, который приходит без заголовков X-Device
• Проверяйте, что продавец указан в файле app-ads.txt паблишера. Спецификация IAB Tech Lab распространяет ads.txt на приложения из «магазинов приложений для подключённых телевизоров»
• Стройте ограничения частоты показов и аудитории на идентификаторах устройств. VAST 4.3 отмечает, что сервис сшивания «не имеет доступа к cookies». В OpenRTB 2.6 поле ifa несёт рекламный идентификатор, который, как ожидается, берётся из операционной системы устройства, а поле lmt указывает, когда трекинг должен быть ограничен

Как считают показы и выставляют за них счета?

Руководство по внедрению OpenRTB сравнивает способы подсчёта оплачиваемых событий. Для аудио и видео оно рекомендует событие показа (impression) в VAST. URL уведомления о биллинге (burl), который хорошо работает для баннеров, «не рекомендуется для аудио/видео».

Руководство также советует биддерам отслеживать задержку между аукционом и уведомлением о биллинге, потому что от неё зависят цели по расходам, ограничения частоты показов и распределение бюджета. В его таблице разумных задержек в строке для аудио или видео с серверным сшиванием указано «очень долго или неизвестно».

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

Серверное сшивание не изменило правил подсчёта. VAST 4.3 цитирует руководство IAB по измерению, разработанное вместе с Media Rating Council (MRC): «Руководство по измерению требует, чтобы подсчёт рекламы использовал подход, инициируемый клиентом». Тот же фрагмент допускает подсчёт на сервере, «если он инициируется на основе событий и средств измерения на стороне клиента». Подсчёт, который сервер начинает сам по себе, он отвергает, потому что такой подсчёт «дальше всего от того момента, когда пользователь действительно видит рекламу». Спросите каждого продавца, какое событие запускает его подсчёт показов, когда рекламу вшивает сервер.

Что строить самим, а что уже берут на себя партнёры?

Некоторые части CTV-схемы — дело паблишера или сервисов, созданных для паблишеров. Само сшивание — одна из них. MediaTailor, например, отправляет данные зрителя на сервер принятия решений о рекламе (ad decision server), получает выбранные ролики в ответе ad-сервера и вшивает их в поток. Конвертация видеофайлов в формат каждого паблишера — часть той же работы.

Другие части определяют, сколько зарабатывает ваша платформа, и их стоит строить самим:

• Для DSP: выбор роликов, которые помещаются в паузу, и назначение им цены за секунду
• Для DSP: распределение бюджетов (pacing), когда уведомления о биллинге приходят с опозданием
• Для DSP: отдача креативов с mezzanine-файлом и идентификатором креатива, который меняется только при изменении самого креатива, — в элементе UniversalAdId в VAST 4 или в расширении из дополнения для VAST 2 и 3
• Для SSP: сборка каждой паузы из ставок нескольких покупателей и применение правил паблишера о том, каким рекламодателям можно появляться
• Для SSP: передача полей ad pod и значения ssai каждому покупателю
• Для обеих: чтение данных устройства из заголовков X-Device и фильтрация недействительного серверного трафика
• Для обеих: подсчёт показов так, чтобы его принимали покупатели и аудиторы

DSP, которая пока хочет лишь проверить, нужен ли CTV её рекламодателям, может начать с одной-двух SSP, которые уже продают CTV, и сначала делать ставки на структурированные паузы. Спросите у этих SSP, какая доля их CTV-инвентаря приходит в виде динамических пауз: руководство по внедрению призывает продавцов по возможности предлагать динамические ad pods. Прямой эфир с его точными длительностями роликов может подождать, пока первые кампании не покажут, что он нужен рекламодателям.

Стройте всё из списка выше, когда CTV станет устойчивой долей вашей выручки. То же относится к случаям, когда вы сами заключаете сделки с ТВ-паблишерами или когда то, как партнёр обрабатывает паузы, раз за разом решает, какие из ваших ставок попадут в эфир.

Что спросить у фирмы, которая добавляет CTV в нашу платформу?

• Какие поля ad pod из OpenRTB 2.6 будет читать система и как она выбирает ролики для динамической паузы?
• Как система рассчитывает цену ставок за секунду и соблюдает ли она mincpmpersec?
• Какие версии VAST будут использовать наши креативы и откуда берутся mezzanine-файлы?
• Будут ли у наших креативов зарегистрированные UniversalAdId или значение по умолчанию «unknown»?
• Как система обрабатывает серверный трафик и откуда берёт IP-адрес и user agent устройства?
• Как считаются показы у каждого продавца?
• Как сохраняется точность распределения бюджета, когда уведомления о биллинге приходят с очень большим опозданием?
• С какими партнёрами мы будем тестировать в первую очередь и какие функции могут подождать?

Где здесь место amBrain?

В AdTech amBrain занимается разработкой DSP, платформ real-time bidding и рекламных бирж. Две строки из списка его услуг гласят: «amBrain строит supply-side платформы (SSP) для паблишеров» и «amBrain строит ad-серверы: таргетинг, ограничение частоты показов и отчётность». RTBBidder — demand-side платформа, которую amBrain построил для клиента.

amBrain делает софт с 2019 года. Компания работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов».

Эта статья — не кейс. Кроме упоминания RTBBidder, работа для клиентов в ней не описывается: в ней не утверждается, что amBrain добавлял Smart TV в какую-либо платформу, и в ней нет ни цифр о RTBBidder, ни цен и сроков amBrain. IAB Tech Lab и AWS цитируются по их собственным документам, и статья не утверждает, что между amBrain и кем-либо из них есть какие-либо отношения. Если amBrain в вашем шорт-листе, задайте ему те же вопросы, что и любой другой компании.