1. Что такое Нелинейная Целевая реклама?

Линейное интернет-ТВ ориентировано на доставку линейного ТВ до зарегистрированных устройств с использованием HTTP и IP-протокола. Таким образом, телевидение в интернете по сути копирует традиционное ТВ и вещает ту же программу и ту же рекламу.

Тем не менее, HTTP является протоколом одноадресного вещания из точки в точку, в отличие от программы, передаваемой по электросетям для общего доступа.  В принципе система доставки контента по интернету может и должна управлять доступом к контенту для каждого подключенного пользователя на индивидуальной основе.

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

Нелинейная Целевая реклама обращает основное внимание на изменение рекламных сообщений, которые получает каждый пользователь.

Для простоты, пользователи могут быть объединены в демографические, региональные или иные группы, но при желании рекламные сообщения можно показать индивидуально.

Технологически не представляется архисложным реализовать эти индивидуальные решения, т.к. для доставки линейного видео по HTTP сети, требуется нарезка потока на небольшие части, называемые сегментами или чанками. Каждый сегмент имеет уникальный URL и список URL-адресов, отражается в файле детализированного плейлиста. При условии, что транскодирование производится таким образом, что границы сегмента соответствуют началу и концу рекламного объявления или рекламного блока, то замена или подмена рекламного сообщения осуществляется путем изменения файла детализированного плейлиста для каждого пользователя в результате которого оригинальный контент замещается таргетированным контентом.

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

2. Организация технологического процесса

Следующая диаграмма иллюстрирует процесс работы размещения Нелинейной целевой рекламы. Она разделена на две области, область с красными стрелками, указывающими на статическую часть процесса, и область с синими стрелками, иллюстрирующую процесс в реальном времени.

По сути, статическая часть процесса фокусируется на управлении рекламными роликами, а динамическая часть на управлении слотами для размещения рекламных роликов.  Объединение двух частей системы означает процесс размещения таргетированных рекламных роликов в реальном времени.

2.1 Статическая часть системы

Рекламодатели, которые хотели бы разместить рекламные ролики, должны предоставить как сами рекламные ролики, так и метаданные, которые контролирует кампанию, т.е. параметры рекламной компании.

2.1.1 Библиотека рекламных роликов

Это набор медиа-файлов, которые содержат аудиовизуальные рекламные объявления. При этом следует иметь в виду, что одна рекламная кампания может содержать несколько версий одного и того же рекламного ролики или несколько разных тематически связанных рекламных роликов. Например, автопроизводитель может заказать кампанию по продвижению сопутствующих финансовых услуг, и, следовательно, может предложить к размещению разные ролики для каждой модели автомобиля. Кроме того, рекламодатель может предложить разные ролики для рекламы одного и тоже продукта, которые будут использоваться в различных контекстах. Например, автопроизводитель может поставить цель продвижения люксовых характеристик для лиц с доходами выше средних, а в другом случае акцентировать внимание на низкобюджетных свойствах продукта для лиц с более низкими доходами.

Рекламные ролики, как правило, предоставляется в виде одного файла для каждого объявления, то есть в формате, который не подходит для распространения адаптивного потокового видео по протоколу HTTP. В результате, прежде чем файлы с роликами могут быть использованы они должны пройти процедуру транскодирования и сегментирования, что требует этапа преобразования автономных файлов в требуемые чанки.

После того, как транскодирование завершено, чанки должы быть загружены в базу данных CMS, откуда они могут быть использованы в линейном вещании. Таким образом, медиа-файлы, предоставляемые рекламодателем, и транскодированные файлы, проходят подготовку до начала вещания в реальном времени.

В принципе можно использовать для этой функции вещательную CMS, но установка полноценной CMS только для управления рекламными роликами (подразумевается, что, как правило, осуществляется управление небольшим количеством объявлений в отдельный момент времени, в то время как полноценные CMS масштабируются для других целей) является чрезмерной.

