Client-Side Ad Insertion (CSAI) и VAST / VPAID / SIMID

Коротко

Client-Side Ad Insertion (CSAI) – это технология, при которой именно видеоплеер, а не сервер-источник, обращается к серверу принятия рекламных решений (Ad Decision Server), загружает креатив, планирует вставку и воспроизводит рекламу через второй видеопоток, наложенный поверх основного контента. В основе CSAI лежит Video Ad Serving Template (VAST) – XML-формат, с помощью которого рекламные серверы и плееры обмениваются данными с 2008 года. За это время способ запуска интерактивной рекламы в VAST обновлялся трижды: от VPAID (устаревший стандарт, использующий произвольный JavaScript внутри плеера) к SIMID (запущенный в изолированном iframe через postMessage API), а измерение видимости рекламы было вынесено в отдельный стандарт – Open Measurement Interface Definition (OMID). CSAI – подходящее решение для открытого веба, где около 30% пользователей используют блокировщики рекламы, но неподходящий выбор для устройств Connected TV, которые не способны выполнять тяжёлые JavaScript-библиотеки и при этом приносят 95% роста рекламных доходов. В этой статье мы проходим весь стек CSAI: VAST 4.3 (декабрь 2022), четыре способа запуска интерактивной рекламы, рекламные поды (ad pods), header bidding, IMA SDK и open-source альтернативы – со ссылками на стандарты, расчётами и деревом решений на 2026 год: когда CSAI всё ещё остаётся актуальным ответом.

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

Если вы продаёте рекламу поверх видео, второе по значимости инженерное решение в стратегии монетизации – сразу после выбора между SSAI и CSAI – это поддержка того или иного интерактивного слоя рекламы, поскольку именно этот выбор определяет, какие рекламодатели вообще будут готовы покупать ваш инвентарь. VPAID был де-факто стандартом интерактивности десять лет и в продакшене приносил пользователям вредоносное ПО; SIMID заменяет его изолированным iframe; OMID измеряет видимость, не давая креативу доступа к странице. Продукт-менеджер, прочитавший эту статью, поймёт, почему «VPAID JS line item» от агентства в 2026 году – это повод отклонить кампанию, почему IMA SDK стал стандартом для открытого веба, почему open-source плагин videojs-contrib-ads до сих пор работает поверх того же VAST-контракта, и почему фраза «нам нужен VPAID-интерактив» от продавца обычно означает «нам нужен SIMID-интерактив, а продавец отстаёт на два года». Инженер уйдёт со знанием XML-структуры VAST 4.3, каталога сообщений SIMID 1.2, потока верификации OMID 1.5, правил последовательности рекламных подов и семи типичных багов в продакшене (таймауты из-за глубины wrapper-цепочки, чёрный кадр при склейке, утечки IFA, сбой загрузки OMID-скрипта, рассинхронизация ad-id, конфликты с cookie-согласиями, несоответствие частоты кадров рекламы и контента), которые могут сорвать запуск за неделю до релиза.

Это седьмая статья из девятиблочного Блока 9 (Операции, DRM, реклама и QoE) корпуса Video Streaming Learn от Фора Софт. Ознакомьтесь с SSAI подробно – это серверная альтернатива, с которой в статье сравнивается CSAI; метриками QoE – чтобы понять, как показатели рекламной эффективности интегрируются в тот же дашборд, который уже используют инженеры; и экономикой стоимости стриминга – для анализа unit-экономики, которая либо оправдывает, либо делает нерентабельным внедрение CSAI.

Что такое CSAI на самом деле

До разговора о протоколах – об архитектуре. Client-Side Ad Insertion – это практика, при которой видеоплеер (в браузере, нативном приложении smart-TV или мобильном приложении) контролирует каждый этап жизненного цикла рекламы, за исключением аукциона. Поток контента и поток рекламы – два независимых источника. Когда плеер достигает рекламной паузы, он останавливает видео с контентом, обращается к Ad Decision Server (ADS), получает ответ, выбирает креатив, подставляет второй видеоэлемент (или меняет источник в текущем), воспроизводит рекламу, отправляет трекинговые beacon’ы – и только после этого возобновляет контент. Каждое устройство, использующее CSAI, несёт одну и ту же нагрузку: VAST-парсер, HTTP-клиент с cookie-менеджером, видеоэлемент, способный динамически менять источник, UI-оверлей с кнопками «пропустить» и «перейти по ссылке», отправку более чем десяти событий на один показ, а всё чаще – OMID-совместимый раннер для верификации.

Контраст с Server-Side Ad Insertion (SSAI) – описанным в нашем разборе SSAI – резкий. В SSAI источник переписывает манифест для каждого зрителя так, что контентные и рекламные сегменты объединяются в единый непрерывный поток байтов, и плеер не может определить, что воспроизводил рекламу. В CSAI плеер сам воспроизводит рекламу, поэтому он точно знает, что она была показана. Эта одна архитектурная разница определяет всё остальное: где блокировщик может вмешаться, как засчитывается показ, кто оплачивает трафик креатива в CDN, кто несёт ответственность, если реклама не загрузится, и какие устройства вообще способны поддерживать такую интеграцию.

