Показ рекламы в OTT: VAST, VMAP и рекламный стек

TL;DR

Ad serving – это цепочка поставки, которая превращает пустой рекламный слот в потоке в оплаченный ролик на экране зрителя, и работает она на двух стандартах IAB: VMAP, который перечисляет, где находятся паузы, и VAST, который доставляет каждый отдельный ролик. Когда пауза открывается, ad-сервер или аукцион выбирает ролики, возвращает их как VAST-документы, а ститчер или плеер собирает их в тот рекламный блок, который видит зритель. Продаёте ли вы этот инвентарь напрямую одному рекламодателю или продаёте его многим через programmatic и header bidding – это решает, сколько он заработает, и два числа – fill rate (какая доля слотов получает ролик) и CPM (цена за тысячу показов) – перемножаются в ваш доход. Сделайте стек верно – и паузы наполняются релевантными, правильно разнесёнными роликами; сделайте неверно – зрители видят пустые заставки «мы скоро вернёмся», один и тот же ролик четыре раза подряд или поток непроданного remnant-инвентаря ценой в копейки.

Почему это важно

Если вы запускаете или строите рекламный стриминг, рекламный стек – это место, где ваша аудитория превращается в доход. Две предыдущие статьи разобрали плумбинг, который открывает рекламную паузу: SCTE-35, внутрипотоковую метку «здесь идёт реклама», и серверную вставку рекламы, которая вшивает ролик в поток. Эта статья – про то, что между ними: про выбор ролика и его доставку. Programmatic-реклама на connected-TV прогнозируется примерно в $36 млрд в США в 2026 году против примерно $28 млрд в 2025 (оценки индустрии, 2026), и почти каждый её доллар проходит через стандарты VAST и VMAP, описанные здесь. Это руководство строителя по рекламной цепочке поставки – стандарты, типы сделок и математика, – и спутник к карте монетизации OTT, которая показывает, где рекламный доход стоит среди всех способов заработка платформы, включая биллинг подписок, который гибридные сервисы крутят рядом с рекламой.

Одна задача: от «здесь идёт реклама» к «реклама на экране»

Начнём с разрыва, который весь этот стек существует, чтобы закрыть. К моменту, когда зритель доходит до рекламной паузы, две вещи уже известны: где пауза и как долго она идёт. Это пришло из внутрипотоковой метки. Что ещё неизвестно – это какие ролики пойдут и где лежат их видеофайлы. Ad serving – это набор систем и стандартов, которые отвечают на эти два вопроса достаточно быстро, чтобы зритель не заметил шва.

Вот аналогия, которую стоит держать в голове. Представьте рекламный блок на обычном телевидении. На таймлайне программы есть слоты, зарезервированные под рекламу, – это расписание. Отдельная служба решает, какие ролики заполнят каждый слот, и достаёт нужные «плёнки» из библиотеки. Стриминг делит ту же работу между двумя стандартами: VMAP – это расписание слотов, а VAST – инструкция, которая доставляет «плёнку» каждого ролика. Всё остальное в этой статье – детали о том, как эти два документа пишутся, запрашиваются, разыгрываются на аукционе и собираются.

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

Нажмите, чтобы увеличить

Стек стандартов: кто что делает

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

Таблица 1. Четыре стандарта рекламного стека и слой, которым владеет каждый. SCTE-35 (внутрипотоковая метка) и OpenRTB (аукцион) обрамляют два стандарта, которые несут сами ролики: VMAP описывает таймлайн пауз, а VAST доставляет каждый ролик внутри них. Спутать VMAP с VAST – самая частая ошибка новичка: одно это расписание, другое это ролик.

Коротко про границы. SCTE-35 – тема предыдущей статьи и метка, которая открывает avail; эта статья подхватывает, когда avail уже открыт. В фокусе здесь – VMAP, VAST и аукцион.

VMAP: таймлайн рекламных пауз

VMAP расшифровывается как Video Multiple Ad Playlist – спецификация IAB, впервые опубликованная в июле 2012 года. Она решает конкретную задачу: компания, владеющая контентом, часто не контролирует видеоплеер, в котором он проигрывается. Студия, лицензирующая фильм трём разным стриминговым приложениям, не может залезть внутрь плеера каждого приложения, чтобы расставить паузы. VMAP позволяет владельцу контента один раз описать структуру пауз отдельным XML-документом, который прочитает любой совместимый плеер.