Таким образом, для управления рекламным эфиром следует использовать неполномасштабную CMS, ориентированную исключительно на рекламу, а не CMS, существующую для вещания.

2.1.2 Метаданные рекламных кампаний

Наряду с предоставлением непосредственно рекламных роликов рекламодатель устанавливает метаданные для управления рекламной компании (медиа-цели), например, количество и частоту контактов, временные слоты, геолокацию, социо-демографические и психо-графические характеристики аудитории и т.д.).

2.2 Динамический процесс в реальном времени

В реальном времени оператор получает видеопоток вместе с метаданными и метками, маркирующими доступные рекламные блоки или иные слоты. Метаданные могут приходить в самом потоке и триггеры передаваться с помощью SCTE35-меток или отдельно вне потока. Если триггеры передаются вне потока, то как правило используется интерфейс известный как ESAM для прокачивания метаданных в транскодер.

Затем потоки с рекламными метками перед загрузкой в сеть доставки окончательно обрабатываются на линейной головной станции сжатия. Сеть оператора располагает информацией о индивидых

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

2.3 Связка процессов

Полноценное использование системы, очевидно, подразумевает связку процессов в тот момент, когда в помеченных слотах должны в режиме реального времени должны быть автоматически размещены рекламные ролики из статичной системы,

Эта взаимосвязь осуществляется через отраслевые стандартные интерфейсы, а двумя наиболее распространенными из которых являются SCTE-130 и VAST. Оба интерфейса позволяют вещающей платформе в режиме реального времени в момент считывания триггера обратиться к статической части системы и запросить необходимые рекламные ролики, а статическая часть подберет необходимые ролики и укажет адрес, откуда эти ролики могут быть загружены.

3. Концептуальные решения

В этом разделе более подробно рассматриваются концепции, указанные выше

3.1 Врезка против Подмены

В центре внимания является замена или подмена реклама. Другими словами, подразумевается, что поток исходного видео уже содержит рекламу.

Система динамической рекламы предназначена для замены рекламных сообщений и анонсов.

Учитывая, что реклама уже есть в потоке, следует остановиться на вопросах, которые мотивируют операторов и вещателей содействовать развитию системы.

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

Использование мультиэкранного просмотра или нетрадиционных экранов, таких как смартфоны и планшеты, как правило, увеличивает охват. Кроме того, просмотр на этих экранах не учитывается в данных о телесмотрении, поставляемых ТНС Медиа в TV Index и TV Index+. С некоторыми оговорками об увеличении охвата следует говорить при использовании SmartTV и STB особенно в отношении тематических каналов, т.е. речь на практике во многих случаях идет о дополнительном инвентаре.

Таргетирование рекламы также увеличивает вовлеченность. Не представляющие для зрителя рекламные сообщения подсознательно отфильтровываются, и, хотя охват федерального или национального общедоступного ТВ достигает 98-99% всей городской аудитории, это не означает, что рекламные сообщения достигают целевую аудиторию рекламодателя, не говоря уже о погрешности измерений. Таргетирование рекламы позволяет улучшить качественные показатели вовлеченности зрителя в просмотр рекламы, и ее просмотр может быть гарантировано учтен, поэтому она стоит в 2-3 раза дороже, чем реклама на федеральном ТВ.

Увеличение доходов от использования того же инвентаря (временных интервалов) позволяет осуществить разделение доходов между вещателями и операторами с взаимной выгодой для обоих, телеканалам увеличить доходы от рекламы на единицу времени (инвентаря), а операторам увеличить ARPU.

Альтернативой замены является врезка дополнительной рекламы. Видеореклама может быть вставлена до начала потока, в середине или в конце – как пре-, миддл- и пост-роллы, соответственно, но эти известные в интернете и онлайн-кинотеатрах формы мало интересны для трансляций линейного телевидения по протоколу HTTP.

Кроме того, замена анонсов тоже может рассматриваться как врезка дополнительной рекламы.

3.2 Маркировка рекламных блоков