Цифры 2026 года объясняют приоритеты. Глобальное проникновение блокировщиков рекламы в начале 2026 года – 29,5% интернет-пользователей, около 1,77 млрд человек, а среди аудитории 16-64 лет ~31,5% говорят, что хотя бы иногда пользуются блокировщиком. Тестовые исследования CSAI против современных блокировщиков фиксируют 95% успешной блокировки на Windows-десктопах и 74% на Mac; опубликованные кейсы оценивают потерю выручки в 15-30% ожидаемого CSAI-инвентаря, со снижением fill-rate до 70-85% из-за таймаутов и ошибок загрузки. Тем временем американский рынок CTV-рекламы (где доминирует SSAI, потому что устройства не могут запускать тяжёлый рекламный SDK) прогнозировался крупными отраслевыми трекерами на 38 млрд долларов в 2026 году и 42 млрд в 2027 году. CSAI не умер – он сохранил открытый веб, где блокировщиков можно частично обойти, где JavaScript-SDK работают свободно, а интерактивность уровня SIMID-креатива в принципе возможна. Он проиграл гостиную.

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

Контракт VAST: что отправляет каждый рекламный сервер

В конечном счёте каждая интеграция CSAI сводится к одному документу – XML-ответу VAST. VAST – Video Ad Serving Template – публикуется и поддерживается IAB Tech Lab. С момента выхода версии 1.0 в 2008 году он служит универсальным «рукопожатием» между рекламным сервером и плеером. Текущая версия – VAST 4.3, выпущенная в декабре 2022 года; последнее редакционное обновление опубликовано 18 июля 2024 года. XSD-схема размещена на github.com/InteractiveAdvertisingBureau/vast, а PDF-спецификация – на iabtechlab.com/wp-content/uploads/2022/09/VAST_4.3.pdf.

Ответ VAST может быть представлен в одной из двух форм:

• InLine – полноценный рекламный блок. Содержит URL медиафайлов, длительность, beacons для трекинга, параметры click-through, опциональные сопутствующие баннеры и (в версии 4.x) блок <AdVerifications> со списком OMID-скриптов для верификации.
• Wrapper – редирект. Указывает плееру на следующий VAST URL, который нужно запросить вместо текущего. Wrapper’ы могут образовывать цепочку (рекламный сервер издателя → SSP → DSP → источник креатива); по рекомендации IAB плеер должен прервать цепочку после пяти wrapper’ов, а парсер плеера ОБЯЗАН вести счётчик таких переходов.

Типовой 4.3 InLine для 30-секундной линейной рекламы включает от восьми до двенадцати верхнеуровневых элементов: Ad, InLine, AdSystem, AdTitle, Impression, AdServingId (обязателен в 4.x), Creatives (оборачивает один или несколько блоков Creative/Linear), MediaFiles (по одной записи на ступень encoding-ladder), TrackingEvents, VideoClicks, AdVerifications и Extensions. Линейная реклама – pre-roll, mid-roll, post-roll – размещается внутри Linear; non-linear-оверлеи – внутри NonLinear; companion-баннеры – внутри CompanionAds.

Три изменения в VAST 4.x стоит запомнить, потому что на них ссылаются каждый вендорский блог и каждый тестер рекламного сервера:

1. Разделение mezzanine. В VAST 4.0 креатив разделён на высокобитрейтный mezzanine MP4 (<Mezzanine>), с которым может работать транскодер SSAI, и блок <MediaFiles> с готовыми к доставке вариантами, из которого CSAI-плеер выбирает нужную ступень ladder. Mezzanine – это источник истины; медиафайлы – это ступени, готовые к воспроизведению на клиентской стороне.
2. UniversalAdId. Элемент <UniversalAdId> содержит идентификатор, выданный рекламной системой; он сопровождает креатив на каждом этапе прохождения через wrapper-цепочку, чтобы системы учёта на более высоком уровне могли избежать дублирования одного и того же ролика, поданного через десять разных SSP.
3. AdVerifications и OMID. Начиная с версии 4.1 каноническим способом подключения стороннего скрипта верификации стал блок <AdVerifications> – список записей <Verification>, в которых указаны URL скрипта, ключ вендора, режим доступа (LIMITED, DOMAIN, CREATIVE, FULL) и параметры верификации. OMID-совместимый раннер плеера загружает каждый скрипт и передаёт ему стандартизированные события видимости. До версии 4.1 верификация передавалась через <Extension type="AdVerifications">; некоторые legacy-серверы до сих пор используют именно этот формат, и качественные плееры поддерживают оба варианта.