VMAP-документ – это список рекламных пауз (ad break), и каждая пауза несёт два важных атрибута. Первый – timeOffset – когда пауза происходит. Стандарт допускает четыре формы: буквальное значение start (pre-roll, перед контентом), end (post-roll, после него), точную метку времени в форме HH:MM:SS.mmm (mid-roll в конкретный момент) или процент от общей длительности. Второй – breakType – обычно linear, то есть полноэкранный видеоролик, прерывающий контент, в отличие от non-linear оверлея.

Вот минимальный VMAP, описывающий три паузы – одну перед контентом, одну на двенадцатой минуте и одну в конце:

<vmap:VMAP xmlns:vmap="http://www.iab.net/vmap-1.0" version="1.0">
  <vmap:AdBreak timeOffset="start" breakType="linear" breakId="preroll">
    <vmap:AdSource><vmap:AdTagURI templateType="vast4">
      https://adserver.example/vast?slot=preroll
    </vmap:AdTagURI></vmap:AdSource>
  </vmap:AdBreak>
  <vmap:AdBreak timeOffset="00:12:00.000" breakType="linear" breakId="mid1"/>
  <vmap:AdBreak timeOffset="end" breakType="linear" breakId="postroll"/>
</vmap:VMAP>

Заметьте, чего в этом документе нет: самих роликов. Каждый AdBreak содержит AdSource, а AdSource либо держит встроенный VAST-документ, либо – гораздо чаще – AdTagURI, указывающий на ad-сервер, который отдаст VAST, когда пауза будет достигнута. VMAP – это расписание и ничего больше; за самим роликом он передаёт эстафету VAST. Это чистое разделение и есть весь смысл: таймлайн фиксируется при публикации контента, но ролики выбираются заново, под каждого зрителя, во время воспроизведения.

VAST: документ, который доставляет один ролик

VAST расшифровывается как Video Ad Serving Template – стандарт IAB, впервые запущенный в 2008 году и ставший универсальным языком между ad-сервером и видеоплеером. Если VMAP – это расписание, то VAST-документ описывает один ролик: расположение его видеофайла, события, о которых плеер должен отчитаться (начался, первая четверть, середина, завершён, клик), адрес перехода по клику и метаданные вроде длительности и идентичности ролика. Когда плеер или ститчер доходит до слота, он запрашивает VAST-документ, парсит его, проигрывает видеофайл, который тот называет, и срабатывает по трекинг-пикселям, которые тот перечисляет.

VAST определяет два типа ответа, и понимание разницы объясняет большую долю багов доставки рекламы. Ответ InLine – это реальный, финальный ролик: он содержит сам MediaFile (видео, которое посмотрит зритель) плюс весь трекинг. Ответ Wrapper не содержит видео; он держит VASTAdTagURI, который перенаправляет плеер на другой ad-сервер, а тот возвращает либо InLine-ролик, либо ещё один Wrapper. Цепочка редиректов продолжается, пока какой-то сервер наконец не вернёт InLine-ответ с реальным медиафайлом.

Эта цепочка редиректов существует не просто так: каждый шаг – это другая компания в цепочке поставки (ad-сервер агентства, supply-side-платформа, верификационный вендор), и каждая добавляет по пути свои трекинг-пиксели, чтобы все измеряли один и тот же показ. Но у цепочки есть цена. Каждый редирект – это ещё один сетевой round-trip, и соглашение ограничивает глубину Wrapper примерно пятью уровнями, прежде чем плеер сдастся и бросит слот. Слишком длинная цепочка или один медленный сервер в ней – частая причина рекламы, которая так и не появилась.

Нажмите, чтобы увеличить

Два стандарта вкладываются. VMAP держит паузы; каждая пауза указывает на VAST; каждый VAST резолвится – возможно, через цепочку wrapper – в один или несколько реальных роликов. Если запомнить одно предложение про структуру, пусть это будет: VMAP – это плейлист пауз, VAST – это ролик внутри паузы, а Wrapper – это VAST, указывающий на другой VAST.

Почему версия VAST важна для OTT

VAST не заморожен, и для стриминга на телевизорах версия по-настоящему важна. Полные версии – 2.0, 3.0, 4.0, 4.1, 4.2 и текущая 4.3, выпущенная в декабре 2022 года, плюс VAST CTV Addendum, опубликованный в июле 2024 года, надстроенный сверху. Три изменения с 4.0 – те, о которых стриминг-команда обязана заботиться.