Для того, чтобы иметь возможность заменить рекламу, рекламная система должна распознать, когда в потоке начинается, а когда заканчивается рекламный блок (иной таймслот). На практике используются два основных подхода – триггеры «в потоке» и «вне потока».

Технология «триггеры в потоке» работает путем включения метаданных в сам линейный поток, которые идентифицируют начало и конец временного слота для размещения таргетированных роликов. Основная технология для рещения этой задачи называется SCTE35, отраслевой стандарт США.

Использование меток SCTE35 значительно упрощает процессы по сравнению с применением триггеров вне потока, но предполагает наличие необходимой технической инфраструктуры у вещателя и операторов, а также безусловную передачу меток по всему вещательному тракту, что встречается не повсеместно.

Альтернативой является передача триггеров вне потока. Обычно это достигается путем использования метаданных из плей-аут сервера вещателя, которые обрабатываются в транскодере интерфейсом ЕSAM.

Система размещения нелинейной таргетированной рекламы использует одну из этих технологий.

3.3 Обработка стриминга

Замена контента осуществляется простой заменой сегментов (чанков) потока, которые относятся к рекламному или заменяемому контенту. Это гораздо проще, чем использование сплайсинга потока, которое применяется в других технологиях вещания. Этот метод основывается на том, что границы сегментов точно совпадают с началом и концом ролика или блока. Если поток разбит на одинаковые по длительности или кратные по длительности чанки, то такое совпадение становится неслучайным. А управляемым.

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

Транскодер также должен уметь управлять чанками следующими сразу за триггером о замене сегмента (в начале блока) или предшествующими триггеру перед заменой сегмента (в конце блока). Это необходимо, так как очень короткие сегменты (только несколько кадров) неудобны для пакетирования и также могут негативно повлиять на работу декодера буферизации.

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

3.4 Шаблон детального плейлиста

Транскодер и «нарезчик» (пэкиджер -упаковщик) являются частями системы интеграции, которые не владеют информацией об индивидуальном пользователе-зрителе. Эта информация становится доступной позднее в сети и на этапе доставки контента.

В результате нарезчик-упаковщик не может создать окончательный детальный плейлист для каждого конечного пользователя.

Вместо этого он должен написать шаблон детального плейлиста, содержащий все исходные сегменты, но потом пометить те сегменты, которые должны быть заменены. Это называется шаблоном.

Шаблон детального плейлиста прокачивается в сеть доставки, которая сама способна заменить помеченные сегменты для конкретного пользователя.

3.5 Подмена шаблона детального плейлиста

После того, как шаблон загружен в сети доставки, можно начать процедуры подмены контента с учетом характеристик пользователя-зрителя,

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

Большим преимуществом телевизионных ОТТ-решений является то, что эти группировки могут быть динамическими и не ограничены архитектурой сети (например, кабельные сети жестко привязаны к какой-либо территории).

Для того, чтобы заменить рекламное сообщение, система управления интернет-ТВ должна обнаружить метку в шаблоне детального плейлиста. Для нее – это сигнал, чтобы направить запрос в статическую часть рекламной системы и получить из нее необходимые ссылки на адрес рекламных роликов, которые заменят оригинальный контент. Результат обращения с новым адресом должны быть записан в новый файл детального плейлиста, который будут исполнен для соответствующей группы принимающих устройств, как показано на следующем рисунке:

Слева показан шаблон детального плейлиста, содержащий только исходные сегменты. Справа новый файл детального плейлиста для одного конкретного пользователя (или группы пользователей), в котором сегменты, выделеные оранжевым цветом, и обрамленные Cue Out и Cue In метками, были заменены на новые сегменты.

3,6 Обращение к рекламному серверу

Когда система управления обнаруживает триггер, она должна определить каким файлом, заменить оригинальный контент. Для это необходим обладать функционал обращения с соответствующим запросом к системе управления рекламным контентом.

В этих целях используются два основных API – SCTE-130 и VAST.

