Жизненный цикл и успешность рекламной кампании, проводимой на цифровой платформе, сильно зависят от наличия надёжного механизма обратной связи. Такой механизм состоит из различных подсистем, спроектированных в расчёте на мониторинг, анализ и оптимизацию рекламных кампаний. Компания Netflix приступила к созданию надёжной платформы для обработки событий, которая не только соответствует текущим нуждам, но и способна расти в соответствии с будущими задачами. Данный материал посвящён рассказу об эволюции архитектуры нашего конвейера для обработки событий рекламной системы, и тому, какие технические решения лежат в его основе.
Система Ad Serving (обслуживание рекламных объявлений) играет роль «мозга» конвейера. Она ответственна за принятие решений, за оптимизацию доставки рекламных материалов, за обеспечение того, что подходящее объявление показано правильному клиенту в правильное время. А система Ad Events (события, связанные с объявлениями) вступает в дело после того, как объявление показано пользователю. Она сравнима с «сердцебиением» и «кровеносной системой» конвейера. Она непрерывно, в реальном времени, обеспечивает работу механизма обратной связи. Сравним те сведения, передачу которых она обеспечивает, с кислородом и питательными веществами. Эти сведения повышают качество принимаемых решений, оптимизации, формирования отчётов, измерений. Они используются при выставлении счетов. Продолжая аналогию с живым организмом, отметим следующие важные моменты:
Так же, как мозг зависит от постоянного кровотока, система Ad Serving зависит от наличия стабильного потока рекламных событий. Наличие постоянного доступа к таким событиям позволяет ей корректировать решения о показе следующих объявлений, ограничивать частоту показа объявлений, управлять распределением рекламного бюджета, персонализировать объявления.
Если кровь (поток рекламных событий) остановится — мозг (Ad Serving) недополучит важных сведений о текущем состоянии дел и начнёт принимать неправильные решения, или даже «поломается».
Чем здоровее «кровеносная система» и чем чётче она работает (как в реальном организме) — тем лучше система Ad Serving сможет адаптироваться к текущей ситуации, тем выше будет уровень оптимизации рекламной кампании, и тем значительнее будут достигнутые с её помощью бизнес-результаты.
Расскажем теперь о том, как создавался наш конвейер.
Пилотный проект
В ноябре 2022 года мы, в партнёрстве с Microsoft, запустили совершенно новый базовый рекламный тариф. Соответствующая программная система расширяла существующую в Netflix систему проигрывания видео, позволяя показывать рекламные сообщения. Изначально эта система проектировалась так, чтобы она была бы простой, безопасной и эффективной. В её основе лежал следующий принцип: инициаторами операций являются устройства пользователей, при выполнении операций используется прокси-сервер. Система состояла из трёх основных компонентов: Microsoft Ad Server, Netflix Ads Manager и Ad Event Handler. За каждым показанным рекламным сообщением нужно наблюдать. Это необходимо для обеспечения эффективного функционирования цикла обратной связи. Он даёт внешнему рекламному серверу сведения о показах объявлений, об ограничениях на число показов (это — реализация политики рекламодателя, ограничивающей количество показов конкретного объявления некоему пользователю), о монетизации рекламной кампании.
Среди ключевых составных частей этой системы отметим следующие:
Client Request. Клиентские устройства отправляют системе воспроизведения контента Netflix запросы на получение объявлений во время перерыва на рекламу. Затем система Ads Manager дополняет эти запросы информацией, необходимой для того, чтобы запрашивать объявления у Ad Server.
Server-Side Ad Insertion. Система Ad Server отвечает на запросы, используя формат VAST (Video Ad Serving Template).
Netflix Ads Manager. Эта служба парсит VAST-документы, извлекает из них информацию о событиях, фиксируемых системой наблюдения за событиями, и создаёт ответы, имеющие упрощённую структуру и предназначенные для системы воспроизведения контента Netflix и для клиентских устройств. А именно, тут происходит следующее:
— Информация, касающаяся отслеживаемых показателей, упаковывается с использованием структурированной модели данных, основанной на protobuf.
— Полученные данные шифруются для создания «непрозрачного» токена (opaque token).
— Итоговый ответ даёт клиентскому устройству сведения о том, когда нужно отправлять сведения о событиях, и о том, какой ему для этого использовать токен.
Client Device. При проигрывании рекламного объявления клиентские устройства отправляют события, снабжённые токеном. Система телеметрии Netflix, получая их, ставит их в очередь Kafka для асинхронной обработки.
Ads Event Handler. Этот компонент представляет собой Kafka-консьюмер, который читает/расшифровывает полезные сведения, которые имеются в событии, и перенаправляет данные об отслеживаемых показателях подсистеме Ad Server и системам сторонних компаний.
Вот — отличный материал на эту тему, где описывается сквозное тестирование этой системы в реалистичных условиях. Эта система спроектирована так, чтобы с её помощью можно было бы быстро устанавливать связь с системами сторонних компаний, вроде DV, IAS и Nielsen для проведения различных измерений.
Расширение проекта
По мере того, как мы расширяли список сторонних компаний, связанных с рекламой, с которыми сотрудничали для проведения различных измерений, трекинга событий, верификации, мы обнаружили очень важную тенденцию: рост объёма данных, включаемых в состав «непрозрачных» токенов. То, что эти токены кешируются на клиентских устройствах, означало риск неоправданно высокого использования памяти, что вполне могло повлиять на производительность устройств. Мы, кроме того, ожидали роста числа трекинговых URL сторонних компаний, роста объёмов метаданных, роста количества типов событий по мере того, как в систему добавлялись новые возможности.
Мы, применяя стратегический подход к решению этих задач, ввели в систему новый слой для хранения информации, основанный на абстракции типа «ключ-значение». Этот слой расположен между системами Ad Serving и Event Handling. Мы назвали его Ads Metadata Registry (реестр рекламных метаданных). Он представляет собой сервис для временного хранения информации о показанных рекламных объявлениях. При срабатывании функции обратного вызова обработчик события читает из него информацию о событиях и перенаправляет её системам сторонних компаний. Контракт между клиентским устройством и рекламными системами Netflix по-прежнему предусматривает применение «непрозрачных» токенов при работе с каждым событием, но теперь, вместо трекинговой информации, он содержит имена событий и справочные идентификаторы: рекламные идентификаторы — Ad ID и идентификаторы записей соответствующих метаданных в реестре. Благодаря такому подходу мы подготовили нашу систему к возможному будущему росту объёма данных, которые нужно будет передавать между подсистемами Event Handling и Ad Serving.
Эволюция проекта
В январе 2024 года мы решили вложить средства в создание собственной рекламно-технологической платформы. Это означало необходимость серьёзной эволюции конвейера обработки событий. А именно, он должен был достичь паритета с существующими решениями, а так же — должен был продолжать поддерживать запуски новых продуктов, обеспечивая высокую скорость итеративной разработки с использованием собственного рекламного сервера Netflix — Netflix Ad Server. Это требовало переоценки всех архитектурных решений в рамках всех проектов, над которыми работали команды подразделения Ads Engineering.
Сначала мы составили перечень сценариев, работу которых должна была обеспечивать система Ad Events.
Поддержка механизмов ограничения частоты показа для всех объявлений, обслуживаемых с помощью Netflix Ad Server.
Интеграция в систему ценовой информации, касающейся показов объявлений, что позволило бы создать основу для обработки биллинговых событий, которые используются для выставления счетов рекламодателям.
Надёжная система формирования отчётов, которая позволяла бы передавать рекламодателям отчёты о рекламных кампаниях. Эти отчёты, вместе с собранными метриками, позволяют анализировать особенности доставки объявлений и эффективность рекламных кампаний.
Возможность масштабирования системы обработки событий в расчёте на работу с трекинговой информацией, предоставляемой различными системами сторонних компаний.
Далее — мы исследовали проекты, которые находились на стадии запуска. В частности — подсистемы Pause Ads и Display Ads. Это нужно было для того, чтобы глубже понять наши стратегические инициативы. Мы выяснили, что подсистема Display Ads будет использовать собственный фреймворк логирования данных. Это говорило о том, что телеметрические данные рекламы могут попадать в эту подсистему из различных конвейеров. При этом ожидалось, что те сценарии, которые предусматривают обработку информации, выходящей из этой подсистемы, в основном, не поменяются. Кроме того мы, изучив цели наших команд, занимающихся телеметрией, выяснили наличие больших планов, предусматривающих обновление платформы. Это указывало на то, что в будущем может возникнуть необходимость в переходе на новую инфраструктуру.
После того, как мы всё это выяснили и учли, у нас получилось следующее:
Мы спроектировали централизованную систему сбора рекламных событий. В ней множество распространённых операций объединяются в единый шаг. Среди таких операций — расшифровывание токенов, добавление в события новых сведений, хеширование идентификаторов. Она предоставляет потребителям событий единый унифицированный контракт, который легко поддаётся расширению (не привязан к конкретным рекламным серверам или к конкретным типам рекламных объявлений).
Мы предложили сделать так, чтобы все потребители рекламной телеметрии получали бы данные от централизованной системы. Такой подход позволяет, в рамках подразделения Ads Engineering, добиться чёткого разделения между системами-поставщиками данных, находящимися до централизованной системы обработки рекламных событий, и потребителями.
На начальной фазе разработки нашей рекламной системы важнейшим шагом было создание механизма формирования рекламных сессий, основанных на индивидуальных рекламных событиях. Эта система была сконструирована с учётом использования телеметрии воспроизведения рекламы, что позволило нам собирать основные метрики из соответствующих рекламных сессий. Здесь мы приняли важное решение, касающееся того, что процесс формирования рекламных сессий логически следует за процессами формирования исходных, необработанных рекламных событий.
Мы, кроме того, порекомендовали перевести все наши конвейеры обработки рекламных событий (ответственные за формирование отчётов, аналитики, метрик) на данные, которые публикует централизованная система.
После того, как мы собрали воедино все наши идеи, получилось то, что нашло отражение на следующей схеме.
Вот основные компоненты, входящие в конвейер обработки событий.
Ads Event Publisher. Эта централизованная система отвечает за сбор рекламной телеметрии и за предоставление унифицированных рекламных событий командам подразделения Ads Engineering. Она поддерживает различные функции, среди которых — выполнение измерений, работа с финансовыми данными, выставление счетов, формирование отчётов, ограничение числа показов объявлений, поддержка обратной связи с подсистемой Ad Server.
Realtime Consumers — подсистемы, которые потребляют данные в режиме реального времени:
Frequency Capping. Эта система отслеживает количество показов объявлений для каждой рекламной кампании и для каждого профиля, собирает сведения о любых других параметрах частоты показа объявлений, заданные для рекламной кампании. Её использует Ad Server, принимая все решения о выдаче объявлений, что позволяет обеспечить показ объявлений с учётом заданных ограничений.
Ads Metrics. Этот компонент представлен задачей Apache Flink, которая трансформирует необработанные данные, «раскладывая» их по различным измерениям и метрикам, а после этого записывает их в OLAP-базу данных Apache Druid. Потоковые данные подвергаются дополнительной обработки с помощью оффлайн-процесса, который исправляет неточности, возникающие в ходе приёма потоковых данных, и обеспечивает корректные значения метрик. Он предоставляет, в режиме реального времени, метрики, позволяющие оценить работоспособность каналов доставки объявлений рекламных кампаний и реализует механизмы ограничения их бюджета.
Ads Sessionizer. Это — задача Apache Flink, которая собирает все события, относящиеся к конкретному объявлению, оформляя их в виде сессии рекламного объявления — Ad Session. Сессия даёт, в реальном времени, сведения о воспроизведении объявления. Эти данные лежат в основе бизнес-аналитики и отчётов. Это — важнейший компонент, данными которыми пользуются все механизмы, ответственные за анализ и формирование отчётов.
Ads Event Handler. Этот компонент в непрерывном режиме отправляет трекинговую информацию, взятую из рекламных событий, системам сторонних компаний, обеспечивая точный и своевременный обмен данными.
Billing/Revenue. Это — оффлайн-подсистемы, задача которых — курирование показов объявлений, поддержка механизмов выставления счетов и процессов признания выручки.
Ads Reporting & Metrics. Эта подсистема поддерживает модуль составления отчётов, предназначенный для наших менеджеров аккаунтов. Она даёт доступ к централизованному API, который позволяет работать с метриками, позволяющими оценивать ход реализации рекламных кампаний.
То, о чём мы рассказали, представляло собой огромный массив работ, выполняемых различными инженерными командами в течение нескольких кварталов. Благодаря тщательному планированию (спасибо нашей команде TPM!) и координации усилий мы смогли быстрее идти по шагам итеративного процесса работы над проектом, смогли создать несколько новых служб и реализовать те планы, о которых писали выше. Всё это стало основой нашей собственной рекламно-технологической платформы.
Заключение
Все эти системы значительно улучшили наши возможности по разработке новых бизнес-механизмов.
Благодаря партнёрству с Microsoft события Display Ad были интегрированы в новый конвейер. Это открыло путь к их многократному использованию и обеспечило обслуживание всех возможных сценариев их применения при запуске кампаний на базе рекламных подсистем Netflix.
Система автоматизированной покупки рекламных показов теперь поддерживает обмен множеством трекинговых URL и динамическую установку цен на события показа объявлений.
Передача сигналов об отказе пользователя от обработки данных помогает обеспечивать конфиденциальность данных и соответствие системы европейским требованиям GDRP, касающимся рекламного бизнеса. Эта система помогает формировать корректные отчёты и метрики.
Новые типы событий, вроде тех, что описывают щелчки по объявлениям или сканирование QR-кодов, тоже проходят через конвейер. Благодаря этому обеспечивается единообразие в сборе метрик и в формировании отчётов.
Основные выводы
Стратегическая, поэтапная эволюция проектов. Разработка наших систем обработки рекламных событий представляла собой хорошо продуманную последовательность действий. Каждая итерация была тщательно спланирована. Здесь учитывались такие факторы, как решение текущих задач и учёт будущих нужд. Каждая итерация опиралась на командную работу, в том числе — на скоординированные усилия различных команд. Всё это — тот фундамент, на котором основан успех нашего проекта.
Применение контрактов данных. Чёткие контракты данных — это чрезвычайно важная часть обеспечения единообразия в интерпретации показателей и в организации совместной работы различных систем. Стандартизуя модели данных, создавая понятные механизмы обмена данными между рекламными подсистемами, централизуя сбор событий, наши команды смогли очень быстро проходить по шагам итеративного процесса разработки и вовремя выпускать новые продукты.
Разделение ответственности. Потребители освобождены от необходимости понимать особенности работы с каждым из источников рекламной телеметрии, им не нужно управлять обновлениями или миграциями данных. Всем этим занимается централизованная система, что позволяет потребителям сосредоточиться на задачах, относящихся к их бизнес-логике.
Впереди нас ждёт много интересных проектов. Среди них и работа с рекламными событиями из объявлений, показываемых на прямых трансляциях Netflix, и организация работы процессов дедупликации данных. Это — задачи по добавлению в состав атрибутов событий новых сведений, которые позволят расширить возможности по формированию отчётов и по анализу данных. Мы, кроме того, развиваем нашу стратегию, называемую Native Ads, интегрируя в систему API Conversion. Это позволит улучшить трекинг конверсий.
Всё это, конечно же, не финал одного из сезонов нашего «сериала». Это — только начало пути к созданию лучшей в своём классе рекламно-технологической платформы. Приглашаем вас высказаться в комментариях, поделиться с нами своими мыслями. А если вы хотите больше о нас узнать, или стать частью нашего путешествия к инновациям — знайте, что подразделение Ads Engineering ищет сотрудников!
О, а приходите к нам работать? 🤗 💰
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.