<?xml version="1.0" encoding="UTF-8"?>
<VAST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="vast.xsd" version="4.3">
  <Ad id="3201" sequence="1" conditionalAd="false">
    <InLine>
      <AdSystem version="4.0">FS-AdServer</AdSystem>
      <AdTitle>Brand X — Pre-roll 30s</AdTitle>
      <AdServingId>a7f4b09c-1c83-4a8c-9c75-7b1f0e1f0a2b</AdServingId>
      <Impression id="imp-1">https://imp.example.com/i?ad=3201</Impression>
      <Creatives>
        <Creative id="cr-1" sequence="1" adId="3201">
          <UniversalAdId idRegistry="ad-id.org">BRX-30S-2026</UniversalAdId>
          <Linear>
            <Duration>00:00:30</Duration>
            <TrackingEvents>
              <Tracking event="start">https://t.example.com/s</Tracking>
              <Tracking event="firstQuartile">https://t.example.com/q1</Tracking>
              <Tracking event="midpoint">https://t.example.com/m</Tracking>
              <Tracking event="thirdQuartile">https://t.example.com/q3</Tracking>
              <Tracking event="complete">https://t.example.com/c</Tracking>
              <Tracking event="skip">https://t.example.com/sk</Tracking>
            </TrackingEvents>
            <VideoClicks>
              <ClickThrough id="ct-1">https://brandx.example.com/lp</ClickThrough>
              <ClickTracking>https://t.example.com/ct</ClickTracking>
            </VideoClicks>
            <MediaFiles>
              <Mezzanine delivery="progressive" type="video/mp4"
                         width="1920" height="1080">https://cdn.example.com/mez/3201.mp4</Mezzanine>
              <MediaFile delivery="progressive" type="video/mp4" bitrate="3500"
                         width="1280" height="720" codec="avc1.4d4028" scalable="true"
                         maintainAspectRatio="true">https://cdn.example.com/mf/3201-720p.mp4</MediaFile>
              <MediaFile delivery="progressive" type="video/mp4" bitrate="1500"
                         width="854" height="480" codec="avc1.4d401f" scalable="true"
                         maintainAspectRatio="true">https://cdn.example.com/mf/3201-480p.mp4</MediaFile>
            </MediaFiles>
          </Linear>
        </Creative>
      </Creatives>
      <AdVerifications>
        <Verification vendor="omid-vendor.example.com-omsdk">
          <JavaScriptResource apiFramework="omid" browserOptional="false">
            https://verify.example.com/omid.js
          </JavaScriptResource>
          <VerificationParameters><![CDATA[opts=track,view]]></VerificationParameters>
        </Verification>
      </AdVerifications>
    </InLine>
  </Ad>
</VAST>

У плеера есть всё необходимое, чтобы проиграть рекламу, отправить десять трекинговых beacon-ов, зарегистрировать переход по ссылке и запустить сторонний скрипт отслеживания видимости – и при этом не обращаться к рекламному серверу. Вот что такое контракт.

Рекламные поды и обёртки

Реальная CSAI-интеграция почти никогда не показывает одну рекламу за паузу. Рекламные паузы на Connected TV обычно включают под (ad pod) из трёх–шести подряд идущих роликов; live-стримы вещательного качества могут содержать поды до восьми роликов. VAST кодирует под, присваивая атрибут sequence каждому элементу <Ad> внутри одного VAST-ответа – sequence="1", sequence="2" и так далее, – а плеер воспроизводит их последовательно, без перезагрузки между роликами. В VAST 4.2 появилось чёткое руководство по рекламным подам для OTT/CTV, где mid-roll из четырёх и более роликов – норма, и плеер обязан обеспечивать плавный переход от pre-roll к поду без потери кадра.

Wrapper-ы – обратная сторона той же монеты. Wrapper – это элемент <Ad>, содержащий <Wrapper> (а не <InLine>) и <VASTAdTagURI>, указывающий на следующий VAST-URL. Каждый переход через wrapper – это сетевой запрос; каждый запрос – потенциальный таймаут. Рекомендация IAB по умолчанию – прерывать цепочку после пяти переходов через wrapper и ограничивать время ожидания отдельного хопа пятью секундами, хотя каждый коммерческий плеер позволяет настраивать оба параметра. Ошибки, связанные с глубиной wrapper, – вторая по частоте проблема в VAST (код 302 в классификации IAB), уступая только ошибкам загрузки медиафайлов (код 303). Production-CSAI фиксирует глубину wrapper на каждом показе и генерирует оповещение, когда 95-й перцентиль превышает три; как только он достигает четырёх – вы оплачиваете работу рекламного сервера, которую пользователь никогда не увидит.

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

Работа плеера: пошаговый разбор с покадровой точностью

Понять CSAI – значит понять конечный автомат плеера в течение одной рекламной паузы. Ниже приведён канонический сценарий для pre-roll в открытом вебе; для mid-roll добавляется одна сложность (видео должно остановиться на известном кадре), для post-roll – одна сложность отбрасывается (возобновлять нечего). Числа в скобках – типичные временные бюджеты, которые необходимо соблюдать в продакшене.

