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

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

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

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

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

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

• 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 Автоматизируйте все, что можно

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

Успехов!

Читайте также: Зарплата $68 тыс. в год: как стать дата-инженером — дорожная карта