SSAI против CSAI: серверная и клиентская вставка рекламы

TL;DR

Вставить рекламу в стриминг можно двумя способами, и различаются они одним: где реклама соединяется с видео. При client-side ad insertion (CSAI) приложение зрителя ставит контент на паузу, само вызывает рекламный сервер и проигрывает рекламу в отдельном маленьком плеере – гибко и интерактивно, но видно ad-блокерам и с риском «подвисания» на каждой паузе. При server-side ad insertion (SSAI) платформа вшивает рекламу в видеопоток до того, как он дойдёт до устройства, и реклама приходит частью того же ровного потока с тех же серверов – поэтому SSAI обходит ad-блокеры и улучшает качество воспроизведения ценой более сложных измерений и более тяжёлой сборки. Эта статья объясняет оба подхода, архитектуру ститчинга, лежащие в основе стандарты SCTE-35 и VAST и то, как выбирать – включая новый гибрид (server-guided insertion / HLS interstitials), который сближает первые два.

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

Если вы запускаете или собираетесь строить рекламный стриминг – advertising video on demand (AVOD), бесплатный рекламный канал free ad-supported streaming TV (FAST) или любой гибрид с рекламой – выбор между CSAI и SSAI тихо решает три важные для вас вещи: сколько рекламного дохода реально дойдёт до отчётности, насколько хорошо ощущается просмотр на каждой паузе и сколько инженерной работы вы на себя берёте. Ошибётесь в web – ad-блокеры сотрут часть дохода; ошибётесь на ТВ – топорные переходы приучат зрителя отворачиваться. Реклама в connected-TV (CTV) в США прогнозируется примерно в $37,95 млрд в 2026 году, и в 2026-м апфронтные обязательства CTV впервые должны превысить прайм-тайм линейного ТВ (прогнозы eMarketer и индустрии, 2026) – так что механика вставки рекламы в поток стала системой дохода первого порядка, а не деталью. Это инженерный гид по этой механике и спутник к карте монетизации OTT, которая показывает, где рекламный доход стоит среди всех способов заработка платформы.

Главное различие: где реклама встречается с видео

Все остальные различия в этой статье вытекают из одного вопроса. Когда зритель доходит до рекламной паузы, кто и где соединяет рекламу с шоу?

При client-side ad insertion – CSAI, методе, встроенном в большинство web- и мобильных плееров, – соединение происходит на устройстве зрителя. У плеера есть небольшой рекламный компонент («ad SDK»). Дойдя до метки рекламы, плеер ставит контент на паузу, отправляет запрос наружу к рекламному серверу (системе, которая решает, какую рекламу показать, и отдаёт её видеофайл), скачивает эту рекламу, проигрывает её в отдельном рекламном плеере и возвращается к шоу. Реклама – это отдельное событие, которое устройство забирает и проигрывает само.

При server-side ad insertion – SSAI, методе, который доминирует в connected-TV, – соединение происходит на серверах платформы, до того как видео дойдёт до устройства. Сервис ститчинга вшивает сегменты рекламы в поток контента так, что к моменту получения потока плеером реклама уже его часть. Плеер просто продолжает играть; он никогда не делает отдельного рекламного запроса и часто не может сказать, где кончается шоу и начинается реклама.

Вот аналогия, которую стоит держать в голове. CSAI – это телевизор, который на каждой паузе останавливает шоу и звонит спонсору спросить «что играть сейчас?»: быстро, когда линия свободна, неловко, когда нет, и легко перерезать провод. SSAI – старая вещательная модель: реклама вклеена в плёнку на станции, поэтому одна непрерывная лента играет и шоу, и рекламу без всяких звонков. Всё ниже – устойчивость к ad-блокерам, плавность, сложность измерений, цена сборки – следствие этого одного выбора, где происходит вклейка.

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

Как работает CSAI, шаг за шагом

Пройдём одну рекламную паузу в client-side вставке – механика объясняет и сильные стороны, и режимы отказа.

Плеер доходит до метки рекламы – маркера «здесь пауза». Ad SDK формирует запрос и шлёт его рекламному серверу по стандарту VAST, сокращённо от Video Ad Serving Template – это поддерживаемый IAB Tech Lab XML-формат, которым рекламный сервер описывает плееру рекламу: где видеофайл, какие маяки слать, что делать по клику (IAB Tech Lab VAST; актуальная линия VAST 4.3, декабрь 2022, плюс VAST CTV Addendum 2024). Сервер отвечает документом VAST. Плеер его читает, скачивает рекламный креатив, проигрывает в своём рекламном плеере и по ходу шлёт маяки – маленькие веб-запросы «реклама началась», «25% просмотрено», «50%», «завершено» – рекламному серверу и вендорам измерений. Когда реклама кончается, плеер сворачивает рекламный плеер и возвращает шоу.

