SSAI – вставка рекламы на стороне сервера: подробный разбор

TL;DR

SSAI (Server-Side Ad Insertion, вставка рекламы на стороне сервера) – это техника, при которой стриминговый origin на лету переписывает манифест каждого зрителя, вшивая персонализированные рекламные сегменты прямо в тот же поток байтов, по которому идёт контент: плеер видит одну непрерывную программу, а не последовательность «контент → реклама». SSAI – основной путь монетизации для Connected TV, FAST-каналов, прямых трансляций спорта и pay-TV-стиля OTT: он переживает блокировщики рекламы, работает на всех классах устройств без отдельного SDK и даёт зрителю опыт уровня обычного телевидения. Платой становится сложность пайплайна: нужны метки SCTE-35 в контрибутивном потоке, manifest manipulator, персонализирующий каждую сессию, перекодированные креативы под лестницу битрейтов контента и серверный слой трекинга, который сам отправляет VAST-маяки. Эта статья проходит весь путь – от метки SCTE-35 в фиде с камеры до маяка показа, который закрывает воронку, – со ссылками на стандарты, арифметикой и деревом решений 2026 года «SSAI vs CSAI vs новый SGAI».

Зачем это важно

Если ваш продукт зарабатывает на рекламе, решение, где именно реклама вшивается в поток, – самое крупное архитектурное решение в монетизационном roadmap. SSAI – дефолт для Connected TV и FAST, потому что он работает на устройствах, где невозможно запустить JavaScript-SDK рекламы: каждый Smart TV на Tizen, webOS и Vidaa, каждый Roku, каждый Fire TV, каждая STB. Это единственный путь, который выдерживает блокировщики рекламы в масштабе. Он же в три-пять раз дороже клиентской вставки в эксплуатации и сильно усложняет измерения. Продакт-менеджер после этой статьи поймёт, почему запуск FAST-канала требует именно SSAI, а не VAST в браузере; почему «прикрутим рекламу позже» – это полугодовой инженерный проект, а не спринт; и почему аналитики первый квартал после запуска проводят в спорах о подсчёте показов. Инженер унесёт с собой набор команд SCTE-35, синтаксис EXT-X-DATERANGE в HLS, структуру MPD с несколькими Period в DASH, обмен VAST 4.3, точку подключения OM SDK и четыре прод-бага, которые проявляются за неделю до запуска.

Статья – шестая в блоке 9 (Operations, DRM, Ads, QoE) Фора Софт Learn по видеостримингу. Полезно прочитать DRM 101: почему три системы и почему вы внедряете все три – слой шифрования, с которым SSAI сосуществует; CSAI и VAST/VPAID/SIMID – клиентскую альтернативу, против которой эта статья позиционируется; и метрики QoE для дашборда стриминга – фреймворк, по которому ad-команда будет общаться с инженерной.

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

Сначала определение. SSAI – это практика подмены или чередования сегментов HLS (HTTP Live Streaming) или DASH (Dynamic Adaptive Streaming over HTTP) рекламными сегментами – на origin или на сервисе manifest manipulator перед origin – до того, как манифест дойдёт до плеера. Плеер видит один media-playlist или один MPD (Media Presentation Description), скачивает непрерывную последовательность сегментов и рендерит кадры так, будто вставки и не было. Вся работа, которую обычно делает рекламный SDK внутри плеера, – вызов ad decision server, скачивание креатива, планирование склейки, отправка маяков показа, – переезжает на сервер.

Контраст с CSAI (Client-Side Ad Insertion, вставка рекламы на стороне клиента) – старым подходом – резкий. В CSAI плеер держит два источника: поток контента и поток рекламы. Дойдя до рекламной паузы, плеер останавливает основной video-элемент, обращается к ad decision server, скачивает манифест рекламы, проигрывает её через второй video-элемент (или тот же, но с новым src), затем возвращается к контенту. Каждый переход – это смена в пайплайне рендера, которую пользователь чувствует; каждый запрос рекламы – сетевой round-trip, который может упасть; каждый рекламный URL блокировщик может узнать по шаблону. CSAI отлично работает в открытом вебе, где JavaScript-SDK вроде Google IMA берёт всё на себя; плохо работает на Smart TV, где такой SDK не запустить; и полностью проигрывает современным блокировщикам.

