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

TL;DR

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

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

Если ваш продукт зарабатывает на рекламе, решение где именно встраивать рекламу в поток – одно из ключевых архитектурных решений в монетизационном плане. 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 плеер использует два источника: поток контента и поток рекламы. Дойдя до рекламной паузы, плеер останавливает основной видеопоток, обращается к серверу принятия рекламных решений, загружает манифест рекламы и воспроизводит её через второй видеопоток (или тот же, но с новым src), после чего возвращается к контенту. Каждый переход – это смена в цепочке рендеринга, которую пользователь ощущает; каждый запрос рекламы – сетевой round-rip, который может не пройти; каждый рекламный 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, управляемый расписанием; в прямом эфире спорта – оператор, нажимая кнопку 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, тогда как прямой эфир транслируется в формате CMAF с разрешениями 1080p, 720p, 540p, 360p, с кодеками H.264 и AAC. Поэтому SSAI-сервис перекодирует (или использует заранее подготовленные версии) каждый рекламный креатив в сегменты, полностью соответствующие контенту по разрешению, битрейту, параметрам кодека и длительности сегмента – чтобы склейка была абсолютно незаметна для ABR-логики плеера. AWS Elemental MediaTailor называет этот процесс ad conditioning и предлагает два режима: динамическое перекодирование (по умолчанию, медленнее, но гибче) и BYOA (bring your own ads, январь 2025 – быстрее, но требует предварительной подготовки).

Стадия 5 – выдача персонализированного манифеста. SSAI-сервис генерирует персонализированный манифест для каждой сессии, в котором оригинальные сегменты контента и подготовленные рекламные сегменты чередуются на 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, генерируют все энкодеры, а также проверяют все тесты на соответствие. Редакция 2023 года (ANSI/SCTE 35 2023r1, официально утверждена ANSI 29 февраля 2024) добавила поддержку вложенных событий, иерархических подсобытий и переименование, в результате которого стандарт был разделён на SCTE 35-1 (на основе legacy splice- и time-based сигнализации) и SCTE 35-2 (на основе event-based сигнализации). Когда в блог-посте 2026 года упоминается «SCTE-35» без указания части, автор, как правило, имеет в виду SCTE 35-1.

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

• splice_insert() – оригинальная, точная по кадру команда склейки. Содержит ID события splice, флаг 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 рекламы не совпадают с таймстемпами основного контента), сбросьте пайплайн декодирования на границе. Без них видеодекодер плеера «споткнётся» на скачке таймстемпа, и зритель увидит застывший кадр.

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, при которой реклама скрывается из исходного манифеста до момента позднего связывания.

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

Обмен 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>, по которому агентства отслеживают креатив в цепочке поставок, и структурированный блок <Verification>. VAST CTV Addendum 2024, опубликованный IAB Tech Lab в июле 2024 года, расширил любую версию VAST поддержкой высококачественных креативов, регистрацией рекламы по 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-трекинговые URL на свои собственные конечные точки маяков. С точки зрения плеера реклама – это просто новые сегменты. А с точки зрения рекламной экосистемы события импрешена и квартилей отправляются с 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 выполняет обработку по требованию и кэширует результат на час, а режим none полагается на VAST-ответ, в котором уже указаны предварительно подготовленные файлы. Функция BYOA (январь 2025) позволяет издателям указывать в VAST URL заранее перекодированные HLS/ DASH-манифесты рекламы прямо в атрибутах creative file, тем самым обходя динамическую перекодировку. В мае 2026 появились персонализация ad-трейкплей (превью-кадры на скраб-баре для VOD отображают рекламу, когда пользователь перемещает ползунок по рекламному отрезку) и компактные DASH-манифесты (дедупликация AdaptationSet между рекламными и контентными периодами, меньший MPD, более быстрый старт).

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

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

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

В SSAI по умолчанию ничего из этого не работает. Сигнал о показе отправляется с SSAI-сервиса. IP-адрес – egress-IP SSAI-сервиса. User-Agent передаётся тем, что SSAI решил переслать. OM SDK на устройстве не функционирует, поскольку между рекламой и плеером отсутствует JS-SDK. Возникает разрыв в измерениях: 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-секундной рекламы; и так далее. Прокси приблизительный – загруженный сегмент не равен отрендеренному кадру, – но это лучшая доступная метрика на нерасширяемом устройстве.

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

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

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

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

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

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

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

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

Бюджет задержки для live-SSAI в 2026 году выглядит следующим образом. Рассмотрим окно «glass-to-glass» продолжительностью 100 миллисекунд:

Захват → энкодер:               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-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-образные рекламы, которые чистый 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 падают. Лечение: заголовки прозрачности VAST 4.1+ должны устанавливаться на каждом трекинг-маяке – это самый дешёвый и эффективный одиночный способ повысить выручку.»

Экономика SSAI

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

Строка один – manipilation manifest. Вендоры тарифицируют 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. Объём исходящего трафика от манифестов невелик – около 10 КБ MPD на зрителя в минуту. А вот egress рекламных сегментов уже ощутим: 60-секундная реклама в высоком качестве 6 Мбит/с составляет 45 МБ, но большую часть этого объёма поглощает кэш CDN. Реальный дополнительный egress, который ложится на SSAI, – примерно 5 МБ на зрителя при каждой паузе. 5 000 зрителей × 14 пауз × 5 МБ = 350 ГБ в час. При цене $0,01 за ГБ исходящего трафика с CDN tier-1 origin это обходится в $3,50 в час. На 100 каналов – $8 400 в день.

Строка четыре – инженерия и эксплуатация. Команда из двух инженеров, работающих над интеграцией SSAI, обходится примерно в 400 000 долларов в год (fully loaded) в США, или около 1100 долларов в день на весь парк SSAI.

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

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

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

Фора Софт разрабатывает видеопродукты с рекламной поддержкой с самого начала эпохи OTT – это FAST-каналы вещательного качества, прямые трансляции киберспорта с мид-роллами, телемедицинские платформы со спонсируемым контентом, e-learning-системы с рекламой на уровне курсов. Чистые интеграции – те, где SSAI рассматривается как соглашение между тремя командами: команда энкодера выдаёт SCTE-35 с корректным pre-roll; платформенная команда запускает 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 – стандарт для принятия решений о показе рекламы и трекинга, на котором общаются все SSAI-сервисы.
• Live-SSAI в 2026 году обеспечивает задержку glass-to-glass около 400 мс при использовании edge-резидентного манипулятора и предварительно подготовленного пула рекламы, против ~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-сервиса.