1. t = 0 – пользователь кликает Play. Плеер инициализирует элемент видео-контента с preload="none", чтобы не тратить трафик на контент, пока идёт реклама.
2. t = 0 – отправлен рекламный запрос. Плеер собирает URL рекламного тега из макросов издателя (URL страницы, категория, IFA / GAID / GPID в средах с поддержкой идентификаторов, метаданные контента, custom key-values) и отправляет HTTPS GET. Цель: ответ ≤ 300 мс на открытом вебе; ≤ 600 мс на CTV.
3. t = 300 мс – пришёл ответ VAST. Плеер парсит XML. Если это Wrapper – запрашивает следующий хоп. Если глубина цепочки превышает заданный максимум, плеер записывает ошибку 302, отправляет beacon-ы об ошибке и переключается на резервный тег или на контент.
4. t = 600 мс – выбор медиафайла. Плеер проходит <MediaFiles> и выбирает наивысший битрейт, который вмещается во viewport, текущую полосу и кодеки. CTV-плееры часто жёстко склоняются к 1080p H.264 progressive MP4, потому что их адаптивная логика ограничена.
5. t = 600 мс – старт OMID-сессии. Если присутствует <AdVerifications>, плеер загружает каждый скрипт верификации через OM SDK-раннер, регистрирует видеоэлемент как цель измерения и отправляет sessionStart.
6. t = 800 мс – начало загрузки медиафайла. Плеер делает range-запрос за первый диапазон байтов выбранного MP4. TCP-/TLS-handshake к источнику креатива на первой рекламе сессии добавляет ещё 200-400 мс.
7. t = 1500 мс – событие canplay. Плеер набуферизовал достаточно для старта. Вызывает play() на рекламном видеоэлементе и показывает skip-after-N-seconds UI, если кампания разрешает пропуск.
8. t = 1500 мс – beacon-ы impression и start. Порядок важен: сначала URL Impression (победный beacon аукциона), потом событие start. Большинство рекламных серверов не выставит счёт, если Impression не пришёл в течение 30 секунд от запроса рекламного тега.
9. t = 9000 мс (30%) – beacon firstQuartile.
10. t = 15000 мс (50%) – beacon midpoint.
11. t = 22500 мс (75%) – beacon thirdQuartile.
12. t = 30000 мс (100%) – beacon complete. Видеоэлемент рекламы ставится на паузу, плеер либо переходит к следующей рекламе в поде (возвращаемся к шагу 4 с очередным <Ad>), либо возобновляет контент.
13. t = 30000 мс – sessionFinish. OMID-раннер закрывает сессию верификации; плеер сворачивает видеоэлемент рекламы и снова показывает видеоэлемент контента.
14. Итоговый бюджет на загрузку рекламы – 1500 мс для одиночного pre-roll в открытом вебе. CTV-плееры регулярно укладываются в 2500-4000 мс – это самый крупный фактор отказа на FAST-каналах.

Два из этих шагов заслуживают отдельного абзаца, поскольку именно на них в первую очередь сосредоточены все интеграции CSAI.

Шаг 7 – разрыв между canplay и play(). Веб-видеоэлемент, у которого набуферизован только первый range, очень часто отдаёт canplay, а потом сразу же ставит проигрывание на паузу. Защитные плееры держат play() до canplaythrough или до момента, когда buffered.end(0) - currentTime > 2. Без этой дисциплины зрители видят, как реклама стартует и сразу замирает на одну-три секунды, что событие playerStateChange от OMID добросовестно зафиксирует как «buffering during playback» – метрика, снижающая viewability-оценку инвентаря по MRC.

Шаг 12 – склейка обратно к контенту. Самый распространённый видимый баг CSAI – короткий чёрный кадр между последним кадром рекламы и первым кадром основного контента. Причина всегда одна: плеер сворачивает рекламный элемент, вызывает load() на элементе контента и play() на контенте до того, как первый кадр успел декодироваться. Защитные плееры держат элемент контента «тёплым» – на паузе с буферизованным первым сегментом – и переход происходит через play(), а не через load(), то есть осуществляется одно-кадровый swap, а не повторное декодирование.

VPAID: стандарт, который не должен был дожить до 2019 года

Чтобы понять, почему CSAI сегодня выглядит именно так, нужно разобраться со стандартом, который индустрия десятилетиями пыталась похоронить. VPAID – Video Player-Ad Interface Definition – был впервые опубликован IAB в 2008 году вместе с VAST 1.0, последняя ревизия – VPAID 2.0 – вышла в 2012 году. Цель была простой: позволить рекламному креативу выполнять произвольный JavaScript внутри плеера издателя, чтобы креатив мог быть интерактивным (квизы, мини-игры, расширяемые оверлеи, управляемые зрителем камеры) и чтобы вендор креатива мог измерять видимость на своих условиях.

Механизм: блок <MediaFile> в VAST мог объявлять атрибут apiFramework="VPAID" – и тогда ресурс становился не видеофайлом, а JavaScript-андлом, который плеер загружал, передавал ему ссылку на свой API и доверял «делать всё правильно». Андл возвращал объект creative с методами initAd, startAd, stopAd, pauseAd, resumeAd, getAdSkippableState и набором подписчиков событий. После этого андл отображал рекламу на canvas, воспроизводил кадры видео, отправлял beacon-ы о показе, при необходимости рендерил интерактивный интерфейс и сообщал плееру, когда завершает работу.

У этой архитектуры было три проблемы, которые инженерам не удалось решить.

1. Безопасность. VPAID-бандл – это сторонний JavaScript, загруженный на страницу издателя и обладающий тем же уровнем доступа, что и сам издатель. В 2017 году AdExchanger сообщил о случае, обнаруженном исследовательской компанией: VPAID-спецификация была использована для доставки вредоносного ПО. Схема была простой – вредоносная DSP входила в пул инвентаря, выигрывала аукцион, отдавала VPAID-креатив, JavaScript которого перенаправлял страницу на эксплойт-кит, после чего исчезала до следующего аудита рекламного сервера. По словам одного из исследователей, для владельца CTV-приложения разрешение на запуск VPAID-тега было «как отдать ключи от собственного дома».
2. Производительность. VPAID-креатив по определению представляет собой один JavaScript-поток, который должен одновременно рендерить видео на canvas, отправлять beacon-ы и выполнять произвольный код от вендора – всё это в главном потоке. Резкие скачки нагрузки на CPU во время VPAID-рекламы были нормой; задержки запуска в три–шесть секунд – обычным явлением; показатели отказов на мобильном вебе для VPAID-инвентаря были заметно хуже, чем для inline VAST.
3. Невозможность CTV. Smart TV, Roku, Fire TV Stick, Chromecast работают в ограниченных JavaScript-средах – некоторые из них вообще не поддерживают JavaScript на уровне плеера. VPAID изначально проектировался под полноценный браузер; на устройствах CTV около половины распространённых VPAID-бандлов не инициализируются вообще.

