RTB. Торги в реальном времени

8 minute read
Инструменты
, , ,

Статья которая должна была появится в 2018 году. Но так сложилось, что RTB догнал меня снова.

RTB(Real Time Bidding) расшифровывается как торги в реальном времени. По сути, это биржа на которой встречаются три стороны: рекламодатель, площадки и пользователь. Рекламодатель решает сколько он готов заплатить за показ рекламы конкретному пользователю. Торги проходят в реальном времени. За тот период пока грузится страница сайта, пользователь(а точнее информация о нем) выставляется на торги и показ уходит тому рекламодателю который готов больше заплатить за него.

В RTB большую роль играет информация о пользователе. Это история показов рекламы ему, соцдем, геопозиция, данные по ретаргетингу и так далее. Все эти данные привязываются к идентификатору пользователя который, например, сохраняется в куках. Реклама становится более релевантной для пользователя, потому что показ отдается тому рекламодателю, который больше нуждается в этом пользователе. Как идентифицировать пользователей и как собирать данные о таких пользователях - тема отдельных статей.

Сложные названия

Самое сложное в RTB технологиях - запомнить аббревиатуры названий всех ее частей.

  • Supply Side Platform (SSP) – рекламная сеть, площадка или другая система, предоставляющая в аукцион места для показов рекламы (продавец).
  • Demand Side Platfrom (DSP) — рекламная сеть предоставляющая в аукцион рекламу — видео, баннеры и пр. (покупатель).
  • Data Management Platform (DMP) — поставщик данных о пользователях
  • Exchanges — рекламные биржи/сети, которые обеспечивают связь между площадками и рекламодателями и позволяют продавать рекламу тысячам подключенных площадок.
  • Trading Desk — централизованная платформа закупки рекламы с использованием экосистемы RTB, позволяющая настраивать параметры выкупа рекламы управлять им в автоматическом режиме. Trading Desk, как правило, является надстройкой над DSP, через которую получает доступ к рекламным местам, доступным в экосистеме RTB.
  • Publisher - владелец сайта/площадки.
  • Advertiser - рекламодатель.

Как работает RTB

RTB можно представить как взаимодействие между биржей и несколькими покупателями. Покупателей можно назвать акционерами участвующими в торгах. RTB определяет методы продажи микро-товаров(например, показов) через рассылку заявок от биржи к партнерам, сбор ответов от партнеров и определения победителя. Биржа может уведомлять покупателей, что их заявки были приняты. Когда происходит продажа, биржа уведомляет выигравшего покупателя и указывает в уведомлении “клиринговую” цену (эта цена может быть с учетом надбавки биржи). Остальные участники могут быть уведомлены что они проиграли аукцион.

Со временем технологии стали сложнее. Большую популярность приобретает header bidding - технология когда сама биржа работает прямо в браузере на сторону площадки и пропадает необходимость в серверах для SSP части. Теперь появились цепочки покупателей - одна биржа использует другую биржу как поставщика и так далее. Появилось много посредников и агрегаторов.

На схеме ниже как раз изображено несколько бирж и DSP. Биржа может сама выступить в роли потребителя и купить показ у вышестоящего источника(слева) или передать запрос нижестоящим источникам(справа). При таком подходе в биржи реализуют одновременно и SSP и DSP части. Важный момент: на рисунке изображен общий случай с N бирж, но в реальности цепочка не может быть бесконечной из-за различных естественных ограничений(таймауты, наценка бирж и т.д.).

Запросы ставок(bid request), ответы ставок(bid response) и другие события могут быть реализованы между любыми частями этой системы. Хотя площадки(publisher) и первая биржа в цепочке(Exchange 1), как правило, интегрируются менее стандартизировано. Потребители и поставщики могут не знать о том какая конкретно цепочка будет в итоге. OpenRTB регламентирует как будет происходить коммуникация между субъектом и его соседом справа(demand side, потребителем) и соседом слева(supply side, поставщиком)

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

  • Я предполагаю, что все события ожидания, покупки или потери подтверждаются моим партнером поставщиком(supply side). Это непосредственно интегрированные партнеры слева от меня.

  • Я несу ответственность за отправку событий ожидания, покупки и потери только моим партнерам потребителям(demand side). Это непосредственно интегрированные партнеры справа от меня.

  • Я брокер и заключаю сделки между моими партнерами поставщиками и потребителями(т.е. партнерами слева и справа от меня) и никакой другой участник, в соответствии с RTB, не может распространять мои сделки вверх или вниз по цепочке.

Протокол OpenRTB

Реклама в интернете похожа на дикий запад где закон только один - право сильного(или большого). Тем не менее, есть попытки хоть как-то стандартизировать эту область. И яркий пример - протокол OpenRTB. На текущий момент уже есть версия OpenRTB v3.0

В протоколе OpenRTB используется многоуровневый подход. Это делает проще использование различных объектов в разных спецификациях и позволяет разным частям спецификации развиваться самостоятельно. Эта модель изображена на картинке ниже. Конечно, все это распределение по уровням достаточно формальное. Уровень 1 определяет как происходит обмен байтами, уровень 2 определяет какое кодирование (или какой “язык”) используется для обмена байтами, уровень 3 описывает как эти байты используются в транзакциях, уровень 4 описывает кто участвует в этих транзакциях

Учитывая эту многоуровневую концепцию, IAB Tech Lab определила общую организацию связанных спецификаций как OpenMedia. На картинке ниже пример организации уровней протокола.

О всех этих уровнях можно почитать в спецификации OpenRTB. Спецификация OpenRTB есть на github. Большинство рекламных сетей используют не самую свежую спецификацию протокола и остановились на версии 2.5