Цифры 2026 года объясняют приоритеты. Мировой доход FAST (Free Ad-Supported Streaming Television) в 2026 году оценивается в 12,23 млрд долларов против 10,60 млрд в 2025-м. Расходы на рекламу в Connected TV в США перевалили в 2026 году за 37,95 млрд долларов. Yospace, крупнейший pure-play SSAI-вендор, в апреле 2026-го преодолел отметку 10 млрд ежемесячных вставок. Вся кривая роста – внутри устройств класса «только SSAI» или «в основном SSAI». CSAI не исчез: он по-прежнему доминирует в браузерах и в коротких роликах, – но деньги в гостиной, а гостиная работает на SSAI.

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

Пять стадий пайплайна SSAI

Любая SSAI-развёртка, независимо от вендора, имеет одну и ту же пятиступенчатую форму. Знание названий стадий – это разница между отладкой интеграции за день и отладкой за неделю.

Стадия 1 – вставка метки. Где-то выше packager-а оборудование отмечает моменты, в которые разрешена реклама. В вещательной контрибуции это master-control automation; в облачном плейауте – origin, управляемый расписанием; на live-спорте – оператор, нажимающий кнопку cue в момент окна коммерческой паузы. Метка – сообщение SCTE-35, мы разберём его в следующей секции. Packager доносит метку до сегментов и сигнализирует о ней в манифесте.

Стадия 2 – запрос манифеста и персонализация. Когда плеер зрителя запрашивает манифест, запрос идёт не на origin, а на SSAI-сервис. Сервис смотрит сессию зрителя (или создаёт новую), читает upstream-манифест от origin, находит в нём метки SCTE-35 и решает, что с каждой делать.

Стадия 3 – решение по рекламе. Для каждой метки, попадающей в playback-окно этого зрителя, SSAI-сервис обращается к Ad Decision Server (ADS), который говорит на языке VAST (Video Ad Serving Template). В запрос идут IP, user-agent, IFA (рекламный идентификатор устройства), publisher ID, метаданные контента и длительность слота. ADS возвращает один или несколько XML-документов VAST 4.x, перечисляющих креативы, которые SSAI-сервису надо вставить.

Стадия 4 – кондиционирование рекламы. Исходники рекламы почти никогда не совпадают с лестницей битрейтов контентного потока. Реальная реклама приходит от агентств в виде mezzanine MP4; live-поток – это CMAF на 1080p, 720p, 540p, 360p, H.264 + AAC. SSAI-сервис поэтому перекодирует (или подтягивает заранее перекодированные версии) каждого креатива в сегменты, у которых те же разрешения, битрейты, параметры кодека и длительность сегмента, что у контента, – чтобы склейка была побайтово невидима для ABR-логики плеера. AWS Elemental MediaTailor называет этот шаг ad conditioning и предлагает два режима: динамическое перекодирование (по умолчанию, медленнее, гибче) и BYOA (bring-your-own-ads, январь 2025, быстрее, но требует подготовки заранее).

Стадия 5 – выдача персонализированного манифеста. SSAI-сервис эмитирует per-session-манифест, в котором оригинальные сегменты контента и подготовленные сегменты рекламы переплетаются на cue-точках. Для HLS это означает подмену или вставку URI сегментов и добавление тегов #EXT-X-DISCONTINUITY вокруг рекламного блока. Для DASH – добавление нового <Period> между двумя контентными периодами. Плеер скачивает манифест, забирает сегменты подряд и проигрывает результат. Первый маяк показа уходит с SSAI-сервиса в момент запроса первого рекламного сегмента.

Весь цикл повторяется для каждого зрителя, каждой рекламной паузы, каждого решения «куда поставить рекламу». Линейный FAST-канал на 5 000 одновременных зрителей с 14 паузами в час прогоняет через SSAI порядка 70 000 персонализированных манифестов в час – каждый подписан и закеширован по сессии.

SCTE-35 – внутриполосный язык меток