Этот цикл – источник двух реальных проблем CSAI. Во-первых, это звонок, который устройство делает на известный рекламный домен, поэтому его можно заблокировать. Ad-блокер – это, по сути, список рекламных доменов плюс правило: гасить любой запрос к ним. Поскольку рекламный запрос CSAI идёт из браузера зрителя к рекламному серверу, который почти наверняка в списке, блокер просто отменяет его, плеер не получает рекламу, и показ – а с ним и доход – не случается. Во-вторых, цикл занимает время в худший момент. Между сворачиванием контента и буферизацией рекламы плеер должен разрешить домен, завершить запрос, разобрать VAST, скачать креатив и наполнить буфер. На чистой связи это пауза в такт; на перегруженном телефоне это одна–три секунды спиннера или таймаут с пустой заглушкой. Каждая пауза – небольшой шанс на затык.

Сильные стороны CSAI растут из той же архитектуры. Поскольку реклама идёт в настоящем плеере на устройстве, она может быть интерактивной и кликабельной – оверлей «нажмите, чтобы узнать больше», разворачиваемый блок – через интерактивный стандарт, заменивший старый VPAID, теперь SIMID (Secure Interactive Media Interface Definition). А поскольку рекламу проигрывает само устройство, клиент точно знает, что произошло: точная viewability, точное завершение, сигналы устройства и сессии, простой пер-девайс frequency capping (ограничение, сколько раз зритель видит одну рекламу). CSAI сохраняет богатейшие данные и максимум интерактивности. Платит он за это уязвимостью к ad-блокерам и затыком на каждой паузе.

Как работает SSAI, шаг за шагом

Server-side вставка переносит всё соединение на платформу. Для этого нужен компонент, которого у клиентской стороны не было: ститчер, он же manifest manipulator (манипулятор манифеста).

Начнём с манифеста – небольшого текстового плейлиста, который говорит плееру, какие короткие видеочанки качать и в каком порядке. Современный стриминг (см. упаковка: CMAF, HLS и DASH) режет видео на сегменты по несколько секунд и перечисляет их в этом манифесте; два формата манифеста – HLS (от Apple, RFC 8216) и MPEG-DASH (ISO/IEC 23009-1). Плеер просто забирает те сегменты, что названы в манифесте. Фокус ститчера – переписать манифест так, чтобы он перечислял рекламные сегменты вперемешку с контентными. Внутреннюю механику этих форматов см. в HLS vs DASH в разделе Video Streaming; здесь нас интересует лишь то, что ститчер с ними делает.