Запрос и ответ в OpenRTB выглядит пугающе, но это только на первый взгляд. Ниже привел пример запроса ставки с одним элементом на продажу и ответ от биржи. Некоторые(ну, много) необязательные параметры были пропущены.

Важно обратить внимание на поле imp. Это поле, которое описывает показ и место которое мы продаем биржи. Важно указать идентификатор - он будет использоваться в респонсе

 1{
 2    "id": "80ce30c53c16e6ede735f123ef6e32361bfc7b22",
 3    "at": 1,
 4    "cur": [
 5        "USD"
 6    ],
 7    "imp": [
 8        {
 9            "id": "2",
10            "bidfloor": 0.03,
11            "native": {
12                "request": "{\"native\":{\"ver\":\"1.0\",\"assets\":[ ... ]}}",
13                "ver": "1.0",
14                "api": [
15                    3
16                ],
17                "battr": [
18                    13,
19                    14
20                ]
21            }
22        }
23    ],
24    "site": {
25        "id": "102855",
26        "cat": [
27            "IAB3-1"
28        ],
29        "domain": "www.foobar.com",
30        "page": "http://www.foobar.com/1234.html ",
31        "publisher": {
32            "id": "8953",
33            "name": "foobar.com",
34            "cat": [
35                "IAB3-1"
36            ],
37            "domain": "foobar.com"
38        }
39    },
40    "device": {
41        "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2",
42        "ip": "123.145.167.10"
43    },
44    "user": {
45        "id": "55816b39711f9b5acf3b90e313ed29e51665623f"
46    }
47}

В поле imp мы должны указать какой тип рекламы мы запрашиваем. imp это массив, а значит мы можем запрашивать сразу пачку баннеров. В нашем случае это нативная реклама. Может смутить поле request. В этом поле мы должны указать какие поля рекламного материала нам нужен. Те в целом RTB запрос описывает какой показ мы продаем, а в поле request мы описываем какой рекламный материал ожидаем. Для этих “запросов в запросе” есть своя спецификация, например для нативной рекламы

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

 1{
 2    "id": "123",
 3    "seatbid": [
 4        {
 5            "bid": [
 6                {
 7                    "id": "12345",
 8                    "impid": "2",
 9                    "price": 3.00,
10                    "nurl": "http://example.com/winnoticeurl",
11                    "lurl": "http://example.com/winnoticeurl",
12                    "burl": "http://example.com/winnoticeurl",
13                    "adm": "{\"native\":{\"ver\":\"1.0\",\"link\":{ ... }, \"imptrackers\":[ ... ],\"assets\":[ ... ]}}"
14                }
15            ]
16        }
17    ]
18}

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

В биде приходит набор URL

  • nurl - урл по которому мы сообщаем бирже, что ее ставка победила
  • lurl - урл по которому мы сообщаем бирже, что ее ставка проиграла
  • burl - этот урл нужен для учета денег, которые нам должна биржа(как правило, вызывается во время показа баннера)

Сам баннер приходит в поле adm и формат этого баннера соответствует описанной выше спецификации.

Как этим всем пользоваться

RTB технологию придумали уже достаточно давно. Но вменяемых открытых проектов все еще мало. Один из самых известных проектов - rtbkit. К сожалению этот проект мертв и не развивается.

Еще один проект vanilla-rtb. Наверное, это лучшее что есть на данные момент. Конечно, придется немного повозиться с настройкой и запуском всего этого добра.

Для любителей ентерпрайза, есть реализация OpenRTB протокола на Java.

Рано или поздно вам захочется написать свою SSP с танцовщицами и шахматами. Как мне кажется, лучше всего для этого подходит язык Go. Для этого языка есть готовая реализация протокола OpenRTB от prebid, еще один вариант. И есть готовые примеры, например DSP API

В 2015 году Даниил Подольский на HighLoad++ рассказывал как писать RTB DSP на языке Go:

Можно не писать совсем все на Go. Vanilla-rtb предоставляет биндинги для Node.js, Golang, Python, PHP и Java. Теоретически, можно писать бидеры на Go с использованием фреймворка vanilla. Есть даже видео как все это можно реализовать.

Математика

Реализация всех систем, которые участвуют в RTB - это вызов для разработчиков. Нужно очень быстро обрабатывать много запросов. Учитывать таргетинги, ограничения по показам, ретаргетинг и много чего еще.

Кроме этого, торги в реальном времени это сложная задача для исследователей. Как выгодно делать ставки? Как повысить заинтересованность пользователей, CTR и т.д.? Все это интересные задачи, которые требуют серьезных исследований. Jun Wang, Weinan Zhang и Shuai Yuan написали целую книгу “Display Advertising with Real-Time Bidding (RTB) and Behavioural Targeting”.

Эти же ребята написали целую пачку работ по RTB:

Список пейперов и докладов для тех у кого есть желание с головой погрузиться в теорию торгов в реальном времени.

Если хорошо поискать, то можно найти записи докладов Jun Wang, Weinan Zhang и Shuai Yuan. Например, тут Jun Wang рассказывает про механизмы и алгоритмы RTB

Польза RTB

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

Система “второй цены”, которая оптимизирует расходы на рекламу. Торги ведутся с шагом 1 цент и если вы указали стоимость за показ в 11 центов, а ваш конкурент — в 9, то вы выигрываете аукцион, но ваша ставка автоматически уменьшается до минимально большей, чем у конкурента — в данном случае, 10 центов.

Технология генерации баннера “на лету” позволяет показать каждому пользователю свой, уникальный баннер - исходя из его уникальных интересов и характеристик. Это позволяет существенно увеличить отклик пользователя на баннер, в том числе CTR.

Ссылки