SCTE-35 – формально «Digital Program Insertion Cueing Message», опубликованный Society of Cable and Telecommunications Engineers и принятый как ANSI/SCTE 35 – самый важный стандарт во всём ad-insertion-стеке. Его читают все SSAI-вендоры, пишут все энкодеры, спрашивают все conformance-тесты. Редакция 2023 года (ANSI/SCTE 35 2023r1, формально одобрена ANSI 29 февраля 2024) добавила вложенные события, иерархические sub-events и переименование, разделившее стандарт на SCTE 35-1 (legacy splice-based and time-based signaling) и SCTE 35-2 (event-based signaling). Когда в блог-посте 2026 года написано «SCTE-35» без номера части, автор обычно имеет в виду SCTE 35-1.

Единица SCTE-35 – splice_info_section, бинарная секция в MPEG-2-стиле, оборачивающая одну из трёх команд и ноль или больше дескрипторов. Три команды, которые встречаются на практике:

• splice_insert() – оригинальная, кадрово-точная команда склейки. Несёт splice event ID, флаг out-of-network (открытие паузы) или back-in-network (закрытие), опциональный pre-roll и длительность паузы. До сих пор самая частая команда в кабельных контрибутивных фидах.
• time_signal() – облегчённая команда, которая просто несёт временную метку. Почти никогда не используется одна; существует, чтобы рядом ехали segmentation_descriptor, объясняющие, что эта метка означает.
• splice_null() – heartbeat. Сообщает «я живой, событий сейчас нет». Нужен для мониторинга.

Современная SCTE-35 живёт в segmentation_descriptor. Он несёт 32-битный segmentation_event_id, segmentation_duration, segmentation_type_id – идентификатор того, что это за сегмент (Provider Advertisement Start 0x30, Provider Advertisement End 0x31, Distributor Advertisement Start 0x32, Distributor Advertisement End 0x33, Provider Placement Opportunity Start 0x34, Network Start, Chapter Start, Break Start и десятки других), – и segmentation_upid, который уникально идентифицирует сегмент в supply chain. На обычную рекламную паузу обычно приходит пара: time_signal() + segmentation_descriptor типа 0x34 (placement opportunity start), а через 60 или 120 секунд – такая же пара с типом 0x35 (placement opportunity end).

В MPEG-2 Transport Stream сообщения SCTE-35 едут в собственном elementary stream со stream_type 0x86. В CMAF-сегменте – в emsg-боксе. В HLS media playlist – в теге EXT-X-DATERANGE. В DASH MPD – в EventStream. Четыре носителя существуют потому, что SCTE-35 пережил MPEG-2 TS.

SCTE-35 в HLS

Apple HLS Authoring Specification документирует единственный поддерживаемый Apple способ нести SCTE-35 в HLS-плейлисте: тег EXT-X-DATERANGE, атрибуты которого называют команду и оригинальный бинарный payload. Каждая splice_info_section() превращается в один EXT-X-DATERANGE с атрибутом SCTE35-CMD. Событие out-of-network через splice_insert() становится тегом с SCTE35-OUT; парное back-in – тегом с SCTE35-IN и тем же ID. Минимальная мид-роллная метка выглядит так:

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:4321
...
#EXT-X-DATERANGE:ID="ad-break-9012",START-DATE="2026-05-26T12:00:00Z",DURATION=60.0,SCTE35-OUT=0xFC302F00000000...
#EXT-X-DISCONTINUITY
#EXTINF:6.0,
ad-segment-0001.m4s
#EXTINF:6.0,
ad-segment-0002.m4s
... (ещё восемь рекламных сегментов, итого 60 секунд) ...
#EXT-X-DISCONTINUITY
#EXT-X-DATERANGE:ID="ad-break-9012",SCTE35-IN=0xFC302F00000000...
#EXTINF:6.0,
content-segment-4332.m4s

Теги #EXT-X-DISCONTINUITY говорят плееру: ждите другой энкод (PTS-таймстемпы рекламы не совпадают с контентом), сбросьте decode-пайплайн на границе. Без них видеодекодер плеера споткнётся на скачке таймстемпа, и зритель увидит застывший кадр.

SCTE-35 в DASH