Последовательность одинакова на каждой паузе. Прямой или VOD-поток несёт внутрипотоковую метку рекламы – SCTE-35-cue, вещательный стандарт, сигналящий «рекламная пауза начинается здесь, такой длины» (ANSI/SCTE 35, подробно в SCTE-35 и сигнализация рекламы). Ститчер видит метку и для сессии этого зрителя вызывает ad decision server запросом VAST – тем же стандартом VAST, что и CSAI, но теперь звонит сервер, а не устройство. Рекламный сервер возвращает рекламу. Ститчер готовит её – транскодирует под точные разрешения и битрейты лестницы качества контента, чтобы она встала без скачка качества – и переписывает манифест так, чтобы сегменты рекламы стояли в линию с контентными, помеченные тегом discontinuity (#EXT-X-DISCONTINUITY в HLS), который говорит плееру «здесь меняются свойства потока, продолжай играть». Плеер скачивает рекламные сегменты ровно так же, как контентные: тот же сервер, тот же формат, тот же буфер.

Два следствия выпадают прямо из этой схемы. Поскольку реклама приходит с тех же серверов и в том же потоке, что и контент, нет отдельного звонка на узнаваемый рекламный домен – и сетевому ad-блокеру нечего гасить, не заблокировав всё видео. А поскольку рекламные сегменты лежат в том же буфере, что плеер уже наполняет контентом, переход ровный, как в вещании: без звонка наружу, без спиннера, без заглушки. SSAI меняет затык и уязвимость CSAI на гладкую, устойчивую к блокерам паузу. Что он отдаёт – измерения и интерактивность – разберём после картинки.

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

Почему SSAI обходит ad-блокеры – то, что никто толком не объясняет

Это вопрос, который и приводит большинство людей к теме, поэтому он заслуживает точного ответа, а не привычного отмахивания, что SSAI просто «более устойчив».

Ad-блокер – это, по сути, охранник со списком рекламных доменов. Он осматривает запросы устройства и гасит любой, адресованный имени из списка. CSAI даёт этому охраннику лёгкую мишень: рекламный запрос плеера идёт с устройства зрителя на рекламный сервер, чей домен почти наверняка в списке, поэтому охранник его отменяет и реклама не грузится. Рекламный запрос – отдельный, опознаваемый, исходящий с клиента вызов, ровно то, что блокеры умеют ловить.

SSAI убирает этот вызов целиком. Нет клиентского запроса к рекламному серверу, который можно осмотреть, потому что этот запрос сделал сервер, вне поля зрения зрителя, когда собирал поток. Устройство скачивает последовательность видеосегментов с собственных контентных серверов платформы, в том же формате и с того же домена, что и шоу. Для блокера рекламный сегмент и контентный – неразличимые байты из доверенного источника; он не может выкинуть один, не выкинув видео, ради которого зритель пришёл. В этом весь механизм: SSAI выигрывает не тем, что лучше прячет рекламу, а тем, что удаляет отдельный запрос, на который опираются ad-блокеры.

Дохода на кону немало, особенно в web, где блокировка тяжелее всего. К 2025 году примерно 42% интернет-пользователей ставили какой-нибудь ad-блокер, на десктопе доля около 51%, на мобильных – около 36%, а потери издателей оценивались порядка $54–62 млрд в год (индустриальные сводки, 2025 – оценки разнятся по методике). В connected-TV угроза другая – большинство ТВ не запускают браузерные ad-блокеры – но SSAI выигрывает там по другой причине: парк ТВ-плееров приложений – это пёстрый зоопарк устройств, и серверный ститчинг даёт каждому из них одинаковый ровный опыт без SDK вместо того, чтобы просить капризный ad SDK каждого устройства вести себя прилично. В web SSAI защищает доход; на ТВ – опыт и единообразие.

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

Честный размен: что SSAI отдаёт

SSAI – не бесплатная победа. Перенос соединения на сервер ломает две вещи, которые клиент делал без усилий – измерения и интерактивность – и добавляет затраты, которых у клиента не было.

Измерения усложняются, потому что рекламный сервер больше вызывает не устройство. При CSAI плеер сам шлёт каждый маяк, и рекламный сервер видит ровно то, что видел зритель. При SSAI слать маяки естественно ститчеру, но ститчер – это сервер: он знает, что отправил рекламные байты, но не знает, был ли экран включён, было ли приложение на переднем плане и был ли зритель вообще в комнате. Индустрия исправила это намеренно: VAST 4.1 (2017) добавил явную поддержку server-side ad insertion и согласование со стандартом Open Measurement (OMID) – фреймворком IAB Tech Lab, который позволяет одобренному скрипту измерений работать в плеере и сообщать реальную viewability, даже когда реклама вшита на сервере (IAB Tech Lab VAST 4.1; Open Measurement SDK). Сделано правильно – SSAI плюс OMID измеряет viewability корректно; сделано лениво – маяки летят с ститчера вслепую – он завышает показы, и аудитор это поймает. Измерения решаемы, но теперь это ваша задача.

Интерактивность усложняется по той же причине: вшитая реклама – это просто видео в потоке, поэтому богатым кликабельным блокам, которые поддерживает CSAI, нужна дополнительная обвязка (боковой канал метаданных, который слушает плеер). Многие внедрения SSAI просто принимают неинтерактивные ролики, что нормально для ТВ-брендовой рекламы и слабо для performance-рекламы, которой нужен клик.

Frequency capping и персонализация требуют сессионной обвязки. Печально известный симптом SSAI – одна реклама пять раз за паузу – результат ститчера, который вызывает рекламный сервер, не передавая достаточно о том, кто этот зритель и что он уже видел. Чтобы таргетировать рекламу и ограничивать повторы, ститчер должен протянуть пер-сессионную идентичность и историю к ad decision server на каждом вызове. Именно это и значит dynamic ad insertion (DAI): SSAI плюс пер-сессионный таргетинг, где каждый зритель получает персональный манифест. Это работает, но пер-сессионный манифест хуже кэшируется, чем единый общий поток, что повышает стоимость доставки – реальная строка, которую несёт модель стоимости OTT.

И подготовка рекламы стоит вычислений. Транскод каждой рекламы под каждую ступень лестницы контента, для каждой кампании, – это реальная нагрузка транскодинга, цена ровного перехода. Ни одно из этого не приговор; вместе они объясняют, почему SSAI – это сборка, а не галочка.

Сравним бок о бок

Два подхода и гибрид, который встретим дальше, выстраиваются ясно, как только понятен механизм. В таблице есть колонка «работает без проблемы ad-блокеров?», потому что с этим вопросом приходит большинство команд – но читайте каждую строку, ведь верный ответ зависит от вашей поверхности (web, мобильные, ТВ) и цели (защита дохода, опыт, интерактивность).

Таблица 1. CSAI, SSAI и сходящийся гибрид. Ни одна строка не делает один подход безусловным победителем; выбор следует за поверхностью и целью. Колонка «обходит ad-блокеры?» – вопрос, с которого стартует большинство, но строки про измерения и интерактивность – там, где проекты SSAI отрабатывают своё.

Рабочий пример: чего стоит выбор в деньгах

Абстрактные размены становятся решениями, когда кладёшь на них деньги. Рекламный доход везде следует одной формуле, с неё и начнём:

рекламный доход = показы × CPM ÷ 1000

CPM – это cost per mille, сколько рекламодатель платит за тысячу показов рекламы. Возьмём средний AVOD-сервис и круглые числа:

зрителей (в месяц)           = 500 000
рекламных часов на каждого   = 15 / месяц
рекламных слотов в час       = 8            (например, 4 паузы × 2 ролика)
рекламных возможностей (avails) = 500 000 × 15 × 8 = 60 000 000 / месяц
fill rate                    = 70%          (доля avails, которую реклама реально заняла)
показы                       = 60 000 000 × 0,70 = 42 000 000 / месяц
CPM                          = $20
рекламный доход              = 42 000 000 ÷ 1000 × $20 = $840 000 / месяц

Теперь часть, которую решает метод вставки. При client-side вставке доля этих 42 млн показов не отрисуется или не засчитается – ad-блокеры гасят звонок в web, ad SDK падают по таймауту на слабых телефонах, медленные загрузки бросают. Возьмём консервативные 15% потерь для аудитории с заметным web- и мобильным охватом:

потеряно показов из-за сбоев CSAI = 42 000 000 × 0,15 = 6 300 000 / месяц
потеряно дохода                   = 6 300 000 ÷ 1000 × $20 = $126 000 / месяц
возвращает переход на SSAI         ≈ $126 000 / месяц  ≈ $1,5 млн / год

Около $1,5 млн в год, на той же аудитории и тех же продажах рекламы, возвращены лишь удалением блокируемого рекламного звонка и потерь клиентской загрузки. Это бизнес-кейс SSAI в одном числе – и причина, почему каждый AVOD- и FAST-оператор на масштабе работает на сервере. Числа здесь иллюстративны; подставьте свой состав аудитории, fill rate и CPM, но форма сохранится: чем больше вашей аудитории сидит в заблокированном web и капризном мобильном, тем дороже стоит SSAI.

Есть меньшая, более резкая версия того же довода – качество воспроизведения. Пауза CSAI тратит одну–три секунды на звонок наружу и буферизацию рекламы; пауза SSAI – примерно ноль, ведь реклама уже в буфере на битрейте контента. Умножьте несколько секунд риска на каждую паузу, каждого зрителя, каждый день – и вы меняете измеримую боль старта и ребуферизации – метрики качества, предсказывающие, останется ли зритель, – на гладкую. Доход и удержание указывают в одну сторону.

Куда всё идёт: гибрид, заканчивающий «или-или»

Самая чистая новость в теме в том, что индустрия сходится к третьему варианту, который сохраняет плавность SSAI и возвращает часть измерений и контроля CSAI. Вместо физического вшивания рекламных байтов в манифест контента сервер вставляет указатель – метку, говорящую плееру «в этой точке сходи проиграй рекламу из этого отдельного списка» – и плеер сам забирает и показывает рекламу, нативно.

Важны два имени. HLS interstitials – версия Apple: манифест несёт метку EXT-X-DATERANGE класса interstitial с X-ASSET-LIST, указывающим на рекламу, и совместимый плеер проигрывает её как нативную паузу (спецификация Apple HLS). Server-guided ad insertion (SGAI) – более широкий паттерн, формализованный для DASH в 6-й редакции MPEG-DASH (2024–2025) и принятый ститчерами вроде AWS Elemental MediaTailor, который добавил поддержку HLS-interstitials для VOD в 2024 и для прямых эфиров в 2025 (документация AWS Elemental MediaTailor, 2024–2025).

Выигрыш структурный. Поскольку нагрузка рекламы отделена от потока контента, манифест контента остаётся общим и кэшируемым – дешевле в доставке, чем пер-сессионный вшитый манифест – а клиентская загрузка рекламы возвращает точную viewability и более простую интерактивность. Это не даровой обед: подход новейший, поддержка ещё расходится по парку устройств, и готовых решений меньше, чем для классического SSAI. Но направление ясно – сервер решает, клиент рисует – и платформа, строящаяся сегодня, должна относиться к SGAI/interstitials как к архитектуре, в которую она врастает, а не как к эксперименту. Поэтому в таблице сравнения три колонки, а не две.

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

Частая ошибка: выбрать метод вставки до поверхности и цели

Повторяющаяся ошибка – считать это единым общеплатформенным переключателем («мы делаем SSAI»), решаемым по вкусу инженера, а не по тому, где смотрит аудитория и что должна делать реклама. Это бьёт предсказуемо. Performance-бизнес, которому нужны кликабельные интерактивные блоки, выкатывает чистый SSAI и обнаруживает, что его реклама не кликается. Web-тяжёлый AVOD выкатывает CSAI ради интерактивности и смотрит, как ad-блокеры стирают пятую часть дохода. Команда выкатывает SSAI, не протянув идентичность сессии к рекламному серверу, и поставляет опыт «одна реклама пять раз», от которого зритель глушит ТВ. Каждый случай – та же корневая ошибка: метод выбрали до того, как назвали поверхность (web, мобильные, CTV) и цель (защита дохода, гладкий опыт, интерактивность, измерения).

Лечение – решать по поверхности под цель, а не раз на всю платформу. CTV, где блокировка редка, но фрагментация устройств жестока, а опыт должен ощущаться как телевидение, – хрестоматийный дом для SSAI или server-guided вставки. Заблокированный web, где отдельный рекламный звонок – обуза, – там SSAI защищает доход, если только интерактивность не есть вся бизнес-модель, и тогда CSAI с анти-блокерными мерами оправдывает себя. Большинство серьёзных платформ заканчивают смешанно: на сервере для ТВ, на сервере или гибрид в web ради устойчивости к блокерам, с измерениями через VAST 4.1 и OMID в любом случае. Сначала назовите поверхность и цель; метод последует.

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

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

Вставка рекламы – там, где масштаб стриминга встречается с рекламным доходом, и дорогие провалы тихие: пятая часть web-показов заблокирована до счёта, парк ТВ, где ad SDK каждого устройства ломается по-своему, ститчер, который завышает показы и валит аудит, или «одна реклама по кругу», гонящая зрителей. Фора Софт строит видеостриминг и OTT/Internet-TV с 2005 года, за 250+ выпущенных проектов для 400+ клиентов, а значит мы вшивали сигнализацию SCTE-35 в прямые и VOD-конвейеры, интегрировали серверный ститчинг с ad decision server, готовили рекламный креатив под лестницу кодирования, чтобы паузы оставались ровными, и держали измерения честными через VAST и Open Measurement. Наша позиция – scalability-first и вендоро-нейтральность: мы стартуем от того, где смотрит аудитория и какой рекламный доход надо защитить на масштабе, и строим архитектуру вставки – CSAI, SSAI или server-guided гибрид – которой реально требуют ваши поверхности и рекламодатели.

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

• CSAI соединяет рекламу на устройстве; SSAI вшивает её в поток на сервере.
• SSAI обходит ad-блокеры, удаляя отдельный блокируемый клиентский звонок к рекламному серверу.
• SSAI даёт ровные, как в вещании, паузы и единый опыт на всех устройствах.
• Цена SSAI – измерения (лечатся VAST 4.1 + OMID), интерактивность и вычисления.
• Гибрид – HLS interstitials / DASH SGAI – хранит плавность и возвращает измерения.
• Выбирайте по поверхности и цели, не раз на всю платформу; большинство работает смешанно.

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

• SCTE-35 и сигнализация рекламы
• Ad serving, VAST/VMAP и рекламный стек
• Карта монетизации OTT: подписки, реклама, транзакции