VAST изнутри: как устроен XML-шаблон, и почему он важен для точного трекинга

Во всём мире рынок онлайн-видеорекламы стремительно растёт, а вместе с ним усложняются и требования к технологиям доставки рекламных роликов. Стандарт VAST (Video Ad Serving Template) стал фундаментом, на котором строятся современные системы показов, трекинга и аналитики в сфере видеорекламы. В этой статье мы разберёмся в структуре VAST-XML, ключевых тегах и принципах работы, чтобы вы могли эффективно использовать этот протокол для точного учёта показов и взаимодействий.

В контексте видеорекламы VAST выступает в роли «универсального языка» между медиаплеером (например, в веб-браузере, мобильном приложении или Smart TV) и рекламным сервером (Ad Server, DSP или SSP). Когда приходит время показа рекламы — например, при запуске видео или в середине контента (mid-roll) — плеер отправляет запрос к рекламной платформе, указывая параметры устройства, геоданные (при наличии), технические ограничения и другие условия. В ответ сервер формирует VAST-тег — XML-документ с подробными инструкциями, как воспроизводить рекламу.

Ключевые элементы обмена:

• Запрос (ad call). Плеер «сообщает», что готов воспроизвести ролик.
• VAST-ответ (VAST response). Сервер возвращает XML-файл с описанием рекламного объявления, ссылками на медиафайлы, трекинговыми пикселями и настройками клика.
• Трекинг (tracking). В процессе воспроизведения ролика плеер «пингует» указанные в теге URL, фиксируя метрики и события (impression, досмотр 25%, клики, пропуск и т.д.).

Так выстраивается связка, где каждая сторона «понимает» формат и логику работы другой благодаря единому стандарту VAST.

С точки зрения взаимодействия между участниками, процесс можно свести к упрощённой схеме:

1. Player → Ad Server: Плеер отправляет запрос, который может содержать параметры пользователя (IP-адрес, User-Agent), данные о контенте, размеры экрана и т.п.
2. Ad Server → Player: Сервер анализирует входящие данные, выбирает подходящий видеокреатив и формирует VAST-XML. Плеер получает XML и обрабатывает его.
3. Player → Tracking URLs: Во время проигрывания рекламного ролика плеер вызывает трекинговые ссылки (Start, FirstQuartile, Complete и пр.). Это необходимо для сбора аналитики и подтверждения факта показа (impression).
4. Player → Landing Page: При клике пользователя на ролик плеер перенаправляет на страницу рекламодателя (ClickThrough), параллельно отправляя сигнал ClickTracking для аналитики.

Таким образом, VAST-тег становится «картой», по которой плеер понимает, куда обращаться, какой ролик загружать и какие действия фиксировать.

Для того чтобы плеер смог показать хотя бы один простой видеоролик, в VAST должен быть определён минимальный набор тегов.

Основные элементы:

• <VAST version="3.0">: корневой элемент, указывающий, по какой версии спецификации построен тег (например, 2.0, 3.0, 4.0 и т.д.).
• <Ad>: контейнер для описания одного или нескольких рекламных креативов.
• <InLine>: полноценное объявление с медиафайлами и трекинг-событиями (в отличие от Wrapper, который ссылается на другой VAST-URL).
• <AdSystem>: система, которая сгенерировала объявление (Ad Server, DSP и т.д.).
• <Impression>: URL или пиксель, на который плеер отправляет запрос, когда объявление запускается.

Такой минимально необходимый блок уже позволит отобразить простой видеоролик и зафиксировать факт его запуска.

Корневой тег <VAST> всегда содержит атрибут version, указывающий, какую версию стандарта использует XML. Значение может быть, к примеру, «2.0», «3.0» или «4.2». Рекламные платформы и плееры ориентируются на это, чтобы знать, какие функции и теги поддерживать, а какие могут отсутствовать.

Внутри <VAST> могут находиться один или несколько элементов <Ad>, что даёт возможность доставлять серию рекламных роликов (Ad Pods) в одном документе.

Элемент <Ad> — это контейнер, описывающий конкретную рекламную единицу. У него обычно есть атрибут id, уникально идентифицирующий объявление. Внутри <Ad> располагается либо <InLine>, либо <Wrapper>:

• <InLine>: содержит все данные об объявлении — ссылки на видеоролик, трекинг-события, настройки клика. Плеер получает этот блок и может сразу воспроизвести рекламу.
• <Wrapper>: вместо полного описания креатива ссылается на другой VAST-файл (через <VASTAdTagURI>). Часто используется для «каскадного» перенаправления, когда несколько Ad Servers цепляются друг за другом, добавляя трекинг или логику выбора ролика.

Когда выбирать InLine:
Если ваша система сама хранит ролик (MediaFile) и все трекинговые ссылки, и нет необходимости переадресовывать запрос к внешней платформе.

Когда выбирать Wrapper:
Если Ad Server или SSP передаёт запрос дальше (например, к ещё одному партнёру), или нужно «вложить» дополнительную аналитическую надстройку (Tracking Events) поверх чужого тега.

<MediaFile>: параметры видео (формат, битрейт, разрешение)

Тег <MediaFile> внутри блока <MediaFiles> указывает медиаресурс, который плеер должен воспроизвести. Основные атрибуты:

• type: MIME-тип (обычно video/mp4, реже video/webm или др.).
• delivery: «progressive» (загрузка файла напрямую) или «streaming» (HLS, DASH).
• width и height: разрешение видео.
• bitrate: битрейт ролика, помогающий плееру определять оптимальное качество.

Плеер, обрабатывая <MediaFiles>, обычно выбирает один <MediaFile> в зависимости от технических условий (скорость соединения, поддерживаемый формат). В более продвинутых случаях используется адаптивное стриминг-видео (HLS/DASH), и тогда указанные параметры играют роль резервных опций.

<TrackingEvents>: события (impression, quartiles, click и т.д.)

Внутри <Linear> (или других типов объявлений) располагается блок <TrackingEvents>, куда включают <Tracking>-теги. Каждый тег описывает событие, которое плеер должен «пинговать»:

Таким образом фиксируются ключевые точки просмотра ролика: начало, 25%, 50%, 75% и завершение. Также есть события skip, pause, mute, unmute и пр. С их помощью рекламодатели получают точную аналитику — насколько глубоко пользователи досматривают видео и как они взаимодействуют с объявлением.

<VideoClicks>: управление кликами и переход на лендинг

Тег <VideoClicks> определяет, что произойдёт при клике на видеообъявление.

Традиционно указывают:

• <ClickThrough>: конечный URL, куда будет перенаправлен пользователь (лендинг рекламодателя).
• <ClickTracking>: трекинговая ссылка, фиксирующая факт клика, до перенаправления на лендинг.
• <CustomClick>: дополнительные кликовые зоны или специализированные сценарии.

Если пользователь кликнул по ролику, плеер сначала отправит запрос на <ClickTracking>, а потом откроет <ClickThrough>. Это помогает рекламным платформам собирать статистику по CTR и оценивать эффективность креатива.

<Extensions>: дополнительный функционал (интерактивность, интеграции)

Чтобы не перегружать спецификацию, IAB ввёл концепцию <Extensions>, которая позволяет добавлять кастомные теги. Например, там можно указать:

• Интерактивные элементы (VPAID или SIMID-обёртка).
• Пиксели для верификации и безопасности.
• Дополнительные параметры, специфичные для конкретной AdTech-платформы.

Плеер может игнорировать неизвестные расширения или обрабатывать их, если знает, как с ними работать. Это делает VAST гибким и совместимым даже с проприетарными надстройками.

Inline-объявления (блок <InLine>) чаще всего применяются, когда рекламная платформа уже «знает», какой ролик нужно показать, и отдаёт всю информацию непосредственно в XML. Это упрощает цепочку, сокращает задержки (latency) и уменьшает риск ошибок.

Однако в современных экосистемах видеореклама редко поставляется напрямую одним сервером. Часто используется модель, когда SSP передаёт запрос DSP, DSP может обратиться к ещё одному Ad Server и т.д. Именно здесь помогает Wrapper, который просто перенаправляет плеер на другой VAST-тег, добавляя при этом свои Tracking-ссылки.

Прямое встраивание креатива (Inline)

Сценарий: Вы рекламодатель или прямой AdServer, у вас есть ролик, трекинг-события и призыв к действию (CTA). В этом случае стоит отдать InLine, чтобы плеер сразу получил финальную инструкцию, не ходил по дополнительным редиректам и не тратил время на подзагрузку других XML.

Преимущества:

• Минимальная задержка.
• Проще отлаживать и тестировать.
• Меньше рисков потери трекинговых событий.

Недостатки:

• Если нужно встроить сторонние пиксели, придётся вручную прописывать их в TrackingEvents или Extensions.

Многоуровневые редиректы (Wrapper) и их влияние на задержки

Сценарий: Программатик-аукцион, где несколько посредников участвуют в выборе креатива. SSP даёт Wrapper, ведущий на DSP, а тот, возможно, ещё на один сервер. Такая структура позволяет «сложить» трекинг сразу от нескольких участников цепочки, однако увеличивает время, затрачиваемое на подгрузку окончательного VAST-файла.

Преимущества:

• Гибкая модель, позволяющая распределять ответственность и аналитику.
• Возможность динамически менять поставщика рекламы без изменения кода плеера.

Недостатки:

• Рост latency из-за нескольких уровней редиректов.
• Сложнее искать проблемы, если реклама не отображается (каждый уровень нужно проверять по отдельности).

IAB рекомендует не превышать 5 уровней Wrapper, так как слишком длинная цепочка может привести к тому, что плеер прервёт загрузку.

Видеореклама ценна не только возможностью показать ролик, но и глубокой аналитикой, которая помогает оптимизировать кампании. При помощи <TrackingEvents> вы можете собирать всю необходимую информацию.

Квартильные события: Start, FirstQuartile, Midpoint, ThirdQuartile, Complete

Четыре «квартиря» (25%, 50%, 75%, 100%) позволяют увидеть, на каком этапе пользователи чаще всего прерывают просмотр. Например, если на 50% ролика уходит большая часть аудитории, это сигнал о необходимости изменить креатив или сократить его длину.

Другие важные события: ClickThrough, Skip, Pause/Resume, Mute/Unmute

• ClickThrough: пользователь кликнул по ролику и перешёл на сайт рекламодателя.
• Skip: если ролик пропускаемый (skipoffset), этот трекинг фиксирует, на какой секунде произошло пропускание.
• Pause/Resume: помогает понять, делают ли пользователи перерывы во время просмотра рекламы.
• Mute/Unmute: отслеживает, выключают ли пользователи звук — полезно для анализа вовлечённости.

Все эти события отправляются на указанные URL, где собираются данные и формируется статистика о показах и вовлечённости.

Ошибки в VAST-XML могут привести к тому, что реклама не будет воспроизводиться или не отследятся ключевые события. Вот несколько практических советов:

Используйте CDATA для ссылок
Если в URL присутствуют спецсимволы (&, <, >), обязательно заключайте строку в CDATA, чтобы не ломать XML-синтаксис.

Следите за длительностью и skipoffset
<Duration> должен быть в формате HH:MM:SS (например, «00:00:15»).
Если ролик пропускаемый, skipoffset не может превышать длительность видео.

Проверяйте логическую согласованность

• Все Tracking-события должны соответствовать реальной структуре объявления (например, если нет skipoffset, не нужно указывать трекинг события skip).
• Убедитесь, что указанные размеры (width, height) совпадают с реальными параметрами видео, чтобы избежать проблем с отображением.

Ограничивайте число Wrapper
Если вы не контролируете цепочку, постарайтесь договориться с партнёрами, чтобы не выходить за 3–5 уровней вложенности.

Тестируйте тег в валидаторах
Прежде чем отдавать VAST в продакшен, проверьте его в инструментах вроде UMG VAST Inspector.

Структура VAST-XML — это краеугольный камень любой системы видеорекламы. Понимание того, как правильно прописывать ключевые элементы (<MediaFile>, <TrackingEvents>, <VideoClicks> и т.д.) и когда выбирать Inline или Wrapper, позволит вам избежать множества типичных ошибок и наладить точный учёт показов и кликов.

Основные выводы:

1. VAST — единый стандарт, упрощающий взаимодействие между плеерами и рекламными платформами.
2. XML-структура должна быть синтаксически корректной и логически связанной, включая необходимые теги и события.
3. Inline-вариант предпочтителен, когда рекламный ролик уже «под рукой», а Wrapper хорош для каскадной логики и передачи трекинга от нескольких сторон.
4. Трекинг-события обеспечивают глубокую аналитику (досмотр, пропуски, клики и т.д.) и дают возможность улучшать эффективность кампаний.

В следующей статье мы рассмотрим, как эволюционировал VAST со времён первых версий до новейших редакций 4.x и почему так важно быть в курсе новых спецификаций при работе с OTT и CTV.