Спецификация DASH, ISO/IEC 23009-1, несёт SCTE-35 в элементе EventStream внутри <Period> или во inband-emsg-боксах внутри сегментов. MPD называет схему: schemeIdUri="urn:scte:scte35:2014:xml+bin" (бинарь в base64) или urn:scte:scte35:2013:xml (XML-форма). Для мид-роллов более распространён шаблон с несколькими периодами: контентный Period A заканчивается на cue-границе, открывается новый Period B с AdaptationSet-ами рекламы, после паузы возобновляется контентный Period C. Каждый период – самостоятельная презентация со своими Representation-ами; именно поэтому SSAI-сервис может подменять рекламу, не трогая таймстемпы контента.

Одна мид-ролл-пауза в DASH (сильно сокращённо):

<MPD type="dynamic" ...>
  <Period id="content-pre" start="PT0S" duration="PT45M0S">
    <AdaptationSet contentType="video">...</AdaptationSet>
  </Period>

  <Period id="ad-9012" start="PT45M0S" duration="PT1M0S">
    <EventStream schemeIdUri="urn:scte:scte35:2014:xml+bin" timescale="90000">
      <Event presentationTime="0" duration="5400000" id="9012">
        <scte35:Signal>
          <scte35:Binary>/DAvAAAAAAAA...</scte35:Binary>
        </scte35:Signal>
      </Event>
    </EventStream>
    <AdaptationSet contentType="video">...</AdaptationSet>
  </Period>

  <Period id="content-post" start="PT46M0S">
    <AdaptationSet contentType="video">...</AdaptationSet>
  </Period>
</MPD>

DASH-IF Implementation Guidelines for Advanced Ad Insertion подробно описывают этот шаблон, включая опциональный механизм разрешения xlink:href (контент рекламного периода подтягивается с другого URL в момент проигрывания) и модель remote-period, которая прячет рекламу от исходного манифеста до late binding.

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

Обмен VAST и кондиционирование рекламы

Video Ad Serving Template – VAST – второй стандарт, к которому прикасается любой SSAI-проект. VAST – XML-схема IAB Tech Lab. VAST 4.0, выпущенный в 2016-м, стал первой большой версией, прямо рассчитанной на server-side ad stitching: он добавил поле mezzanine-файла для качественного исходника, который SSAI-сервис мог перекодировать; несколько рендиций для ABR-совместимой выдачи; универсальные ID; метаданные verification-вендоров. VAST 4.1, 4.2 и 4.3 (последняя на 2026 год) подтянули схему, добавили опциональный <UniversalAdId>, по которому агентства отслеживают креатив через supply chain, и структурированный блок <Verification>. VAST CTV Addendum 2024, опубликованный IAB Tech Lab в июле 2024-го, добавил поверх любой версии VAST поддержку high-resolution креативов, регистрацию рекламы по ACIF (Audio Common Industry Format) и иконки соответствия Digital Services Act; SSAI-вендоры для Connected TV обязаны поддерживать и 4.3, и аддендум.

Обмен VAST в SSAI-контексте выглядит так. SSAI-сервис держит метку SCTE-35, решает, что данный зритель имеет право на рекламу в этом слоте, и POST-ит запрос VAST на URL Ad Decision Server-а. В запросе – publisher ID, IFA зрителя, IP и user-agent, метаданные контента, длительность слота. ADS возвращает XML-документ VAST 4.3. Каждый <Ad> несёт <InLine> (креатив лежит у ad server-а) или <Wrapper> (креатив лежит у нижестоящего сервера, и SSAI-сервис должен пройти по этой цепочке). Внутри блок <Creatives> называет media-файл (часто mezzanine MP4), список <TrackingEvents> (impression, firstQuartile, midpoint, thirdQuartile, complete, mute, pause, fullscreen, close, skip), опциональный <ClickThrough> и <Verification> для viewability-вендоров.

SSAI-сервис не передаёт VAST-документ плееру. Он его читает, скачивает или подтягивает заранее подготовленные версии перечисленных креативов и заменяет VAST-tracking-URL на собственные конечные точки маяков. С точки зрения плеера реклама – это просто новые сегменты. С точки зрения рекламной экосистемы импрешн- и quartile-события улетают с IP SSAI-сервиса, а не с устройства.

Кондиционирование рекламы – этап, о котором не любят говорить