Google Ad Manager публично объявил о прекращении поддержки VPAID на собственном инвентаре с 2020 года, перейдя на SIMID. Сам IAB Tech Lab теперь относит VPAID к категории deprecated и зафиксировал, что VAST 4.х полностью исключил поддержку VPAID. Отправлять VPAID-креатив в современный плеерный стек в 2026 году – всё равно что использовать Flash SWF: его могут проиграть, но аукционы за него не заплатят, а команды безопасности заблокируют. Если в 2026 году sales-менеджер предлагает «VPAID JS line item», относитесь к этому так же, как к предложению использовать Flash – вежливо переводите клиента на SIMID.

SIMID: правильная замена VPAID

SIMID – Secure Interactive Media Interface Definition – это специально разработанная альтернатива VPAID от IAB Tech Lab. Первый публичный черновик был открыт для отзывов в апреле 2019 года; SIMID 1.0 был опубликован вскоре после этого; SIMID 1.1 добавил поддержку non-linear-рекламы и сообщений expand/collapse; SIMID 1.2, представленный для публичного обсуждения 8 сентября 2022 года вместе с VAST 4.3 и утверждённый вскоре после, ввёл адаптивный sizing (спецификация позволяет креативу сообщить -1 в смысле «я не знаю свой конечный размер»), поддержку squeeze-бэка (L-образный макет, где основной контент сжимается в угол, а остальная часть экрана становится рекламной) и ужесточение требований к безопасности: плеер обязан выдавать криптографически защищённые идентификаторы сессии.

Архитектурное отличие от VPAID – в этом и состоит весь смысл. SIMID-креатив работает в sandboxed iframe, а не в JavaScript-контексте плеера. Плеер и креатив обмениваются данными исключительно через определённый API postMessage; креатив не может читать cookie, изменять DOM за пределами своего iframe, инициировать сетевые запросы вне allow-лист или вызывать сбой плеера необработанным исключением. Видео – в ведении плеера; интерактивный оверлей – в ведении SIMID.

Каталог сообщений небольшой. Плеер отправляет Player:init, Player:startCreative, Player:adStopped, Player:adSkipped, Player:resize и несколько сообщений о смене состояния. Креатив отправляет Creative:resize, Creative:requestSkip, Creative:reportTracking, Creative:fatalError, Creative:requestExpand, Creative:requestCollapse и Creative:requestPlayResume. Каждое сообщение – это JSON, в котором содержатся session ID и монотонно возрастающий номер; у каждого сообщения задокументирован таймаут. SIMID-совместимый плеер требует примерно 600 строк интеграционного кода, тогда как VPAID-совместимый – 3000.

Интеграция в VAST прозрачна: креатив объявляет себя через apiFramework="SIMID" внутри блока <Linear> <MediaFile> или <InteractiveCreativeFile>, плеер загружает его в iframe с помощью sandbox="allow-scripts allow-same-origin" (или строже), после чего начинается процесс согласования. Google IMA SDK для HTML5, Android и iOS поддерживает client-side SIMID с 2020 года – DAI SDK для Android добавил эту функцию в версии 3.21.0. Современные open-source-плееры – hls.js + videojs-contrib-ads, Shaka Player, JW Player, THEOplayer, Bitmovin Player – все корректно обрабатывают SIMID из VAST 4.x.

Практический итог на 2026 год: если рекламная кампания предполагает интерактивность – квиз, карусель продуктов, L-queeze-бэк, управляемая зрителем камера на спортивном моменте – то SIMID становится основным каналом её доставки. VPAID – сигнал, что кампанию нельзя пропускать через QA.

OMID: измерение, отделённое от интерактивности

Третий стандарт в стеке CSAI – OMID (Open Measurement Interface Definition) и реализующий его SDK – OM SDK – оба поддерживаются IAB Tech Lab. OMID появился, потому что индустрия поняла: «интерактивность» (проблема VPAID → SIMID) и «измерение видимости» (была ли реклама действительно видна пользователю?) были искусственно объединены в VPAID без архитектурной необходимости и должны быть разделены.

Задача OMID – точная. Он определяет JavaScript- и нативный API, который поставщик видимости (Moat, IAS, DoubleVerify, Nielsen, Comscore и др.) реализует на стороне верификации, который плеер или приложение – на стороне измерения, а VAST-ответ связывает через блок <AdVerifications>. Когда плеер создаёт рекламную сессию, OM SDK-раннер инстанцирует каждый объявленный скрипт верификации в изолированном контексте, регистрирует видеоэлемент плеера как цель измерения и передаёт стандартизированный поток событий – impressionOccurred, loaded, start, firstQuartile, midpoint, thirdQuartile, complete, pause, resume, bufferStart, bufferFinish, skipped, volumeChange, playerStateChange, geometryChange – скрипту верификации. Скрипт выполняет свои расчёты (находится ли плеер на экране, включена ли громкость, не стоит ли видео на паузе более двух секунд) и отправляет отчёт в собственный бэкенд вендора.