Когда оператор контролирует рекламную систему, чаще используется SCTE-130.

VAST – это стандарт IAB ( Internet Advertising Bureau), и чаще всего ассоциируется баннерами на веб-страницах. Веб-сайты могут обращаться к системам внешних рекламных агентств с тем, чтобы загружать с них рекламные баннеры – это делает интернет-рекламу доступной даже для небольших, независимых веб-сайтов, которые не имеют возможности запустить свой собственные продажи рекламы. Используя внешнее агентство, небольшие веб-сайты могут эффективно объединить свои ресурсы, чтобы достичь необходимой привлекательной консолидации ресурсов.

Эти внешние агентства также предоставляют видео-рекламу. Следовательно, при использовании внешнего агентства, VAST является наиболее распространенным способом обращения к рекламным сервисам.

3,7 Способы замены рекламы

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

Принципиально возможны две модели

Один на Один

Эта модель предполагает, что индивидуально помечены начало и конец каждого рекламного роликаотмечалось, в отличие от более простого метода разметки начала и конца всего рекламного блока.

В этом случае система будет распозновать всю последовательность роликов, спот, например, 15 секунд, затем 30 секунд, а затем еще на 15 секунд и, наконец, 60 секунд. Тогда система направит отдельные соответствующие запросы в рекламную систему на каждый ролик отдельно.

Все на Все

Если отмечены только начало и окончание рекламного блока, то в таком случае требуются несколько итераций запросов. Система управления ТВ запрашивает первый ролик у рекламной системы и резервирует оставшееся время после получения о длительности первого ролика, а затем направляет второй запрос, третий и т.д., пока не заполнит весь выделенный слот. Последовательность рполиков по продолжительности в этом случае может отличаться от оригинальной.

3,8 Отчетность

Для выполнения обязательств перед рекламодателями любая рекламная система должна осуществлять мониторинг выходов и просмотров рекламы.

Мониторинг для VAST отличается от мониторинга для SCTE130.

В технологии VAST, ответ отслеживает URL, который работает в качестве адреса обратного вызова. Система рекламы может быть настроена на поиск этого специфического адреса адрес (он будет отличаться для разных VAST -провайдеров) и отфиксировать URL, когда рекламное сообщение проигрывается.

В рабочих процессах SCTE130 каждым ответом на рекламный запрос создается XML объект, называемый Уведомление о состоянии Размещения (PSN). Объект PSN затем возвращается в систему управления рекламными кампаниями и закрывает запись в момент проигрывания ролика, что позволяет системе управления рекламными кампаниями генерировать требуемый отчет.

В общем система генерирует рекламные запросы в ответ на просмотр рекламного объявления.  Рекламный ролик можно считать показанным потому, что обновленный файл детального плейлиста должен быть создан для данного пользователя, а следующий сегмент для воспроизведения был отмечен как доступный для замены или вставки. В этом случае реклама проигрывается, как только первый сегмент вставляется в обновленный детальный плейлист. Учитывая, что время обращения обратных вызовов очень короткое возникает вопрос, зачем отчетность нужна вообще.

Необходимо охватить два специфических сценария. Первый – это продолжительные рекламные ролики с хронометражем более 30 или 60 секунд. Эти ролики нарезаются на более, чем один сегмент и, как правило, захватывают несколько сегментов, и, следовательно, воспроизведение первого чанка не означает, что пользователь отсмотрел весь ролик. Из-за этого отчет может быть получен только после выхода всех сегментов одного ролика и можно быть полностью увереным, что пользователь отсмотрел весь ролик.

Второй сценарий распространяется на случай, когда система выдает серию последовательных рекламных роликов. Обычно такой случай происходит при одном SCTE130 или ВАСТ запросе га группу роликов, хотя выход сегмента первого ролика означает, что пользователь смотрит первый ролик объявление, вероятность того, что он просмотрит второй и т.д. уменьшается в течение выхода блока. Следовательно, необходимо проверить выход каждого ролика индивидуально.