Агентство присылает mezzanine MP4 на 50 Мбит/с, 1920×1080, 30 кадров в секунду, H.264 high profile, AAC stereo. Ваш live-поток – CMAF на 6/4/2,5/1,2 Мбит/с, четыре разрешения, 2-секундные сегменты, H.264 main profile, AAC stereo. Эти два потока нельзя склеить как есть – плеер споткнётся на границе, как только сменится профиль, GOP-структура или параметр-сет кодека.

Поэтому SSAI-сервис переэнкодирует (или подтягивает уже переэнкоженные) версии рекламы для каждой рендиции, которую использует контент: совпадает профиль кодека, формат пикселя, цветовое пространство, длительность сегмента, частота аудио. Получается параллельный набор рекламных сегментов, которые ложатся в группу рендиций контента так, будто реклама – продолжение контента. AWS Elemental MediaTailor называет это «ad conditioning»; режим transcode делает работу on-demand и кеширует результат на час; режим none доверяет VAST-ответу, который уже указывает на pre-conditioned файлы. Фича BYOA (январь 2025) позволяет издателям прописывать в VAST URL заранее перекодированных HLS/DASH-манифестов рекламы прямо в атрибутах creative file, минуя динамическую перекодировку. В мае 2026 добавились ad-trickplay-персонализация (превью-кадры скраб-бара для VOD показывают именно рекламу, когда зритель ведёт ползунок по рекламному отрезку) и compact DASH-манифесты (дедупликация AdaptationSet между рекламными и контентными периодами, меньший MPD, быстрее startup).

Кондиционирование – самая дорогая строка в SSAI-счёте. 60-секундная реклама в пяти рендициях на 30 fps декодируется в 9 000 кадров, энкодится в примерно 30 мегабайт сегментов, и оживлённый FAST-канал может прокачивать через перекодер 200 уникальных креативов в час. Если кеш креативов попадает в 70 %, счёт терпимый; если ротация креативов высокая (новая реклама каждому зрителю и каждой паузе), расходы на перекодер растут быстрее расходов на CDN.

Трекинг и viewability в SSAI: где сидит сложная задача

В CSAI рекламный SDK плеера сам отправляет impression- и quartile-маяки на ad server. IP в маяке – зрителя. User-agent – зрителя. OM SDK от viewability-вендора крутится прямо в плеере и сообщает фактические пиксели на экране. Экосистема доверяет этим данным, потому что они с устройства.

В SSAI ничего из этого не верно по умолчанию. Маяк показа уходит с SSAI-сервиса. IP – egress-IP SSAI-сервиса. User-agent – то, что SSAI решил переслать. OM SDK на устройстве не работает, потому что между рекламой и плеером нет JS-SDK. Появляется gap в измерениях: ad server считает, что реклама была доставлена, но не знает, отрисовало ли её устройство.

Появились три митигейшна.

Первый – SSAI-сервис форвардит телеметрию устройства на ad server. VAST 4.1 и старше добавили заголовки запроса – X-Device-User-Agent, X-Device-IP, X-Forwarded-For, X-Device-Referer, – которые SSAI обязан заполнить из входящего запроса плеера. По свежим отраслевым данным только около 26 % SSAI-показов уходят с полным набором transparent-заголовков; остальные непрозрачны – отсюда и высокие показатели мошенничества в CTV.

Второй – плеер запускает тонкий tracking-SDK, который мапит рекламные слоты на позиции воспроизведения. SSAI-сервис рядом с медиа-манифестом отдаёт tracking-манифест (JSON со списком таймстемпов quartile-событий каждой рекламы). SDK плеера следит за позицией, дёргает OM SDK на нужных моментах и репортит обратно. По такому пути идут OM SDK-интеграция Yospace, Mux Data SDK, Innovid SDK. Решение работает только на устройствах, способных хостить SDK.

Третий – на Smart TV, где кастомный SDK не запустить, SSAI-сервис использует события запроса сегментов как прокси. Показ срабатывает, когда запрошен первый рекламный сегмент; firstQuartile – когда запрошен сегмент, покрывающий 15-ю секунду 60-секундной рекламы; и так далее. Прокси приблизительный – fetched-сегмент не равен отрендеренному кадру, – но это лучшая доступная метрика на нерасширяемом устройстве.