Три аспекта OMID важны для инженера CSAI.

1. OMID 1.5 – текущая версия спецификации по состоянию на ратификацию 2025 года (Compliance API на complianceomsdkapi.iabtechlab.com/compliance ведёт список сертифицированных партнёров; последнее обновление списка ратификации – март 2026). В OMID 1.5 появилась улучшенная классификация рекламной сессии (adSessionType: "html", "native", "javascript"), поддержка аудиосессий и API регистрации friendly-обструкций – оно позволяет плееру сообщить SDK, что его собственные элементы интерфейса (воспроизведение, пауза, пропуск, полноэкранный режим) не являются окклюзиями и не должны снижать оценку видимости.
2. Режимы доступа согласовываются. Элемент <Verification> объявляет accessMode со значением LIMITED, DOMAIN, CREATIVE или FULL. LIMITED – значение по умолчанию и самый безопасный режим: скрипт верификации выполняется, но не имеет доступа к странице издателя. CREATIVE – самый строгий песочница: скрипт может взаимодействовать с креативом, но не с издателем. FULL (редкий, требует прямых отношений с издателем) предоставляет скрипту полный доступ ко всей странице. Каждый плеер обязан применять запрошенный режим доступа или считать верификацию недействительной.
3. Friendly obstructions – не опция. Если плеер использует элементы управления, накрывающие видео, и не зарегистрирует их как friendly obstructions, основные MRC-аккредитованные вендоры будут снижать его оценки видимости вдвое. IMA SDK предоставляет соответствующий API, open-source-плееры включают вспомогательные инструменты, но интеграторы часто забывают об этом и сталкиваются с проблемой только после получения первого месячного отчёта по кампаниям. Не выпускайте релиз CSAI без этой настройки.

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

Как реклама CSAI на самом деле доходит до плеера: direct, программатик, header bidding

VAST – это контракт; как именно URL рекламного тега обогащается победившей рекламой – другой вопрос, ответ на который изменился в 2017 году с появлением video header bidding. В 2026 году CSAI-интеграция должна будет работать в трёх режимах.

Прямые продажи

Издатель продаёт показ напрямую рекламодателю. URL рекламного тега ведёт на основной рекламный сервер издателя (Google Ad Manager, Magnite Ad Server, Equativ, FreeWheel для CTV). Рекламный сервер выбирает победивший креатив из собственных line items, возвращает VAST, и плеер его воспроизводит. Латентность: 100–300 мс в открытом вебе. Надёжность: самая высокая в стеке – один сетевой хоп, один decision engine, без аукциона.

Программатик через OpenRTB

Показ уходит в аукцион в реальном времени. Рекламный сервер издателя при получении запроса инициирует аукцион OpenRTB (спецификация IAB Tech Lab – OpenRTB 2.6 добавила поля video-pod в 2022 году и остаётся актуальной на 2026 год) к своим SSP, которые, в свою очередь, собирают ставки от DSP. Аукцион завершается примерно за 100 мс, победившая DSP возвращает VAST-URL, и рекламный сервер оборачивает этот URL в ответ VAST Wrapper. Плеер парсит wrapper, обращается за VAST к победившей DSP и воспроизводит рекламу. Латентность: 400–800 мс. Надёжность: средняя – три–четыре хопа, несколько сторон, любой из слоёв может уйти в таймаут.

Video Header Bidding (Prebid.js / Prebid Server)

Издатель решает не передавать аукцион исключительно основному рекламному серверу. Перед формированием URL рекламного тега header-bidding wrapper (Prebid.js на странице или Prebid Server в облаке) проводит собственный параллельный аукцион среди фиксированного набора demand-партнёров. CPM победителя и URL креатива упаковываются в URL рекламного тега в виде параметров hb_pb (price bucket Prebid) и hb_uuid (cache key Prebid), после чего происходит вызов основного рекламного сервера. Тот воспринимает header-bid как конкурирующий line item по отношению к direct-sold и SSP-обработанному спросу.

Латентность – 800–1500 мс – самая высокая из трёх схем, поскольку вместо одного аукциона запускаются два. Однако прирост выручки на премиум-видеоинвентаре стабильно держится на уровне 15–35% с 2019 года, поэтому header bidding доминирует в премиум-сегменте.

Три правила имплементации решают большую часть проблем в продакшене. Запускайте аукционы header bidding параллельно, а не последовательно, с таймаутом 1500 мс – пропущенная ставка лучше, чем потерянный пользователь. Используйте Prebid Server (в облаке) вместо Prebid.js (в браузере) в CTV-приложениях, где ресурсы CPU клиента ограничены. Всегда передавайте победившую ставку Prebid в основной рекламный сервер, а не напрямую в плеер – чтобы у существующих direct-sold-линейных позиций издателя оставался шанс на победу. Если нарушить третье правило, вы незаметно «съедите» свой высокомаржинальный инвентарь – ошибку, которую хотя бы раз совершал каждый издатель, подключавший Prebid к видео-стеку.

