Header bidding: что это и чем он лучше водопада
Header bidding (хедер-биддинг) — параллельный аукцион на стороне издателя: прежде чем обратиться к своему рекламному серверу, сайт рассылает запрос сразу нескольким SSP и биржам и собирает их ставки. Лучшая из них попадает в рекламный сервер как обычная позиция и соревнуется с прямыми продажами. Так издатель получает рыночную цену за каждый показ, а не цену первого согласившегося партнера.
Откуда взялся header bidding
До него издатели работали по водопаду (waterfall): рекламный сервер опрашивал источники по очереди в порядке их средней исторической цены. Первая сеть, готовая купить показ выше своего порога, забирала его. Проблема в том, что вторая сеть в цепочке могла заплатить за этот конкретный показ больше — но ее даже не спросили.
Header bidding заменил очередь параллельным аукционом. Название пришло из веба: JavaScript-код аукциона ставили в <head> страницы, чтобы он отработал до загрузки рекламных мест.
Как проходит аукцион в браузере
- Пользователь открывает страницу; в
<head>загружается обертка (wrapper), чаще всего open-source библиотека Prebid.js. - Обертка параллельно отправляет запросы в несколько SSP через адаптеры — каждый переводит запрос в формат своего партнера, обычно в OpenRTB.
- SSP проводят свои аукционы среди DSP и возвращают лучшие ставки.
- Обертка ждет ответы не дольше заданного таймаута, затем передает лучшую цену в рекламный сервер издателя через ключи таргетинга (например,
hb_pb=150.00). - Рекламный сервер сравнивает ее с прямыми кампаниями и выбирает победителя.
браузер ──► SSP A ┐
──► SSP B ├─► лучшие ставки ──► рекламный сервер ──► показ
──► SSP C ┘
Client-side и server-side
| Client-side | Server-side | |
|---|---|---|
| Где идет аукцион | в браузере пользователя | на сервере (например, Prebid Server) |
| Число партнеров | ограничено скоростью страницы | можно больше |
| Сопоставление пользователя | лучше: у каждой SSP свои cookie | хуже: нужна синхронизация идентификаторов |
| Нагрузка на страницу | выше | ниже |
На практике часто комбинируют: несколько ключевых партнеров в браузере, остальные — через сервер.
Header bidding в приложениях
В мобильных приложениях то же самое называется in-app bidding. Роль обертки выполняет SDK медиации: он запрашивает ставки у сетей одновременно, а не идет по водопаду. Многие медиационные платформы совмещают оба режима — сети с биддингом торгуются в реальном времени, остальные стоят в водопаде.
Чем header bidding отличается от RTB
RTB — это механизм аукциона на каждый показ внутри SSP или биржи. Header bidding — надстройка уровнем выше: аукцион между несколькими SSP, каждая из которых внутри себя тоже проводит RTB. Поэтому один показ может пройти два аукциона подряд.
Что важно настроить
- Таймаут решает все. Слишком короткий — дорогие ставки не успевают прийти; слишком длинный — страница тормозит и падает видимость рекламы. Логика та же, что у tmax в OpenRTB.
- Дублирование спроса. Одна DSP может получить запрос на тот же показ через несколько SSP и фактически соревноваться сама с собой. Это одна из причин, почему DSP фильтруют дубли и смотрят на цепочку поставщиков.
- Первая цена. Header bidding подтолкнул рынок к аукциону первой цены: сравнивать ставки разных SSP со второй ценой внутри было бы некорректно.
Частые вопросы
Чем header bidding отличается от водопада?
В водопаде источники спрашивают по очереди, от дорогого к дешевому, и первый согласившийся забирает показ, даже если следующий заплатил бы больше. В header bidding все источники получают запрос одновременно, и показ уходит лучшей ставке.
Замедляет ли header bidding сайт?
Client-side вариант добавляет сетевые запросы в браузере, поэтому для него задают жесткий таймаут. Server-side переносит аукцион на сервер и снимает нагрузку со страницы ценой меньшей точности сопоставления пользователя.
Есть ли header bidding в мобильных приложениях?
Аналог называется in-app bidding: SDK медиации запрашивает ставки у нескольких сетей одновременно вместо последовательного водопада.