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

Коротко

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

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

Если вы продаёте рекламу против видео, второе по важности инженерное решение в стратегии монетизации – сразу после выбора между SSAI и CSAI – это какой интерактивный слой рекламы поддерживать, потому что именно этот выбор тихо решает, какие рекламодатели вообще будут готовы покупать ваш инвентарь. VPAID был фактическим стандартом интерактивности десять лет и в продакшене доставлял пользователям malware; SIMID заменяет его sandboxed-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-consent, несоответствие частоты кадров рекламы и контента), которые ломают запуск за неделю до релиза.

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

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

До разговора о протоколах – об архитектуре. Client-Side Ad Insertion – это практика, при которой видеоплеер (в браузере, нативном приложении smart-TV или мобильном приложении) владеет каждым шагом жизненного цикла рекламы, кроме аукциона. Поток контента и поток рекламы – два отдельных источника. Когда плеер достигает рекламной паузы, он останавливает видеоэлемент контента, обращается к Ad Decision Server (ADS), скачивает ответ, выбирает креатив, накладывает второй видеоэлемент (или меняет источник на том же), проигрывает рекламу, отправляет beacon-ы трекинга – и только потом возобновляет контент. Каждое устройство, запускающее CSAI, везёт одну и ту же тяжесть: VAST-парсер, HTTP-клиент с cookie-jar, видеоэлемент, способный менять источник на лету, UI-оверлей для кнопок «пропустить» и click-through, отправитель десяти и более событий на одно показ, и всё чаще – 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 медиафайлов, длительность, beacon-ы трекинга, click-through, опциональные companion-баннеры и (в 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-ов трекинга, зарегистрировать click-through и запустить сторонний скрипт видимости – и при этом не возвращаться к рекламному серверу. Это и есть контракт.

Рекламные поды и wrapper-ы

Реальная 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-хоп – это сетевой round-trip; каждый round-trip – потенциальный таймаут. Рекомендация IAB по умолчанию – прерывать после пяти wrapper-хопов и таймаутить отдельный хоп на пяти секундах, хотя каждый коммерческий плеер выставляет оба числа как конфигурацию. Сбои по глубине wrapper – вторая по частоте ошибка VAST (код 302 в списке кодов IAB) после ошибок загрузки медиафайлов (код 303). Production-CSAI логирует глубину wrapper на каждом показе и поднимает alert, когда p95 пересекает три; как только пересекает четыре – вы оплачиваете работу рекламного сервера, которую пользователь никогда не увидит.

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

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

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

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-ы показа, при желании рендерил интерактивный UI и говорил плееру, когда закончил.

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

1. Безопасность. VPAID-бандл – это сторонний JavaScript, загруженный в страницу издателя с полным доступом ко всему, к чему может обратиться сам издатель. AdExchanger в 2017 году сообщал об обнаружении исследовательской компанией случая, когда VPAID-спецификация была использована для доставки malware; паттерн был простой – вредоносная 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.x полностью убрал поддержку VPAID. На 2026 год отправлять VPAID-креатив в современный плеерный стек – это примерно тот же жест, что отправлять Flash SWF: принимающая сторона может его и проиграть, аукционы за него не заплатят, а команды безопасности заблокируют. Если в 2026 году sales-rep продаёт «VPAID JS line item», обращайтесь с этим так же, как с предложением Flash – вежливо переключайте на SIMID.

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

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

Архитектурное отличие от VPAID – это весь смысл. SIMID-креатив работает в sandboxed iframe, а не в JavaScript-контексте плеера. Плеер и креатив общаются исключительно через определённый API postMessage; креатив не может читать cookie, трогать DOM за пределами своего iframe, инициировать сетевые запросы вне allow-list и валить плеер необработанным исключением. Видео – за плеером; интерактивный оверлей – за 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-squeeze-back, управляемая зрителем камера на спортивном моменте), 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-раннер инстанцирует каждый объявленный скрипт верификации в sandboxed-контексте, регистрирует видеоэлемент плеера как цель измерения и подаёт стандартизованный поток событий – 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"), поддержка audio-сессий и API регистрации friendly-obstruction – он позволяет плееру сообщить SDK, что его собственные элементы UI (play / pause / skip / fullscreen) не являются окклюзиями и не должны снижать viewability-оценку.
2. Режимы доступа согласовываются. Элемент <Verification> объявляет accessMode со значением LIMITED, DOMAIN, CREATIVE или FULL. LIMITED – значение по умолчанию и самое безопасное: скрипт верификации выполняется, но не видит страницу издателя. CREATIVE – самый строгий sandbox: скрипт может общаться с креативом, но не с издателем. FULL (редкий, требует прямых отношений с издателем) даёт скрипту доступ ко всей странице. Каждый плеер обязан применять запрошенный режим доступа или считать верификацию недействительной.
3. Friendly obstructions – не опция. Плеер, у которого UI-контролы накрывают видеоэлемент, увидит, что его viewability-оценки урезаны вдвое каждым основным MRC-аккредитованным вендором, если эти контролы не зарегистрированы как friendly obstructions. IMA SDK предоставляет API; open-source-плееры везут helper; интеграторы регулярно забывают про это и обнаруживают баг только после первого месячного отчёта по кампаниям. Не выпускайте CSAI-релиз без этого.

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

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

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

Direct-sold-инвентарь

Издатель продаёт показ напрямую рекламодателю. 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-medited спроса. Латентность: 800-1500 мс – самая дорогая из трёх, потому что вместо одного аукциона запускаются два, – но прирост выручки на премиум-видеоинвентаре стабильно фиксируется на уровне 15-35% с 2019 года, поэтому header bidding доминирует в премиум-сегменте.

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

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. Эта связка – то, что отгружает большинство независимых медиа-издателей; open-веб-собрат прямого IMA-подхода.

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

hls.js + кастомный или IMA-слой – аналогично Shaka, на стороне HLS. Богатая поверхность событий hls.js и возможность управлять вторым видеоэлементом из JS превращают кастомную 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-TV-приложения (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-покрытием, и даже у IMA в Vidaa и Tizen 8.0 в начале 2026 года есть дыры. Если меньше 10% просмотров с CTV – по умолчанию CSAI. Если 10-30% – запускайте параллельный пилот.

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

Ветка 3 – интерактивность. Если roadmap рекламного продукта требует интерактивных креативов (квизы, расширяемые баннеры, shoppable-реклама, управляемое зрителем видео), 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) за каждый concurrent stream. Вендорский путь – правильный выбор для большинства запусков; in-house путь – правильный, только когда экономика издателя зависит от маржи на рекламной паузе и издатель работает на масштабе FAST-канала.

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

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

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

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

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

CTA

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