Як нестандартно автоматизувати таргетовану рекламу: головні поради дата-інженера

Здавалося б, сервіси таргетованої реклами вже достатньо автоматизовані. Та наша команда Data-інженерів вирішила поглянути на деякі звичні технології під іншим кутом. Врешті ми знайшли нові дієві рішення для клієнта.

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

Згадаймо принципи таргетованої реклами

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

З часом всі ці кроки владося автоматизувати завдяки таким сервісам:

• Supply-Side Platform. Ці платформи керують рекламними місцями на сторонніх сайтах і застосунках.  Їх головна мета — продати рекламні місця користувачів такого сервісу за вигідною ціною. Також SSP надає вичерпну інформацію про відвідувачів. Фактично це сторона пропозиції на ринку.
• Demand-Side Platform. Створені для розміщення реклами на майданчиках, які пропонує SSP. Вони формують запити, тобто попит. DSP допомагає рекламодавцям розміщувати оголошення на якісних майданчиках за мінімальну ціну.
• Real-Time Bidding. Це механізм рекламних аукціонів у режимі реального часу. В ньому беруть участь SSP та DSP. Принцип роботи RTB зображено на цій схемі:

Що саме відбувається:

• Користувач заходить у мобільний застосунок, де є банери.
Курс-професія "Дизайнер інтер'єрів" від Skvot.
Велика практична програма для всіх, хто хоче засвоїти професію дизайнера інтер'єрів і заробляти на реальних проєктах відразу після курсу. Досвідом та інсайтами діляться одразу три лектори.
Програма курсу
• Інформація про цей вхід передається до SSP, що керує рекламними місцями в цьому застосунку.
• Далі створюється запит до сервісу, який проводить аукціон — AD Exchange.
• Він надсилає бід-реквест на всі DSP, на які підписана SSP (у зображеному прикладі їх три).
• Усі платформи роблять ставки, що повертаються до сервісу-аукціону.
• Сервіс порівнює ставки.
• Хто поставив більше, той і отримує право розмістити банер у застосунку. Все відбувається автоматично, за долі секунди.

У контексті нашої теми варто згадати і такі терміни:

• User Acquisition — процес пошуку нових клієнтів, привертання уваги до сайту або застосунку за допомогою реклами. Це основа рекламної діяльності як такої.
• Ретаргетинг — це спрямування реклами на ту аудиторію, яка вже знайома з продуктом, який презентується. Тут увага акцентується на користуванні певним сайтом чи застосунком.
Онлайн-курс "Режисура та візуальний сторітелінг" від Skvot.
Перетворюй свої ідеї на сильні історії в рекламі, кліпах чи кіно Досвідом ділиться режисер, продюсер та власник продакшену, який 10+ років у професії.
Детальніше про курс

Переходимо до проєкту. Яка мета стояла перед нами?

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

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

• Для хендлінгу бід-реквестів ми використовували бідер, головний модуль хендлінгу реквестів, написаний на Scala. Для його API беремо стек Akka-бібліотек. Також вони потрібні для інших модулів на Scala.
• Для передачі бід-реквестів — в якості меседж-брокера обрали Apache Kafka. Він може не лише передавати іншим модулям реквести про ставки, а й витримувати значне навантаження у режимі реального часу.
• Для обробки масивів даних — застосовуємо Spark Job для різних цілей з обробки таких великих обсягів інформації.
• Для фронтенду використовуємо Angular. Сервіс, який керує API фронтенду, написаний на Java із застосуванням фреймворку Spring.
• Для прогнозування ставки потрібен потужний інструмент передбачення оптимального рівня ціни за рекламний показ. З цим нам допоміг Python із PMML-моделями.
• Для збереження інформації — MySQL обрали для даних, які мають зберігатися більше тижня, для часто змінюваних даних та кешу — Aerospike та Redis, а для аналітичних даних — Apache та Druid.
Кіноклуб "Забагато драми" від Skvot.
10 лекцій та 10 практикумів, щоб зрозуміти мистецтво кіномови.Сформуй власний смак та бібліотеку фільмів і навчись писати рецензії.
Програма кіноклубу
• Для роботи з логами взяли 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-інстанси.
Онлайн-курс "Business English for Marketers" від Laba.
Опануйте професійну англійську для маркетингу.Розширте карʼєрні можливості для роботи з іноземними колегами: від розробки нових продуктів до презентації стратегії бренду.
Детальніше про курс

Як працює 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Автоматизуйте все, що можна

Навіть якщо здається, що це неможливо — шукайте варіанти реалізації. Все реально. Ми в цьому впевнились на прикладі з хендлінгом деяких ексепшенів, який звільнив частину ресурсів наших фахівців.

Бажаю успіхів!