Что такое header bidding?

Header bidding (header bidding, пребиддинг, «аукцион в шапке») — схема продажи рекламного показа, при которой площадка одновременно запрашивает ставки у нескольких источников спроса — бирж, SSP и прямых DSP — до вызова своего ad-сервера и затем отдаёт impression победителю. Партнёры конкурируют за один показ в одном окне, а не стоят в очереди по приоритету line item. Термин закрепился в середине 2010-х как ответ на waterfall в Google Ad Manager и аналогах; в СНГ тот же контур чаще настраивают в Яндекс Adfox.

Header bidding и waterfall

В классическом waterfall (daisy chain) ad-сервер обходит партнёров по очереди: сначала сеть или SSP с самым высоким приоритетом, при незаполненном слоте — следующий. Если первый партнёр закрыл показ по $1,50, второй, готовый заплатить $3, этот impression уже не видит. Площадка теряет yield; спрос внизу цепочки получает «остатки».

Header bidding ломает эту очередь. Wrapper на странице (или на сервере) шлёт параллельные bid request, собирает ответы за отведённый timeout и передаёт ставки в ad-сервер как key-value. Там они участвуют в итоговом аукционе вместе с прямыми кампаниями и остаточным спросом. Побеждает более высокая ставка, а не место в списке. Для паблишера это рост CPM и eCPM; для байера — более честная конкуренция за тот же слот display или video.

Чем header bidding не равен RTB

RTB (real-time bidding) — протокол и механика аукциона за один impression за миллисекунды. Header bidding — оркестрация: несколько таких вызовов (часто по OpenRTB) идут параллельно, затем ad-сервер выбирает победителя. Один партнёр внутри своего вызова может крутить обычный RTB; другой — отвечать фиксированной ставкой из programmatic guaranteed. Путать «RTB» и «header bidding» не стоит: первое описывает, как торгуется показ, второе — когда и сколько источников спроса видят его одновременно. Общий контур закупки — programmatic. Отдельно не путать с RTB-фидом: там байер покупает XML/API-поток как источник трафика, а не участвует в аукционе паблишера.

Wrappers: Prebid, server-side, Adfox

Клиентский wrapper — JavaScript в <head> страницы. Де-факто стандарт открытой реализации — Prebid.js (Prebid.org): адаптеры к десяткам SSP и бирж, единый timeout, analytics. Коммерческие обёртки делают Amazon (TAM / Unified Ad Marketplace), крупные SSP и локальные ad-серверы.

Серверный вариант (Prebid Server, Google Open Bidding и аналоги) переносит параллельные запросы с устройства пользователя на инфраструктуру паблишера или Google. Страница быстрее, меньше нагрузка на браузер, но cookie matching слабее: часть спроса не узнаёт пользователя и ставит ниже. На практике часто гибрид: часть партнёров в браузере, часть — server-side.

В СНГ header bidding обычно стыкуют с Яндекс Adfox: wrapper собирает ставки, Adfox проводит аукцион с прямыми кампаниями и собственной сетью. Настройка — список партнёров, timeout, floor, соответствие размеров слота IAB. Без корректной связки wrapper ↔ Adfox ставки «не доезжают» в аукцион, и схема деградирует обратно к waterfall.

Как проходит один показ

  1. Страница грузит wrapper; слот ещё пустой.
  2. Wrapper параллельно вызывает подключённых партнёров (типичный timeout 800–1500 мс).
  3. Ответившие возвращают ставку, creative ID и служебные параметры.
  4. Ad-сервер (GAM, Adfox) сравнивает эти ставки с прямыми line item и residual demand.
  5. Победивший креатив рендерится; проигравшие запросы отбрасываются.

Опоздавший ответ = потерянный bid, не «вторая очередь». Отсюда жёсткий trade-off: длинный timeout поднимает fill и CPM, но бьёт по Speed Index и Core Web Vitals.

Что это значит для байера

Для медиабаера в DSP (DV360, The Trade Desk и др.) header bidding означает, что один и тот же URL чаще торгуется в нескольких контурах сразу. Ставки и стратегия конкурируют не только с open auction, но и с партнёрами wrapper. Рост конкуренции поднимает CPM; взамен меньше «дешёвого» остаточного инвентаря из низа waterfall. Имеет смысл смотреть domain/app, deal ID, viewability и post-click CR в трекере, а не только win rate в кабинете. Прямые PMP через header bidding дают более предсказуемый inventory, чем слепой open exchange.

Ограничения

Слишком много адаптеров на клиенте увеличивает latency и риск, что пользователь уйдёт до показа. Расхождение counts между SSP, ad-сервером и DSP — норма, если timeout и фильтрация креативов режут часть ответов. Identity (cookie, ID-граф) после ограничений браузеров и ATT слабее на client-side, ещё слабее на server-side без логина. Header bidding не заменяет фильтры качества: bot traffic, domain spoofing и низкая viewability остаются отдельной задачей на стороне спроса.

См. также: programmatic, display, показ, CPM, DV360.