IAB Open Measurement SDK (OM SDK), версия 1.5, июнь 2024-го – индустриальная стандартная библиотека viewability и ad-verification. Она крутится в плеере на устройствах, которые её тянут (большинство браузерных плееров, нативные iOS- и Android-плееры), даёт стандартное API для verification-вендоров (DoubleVerify, IAS, Moat) и репортит impression, изменения геометрии и метрики viewability обратно через SDK. В SSAI OM SDK работает в обёртке плеера там, где может; на Connected TV, которые не могут, SSAI-сервис выставляет флаг «non-OM verifiable», и показы попадают в отчёт с пониженной достоверностью.

Практический вывод: измерения в SSAI всегда на шаг хуже, чем в CSAI, и этот разрыв – одна из структурных причин, почему CSAI до сих пор живёт в открытом вебе.

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

Live SSAI vs VOD SSAI: налог на задержку

VOD-SSAI – простой случай. Контент закончен, метки запекаются в манифест на этапе packaging, у перекодера часы на подготовку креативов, у SSAI-сервиса нет давления реального времени. Per-session-манифест собирается за миллисекунды, и весь поток показов укладывается в один HTTP-ответ, возвращающий манифест.

Live-SSAI – сложный. Метка приходит в контрибутивном фиде за секунды до открытия паузы; SSAI должен вызвать ADS, подготовить рекламу, вшить её в манифест и выдать персональный плейлист раньше, чем плеер попросит следующий сегмент, – и без поломки ABR-логики. Исторически round-trip добавлял 15–30 секунд задержки live-SSAI поверх обычного LL-HLS или LL-DASH: пауза требовала запаса по времени. В 2026-м два архитектурных хода сжимают эту цифру.

Первый – edge-resident SSAI: manifest manipulator работает не в одном дата-центре, а на edge-узлах CDN. Зритель в Сан-Паулу попадает на сан-паульский edge, у которого уже есть и метка, и креатив, и логика персонализации. Сетевая компонента RTT падает со ~150 мс (трансконтинент) до ~10 мс (городская сеть), что в большинстве сценариев убирает потребность в look-ahead-буфере.

Второй – пулы заранее перекодированной рекламы. VAST-ответ больше не указывает на mezzanine, нуждающийся в перекодировании; он указывает на готовые HLS/DASH-манифесты, которые SSAI-сервис вшивает без дополнительного энкодинга. AWS MediaTailor BYOA (январь 2025) – одна из реализаций; Bitmovin, THEO, Yospace предлагают аналогичные.

Бюджет задержки для live-SSAI 2026 выглядит так. Возьмём 100-миллисекундное окно glass-to-glass:

Захват → энкодер:               30 мс
Энкодер → packager:             60 мс
Packager → ingest origin:       50 мс
Origin → SSAI-сервис:           20 мс   (та же зона)
SSAI: решение по рекламе:       80 мс   (кешированная реклама)
SSAI: кондиционирование:        10 мс   (BYOA, заранее подготовлено)
SSAI → CDN edge:                15 мс
CDN edge → зритель:            120 мс
Плеер: декод и рендер:          40 мс
---------------------------------------
Итого glass-to-glass:          425 мс

Тот же бюджет без BYOA (динамическое перекодирование) и без edge-resident SSAI:

Захват → энкодер:               30 мс
Энкодер → packager:             60 мс
Packager → ingest origin:       50 мс
Origin → SSAI-сервис:          150 мс   (другая зона)
SSAI: решение по рекламе:      180 мс   (холодный кеш)
SSAI: кондиционирование:       800 мс   (динамика)
SSAI → CDN edge:               150 мс
CDN edge → зритель:            120 мс
Плеер: декод и рендер:          40 мс
---------------------------------------
Итого glass-to-glass:        1 580 мс

Архитектура 2026 года примерно в четыре раза быстрее архитектуры 2022 года, и именно этот разрыв объясняет, почему live-спортивные SSAI-деплои наконец перестали быть теми самыми «15-секундными компромиссами», которые помнят все. До чистого live без рекламы они по-прежнему чуть отстают – шаги ad-decision и ad-conditioning не исчезают полностью, – но разрыв теперь треть секунды, а не восемь.

