Воронки программной конверсии с Apache Druid

В нашем последнем сообщении в блоге мы объяснили, что такое программатик-реклама, как создать базовую систему назначения ставок и как анализировать запросы ставок с помощью Apache Druid.

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

Цель состоит в том, чтобы создать панель отчетов для визуализации воронок конверсии между bid requests->bids->wins->impressions->clicks по издателям, местоположениям, моделям устройств и т. д.

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

Весь упомянутый здесь код, а также автоматизированные спецификации и инструменты для создания примеров данных включены в репозиторий simple-bidder:



Настройка кампании

Сначала нам нужно расширить нашего базового участника торгов, чтобы он действительно возвращал ставку вместе с тегом. В этом руководстве мы будем поддерживать только мультимедийные креативы. Однако эти концепции также применимы к VAST и другим типам объявлений.

Для этого нам нужно создать три новые модели MVC: Seat, Campaign, & Advertisement. advertisement содержит такие атрибуты, как width and height, html/xml tag, domain и т. д. В этом примере мы не будем усложнять.

Сделать ставку

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

advertisement = Targeter.call(bid_request: bid_request)

В нашем случае мы не будем усложнять и просто вернем последнее объявление в базе данных: return Advertisement.last.

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

Анализ заявки и других событий

Теперь, когда у нас есть способ обрабатывать запросы ставок и возвращать ставку с креативом, нам нужно настроить Druid для отслеживания и анализа wins, impressions, clicks, etc.

Мы собираемся сделать нашу систему универсальной, создав схему, похожую на функцию Единая таблица Rail Наследование, где значение поля type строки определяет класс, экземпляр которого создается.

Давайте создадим общую таблицу events SQL:

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

Мы возьмем нашу старую схему и добавим несколько новых показателей. Мы собираемся отслеживать счетчики, сгруппированные по type. Это делает систему отслеживания универсальной и расширяемой. Эти новые метрики javascript определяются путем предоставления функции aggregate, combine, & reset для метрики в друиде.

Вы можете найти полную новую схему здесь: https://gist.github.com/therevoltingx/59f92dc823cf5b8ff3dd86f0c5a5c213

Shaman, наша облачная платформа Druid, поддерживает эти типы метрик и называет их Filtered Long Sum метриками.

Хранение событий в PostgreSQL

Поскольку такие события, как bids, wins, impressions, clicks, etc, представляют собой небольшие данные и происходят не так часто, как запросы ставок, мы можем использовать PostgreSQL для их хранения. В производственной среде Redshift хорошо справляется с обработкой этих небольших данных о событиях. Однако Redshift не сможет справиться с объемом запросов ставок.

Однако Druid отлично справляется с анализом запросов ставок, поскольку может обрабатывать большое количество событий. Таким образом, запрос ставки — это просто еще один тип событий, но они не хранятся в PostgreSQL.

Наша таблица events также является универсальной, как мы упоминали ранее. Мы используем поле type для обозначения класса события.

Новые маршруты отслеживания

Теперь, когда Druid и PostgreSQL настроены, мы можем вернуться к участнику торгов. Возвращаясь к возможности вернуть ставку, мы собираемся сохранить ставку в PostgreSQL как event и отправить ее в Druid для анализа.

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

Один новый маршрут — /v1/wins, который является частью URL-адреса, который возвращается в ставке как его nurl. nurl – это URL-адрес, который открывается, когда клиент выбирает нашего конкретного участника торгов в качестве победителя. Вот пример win url:

http://localhost:9292/v1/wins?bid_id=ABC123&price=1.50

Наш простой участник торгов использует localhost, потому что оттуда мы будем запускать все наши тесты. Очевидно, что в производственных условиях это было бы иначе.

Первое, что делает маршрут win, это ищет bid из таблицы событий по bid_id.

Он использует всю информацию из bid для создания нового события win. Новое событие win также сохраняется в PostgreSQL и отправляется в Druid для анализа.

Другой наш новый маршрут, /v1/events, представляет собой общий маршрут для отслеживания невыигрышных событий. Такие вещи, как impressions, clicks, etc., попадают в эту категорию. Мы используем этот общий механизм, чтобы иметь возможность отслеживать любые события в будущем, такие как installs, video_views, video_25%, etc..

Вот пример события показа:

http://localhost:9292/v1/events?bid_id=ABC123&type=impression

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

Генерация демонстрационных данных

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

Сначала нам нужно запустить наш веб-сервер в localhost для прослушивания http-запросов. Мы обновили этот процесс из нашего предыдущего поста в блоге.

Если вы еще этого не сделали, запустите миграцию и заполните пробную кампанию, используя следующее:

Затем запустите веб-сервер, используя:

export TRANQUILITY_URI=https://shaman-proxy-staging.zero-x.co/v1/index/593a1a4ad68c54057090b38b/fa7cdcc2a478af82680070f61a3779a1
bundle exec puma

Вам нужно изменить TRANQUILITY_URI, чтобы он указывал на ваш хост tranquility.

Затем запустите тестер, который сгенерирует образец bid_requests, wins, & impressions.

ruby bin/tester

Теперь у вас будут данные и в Druid, и в PostgreSQL.

Визуализация воронок

Как и прежде, мы собираемся использовать Superset для создания панели инструментов для визуализации производительности по различным параметрам, таким как местоположение, пол и т. д.

Наша настройка в основном такая же, как и раньше, за исключением того, что мы добавляем новые показатели для bid_requests, bid, wins, and impressions. Это очень просто, и их определение JSON выглядит так:

{"type": "longSum", "name": "impressions", "fieldName": "impressions"}

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

В заключении

Теперь мы создали простую систему, позволяющую делать ставки и эффективно анализировать воронки конверсии в программатик-рекламе.

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

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

Шаман: Облачный друид

Если вы хотите получать потоки запросов ставок в режиме реального времени и создавать мощные информационные панели для своей команды, не нарушая при этом своего кошелька, тогда Shaman для вас.

Shaman — это платформа самообслуживания для развертывания кластеров с одним и несколькими узлами в облаке.

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

Посетите https://zero-x.co, чтобы узнать больше и создать учетную запись.

О

ZeroX предоставляет размещенные кластеры Druid, службы данных и консультационные услуги AdTech.

Свяжитесь с нами по телефону [email protected] и давайте поговорим.

Кроме того, узнайте больше обо мне в LinkedIn и не стесняйтесь подключаться!