Во-первых, VAST 4.0 (2016) отделил медиафайл от интерактивного кода. Более ранние ролики связывали видео и любое интерактивное поведение вместе через старый интерфейс VPAID (Video Player-Ad Interface Definition). Эта связка ломала серверную вставку рекламы, потому что ститчеру нужен простой видеофайл, который он может перекодировать и вшить, а не исполняемый код. Дав реальному MediaFile собственный элемент, VAST 4.0 сделал ролики пригодными для вшивания – а именно это требуется доставке на OTT и connected-TV.

Во-вторых, VPAID объявлен устаревшим и заменён на SIMID (Secure Interactive Media Interface Definition), представленный вместе с VAST 4.2 в 2019 году. Если ваш рекламный стек всё ещё зависит от VPAID, он будет падать на большинстве устройств в гостиной и ломать серверную вставку; SIMID плюс отделённый медиафайл – современный, безопасный для CTV путь для любой интерактивности.

В-третьих, VAST 4.x добавил узел AdVerifications, через который Open Measurement SDK (OM SDK) от IAB получает информацию, нужную, чтобы измерить, был ли ролик реально видимым (viewable). OM SDK парсит этот узел и отчитывается стандартизированными сигналами – геометрия экрана и ролика, перекрытия, видимые показы и завершение по четвертям – тому измерительному вендору, которому доверяет покупатель. Open Measurement SDK расширился на платформы connected-TV, включая Samsung и LG, покрывая примерно 40% домохозяйств с CTV по состоянию на 2024 год, и добавил поддержку device-attestation для борьбы со спуфингом. CTV Addendum 2024 пошёл дальше с фреймворком Ad Creative ID (ACIF) для более чистой идентификации креатива и поддержкой обязательных иконок раскрытия по Digital Services Act. Практическое правило: на connected-TV цельтесь в VAST 4.x, используйте SIMID, а не VPAID, и внедряйте узел AdVerifications – покупатели всё чаще не ставят на инвентарь, который не могут измерить.

Ad pods: рекламный блок и его четыре контроля

Один mid-roll редко держит всего один ролик. Двухминутная пауза может нести четыре тридцатисекундных ролика подряд – ровно как телевизионный рекламный блок. Эта последовательность роликов внутри одной паузы и есть ad pod, и сама концепция входит в VAST с версии 3.0 (2012), выражаясь атрибутом sequence, который задаёт порядок роликов внутри pod.

Pods – это место, где ad serving в стриминге становится по-настоящему сложным, потому что заполнить слот каким-то роликом легко, а заполнить pod правильным набором роликов требует четырёх контролей, которые традиционное ТВ решило десятилетия назад, а стриминг всё ещё доводит до ума:

• Дедупликация – один и тот же креатив не должен идти дважды в одном pod. Без неё зритель видит идентичный ролик подряд, что читается как сбой.
• Конкурентное разделение – два ролика одной категории (два автобренда, два банка) не должны делить pod. Рекламодатели платят за то, чтобы не стоять рядом с конкурентом.
• Частотный кап – зритель не должен видеть один и тот же ролик слишком много раз за сессию или за день. Это разница между запоминающейся кампанией и раздражающей.
• Контроль задержки – каждый ролик в pod должен быть выбран и готов до начала паузы, иначе зритель получает пустой экран или заставку «мы скоро вернёмся», пока сервер судорожно ищет.

В programmatic-pods эти контроли согласуются прямо в аукционе. Текущая спецификация OpenRTB 2.6 (IAB Tech Lab) добавила pod bidding, который позволяет продавцу описать pod – его общую длину, число слотов, их последовательность – в bid-запросе, чтобы покупатели могли ответить роликами под конкретные позиции. Она определяет structured, dynamic и hybrid pods в зависимости от того, сколько продавец фиксирует заранее. Управление pods остаётся одной из по-настоящему «недоделанных» на ощупь частей CTV: сделаешь верно – блок ощущается как телевидение, сделаешь неверно – ощущается сломанным.

Нажмите, чтобы увеличить

Прямые продажи против programmatic: как заполняется слот

Теперь сторона спроса – кто на самом деле покупает слот. Есть два широких маршрута, и современный стек заставляет их конкурировать.

Более старый маршрут – прямые продажи (direct-sold). Продавец договаривается с рекламодателем крутить кампанию по фиксированной цене за гарантированное число показов. Ad-сервер платформы (Google Ad Manager и SpringServe – частые примеры) хранит кампанию и отдаёт её, когда таргетинг совпадает. Прямые сделки несут самые высокие цены и максимальный контроль, но требуют отдела продаж и не могут заполнить каждый слот большой фрагментированной аудитории.