Бюджет задержки также объясняет, почему live-SSAI требует pre-roll SCTE-35. Метка выдаётся не в момент склейки, а за 4–6 секунд до неё, чтобы SSAI успел вызвать ADS, подготовить рекламу и переписать манифест до того, как плеер попросит сегмент после метки. Без pre-roll live-SSAI работает только на VOD-подобных потоках с длинным look-ahead; с ним – и live, и near-live на одном пайплайне.

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

SSAI vs CSAI vs SGAI: решение 2026 года

Третий вариант в комнате – SGAI (Server-Guided Ad Insertion), формализованный IAB Tech Lab в конце 2025 как гибрид, закрывающий пробел в измерениях и жёсткость персонализации чистого SSAI. В SGAI сервер по-прежнему решает, какая реклама в каком слоте идёт – это серверная часть, – но плеер скачивает креатив и сам гоняет стандартный OM SDK и VAST-трекинг. Сервер отдаёт манифест с cue-точками плюс sidecar-JSON с описанием рекламы; плеер уважает оба. Инициатива Ad Format Hero, запущенная IAB Tech Lab вместе со SGAI-спецификацией, добавляет поддержку Pause ads, Squeezebacks, Overlays и L-shaped реклам, которые чистый SSAI не умеет, потому что для них нужно клиентское композитинг.

Дерево решений 2026 года – какую модель выбрать – выглядит так:

Прямое чтение таблицы: SSAI – дефолт для CTV и FAST сегодня; SGAI – стратегическая ставка на 2027–2028, если IAB-спека получит индустриальную тягу; CSAI – правильный инструмент для браузерных и коротких форматов, где на каждом устройстве уже есть JS-SDK. Большинство современных OTT-сервисов запускают все три модели в зависимости от класса устройства – SSAI на Smart TV, CSAI в вебе, SGAI в мобильном – и оставляют выбор слою абстракции на сессию.

Распространённые ловушки SSAI

Четыре бага, которые блокируют запуск за неделю до даты:

«Ловушка – метка без pre-roll. Контрибутивный фид выдаёт splice_insert точно в момент склейки, а не за 4–6 секунд до неё. SSAI не успевает вызвать ADS и подготовить рекламу до запроса следующего сегмента; склейка проскакивает мимо границы, плеер замирает. Лечение: настройте на энкодере или master-control автоматическую выдачу меток на splice_event_id - pre_roll.»

«Ловушка – склейка в HLS без discontinuity. Инженерия забывает тег #EXT-X-DISCONTINUITY вокруг рекламного блока. Видеодекодер плеера видит неожиданный PTS-скачок и зависает на кадре. Лечение: каждый рекламный блок обёрнут двумя тегами #EXT-X-DISCONTINUITY – один до первого рекламного сегмента, один после последнего.»

«Ловушка – несовпадение рендиций в DASH. Рекламный AdaptationSet перечисляет разрешения, которых нет у контентного AdaptationSet. Плеер не находит соответствия для текущего битрейта и стопорится или скатывается. Лечение: кондиционирование производит все рендиции, что есть у контента, а не подмножество.»

«Ловушка – непрозрачные трекинг-маяки. SSAI-сервис стреляет в маяки показа без X-Forwarded-For или X-Device-User-Agent. Ad server не умеет дедуплицировать по устройствам, viewability-вендоры не умеют атрибутировать, мошенничество растёт, CPM падают. Лечение: transparency-заголовки VAST 4.1+ должны выставляться на каждом маяке – самый дешёвый одиночный фикс, поднимающий выручку.»

Экономика SSAI

Стек расходов SSAI стоит на четырёх строках.

Строка один – manifest manipulation. Вендоры тарифицируют per-ad-request (точка биллинга SSAI), обычно 1–4 цента США за тысячу запросов в 2026-м. FAST-канал с 5 000 одновременных зрителей, 14 паузами в час, одним запросом на паузу на зрителя, отправляет 70 000 запросов в час. По 2 цента за тысячу: 70 000 / 1 000 × $0,02 = $1,40 в час, или ~$34 в день на канал. На 100 каналов – $3 400 в день.