IMA SDK и open-source альтернативы

В production-развёртываниях CSAI сегодня четыре реализации охватывают примерно 95% интеграций.

Google IMA SDK – доминирующий выбор для открытого веба и мобильных приложений. Бесплатный, доступен для HTML5, Android, iOS, tvOS, Roku, Cast. Версия HTML5 SDK – 3.726.0 (2026); включает полный парсер VAST 4.x, поддержку SIMID с 2020 года, интеграцию с OMID 1.5, последовательную доставку подов, рендеринг companion-рекламы и тесную интеграцию с Google Ad Manager. Цена сделки: каждый рекламный запрос, обслуженный IMA, виден Google. Большинство издателей готовы принять этот компромисс, потому что альтернатива – писать собственный VAST-парсер.

videojs-contrib-ads + videojs-ima (open-source web) – канонический рекламный стек для Video.js. Плагин contrib-ads управляет state-машиной плеера: приостанавливает контент, отображает рекламу поверх видео, обрабатывает события и возобновляет воспроизведение основного контента; videojs-ima интегрирует IMA SDK, позволяя издателям проводить аукционы через Google Ad Manager прямо на сайте с использованием Video.js. Эта связка – стандартный выбор большинства независимых медиа-издателей; она является аналогом прямого подхода с IMA, но для открытого веба.

Shaka Player + кастомный рекламный слой – у Shaka нет встроенной поддержки рекламы, но он предоставляет необходимые примитивы (вставка cue в стиле text-track, динамическая смена источника). Издатели, выбирающие Shaka ради DASH-доставки, как правило, реализуют минимальный CSAI самостоятельно – VAST-парсер, Ad-оверлей, интеграцию IMA SDK – и выпускают единую интеграцию. Shaka 4.x в 2024 году получил экспериментальные API, связанные с рекламой, но подход по-прежнему остаётся «приносите своё решение».

hls.js + кастомный или IMA-слой – аналогично Shaka, но для HLS. Богатая система событий в hls.js и возможность управлять вторым видеоэлементом через JavaScript позволяют реализовать кастомную интеграцию CSAI за неделю силами одного инженера.

Заметка для продакт-менеджеров: разница между этими четырьмя решениями проявляется ровно в двух метриках – доле рекламных запросов, доходящих до beacon показа, и доле показов, проходящих MRC-видимость. IMA SDK – лидер по обоим параметрам, потому что любая другая реализация на каком-то уровне представляет собой аккуратную переделку того, что IMA уже делает. Если у инженерной команды при релизе CSAI возникает первое желание – «давайте напишем свой рекламный слой», – переключайте их на IMA, если только у вас нет конкретной причины (например, privacy-мандат, CTV-таргет, который IMA не поддерживает, или точка контроля, которую SDK не предоставляет) идти на кастомную реализацию.

Сравнительная таблица: CSAI vs SSAI vs SGAI в 2026

Одна сравнительная таблица фиксирует компромиссы, из-за которых ваша команда монетизации будет спорить. Она ориентирована на реальность 2026 года: SSAI доминирует в гостиной, CSAI – в открытом вебе, а SGAI занимает промежуточное положение.

| Эвристика Фора Софт | Если SIMID на ваших устройствах работает – используйте CSAI. Если нет – применяйте SSAI. Если ни одно из решений не выглядит оптимальным – запускайте 12-месячный пилот SGAI. |

«Частая ошибка – запускать CSAI на CTV-таргете без SDK-фолбэка. Самый болезненный сценарий отказа CSAI в 2026 году – запуск smart-ТВ-приложения (Tizen, webOS, Vidaa, Roku) без предварительной проверки, доступен ли IMA SDK или его аналог (Magnite, FreeWheel, CSAI-клиент AWS Elemental MediaTailor) для данного класса устройств. Веб-команда издателя строит интеграцию на основе IMA HTML5, CTV-команда пытается её перенести, но SDK отсутствует для Tizen 8.0, и в последний момент приходится писать собственный VAST-парсер – релиз сдвигается на три месяца. Решение – выбирать матрицу рекламного SDK ДО матрицы плееров. Доступность SDK – фундаментальное ограничение, а не интеграционная деталь.»

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

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

Фора Софт с момента выхода первого IMA SDK интегрирует решения CSAI в продукты видеостриминга, OTT, e-learning и телемедицины. На всех этих проектах наблюдается один и тот же паттерн: реализация рекламного слоя – не самая сложная инженерная задача. Главная сложность – синхронизация его с дашбордом QoE. Команда может за две недели реализовать чистый парсер VAST 4.3, за три – интеграцию OMID, а затем всё равно проведёт следующий квартал, объясняя аналитической команде, почему счётчик показов CSAI отличается от данных OM SDK на два процента и какой из них считать правильным (счётчик рекламного сервера используется в биллинге, а счётчик OM SDK – в MRC-аудите). Мы продаём именно вторую часть – согласование потока событий рекламного слоя с тем же конвейером, который уже собирает метрики QoE и аналитику, чтобы у продуктовой команды была одна единая истина, а не три. Наши вертикали, где эта работа уже внедрена, – видеостриминг, OTT/IPTV, e-learning, телемедицина, конференц-связь, AR/VR; типовая архитектура развёртывания – hls.js или Shaka на открытом вебе плюс нативное CTV-приложение с SSAI-фолбэком для устройств, до которых IMA SDK не дотягивается.