Более новый маршрут – programmatic – автоматизированная покупка через аукцион. Когда слот открывается, платформа рассылает bid-запрос многим покупателям (demand-side-платформам, представляющим рекламодателей), и побеждает наибольшая ставка – всё это сильно меньше чем за секунду. У programmatic есть уровни: programmatic guaranteed (автоматизированная версия прямой сделки), private marketplace (PMP – закрытый аукцион по приглашению для избранных покупателей) и open exchange (ставить может любой; самые низкие цены, самый высокий fill).

Ключевой архитектурный вопрос – как они конкурируют. Старый способ – waterfall: ad-сервер предлагал каждый слот источникам спроса по одному, в фиксированном порядке приоритета, пока кто-то не согласится. Waterfall медленный и оставляет деньги на столе, потому что покупателя пониже в очереди, готового заплатить больше, так и не спрашивают, как только источник повыше согласился на меньшую цену. Современная замена – header bidding (он же единый аукцион): все источники спроса – прямые, PMP и open exchange – ставят одновременно на каждый слот, и побеждает по-настоящему наибольшая ставка. Индустрия оценивает прирост дохода от «выпрямления» waterfall в единый аукцион примерно в 15–25% для видео и CTV (оценки индустрии, 2026). Урок для строителя: waterfall прост, но недооценивает ваш инвентарь; единый аукцион сложнее в реализации, но именно так серьёзные рекламные платформы максимизируют доход.

Таблица 2. Типы спроса, заполняющие рекламный слот, от наибольшего контроля к наименьшему. Большинство платформ крутят все четыре через единый (header bidding) аукцион, чтобы каждый источник конкурировал за каждый слот, – колонка «типичный fill» показывает, почему ни один источник не достаточен сам по себе. Цены и fill зависят от аудитории, сезона и контента; читайте колонки как относительные, не абсолютные.

Математика дохода: fill rate × CPM

Два числа превращают всё это в доход, и проговорить их вслух – самое полезное в этой статье. Первое – fill rate – доля рекламных запросов, на которые реально вернулся ролик. Если ваш плеер просит рекламу десять миллионов раз в месяц и семь миллионов запросов возвращают ролик, ваш fill rate – 70%. Второе – CPM – cost per mille, цена за тысячу показов (mille – латынь для «тысяча»). CPM $20 означает, что рекламодатель платит $20 за каждую тысячу показов своего ролика.

Доход – это произведение этих двух, прогнанное через показы. Пройдём по шагам:

ad-запросов в месяц           = 10 000 000
fill rate                     = 70%
показы  = 10 000 000 × 0,70 = 7 000 000
средний CPM                   = $20
доход   = 7 000 000 ÷ 1 000 × $20 = $140 000 / месяц

Теперь посмотрим, что делает каждый рычаг. Допустим, единый аукцион поднимает fill rate с 70% до 85%:

показы  = 10 000 000 × 0,85 = 8 500 000
доход   = 8 500 000 ÷ 1 000 × $20 = $170 000 / месяц   (+$30 000)

А допустим, конкуренция в этом аукционе ещё поднимает средний CPM с $20 до $25:

доход   = 8 500 000 ÷ 1 000 × $25 = $212 500 / месяц   (+$72 500 к старту)

Те же десять миллионов запросов теперь зарабатывают на 52% больше – чисто за счёт лучшего fill и более сильного спроса. Вот почему архитектура аукциона выше – не технический пустяк, а двигатель дохода. Есть и тесно связанная метрика – eCPM (эффективный CPM) – это ваш фактический заработанный доход на тысячу показов по всем источникам вместе: доход ÷ показы × 1 000. eCPM – честная зачётка, потому что он уже учитывает fill rate, непроданные слоты и remnant-ролики; CPM – это цена одной сделки. А правильная ли реклама вообще основная модель для вашего каталога – отдельный стратегический вопрос, разобранный в ценах, паковке и решении по монетизации.

Нажмите, чтобы увеличить

Прозрачность цепочки поставки: ads.txt, app-ads.txt и sellers.json

Ещё один слой отделяет платформу, которой покупатели доверяют, от той, которую обходят, и на connected-TV он не опционален. Programmatic-покупатели обжигались на фроде – поддельные приложения и неавторизованные реселлеры выдают фейковый инвентарь, – поэтому IAB Tech Lab публикует набор стандартов прозрачности, позволяющих покупателю убедиться, что он покупает реальный инвентарь у авторизованного продавца.

