Привет, Хабр! С вами команда Russtech — разработчики ведущего российского оператора рекламы вне дома Russ. Сегодня мы расскажем о еще одном нашем IT-продукте — платформе управления контентом на цифровых экранах Russ Player. Данный инструмент помог нам существенно оптимизировать работу с креативами и добиться гибкого, эффективного планирования рекламных кампаний. В статье разберем, что представляет собой система вещания, как формируется расписание эфира и какие возможности в цифровой рекламе вне дома (DOOH) открывают realtime-механики.
Разработка децентрализованной платформы
В 2020 году наша компания взяла курс на цифровизацию рекламного инвентаря. На тот момент мы уже имели опыт работы в различных системах вещания, и у каждой из них были как несомненные плюсы, так и минусы. Однако полностью удовлетворяющего нашим потребностям решения на рынке не было. Поэтому мы решили разработать свою систему управления контентом для всей сети цифровых рекламных конструкций.
Мы построили систему вещания как клиент-серверное приложение с микросервисной архитектурой. Основными компонентами стали:
сервер управления — координирует работу системы, управляет контентом и собирает аналитику;
плееры (клиенты) — отвечают за воспроизведение креативов;
база данных — в ней хранится информация о рекламных кампаниях и инвентаре;
файловое хранилище, работающее по протоколу S3, — предназначено для хранения медиафайлов.
Для управления микросервисами и их взаимодействием была разработана специализированная платформа. Она установлена на каждом плеере (клиенте) и сервере и самостоятельно скачивает, разворачивает и обновляет необходимый набор микросервисов из репозитория.
В стандартный пакет микросервисов платформы плеера мы добавили сервисы, которые отвечают за:
загрузку контента с хранилища S3 на плеер и формирование расписания вещания;
подключение к серверу;
систему вывода изображения (отрисовка и формирование изображения, обработка разметок и сигналов ввода);
интеграцию с системой аукционных продаж (RTB, Real-Time Bidding, торги в реальном времени);
активацию триггеров;
составление фотоотчетов и эфирной справки.
При этом настроили систему так, чтобы при появлении эксклюзивной услуги для определенного типа конструкций на всех устройствах этого формата автоматически устанавливался необходимый дополнительный микросервис.
Серверная часть базируется на той же платформе, но уже со своими микросервисами. По сути, серверы для нас также являются управляемыми устройствами (клиентами), и мы можем ими также быстро управлять, добавляя новые услуги и распределяя высоконагруженные задачи.
Планирование эфира
На этапе разработки Russ Player наиболее востребованными были креат��вы длительностью 5–10 секунд. Ориентируясь на это и учитывая удобство расчета расписания, мы регламентировали выход контента 5-секундными слотами. При этом предусмотрели, чтобы при необходимости система могла также формировать расписание и для контента любой другой продолжительности.
Ключевая функция системы вещания — это доставка и воспроизведение рекламных кампаний. Каждая цифровая конструкция получает свой собственный набор рекламных кампаний и, как следствие, имеет свое индивидуальное расписание.
Рекламные кампании могут состоять из различного вида контента: видеоролики, картинки, HTML-контейнеры. Их выходы внутри кампании в каждом случае настраиваются по-разному:
последовательно друг за другом;
в соответствии с процентным распределением (ролик 1 — 10%, ролик 2 — 50%, ролик 3 — 40%);
с учетом заданного интервала (ролик 1 — с 1 по 15 мая, ролик 2 — с 15 по 30 мая, ролик 3 —только по понедельникам, ролик 4 — с 14:00 до 16:00 по выходным) и т. д.
Таким образом, получается, что рекламная кампания — это как бы заказ на размещение определенного контента с четкими правилами трансляции. Расписание строится именно из рекламных кампаний, а они, в свою очередь, являются конвейерами-поставщиками креативов, которые имеют свой алгоритм воспроизведения. То есть построение расписания — это, по сути, NP-полная задача. В первую очередь нам необходимо соблюдать частотность и равномерность выхода в эфир каждой кампании. Кроме этого, настолько, насколько это возможно, мы разделяем рекламодателей по категориям, то есть стараемся, чтобы ролики разных банков, застройщиков и автодилеров не играли подряд друг за другом. По большей части задача сводится к построению цикла, который мы могли бы вещать по кругу, удовлетворяя всем условиям задачи на минимальном временном промежутке.
Другими словами, строится первичное расписание, во время которого можно частично применить известные практики комбинаторной оптимизации, например, задачу о рюкзаке. Далее это построение по определенным правилам перебирается 3 628 800 раз (10! — десять факториал), и система выбирает наилучший вариант расписания на следующий час. Учитывая сложность необходимых вычислений, мы перенесли формирование расписаний на сами клиентские устройства. В противном случае планирование эфира для десятка тысяч конструкций стало бы колоссальной нагрузкой на сервер.
Изменения в расписании
Система управления вещанием позволяет вносить динамические изменения в построенное расписание. Контент в рекламных кампаниях может иметь различный приоритет (вес). Ролики с нулевым приоритетом предварительно загружаются на устройство, но воспроизводятся только в исключительных случаях. В частности, для заполнения свободных слотов мы используем специальные кампании — филлеры. В них входят ролики-заглушки с приоритетом 1 и ролики с нулевым приоритетом, которые мы продаем через аукцион реального времени (RTB). За 5 секунд до выхода контента система отправляет запрос на эндпоинт и в зависимости от ответа в эфир показывает либо креатив победителя RTB-аукциона, либо ролик с приоритетом 1.
Аналогичный механизм используется в случае событийной рекламы, то есть только при наступлении определенных событий (смена погодных условий, дорожные пробки и др.). Благодаря этому мы можем транслировать наиболее релевантный контент в зависимости от текущей ситуации.
Второй способ изменения расписания — триггерные механики. Они позволяют показывать определенный контент точно в заданный момент. При срабатывании триггера текущий ролик доигрывается до конца, и сразу после него запускается новый, указанный в триггере. При этом данный ролик может как входить в общее расписание, так и быть с нулевым приоритетом. Получается, что из-за триггера мы как бы добавляем новый элемент в график вещания, что может нарушить запланированную частотность всех элементов расписания. Чтобы этого избежать, мы используем следующий подход: триггерный выход происходит за счет кампании, в которой расположен вызываемый контент. Когда он срабатывает, система автоматически удаляет ближайший запланированный выход в эфир той кампании, за счет которой произошел вызов.
Позже мы адаптировали эту механику в синхронизацию. В частности, при синхронизации с рекламой на радио в качестве сигнала триггера используется запрос от радиостанции о старте рекламного ролика, который перенаправляется триггерным запросом на экраны, участвующие в рекламной кампании.
Для одновременного выхода креативов на цифровых конструкциях нам также потребовалось предварительно выровнять сетку вещания и привязать ее ко времени, чтобы стандартные 5- и 10-секундные ролики стартовали в ровное время, например, в 12:00:00, и научиться вызывать триггеры локально по заданному циклу, чтобы не зависеть от нестабильной связи.
С помощью HTML+JavaScript можно также реализовывать умные креативы. Например, показывать счет матча, таймер обратного отсчета до события, отобразить погоду в реальном времени и т. д.
Обычно при корректировке расписания устройства получают описание рекламных кампаний и при необходимости скачивают недостающий контент. Если одна из кампаний должна пойти в эфир прямо сейчас, одновременно запускается расчет нового расписания. Нередко скорректированный график начинает работать быстрее, чем догружается весь контент. Переход на новое расписание, как правило, происходит бесшовно. Если ролик, необходимый для текущего момента эфира, еще не загружен, он пропускается, и воспроизводится следующий.
При отсутствии связи цифровая конструкция не получает нового расписания, но продолжает воспроизводить прежнее в соответствии с условиями запланированных кампаний. В такой ситуации обычно также недоступны realtime-механики, например, RTB, триггеры и HTML. Поэтому для себя мы выработали следующую схему действий. В случае с RTB мы просто показываем филлеры. Триггеры, в свою очередь, могут продолжать работать локально по заданному расписанию (например, для синхронизации), однако те, что основаны на realtime-событиях, само собой, на данном инвентаре не отрабатываются. С HTML нужно заранее учитывать возможность отсутствия связи и предусматривать соответствующую обработку событий.
Впоследствии при восстановлении соединения устройство сразу получает актуальное расписание и начинает загрузку недостающего контента. Также возобновляется работа всех realtime-механик.
Защитные механизмы системы
Ежедневно мы отслеживаем работоспособность и техническое состояние десятков тысяч устройств. Нам важно контролировать состояние экранов, температуру процессора и видеокарты, использование оперативной памяти и свободное место на накопителях. Агрегируя эти метрики, мы получаем возможность оперативно выявлять устройства, требующие технического обслуживания, включая и те, на которых перестало меняться изображение или возникли трудности с загрузкой контента.
Мы контролируем стабильность соединения, статус «онлайн/офлайн» в реальном времени, историю активности в сети и состояние загрузки контента. А также дополнительно следим за воспроизведением и имеем доступ к изображению в реальном времени с рабочего стола и с камеры, направленной на экран.
Кроме того, система вещания самостоятельно контролирует воспроизводимый контент. Во-первых, она не включает в эфир креатив, который сама не скачивала с доверенного источника. Во-вторых, контент имеет цифровую подпись, которую система сверяет во время каждого воспроизведения. Что также исключает трансляцию материала, который нештатным образом попал к доверенному источнику. Кроме того, внутренний способ загрузки рекламных материалов имеет многоуровневую систему согласования с юридической и технической точки зрения, и пока на всех уровнях контент не получит подтверждения, загрузить его в систему невозможно.
Также мы собираем отчетность о вещании. Каждый показ ролика фиксируется в логе с указанием идентификаторов рекламной кампании и контента, точного времени начала и окончания воспроизведения. Обычно используем два способа передачи данных:
реактивный лог — отправка коротких сообщений (2–3 записи) в режиме реального времени без подтверждения доставки;
агрегированный лог — ежечасная отправка архива данных с подтверждением доставки.
Система способна также формировать эфирные справки, содержащие детальную статистику выходов рекламных кампаний с указанием точного времени начала и окончания показа каждого ролика. Справки создаются за выбранный период (например, за последние 2–3 дня). Для RTB-кампаний предусмотрен еще и Proof of Play. Так, после успешного показа рекламного контента генерируется подтверждение, которое также передается для отчетности в систему аукционов.
Дополнительно реализована возможность визуального подтверждения выхода креатива в эфир. Система интегрирована с видеокамерой и производит фотофиксацию контента в момент его воспроизведения. Каждый час устройство фиксирует уникальные креативы и отправляет фотоотчеты в специальное хранилище.
Итоги
Мы создали систему управления цифровым контентом, которая сочетает в себе децентрализованную архитектуру, высокую отказоустойчивость и гибкость. Благодаря этим характеристикам она способна оперативно адаптироваться к изменениям в рекламных кампаниях, обеспечивая бесперебойное вещание даже при нестабильном соединении.
Спасибо за внимание!
