Автоматизация 07/03/2023

Как нестандартно автоматизировать таргетированную рекламу: главные советы дата-инженера

Scala Data Engineer в NIX

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

Курс Комерційний директор.

Зосередження на практичних завданнях та послідовному аналізі проектів замість великої теорії. Реалізуй свої мрії про керівну посаду після завершення курсу.

Дізнатись програму

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

Вспомним принципы таргетированной рекламы

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

Со временем все эти шаги удалось автоматизировать благодаря таким сервисам:

Supply-Side Platform. Эти платформы управляют рекламными местами на сторонних сайтах и приложениях. Их главная цель — продать рекламные места пользователей такого сервиса по выгодной цене. Также SSP предоставляет исчерпывающую информацию о посетителях. Фактически это сторона предложения на рынке.

Demand-Side Platform. Созданы для размещения рекламы на площадках, предлагаемых SSP. Они формируют запросы, то есть спрос. DSP помогает рекламодателям размещать объявления на качественных площадках по минимальной цене.
Real-Time Bidding. Это механизм рекламных аукционов в режиме настоящего времени. В нем принимают участие SSP и DSP. Принцип работы RTB изображен на этой схеме:

Что именно происходит:

Пользователь заходит в мобильное приложение, где есть баннеры.
Информация об этом входе передается SSP, управляющей рекламными местами в этом приложении.
Далее создается запрос к сервису, проводимому аукционом — AD Exchange.
Он посылает бид-реквест на все DSP, на которые подписана SSP (в изображенном примере их три).
Все платформы делают возвращаемые ставки к сервису-аукциону.

Сервис сравнивает ставки.
Кто поставил больше, тот и получает право разместить баннер в приложении. Все происходит автоматически, за доли секунды.

В контексте нашей темы следует упомянуть и следующие термины:

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

Ретаргетинг — это направление рекламы на ту аудиторию, которая уже знакома с презентуемым продуктом. Здесь внимание акцентируется на использовании определенного сайта или приложения.

Переходим к проекту. Какая цель перед нами стояла?

Наша команда должна была усовершенствовать систему таргетированной рекламы, которая модифицировала и оптимизировала User Acquisition и ретаргетинг. Масштабы деятельности этой системы действительно поразительны. В среднем сервис обрабатывает почти миллион реквестов в секунду! К тому же трафик поступает из многих регионов: от США и Бразилии в Европу и Японию.

Сервис построен на многих модулях, поэтому стек технологий очень разнообразен:

Для хендлинга бид-реквестов мы использовали бидер, главный модуль реквестов хендлинга, написанный на Scala. Для его API берем стек Akka-библиотек. Также они требуются для других модулей на Scala.
Для передачи бид-реквестов — в качестве месседж-брокера выбрали Apache Kafka. Он может не только передавать другим модулям рекламу о ставках, но и выдерживать значительную нагрузку в режиме реального времени.

Для обработки массивов данных — применяем Spark Job для различных целей по обработке таких больших объемов информации.
Для фронтенда используем Angular. Сервис, управляющий API фронтенда, написан на Java с применением фреймворка Spring.
Для прогнозирования ставки требуется мощный инструмент предсказания оптимального уровня цены за рекламный показ. С этим помог Python с PMML-моделями.
Для сохранения информации MySQL выбрали для данных, которые должны храниться более недели, для часто изменяемых данных и кэша — Aerospike и Redis, а для аналитических данных — Apache и Druid.

Для работы с логами взяли Elasticsearch. Платформа генерирует множество логов. С таким массивом он лучше справится.
Веб-сервисы. Для деплоя и других связанных задач мы подключили множество AWS-сервисов: EC2, ECS, EMR, S3, S3 Glacier и т.д.

Разница между Redis и Aerospike

Наверняка вы обратили внимание на использование одновременно Redis и Aerospike. Но ведь это NoSQL-базы со схожим функционалом. Почему бы тогда не оставить одну из них? Но нам нужны оба варианта (у нас это опенсорс-версии).

Здесь следует учитывать их отличия — критические для нашего проекта:

Использование флеш-памяти. Сервис генерирует множество данных, которые трудно хранить только в оперативной памяти. Redis в бесплатной версии работает только с RAM. Aerospike этой проблемы нет, поэтому мы используем с ним SSD.
Поддержка триггеров. У Aerospike отсутствует такой функционал, а вот у Redis он есть. Для нашего проекта это очень важно. Мы используем publish/subscribe-механизм для некоторых данных, и их изменение должно триггерит конкретный метод.
Горизонтальный скейлинг. В отличие от Aerospike Redis плохо масштабируется на горизонтальном уровне. Эта БД больше подходит для хендлинга большой нагрузки.
Консистентность данных. Redis не гарантирует консистентность данных, что для нашего проекта критично. У Aerospike есть полная поддержка этого.
AWS-интеграции. Redis успешно интегрирован с Amazon Web Services через ElastiCache. У Aerospike этого нет. Он деплоится фактически только на EC2-инстанции.

Как работает Reporting UI

В проекте все модули по-своему интересны. И я бы выделил две наиболее нетипичные части. Первая — Reporting UI. Этот модуль отправляет репорты, но реализуемый механизм отличается от привычных методов. Обычно репорты с важной бизнес-информацией поступают на email или разные BA-инструменты.

В нашем случае репорты можно посылать еще в Slack. В этом мессенджере происходит вся коммуникация по проекту.

Мы добавили и другие функции:

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

Техническая реализация модуля не сложная. Сначала мы делаем запрос на Amazon Athena для получения нужной информации по бид-логам. Эти данные приводим в нужные для репортов форматы. Далее остается выбрать путь рассылки: на email, у Slack-канал или чат-бот (если есть соответствующая команда).

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

Другой интересный модуль — это Stopper

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

Обычно зафиксировать эти проблемы просто, ведь у нас много аналитических данных и метрик. Нужно было остановить бидер и исправить баг. Тогда мы решили сделать высокоуровневый Exception Handler, наш Stopper. Его цель — автоматизировать идентификацию проблем и остановку хендлинга реквестов.

Реализация Stopper довольно проста:

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

Поскольку мы понимаем нормативные показатели, то можем выставлять минимальные и максимальные уровни для топиков и тайм задержки. При превышении или недостатке ивентов данные об этих проблемах отправляются в MySQL-таблицу. Там Stopper проверяет информацию и решает: останавливать хендлинг реквестов или нет.

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

Что следует учесть перед началом работы?

1 Не нужно загонять себя в рамки одного решения

Как видите, одной NoSQL-базой дело не ограничились. Это позволило нам объединить все лучшее из Redis и Aerospike, увеличить возможности расширения системы и в конечном счете сэкономить деньги, что также ценит бизнес.

2 Используйте привычные подходы и инструменты необычным способом

Мы попытались отправлять важную BA-информацию в мессенджеры. Это не так уж традиционно в большинстве проектов, но оттого и интересно. И что важно — такое решение в разы повысило мобильность бизнес-аналитиков.

3 Автоматизируйте все, что можно

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

Успехов!

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.