В сотрудничестве с Online Marketing команда Siggi из OTTO BI в 2018 году разработаласобственное решение для программной рекламы. Для этой цели, среди прочих элементов, были созданы отдельные SSP (платформа на стороне предложения) и DSP (платформа на стороне спроса). ) было разработано решение под названием Orbidder.
Хотите больше справочной информации? Наш коллега, доктор Райнер Фольк, уже описал предысторию SSP и DSP и рассказал, как эти сервисы работают вместе, в этой записи блога (на немецком языке) в нашем техническом блоге.
Orbidder работает с 2019 года. Ежедневно он обрабатывает от 1 до 1,2 млрд запросов ставок и одновременно управляет более чем 300 активными маркетинговыми кампаниями с помощью моделей Data Science, работающих в фоновом режиме.
В начале 2022 года он Было решено, что решение, изначально созданное с помощью отдела продаж для управления маркетинговыми рекламными кампаниями на внешних веб-сайтах, теперь также должно использоваться для управления рекламой на сайтах otto.de. Это породило новые требования к системному ландшафту и логике управления. В следующей записи блога мы хотели бы поделиться с вами тем, как мы реализовали эти новые требования.
Проблема, которую мы решили
По сути, решение SSP/DSP работает в рамках процесса, показанного на рис. 1 ниже. Запросы ставок для рекламных мест (также называемых «местами размещения») перенаправляются в SSP через адаптер openRTB или prebid.js. Оттуда они обрабатываются и передаются в DSP. В DSP наши ставки определяются на основе моделей, предоставленных командой Data Science. Рассчитанная ставка возвращается и затем реализуется на аукционе. Если мы выиграем, появится визуальное объявление.
Рисунок 1. Базовая структура SSP/DSP
Подключение otto.de к системе создало ряд требований, которые нельзя было сопоставить с настройкой, которую мы использовали до сих пор.
На данный момент для всех известных пользователей («известный» означает, что файл cookie Otto в настоящее время находится на их конечном терминале) каждые 2 часа с помощью пакетного процесса мы определяли, какая кампания может им подойти на основе ряда функций (история кликов, брошенные тележки и др.). Затем это пользовательское назначение экспортировалось и регистрировалось в DSP. Однако этот предварительный расчет и сосредоточенность на одной кампании на пользователя вызвали две технические проблемы, а также организационную «спортивную задачу».
Рисунок 2. Назначение пользователей
Проблема 1 — Нет кампании для текущей страницы
Рисунок 3. Проблема 1
В первом примере пользователь 1 попадает на страницу мультимедиа. Несмотря на то, что им назначена кампания «Бытовая электроника», в данном случае объем контента не совпадает. Предыстория заключается в том, что оптимальная вероятность клика для этого конкретного клиента на самом деле находится на внешних веб-страницах, и поэтому этот клиент получит баннер, отображаемый на otto.de. Во втором примере пользователь 3 вызывает веб-страницу. Для них был рассчитан объем на месте, но они находятся в неправильном контексте — Бытовая электроника, а не Мода, как рассчитано. Итак, опять же, реклама им не показывается.
Проблема 2 — Кампании и рекламные носители на страницу, а не на место размещения
Что на самом деле происходит на веб-сайтах, где есть несколько рекламных мест или мест размещения? В нашем примере мы настроим таблицу «Назначение пользователей», чтобы назначить пользователя 1 кампании, соответствующей области действия.
Рисунок 4. Проблема 2
Обычно запрос ставки включает все места размещения/рекламные места на веб-сайте. Хотя ставки теперь подаются индивидуально для всех мест размещения, предыдущее назначение основывалось на пакетных процессах. В результате пользователь всегда назначается ровно на одну кампанию на 2 часа. Если на веб-сайте доступны 3 места размещения и 2 места выиграны, то одна и та же кампания и, следовательно, один и тот же рекламный носитель отображается на обоих местах размещения.
В нашем примере кампания бытовой электроники была рассчитана для пользователя 1, который также имеет нужный размах. Это означает, что все рекламные места на веб-странице относятся к одной и той же кампании, и это приводит к отображению одинаковых рекламных носителей на всех местах размещения.
Обязанности распределены между несколькими командами
Помимо двух проблем, о которых мы упоминали выше, была еще одна проблема — не столько техническая или профессиональная, сколько организационная. Согласно Википедии, «Закон Конвея» постулирует, что:
«Организации вынуждены разрабатывать системы, отражающие их собственную коммуникационную структуру».
Что ж, этот «закон» отражен и в нашем собственном продукте! Работой инфраструктуры SSP/DSP и выполнением результатов модели занималась одна команда, а моделями Data Science — другая команда — может быть, вы представляете, какие сложности это может вызвать. Одни только различные языки программирования (модели Data Science в Python, DSP/SSP в GO) затрудняли модификацию и тестирование алгоритмов.
Поэтому, стремясь к дальнейшему развитию, нам также необходимо было решить проблему продукта интерфейсы и смогут ли обе команды разрабатывать более независимо друг от друга.
Стек решений и технологий
Итак, как мы могли бы решить эти проблемы? Прежде всего, через обсуждение. Разработчики обеих команд резюмировали основные требования на серии совместных встреч следующим образом:
• Расчет назначения пользователей на рекламное место/место размещения, т. е. больше не одна кампания на пользователя
• Учет текущей среды пользователя (на сайте, вне сайта, приложение, URL-адрес)
• Независимость в разработке Data Science.
Чтобы успешно реализовать эти требования, нам нужно было назначать пользователей для кампании и размещения гораздо быстрее и гибче, чем раньше. А для того, чтобы иметь возможность учитывать информацию об окружающей среде, расчеты должны выполняться в режиме реального времени. Таким образом, мы явно нуждались в назначении в реальном времени.
Решив одну проблему, мы теперь столкнулись с реализацией. Быстро стало ясно, что мы не сможем реализовать новые требования с существующей методологией внедрения. Вот лишь некоторые из препятствий:
• Функция назначения ставок не должна быть настолько сложной, чтобы препятствовать расчету цены за тысячу показов в диапазоне малых задержек
• Доступ к большому количеству данных должен осуществляться в короткие сроки, что увеличит потребность в доступе к нашей базе данных примерно в 1000 раз< br /> • Объем данных и размер данных (например, функций) резко вырастут
• Команды по науке о данных будут сильно ограничены, если потребуется внести изменения.
TensorFlow спешит на помощь
Как вам удается рассчитыватьоптимальный уровень ставок и кампании в режиме реального времени? Ряд различных факторов, таких как бюджет, релевантные кампании и самые разнообразные пользовательские функции, должны быть доступны в миллисекундах и, наконец, связаны друг с другом с помощью формулы, предоставленной специалистами по данным… и все это с очень низкой задержкой!
Поскольку одной из наших целей также было обеспечение независимости специалистов по данным, мы хотели избежать реализации сложной статической функции непосредственно в сервисе. Чтение и запись больших объемов данных из базы данных и в базу данных не прошли тест на скорость, а предварительный расчет отдельных шагов, в свою очередь, оказался недостаточно гибким для решения этих проблем.
Рисунок 5. Логотип TensorFlow
После тщательного рассмотрения и обсуждения лучшим вариантом оказалась платформа машинного обучения, которая позволяет экспортировать полную обученную модель, включая связанные данные. Затем эту экспортированную модель необходимо будет интегрировать в службу и вызвать через интерфейс.
Это привело к нашему подходу к использованию TensorFlow и TensorFlow Serving, разработанных Google для упрощения именно этого типа использования. TensorFlow — это фреймворк для реализации задач машинного обучения и искусственного интеллекта; С помощью TensorFlow специалисты по обработке и анализу данных могут инкапсулировать модели и данные в экспортируемый формат, тем самым сохраняя контроль над алгоритмами и независимо изменяя их, не требуя дополнительных усилий по разработке в SSP или DSP. TensorFlow Serving предлагает простой и эффективный способ оперативной реализации моделей после их обучения. По сути, расширенные запросы ставок можно отправлять в TensorFlow Serving через API, а ответ, состоящий из заявки и кампании, можно прочитать.
Ответ на запрос
Для расчета большая часть данных и функций уже была реализована в моделях TensorFlow, а затем экспортирована как «сохраненная модель», в результате чего модели заняли 15 ГБ. Модели полностью загружаются в Orbidder сервером моделей TensorFlow Serving. Это обеспечивает очень быстрое выполнение кода модели и время отклика в диапазоне от 10 до 20 миллисекунд.
Чтобы мы могли рассчитать ставки и кампании, теперь отсутствуют только расширенные запросы ставок. В дополнение к идентификатору пользователя они также включают информацию о кампаниях, контексте и бюджете. Сервер модели TensorFlow Serving предлагает готовые интерфейсы для gRPC и REST, которые затем позволяют использовать модель. Затем ответ обрабатывается в SSP, и делается ставка на место размещения, что затем может привести к показу веб-страницы и, в идеале, к клику.
Более подробную информацию о расчете ставок можно найти в блоге наших коллег по Data Science.
Карта потока архитектуры
Ландшафт SSP/DSP представлен на упрощенной блок-схеме архитектуры ниже. Это иллюстрирует путь запроса предложения через SSP/DSP, а также показывает некоторые важные компоненты, которые мы кратко объясним.
Рисунок 6. Карта потока архитектуры
Kubernetes
Кластер Kubernetes состоит из отдельных пулов узлов в разных зонах для удовлетворения различных требований к службам (ЦП и ОЗУ).
Redis
Кэш нашего приложения хранит данные от 1 до 60 секунд, после чего обновляется данными из Redis.
Облачное хранилище
Облачное хранилище используется для удобного обмена файлами, а также для хранения и архивирования данных.
PubSub
Это брокер сообщений для передачи ставок, показов и кликов, а также внесения изменений в кампанию
.
BigQuery
Хранилище данных для постоянного хранения данных для улучшения моделей и алгоритмов, а также для сверки доходов и расходов.
Хранилище файлов
Учитывая, что в GKE мы не можем подключить хранилище, которое одновременно читает и записывает, мы используем хранилище файлов (NFS), чтобы
включить это — необходимо обмениваться моделями TensorFlow без простоев.
Prometheus / Grafana
Наши Сервисы генерируют метрики в режиме реального времени; затем они сохраняются в Prometheus и визуализируются с помощью Grafana.
TensorFlow Serving
Для оперативного запуска моделей специалистов по данным эти модели экспортируются со всеми необходимыми данными, а затем запрашиваются с помощью TensorFlow Serving через REST с запросами ставок. .
Орбидер — ключевые факты и цифры
• В октябре 2022 г. Orbidder SSP обработал 71 миллиард запросов.
• В среднем Orbidder обрабатывает от 25 000 до 30 000 запросов в секунду.
• 100 000 запросов в секунду – это максимальная зарегистрированная пропускная способность запросов к Orbidder SSP.
• Средняя задержка обработки запросов составляет 15 миллисекунд.
• Кластер Orbidder GCP Kubernetes регистрирует около 1000 экземпляров службы (модулей) в определенный день.
Орбидер и устойчивость
Otto стремится к 2030 году работать с нейтральным климатом. Вот отличное объяснение климатических целей Otto Group.
Мы всегда стараемся помнить об этих целях в Otto BI, а значит, и в Orbidder. Хотя трудно повлиять на выбросы CO2 на стороне внешнего интерфейса, например. в интернет-браузере при отображении онлайн-рекламы (и даже для того, чтобы вообще сделать их измеримыми), на стороне SSP/DSP в бэкенде мы можем сознательно выбрать применение устойчивых технологий.
Платформа Google Cloud предлагает широкий спектр вариантов для обеспечения устойчивости услуг, например. при выборе услуг всегда можно увидеть, сколько CO2 вызывает конкретная технология или услуга. В среднем компоненты Orbidder выделяют около 1,6 т CO2 в месяц. Это много или мало? Согласно некоторым исследованиям, это соответствует выбросам CO2 всего 6 человек каждый день.
Если на мгновение оставить в стороне принципиальную дискуссию о необходимости интернет-рекламы, то это уже сравнительно неплохие значения. Наши услуги предоставляются в центрах обработки данных в Бельгии, где зафиксированы одни из самых низких значений выбросов в Европе. Тем не менее, мы постоянно оптимизируем арифметические операции Orbidder и, таким образом, последовательно снижаем потребление ресурсов.
Мы приветствуем любые вопросы или комментарии, которые могут возникнуть у вас по поводу Orbidder или других наших задач в Team Siggi! Просто напишите по адресу [email protected].
Эту и еще множество интересных статей ищите в нашем Техлоге.
Написано Майклом Вилгошем и Сергеем Ковальчуком