ads.txt (Authorized Digital Sellers) – публичный файл на сайте, перечисляющий ровно те компании, которым разрешено продавать его рекламный инвентарь. app-ads.txt – та же идея для приложений, и именно она релевантна для OTT и CTV, где ваш сервис – это приложение на телевизоре. sellers.json – зеркальное отражение, публикуемое supply-side-платформами и биржами, называющее каждого продавца, которого они представляют. А SupplyChain object (часто «schain») едет вместе с каждым bid-запросом, фиксируя весь путь, который инвентарь прошёл от вашей платформы к покупателю. Вместе они позволяют покупателю ответить на один вопрос – «это правда инвентарь Фора Софт, проданный через авторизованных партнёров?» – и на CTV, где app-ads.txt – норма, не опубликовать его означает, что премиум-покупатели просто не будут ставить. Внедрить эти файлы дёшево; пропустить их – тихо обрезать свои CPM.

Частая ошибка: гнаться за fill rate вместо дохода

Повторяющаяся ошибка в монетизации рекламы – оптимизировать не то число. Команда смотрит на дашборд fill rate, видит, как он лезет к 100% после добавления низкокачественного open-exchange-партнёра, и объявляет победу – а доход едва шевелится или даже падает. Причина в том, что fill rate считает, заполнен ли слот, а не сколько он заработал. Слот, заполненный remnant-роликом за $1, и слот, заполненный премиум-роликом за $30, оба считаются «заполненными», но это не один и тот же бизнес.

Математика делает это наглядным. Переход с 60% fill при blended eCPM $30 на 100% fill при blended eCPM $12 выглядит как улучшение fill на 40 пунктов, а на деле это срез дохода: 0,60 × $30 = $18 дохода на тысячу запросов против 1,00 × $12 = $12. Дисциплина в том, чтобы оптимизировать доход на тысячу запросов (fill rate × eCPM вместе), а не fill rate в одиночку, и держать ценовой пол, отсекающий ставки настолько низкие, что они тянут смесь вниз. Рядом сидят три связанные ловушки: оставить устаревший VPAID-креатив в стеке, чтобы реклама падала на телевизорах; дать цепочкам wrapper вырасти так глубоко, что слоты вылетают в пустые заставки по таймауту; пропустить частотный кап, чтобы ролик вашего лучшего рекламодателя прошёл шесть раз за один сеанс и приучил аудиторию его ненавидеть. Правильный ad serving – это не «заполнился ли слот», а «заработал ли слот, чисто, на каждом устройстве».

Где здесь Фора Софт

Ad serving – это место, где масштаб стриминга встречается с рекламным плумбингом, и дорогие сбои тихие: pod, вылетающий в пустой экран в самый трафиковый вечер; цифра fill rate, прячущая падающий доход; премиум-покупатели, обходящие ваш инвентарь, потому что нет app-ads.txt, чтобы его проверить. Фора Софт строит видеостриминговые и OTT/Internet-TV платформы с 2005 года, на 250+ запущенных проектах для 400+ клиентов, а значит, мы вшивали конвейеры VMAP и VAST в плееры и серверные ститчеры, подключали их к ad-серверам и programmatic-спросу через header-bidding-аукционы и строили контроли pod – дедупликацию, конкурентное разделение, частотный кап, – которые делают стриминговый блок похожим на телевидение. Наша позиция – scalability-first и вендор-нейтральность: мы стартуем от масштаба и доходности, которых требует ваша аудитория – каждый слот заполнен самым доходным роликом, готов до начала паузы, измерим на каждом устройстве, – а затем строим тот рекламный стек, который ваши AVOD-, FAST- и гибридные потоки действительно требуют.

Ключевые выводы

• VMAP перечисляет, где рекламные паузы; VAST доставляет каждый отдельный ролик внутри них.
• VAST Wrapper редиректит на другой ad-сервер; цепочка кончается InLine-роликом с реальным видеофайлом.
• На connected-TV цельтесь в VAST 4.x, используйте SIMID, а не VPAID, и внедряйте ad-верификацию.
• Ad pods нужны дедупликация, конкурентное разделение, частотный кап и контроль задержки.
• Единый header-bidding-аукцион бьёт waterfall, потому что весь спрос конкурирует за каждый слот.
• Доход = fill rate × CPM; оптимизируйте доход на запрос, а не fill rate в одиночку.

Что почитать дальше

• SCTE-35 и сигнализация рекламы
• Server-side ad insertion (SSAI) против client-side (CSAI)
• Карта монетизации OTT: подписки, реклама, транзакции