Дерево решений 2026: когда CSAI всё ещё остаётся правильным ответом

CSAI – не прошлое. Это реальность для открытого веба и значительной доли мобильного трафика. Вопрос в том, когда выбирать его вместо SSAI при запуске нового продукта. Дерево решений ниже – то, по которому мы реально идём с клиентами в 2026 году.

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

Ветка 1 – класс устройств. Если более 30% ожидаемых просмотров приходится на CTV (Roku, Fire TV, Tizen, webOS, Vidaa, Android TV) или издатель целенаправленно работает с этими платформами, по умолчанию выбираем SSAI. IMA SDK – единственный рекламный SDK с адекватным покрытием CTV, однако даже у него в Vidaa и Tizen 8.0 в начале 2026 года остаются пробелы. Если доля просмотров с CTV составляет менее 10% – по умолчанию используем CSAI. При показателе от 10 до 30% – запускаем параллельный пилот.

Ветка 2 – экспозиция ad-Blocker. Если ваша аудитория в основном использует desktop-устройства на Windows и технически подкована (например, сайты с developer tools, гейминг-аудитории, финансовые ресурсы), уровень блокировки рекламы может достигать 50–70% сессий. При таких показателях CSAI теряет 30–50% инвентаря по показам, и SSAI становится оптимальным решением даже для открытого веба. Если же аудитория в основном мобильная – Android и iOS (где распространённость ad-blocker ниже из-за ограничений платформ), – CSAI работает эффективно.

Ветка 3 – интерактивность. Если в дорожной карте рекламного продукта предусмотрены интерактивные форматы (квизы, расширяемые баннеры, шоппабельная реклама, видео с управлением со стороны зрителя), то CSAI – единственный вариант, при котором SIMID работает корректно. SSAI тоже может поддерживать интерактивные форматы, но только в гибридной схеме: SSAI-поток остаётся линейным, а поверх него накладывается клиентский SIMID-оверлей. В этом случае у вас получается два рекламных слоя, и архитектурная простота SSAI теряется – усложняется и отладка, и интеграция.

Ветка 4 – требования к измерению. Если ваши рекламодатели требуют MRC-сертифицированных поставщиков видимости (а это требование большинства корпоративных рекламодателей в 2026 году), оба подхода поддерживают OMID. У CSAI история реализации OMID более зрелая; у SSAI – требуется либо SGAI-гибрид, либо серверный IAB SDK for SSAI Ad Reporting (который всё равно нуждается в хуках плеера, чтобы быть полезным).

Ветка 5 – инженерная ёмкость. Если в команде меньше двух full-time бекенд-инженеров на шесть месяцев для сборки рекламного стека, CSAI – единственный реалистичный вариант, потому что основная сложность сосредоточена в библиотеках (IMA, contrib-ads), которые вы не разрабатываете самостоятельно. SSAI требует либо создания манипулятора манифеста (что связано с высокими затратами), либо оплаты вендору (Yospace, AWS Elemental MediaTailor, Broadpeak BkS400, Mux Stitch, Bitmovin Streams) за каждый одновременный поток. Вендорское решение – правильный выбор для большинства запусков; собственное (in-house) – оправдано только тогда, когда экономика издателя зависит от маржи на рекламной паузе и он работает в масштабе FAST-канала.

Если по всем пяти веткам приходит ответ «нам нужен CSAI», то скачиваемый в конце статьи материал – CSAI Integration Checklist – представляет собой семистраничный документ, с помощью которого наша команда держит запуск в графике.

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

• CSAI управляет открытым вебом, SSAI – гостиной. Сначала оценивайте разнообразие устройств – всё остальное вторично.
• VAST 4.3 – универсальный стандарт – любая интеграция CSAI в конечном счёте сводится к правильному парсингу этого XML.
• VPAID устарел. SIMID заменяет его для интерактивности, OMID – для измерения; запуск VPAID-креативов в 2026 году – повод отклонить кампанию.
• Глубина цепочки обёрток – самый затратный параметр CSAI-тега: каждый переход – это сетевой round-trip и потенциальный таймаут.
• Регистрация friendly obstructions в OMID не является опциональной – без неё ваши оценки видимости будут искусственно занижены вдвое.
• Header bidding приносит прирост выручки 15–35% на премиальном инвентаре, но добавляет задержку 400–700 мс в рекламную паузу.

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

• SSAI подробно – архитектура, с которой статья противопоставляет CSAI.
• Метрики QoE, которые должен показывать каждый дашборд – где события рекламного слоя коррелируют с показателями качества плеера.
• Экономика стриминга – unit-экономика, которая либо оправдывает, либо делает невозможным запуск CSAI.

CTA

• Поговорить с инженером по стримингу – забронируйте 30-минутный скоупинг-колл.
• Посмотреть наши кейсы – OTT, FAST, e-learning и проекты по видеонаблюдению, которые уже отгружают CSAI сегодня.
• Скачать CSAI Integration Checklist – одностраничный A4-референс, по которому наша команда держит запуск на рельсах.