ML Advertising

Проектируем платформу ставок с нуля? 💵

Сегодня займемся проектированием своей Real Time Bidding платформы ставок. На упрощенной схеме мы разберем из каких основных блоков она должна состоять, и как эти блоки между собой связаны.

➡️ Article
Собственно сама веб-страница с размещенными на ней рекламными слотами. Также в случае Header Bidding интеграции в шапке HTML кода страницы могут быть прописаны настройки, в которые добавлен наша платформа ставок, как игрок, имеющий доступ к покупке слотов.

➡️ TagJS
JS код, размещенный на странице паблишера. Отвечает за трекинг действий пользователя на сайте, например, когда пользователь доскролил до слота, увидел пиксель, кликнул etc. Отправляет события на нашу сторону.

➡️ Bidder
Биддер - это модуль, отвечающий за коммуникацию с паблишером (или с Prebid'ом, если закупаем трафик через Header Bidding) и отправку ставок.
- Принимает запрос на ставку + фичи паблишера + user agent, чтобы извлечь фичи пользователя.
- Собирает ставку с учетом заложенной маржи на запрос bid = CPM x (1 - margin) x bidFactors, с учетом коэффициентов, понижающих ставок, выданных автобиддингом.
- Когда ставка посчитана, отправляет на ендпоинт паблишера или Prebid'а ответ со ставкой.

➡️ Models
Все ML модели, отвечающие за фильтрацию, монетизацию
- Фильтрация по вероятности показа, клика, досмотра etc.
- Фильтрация по фроду
- Оптимизация ставки (shading, автобиддинг)
- Budget pacing
Может быть как интегрирован внутрь биддера, так и вынесен в отдельный сервис, к которому биддер будет обращаться как клиент.

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

Отдельный инференс сервис
Во втором же случае структура получается модульная, в оба сервиса можно вносить изменения независимо друг от друга, но придеться заплатить более высоким latency (в основном из-за HTTP коммуникации между сервисами). Также встает вопрос, что делать биддеру, если сервис с моделями упал. Если в первом случае артефакты были закешированны на биддере, он мог пользоваться ими до тех пор, пока новые модели не подъедут, то во втором случае модули друг для друга становятся черными ящиками, и нужно задаться вопросом обеспечения минимального availability

➡️ Tracking
Пожалуй, центральный элемент всей схемы, поскольку на нем замыкаются все. Логирует абсолютно все события
- на стороне паблишера: действия пользователя + транзакции
- на стороне биддера: отказ от ответа, таймаут, ставка с ее значением
- на стороне моделей фильтрации: события фильтрации + ее причины
Кроме того логируем события биллинга, когда по аукциону мы должны получить оплату от рекламодателя и заплатить паблишеру

➡️ DB
Затреканные события и транзакции нужно куда-то писать, делать это быстро, и иметь оптимизированное хранилище. Здесь все делаем по заветам книжки с кабанчиком. Чаще всего прибегаем к следующему варианту. Tracking сервис пишет события по мере их поступления в очередь данных (Kafka, RabbitMQ). Далее с помощью либо Kafka коннектора, либо Spark Streaming джобы пишем события из очереди в батчи в объектное хранилище (S3, GCS) партициями. Также можно писать и в OTLP хранилище с быстрой записью транзакций (Greenplum)

Кроме того, нам также потребуется хранилище для аналитики (по-английски еще называют OLAP хранилища). Это нужно для отслеживания статов платформы в целом по аггрегатам трафик, CPM, CPC, CPV group by publisher, тип контракта, страна etc. Для этого подойдут ClickHouse или Google BigQuery

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

docs.prebid.org

About Prebid.js for Header Bidding

An overview of Prebid.js

www.group-telegram.com/us/dsinsights.com/315

1.2K viewsedited  Jan 28 at 00:43

Проектируем платформу ставок с нуля? 💵

Сегодня займемся проектированием своей Real Time Bidding платформы ставок. На упрощенной схеме мы разберем из каких основных блоков она должна состоять, и как эти блоки между собой связаны.

➡️ Article
Собственно сама веб-страница с размещенными на ней рекламными слотами. Также в случае Header Bidding интеграции в шапке HTML кода страницы могут быть прописаны настройки, в которые добавлен наша платформа ставок, как игрок, имеющий доступ к покупке слотов.

➡️ TagJS
JS код, размещенный на странице паблишера. Отвечает за трекинг действий пользователя на сайте, например, когда пользователь доскролил до слота, увидел пиксель, кликнул etc. Отправляет события на нашу сторону.

➡️ Bidder
Биддер - это модуль, отвечающий за коммуникацию с паблишером (или с Prebid'ом, если закупаем трафик через Header Bidding) и отправку ставок.
- Принимает запрос на ставку + фичи паблишера + user agent, чтобы извлечь фичи пользователя.
- Собирает ставку с учетом заложенной маржи на запрос bid = CPM x (1 - margin) x bidFactors, с учетом коэффициентов, понижающих ставок, выданных автобиддингом.
- Когда ставка посчитана, отправляет на ендпоинт паблишера или Prebid'а ответ со ставкой.

➡️ Models
Все ML модели, отвечающие за фильтрацию, монетизацию
- Фильтрация по вероятности показа, клика, досмотра etc.
- Фильтрация по фроду
- Оптимизация ставки (shading, автобиддинг)
- Budget pacing
Может быть как интегрирован внутрь биддера, так и вынесен в отдельный сервис, к которому биддер будет обращаться как клиент.

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

Отдельный инференс сервис
Во втором же случае структура получается модульная, в оба сервиса можно вносить изменения независимо друг от друга, но придеться заплатить более высоким latency (в основном из-за HTTP коммуникации между сервисами). Также встает вопрос, что делать биддеру, если сервис с моделями упал. Если в первом случае артефакты были закешированны на биддере, он мог пользоваться ими до тех пор, пока новые модели не подъедут, то во втором случае модули друг для друга становятся черными ящиками, и нужно задаться вопросом обеспечения минимального availability

➡️ Tracking
Пожалуй, центральный элемент всей схемы, поскольку на нем замыкаются все. Логирует абсолютно все события
- на стороне паблишера: действия пользователя + транзакции
- на стороне биддера: отказ от ответа, таймаут, ставка с ее значением
- на стороне моделей фильтрации: события фильтрации + ее причины
Кроме того логируем события биллинга, когда по аукциону мы должны получить оплату от рекламодателя и заплатить паблишеру

➡️ DB
Затреканные события и транзакции нужно куда-то писать, делать это быстро, и иметь оптимизированное хранилище. Здесь все делаем по заветам книжки с кабанчиком. Чаще всего прибегаем к следующему варианту. Tracking сервис пишет события по мере их поступления в очередь данных (Kafka, RabbitMQ). Далее с помощью либо Kafka коннектора, либо Spark Streaming джобы пишем события из очереди в батчи в объектное хранилище (S3, GCS) партициями. Также можно писать и в OTLP хранилище с быстрой записью транзакций (Greenplum)

Кроме того, нам также потребуется хранилище для аналитики (по-английски еще называют OLAP хранилища). Это нужно для отслеживания статов платформы в целом по аггрегатам трафик, CPM, CPC, CPV group by publisher, тип контракта, страна etc. Для этого подойдут ClickHouse или Google BigQuery

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

BY ML Advertising