Строка два – кондиционирование рекламы (перекодирование). Per-creative-variant. 60-секундная реклама в пяти рендициях по 5 центов = $0,25 за креатив. При 70 % cache-hit только 30 % требуют кондиционирования в час. Канал, ротирующий 50 уникальных креативов в час: 50 × 0,30 × $0,25 = $3,75 в час. На 100 каналов – $9 000 в день.

Строка три – egress. Персональные манифесты и рекламные сегменты уходят с SSAI. Egress манифестов незначителен (~10 КБ MPD на зрителя в минуту). Egress рекламных сегментов реален: 60-секундная реклама в верхней рендиции 6 Мбит/с – это 45 МБ, но кеш CDN съедает большую часть. Маржинальный egress, бьющий по SSAI, – около 5 МБ на зрителя на паузу. 5 000 зрителей × 14 пауз × 5 МБ = 350 ГБ в час. По $0,01 за ГБ egress с CDN tier-1 origin: $3,50 в час. На 100 каналов – $8 400 в день.

Строка четыре – инженерия и эксплуатация. Команда из двух инженеров на интеграцию SSAI стоит ~$400 000 в год fully loaded в США, или $1 100 в день, размазанные по SSAI-парку.

Общая дневная стоимость 100-канального FAST-парка на 5 000 одновременных зрителей на канал – примерно $3 400 + $9 000 + $8 400 + $1 100 = $21 900 в день, или $656 700 в месяц. Тот же парк под CSAI сэкономил бы строки manifest manipulation и кондиционирования (порядка $12 400 в день), но потерял бы примерно треть показов на блокировщиках и ещё около десятой части – на несовместимых Smart TV. При CPM в $30 потерянная выручка измеряется семизначными суммами в месяц – и именно поэтому SSAI доминирует в CTV и FAST, несмотря на более высокую стоимость показа.

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

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

Фора Софт строит ad-supported видеопродукты с ранних дней OTT – FAST-каналы вещательного качества, прямые трансляции киберспорта с мид-роллами, телемедицинские платформы с спонсируемым контентом, e-learning-системы с рекламой на уровне курсов. Чисто заходящие интеграции – это те, в которых SSAI рассматривается как контракт между тремя командами: энкодер-команда выдаёт SCTE-35 с правильным pre-roll; платформенная команда крутит manifest manipulator на edge; ad-ops владеет VAST-обменом и точностью OM SDK. Мы делали интеграции с AWS Elemental MediaTailor, Yospace, Broadpeak, Wowza и несколькими кастомными origin-ами; режим отказа почти всегда сидит на стыке команд, а не в самом протоколе. Самым крупным подъёмом 2026-го стал перевод FAST-клиентов с чистого SSAI на сплит «SSAI в вебе / SGAI на мобильных / SSAI на CTV», потому что IAB-работа по SGAI достаточно созрела, чтобы клиентская сложность окупалась выигрышем в измерениях.

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

• SSAI переписывает манифест каждого зрителя на сервере, чтобы реклама ехала по тому же потоку байтов, что и контент, – это побеждает блокировщики и ограничения CTV-устройств.
• SCTE-35 (2023r1) – внутриполосный язык меток; EXT-X-DATERANGE в HLS и multi-period MPD в DASH доносят его до плеера.
• VAST 4.3 плюс июльский 2024 CTV Addendum – схема ad-decision и трекинга, на которой говорит любой SSAI-сервис.
• Live-SSAI в 2026 году идёт за ~400 мс glass-to-glass с edge-resident manipulator-ом и pre-conditioned-пулом рекламы, против ~1 600 мс в 2022-м.
• Точность измерений – структурная слабость; transparency-заголовки VAST 4.1+ и OM SDK v1.5 закрывают её там, где устройство тянет SDK.
• SGAI (IAB Tech Lab, конец 2025) – стратегическая ставка 2027–2028 для CTV, объединяющая охват SSAI с измерениями CSAI.

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

• CSAI и VAST/VPAID/SIMID – подробный разбор – клиентская альтернатива, против которой статья позиционируется.
• Метрики QoE для каждого стримингового дашборда – как метрики рекламы укладываются в инженерный скоринг.
• Экономика стримингового продукта: проработанная модель – где SSAI сидит в полном P&L OTT-сервиса.