Видеореклама в programmatic — это не просто передача MP4-файла в плеер. До момента воспроизведения нужно определить, какой креатив показывать, передать плееру информацию о ролике, настроить отслеживание событий и корректно обработать возможные ошибки.
Для стандартизации этой части цепочки используется VAST (Video Ad Serving Template) — стандарт IAB Tech Lab для описания видеорекламы и взаимодействия рекламной системы с видеоплеером.
В этой статье разберём VAST с точки зрения programmatic-интеграции: где он находится в RTB-цепочке, чем отличаются Inline и Wrapper, какие события отслеживаются, почему важна скорость ответа и какие версии стандарта актуальны сегодня.
Что такое VAST
VAST — это стандарт, который описывает структуру ответа с инструкциями для воспроизведения видеорекламы.
Важно не путать VAST с самим видеофайлом. VAST — это XML-документ или VAST tag URL, через который плеер получает информацию о рекламе: где находится медиафайл, сколько длится ролик, какие события нужно отслеживать и куда отправлять сигналы о них.
В зависимости от сценария VAST может содержать:
- ссылку на один или несколько медиафайлов;
- длительность рекламного ролика;
- URL для фиксации Impression и других событий;
- информацию о клике;
- события начала и прогресса воспроизведения;
- настройки пропуска рекламы;
- обработку ошибок;
- дополнительные данные и идентификаторы, предусмотренные конкретной версией стандарта.
Упрощённо:
VAST отвечает на вопрос «как передать рекламную информацию видеоплееру и отследить её воспроизведение», а не «какой рекламодатель должен победить в аукционе».
Где VAST находится в programmatic-цепочке
Чтобы понять роль VAST, важно отделить его от OpenRTB.
В типичном programmatic-сценарии цепочка выглядит примерно так:
Плеер → рекламный запрос → SSP / ad server → OpenRTB → DSP → bid response → VAST → плеер → показ → трекинг
При этом конкретная архитектура зависит от участников интеграции.
1. Плеер формирует рекламный запрос
Когда пользователь запускает видео, плееру может понадобиться рекламный ролик — например, для pre-roll или mid-roll.
В запросе рекламная система может получить параметры рекламного места и контекста показа: устройство, размеры плеера, тип инвентаря, географию, идентификаторы и другие доступные параметры.
2. Запрос попадает в programmatic-систему
SSP или ad server может передать запрос нескольким источникам спроса через OpenRTB.
DSP получает bid request и решает, участвовать ли в аукционе и какую ставку предложить для конкретного показа.
3. Победившая сторона возвращает рекламный ответ
После применения правил аукциона рекламная система формирует ответ с выбранным креативом.
Для видеорекламы в этом ответе может находиться VAST XML либо ссылка на VAST tag URL, по которой плеер или промежуточная система получает VAST-ответ.
4. Плеер разбирает VAST
Плеер получает XML и извлекает из него необходимую информацию: медиафайлы, длительность, tracking events, click tracking и другие параметры.
5. Плеер загружает и воспроизводит ролик
После проверки доступных форматов плеер выбирает подходящий медиафайл и запускает воспроизведение.
6. Во время показа отправляются события
По мере воспроизведения фиксируются события — от Impression и Start до Complete, а также клики, пропуск и ошибки.
VAST и OpenRTB: в чём разница
Эти стандарты связаны, но решают разные задачи.
OpenRTB стандартизирует обмен данными между участниками programmatic-цепочки: bid request, bid response и параметры рекламного запроса и предложения.
VAST описывает, как видеореклама представлена для видеоплеера: какой ролик загрузить, как его воспроизводить и какие события отслеживать.
Поэтому корректнее представить их как последовательные уровни:
- OpenRTB помогает организовать programmatic-обмен и участие в аукционе;
- VAST описывает видеорекламный ответ, который должен быть обработан плеером.
При этом правила определения победителя не являются функцией самого VAST. Их реализует соответствующая рекламная система в рамках своей аукционной логики.
Inline и Wrapper: два основных типа VAST-ответа
VAST-ответ может содержать рекламную информацию непосредственно внутри XML или ссылаться на следующий VAST-ответ.
Inline
Inline содержит информацию, необходимую для показа рекламы, непосредственно в текущем VAST-ответе.
В нём могут находиться:
- информация о креативе;
- ссылки на медиафайлы;
- длительность;
- tracking events;
- click tracking;
- параметры обработки ошибок.
Если все необходимые данные уже находятся в Inline, плееру не требуется раскрывать дополнительную VAST-цепочку.
Wrapper
Wrapper не содержит финальный рекламный креатив. Он указывает на другой VAST URL, который должен вернуть следующий ответ.
Например:
Плеер → Wrapper 1 → Wrapper 2 → Wrapper 3 → Inline → видео
Wrapper используется, когда в цепочке участвуют несколько рекламных систем или когда одна система передаёт запрос дальше другой.
Проблема начинается, когда цепочка становится слишком длинной. Каждый дополнительный переход означает ещё один сетевой запрос и дополнительную задержку. Если один из участников отвечает слишком долго или возвращает некорректный VAST, финальный показ может не состояться.
Поэтому при интеграции важно учитывать не только поддержку VAST как таковую, но и допустимую глубину Wrapper-цепочки.
Linear, Non-linear и VMAP
В VAST встречаются разные способы размещения рекламного контента.
Linear
Linear — реклама воспроизводится как отдельный видеоролик относительно основного контента.
Наиболее знакомые сценарии:
- Pre-roll — перед основным видео;
- Mid-roll — во время просмотра;
- Post-roll — после основного видео.
Non-linear
Non-linear — рекламный элемент отображается поверх основного видеоконтента, не заменяя его полностью.
VMAP
VMAP (Video Multiple Ad Playlist) решает другую задачу: он задаёт расписание рекламных вставок внутри длинного видеоконтента.
Например, VMAP может описывать, где должны находиться pre-roll, mid-roll и post-roll. Сам VMAP не заменяет VAST: он определяет структуру рекламных вставок, а VAST используется для описания конкретной рекламы.
Какие версии VAST актуальны
Стандарт VAST развивается IAB Tech Lab уже много лет. На текущий момент последней опубликованной версией является VAST 4.3, выпущенная в 2023 году.
При этом в реальных интеграциях всё ещё могут встречаться более ранние версии. Поэтому при подключении партнёра недостаточно написать в технических требованиях просто «поддерживаем VAST» — нужно согласовать конкретную версию и используемые возможности стандарта.
В общих чертах:
- VAST 2.0 — более ранняя версия стандарта с базовыми возможностями доставки и tracking;
- VAST 3.0 — расширяет возможности работы с видеокреативами и событиями;
- VAST 4.0 — существенное развитие стандарта для современных video-рекламных сценариев;
- VAST 4.1 — расширения, связанные в том числе с verification и современными способами измерения;
- VAST 4.2 — дальнейшее развитие стандарта и поддержка современных сценариев интерактивности;
- VAST 4.3 — текущая версия стандарта, включающая дополнительные обновления и уточнения спецификации.
Для CTV также важно учитывать отдельные рекомендации IAB Tech Lab по сигналингу рекламных возможностей и совместимости. В 2026 году IAB Tech Lab финализировала CTV Ad Portfolio Signaling Guidance, поэтому для CTV-интеграций имеет смысл проверять не только версию VAST, но и применимые CTV-требования.
VAST и VPAID — не одно и то же
VAST и VPAID исторически часто использовались вместе, но это разные технологии.
VAST описывает доставку видеорекламы и связанные с ней события.
VPAID был отдельным стандартом для взаимодействия исполняемого рекламного креатива с видеоплеером и использовался для интерактивных сценариев.
Сегодня VPAID считается устаревающим подходом. IAB Tech Lab указывает на переход к другим стандартам:
- SIMID — для интерактивного взаимодействия рекламы с плеером;
- OMID / Open Measurement — для измерения и верификации рекламы.
Поэтому при современной интеграции не стоит автоматически считать, что «VAST поддерживает VPAID». Необходимо отдельно проверять, какие механизмы интерактивности и measurement поддерживаются конкретным плеером и рекламной платформой.
Какие события отслеживает VAST
Одна из ключевых функций VAST — стандартизация событий воспроизведения.
Типичная последовательность выглядит так:
Impression → Start → 25% → 50% → 75% → Complete
Кроме того, могут отслеживаться:
- Click;
- Skip;
- Error;
- другие события, предусмотренные конкретной реализацией и версией стандарта.
Важно различать Impression и Start. Это не одно и то же событие: Impression фиксирует событие показа в соответствии с логикой VAST, а Start — начало воспроизведения ролика. Поэтому показатели этих событий могут отличаться.
Для ошибок VAST предусматривает передачу информации о причине сбоя. Корректная обработка tracking URL и макросов важна для того, чтобы рекламодатель и рекламная платформа получали согласованную статистику.
Почему скорость важна для VAST
В баннерной рекламе дополнительный сетевой запрос может быть неприятным, но для видео задержка особенно критична.
Пользователь уже ждёт запуска основного контента. Если рекламный ответ долго не приходит, плеер может перейти дальше по сценарию, пропустить рекламу или получить ошибку.
На задержку влияет вся цепочка:
плеер → SSP/ad server → DSP → Wrapper-цепочки → VAST → media file
Поэтому проблемы могут возникнуть даже тогда, когда каждый отдельный компонент технически работает корректно.
Особенно внимательно стоит смотреть на:
- время формирования bid response;
- время получения VAST;
- количество Wrapper-переходов;
- доступность media file;
- DNS/TLS/HTTP-задержки;
- таймауты на каждом этапе.
В programmatic важна не только способность системы вернуть рекламу, но и способность сделать это вовремя.
Типичные проблемы при интеграции VAST
Даже при формально корректной поддержке VAST видеореклама может не запускаться или некорректно собирать статистику.
Несовместимый формат видео
Плеер может не поддерживать конкретный тип медиафайла, кодек, разрешение или другой параметр креатива.
Слишком долгий ответ
Если DSP, SSP, ad server или Wrapper отвечает слишком медленно, запрос может не успеть завершиться до истечения таймаута.
Ошибка загрузки media file
VAST может быть корректным, но сам ролик недоступен: ссылка не работает, сервер не отвечает или ресурс нельзя воспроизвести в конкретном окружении.
Некорректный tracking
Если tracking URL или макросы обрабатываются неправильно, показ может происходить, но статистика окажется неполной или некорректной.
Слишком длинная Wrapper-цепочка
Каждый дополнительный переход увеличивает число запросов и добавляет потенциальную точку отказа.
Несовместимость возможностей
Две стороны могут формально поддерживать одну и ту же версию VAST, но использовать разные подмножества возможностей стандарта. Например, одна сторона может рассчитывать на конкретный механизм verification или интерактивности, который другая сторона не поддерживает.
Что проверить перед подключением VAST-партнёра
Перед запуском интеграции стоит согласовать не только сам факт поддержки VAST, но и конкретные технические параметры.
1. Версия VAST
Какие версии принимает и возвращает каждая сторона? Какие функции реально поддерживаются?
2. Форматы видео
Какие кодеки, разрешения, длительности, размеры файлов и способы доставки допустимы?
3. Inline и Wrapper
Используются ли Wrapper? Какая максимальная глубина цепочки допустима?
4. Таймауты
Сколько времени есть на получение bid response, VAST и media file? Что происходит после таймаута?
5. Трекинг
Проверить Impression, Start, quartile events, Complete, Click, Skip и Error. Отдельно проверить корректность макросов и URL.
6. Обработка ошибок
Что произойдёт, если DSP не ответила, VAST некорректен, Wrapper недоступен или media file не загрузился?
7. Реальный тестовый трафик
После технической проверки важно проверить не только XML, но и полный путь:
запрос → аукцион → VAST → загрузка видео → воспроизведение → tracking
Что влияет на эффективность VAST-рекламы
Поддержка VAST сама по себе не гарантирует высокий результат. На работу видеорекламы влияет вся цепочка.
Скорость принятия решения. Чем быстрее рекламная система формирует ответ, тем меньше вероятность потерять показ из-за таймаута.
Качество трафика. Для рекламодателя разные показы имеют разную ценность. Поэтому система должна учитывать параметры конкретного рекламного запроса.
Конкуренция за инвентарь. В programmatic несколько источников спроса могут участвовать в покупке одного показа. Конкуренция влияет на экономику конкретного рекламного запроса в соответствии с правилами аукциона.
Стабильность интеграции. Ошибки на любом этапе — от bid response до загрузки media file — приводят к потере потенциального показа.
Корректный tracking. Даже успешно воспроизведённый ролик мало полезен для аналитики, если события не доходят до соответствующих систем.
VAST в Adtec
Adtec DSP работает с видеорекламой в формате VAST наряду с баннерным инвентарём в programmatic-сценариях.
Для B2B-партнёров при такой интеграции важна не только поддержка самого стандарта, но и согласование технических параметров: версии VAST, форматов видео, способов передачи VAST, tracking events и требований к времени ответа.
Adtec развивает собственную технологическую платформу и команду разработки. Это позволяет самостоятельно работать с техническими интеграциями и учитывать согласованные требования конкретного партнёра.
Если ваша компания работает с programmatic-видеорекламой и рассматривает подключение DSP, перед интеграцией стоит заранее согласовать поддерживаемые версии VAST, форматы и особенности обработки видеозапросов.
VAST — это не отдельный рекламный аукцион, а стандартный слой доставки и отслеживания видеорекламы. Для стабильной интеграции важно смотреть на всю цепочку: от RTB-запроса и решения DSP до VAST, воспроизведения ролика и передачи tracking events.
Главное
VAST стандартизирует передачу видеорекламы между рекламной системой и видеоплеером. Он описывает не сам видеофайл, а информацию, необходимую для его воспроизведения и измерения результатов.
В programmatic VAST работает рядом с OpenRTB, но решает другую задачу: OpenRTB используется для programmatic-обмена и участия в аукционе, а VAST — для представления видеорекламы плееру и отслеживания её воспроизведения.
При интеграции особенно важно проверить:
- совместимость версий и возможностей VAST;
- Inline и Wrapper-сценарии;
- допустимые форматы видео;
- таймауты и задержки всей цепочки;
- трекинг события и макросы;
- обработку ошибок;
- работу на реальном трафике.
Для современных video- и CTV-сценариев также важно учитывать актуальное состояние стандарта: последняя версия VAST — 4.3, а VPAID постепенно заменяется современными подходами к интерактивности и measurement.
