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

Сегодня займемся проектированием своей 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 хранилища и отвечает за выстапление счетов рекламодателю. На этапе трекинга в момент логирования события оплаты, сама оплата не происходит. Записанные события с биллингом аггрегируются, и рекламодателю выставляется счет на сумму, которая должна биться с бюджетом, который наша платформа открутила. Эта процедура делается раз в месяц или в квартал.



tgoop.com/dsinsights/315
Create:
Last Update:

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

Сегодня займемся проектированием своей 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


Share with your friend now:
tgoop.com/dsinsights/315

View MORE
Open in Telegram


Telegram News

Date: |

Telegram message that reads: "Bear Market Screaming Therapy Group. You are only allowed to send screaming voice notes. Everything else = BAN. Text pics, videos, stickers, gif = BAN. Anything other than screaming = BAN. You think you are smart = BAN. There have been several contributions to the group with members posting voice notes of screaming, yelling, groaning, and wailing in different rhythms and pitches. Calling out the “degenerate” community or the crypto obsessives that engage in high-risk trading, Co-founder of NFT renting protocol Rentable World emiliano.eth shared this group on his Twitter. He wrote: “hey degen, are you stressed? Just let it out all out. Voice only tg channel for screaming”. Judge Hui described Ng as inciting others to “commit a massacre” with three posts teaching people to make “toxic chlorine gas bombs,” target police stations, police quarters and the city’s metro stations. This offence was “rather serious,” the court said. Hashtags Add up to 50 administrators
from us


Telegram ML Advertising
FROM American