Header bidding

Происхождение и история термина

Название связано с ранним размещением кода торгов внутри элемента head — служебной части веб-страницы. По объяснению Prebid, подход затем распространился на серверные, мобильные и видеосценарии, где такой привязки к странице нет ^[1]. Поэтому перевод «торги в заголовке» объясняет происхождение названия, но не весь круг реализаций.

Документация проекта датирует создание Prebid.js началом 2015 года и называет Мэтта Кендалла, Пола Янга и участвовавшего в работе Ника Джейкоба ^[2]. Это история конкретной библиотеки программного кода, а не установленная дата изобретения header bidding.

Отдельная веха — выпуск OpenRTB 2.6 в апреле 2022 года. Это спецификация обмена сообщениями между покупателями и продавцами рекламы, а не название способа продажи ^[7]. При описании полей ниже используется именно этот датированный документ; он не объявлен последней версией всех последующих дополнений.

Суть и механизм

Кто участвует

Площадка предоставляет рекламный инвентарь — места, в которых можно показать объявления. Со стороны продавца работает SSP, supply-side platform: платформа, через которую рекламные места предлагаются покупателям. Со стороны покупателя действует DSP, demand-side platform: платформа покупки рекламы. Такое разделение сторон описано в OpenRTB ^[7]. Один внешний ответ площадке может представлять результат отбора среди покупателей, а не решение одного рекламодателя ^[6].

Для координации запросов используют wrapper, буквально «обёртку»: общий программный слой подключения участников. В Prebid.js обмен с конкретными партнёрами обеспечивают адаптеры — модули, которые связывают библиотеку с их интерфейсами ^[3]. Это позволяет различать организатора сбора ставок и сами источники предложений.

Как ставка доходит до показа

В схеме Prebid страница запрашивает предложения, получает ответы и передаёт часть или все ставки рекламному серверу ^[10]. Рекламный сервер здесь — система окончательного выбора и доставки объявления. В описании Prebid он учитывает также прямые продажи — кампании, о которых площадка договорилась с рекламодателем напрямую, — и другие доступные кампании ^[1].

Затем выбранное объявление должно отобразиться у пользователя. Креативом называют сам рекламный материал: например, баннер или ролик. Уведомление о победе ещё не доказывает, что материал показан и наступило событие оплаты; спецификация OpenRTB разделяет эти значения ^[7]. Для анализа полезно сохранять последовательность: ответ получен → допущен к выбору → победил → объявление показано → учтён доход. Это схема проверки редакции, а не перечень одинаково названных полей всех кабинетов.

Что означает цена ставки

В OpenRTB поле price выражает предложение как CPM, cost per mille, — цену за тысячу показов, хотя конкретная ставка относится к одному показу ^[7]. Например, в учебной модели CPM 180 рублей соответствует 180 / 1000 = 0,18 рубля за один показ. Это перевод единиц цены, а не доказательство выплаты: для неё нужны условия сделки и состоявшееся оплачиваемое событие.

Зачем нужен тайм-аут

Тайм-аут — предельное время ожидания. Документация Prebid различает ограничение времени аукциона и отдельный защитный таймер, который позволяет вызвать рекламный сервер при сбое. Слишком короткое ожидание ограничивает сбор ставок; слишком длинное может отложить рекламу до ухода посетителя ^[5]. Значения подбираются для конкретной интеграции, а не выводятся из самого названия технологии.

Не следует также считать заданный тайм-аут измеренной скоростью показа. Он ограничивает один участок работы, тогда как доставка объявления продолжается после выбора. Это различие важно в следующем примере: опоздание ответа оценивается относительно момента завершения сбора, а не относительно появления баннера на экране.

Виды и классификации

По месту выполнения работы документация Prebid описывает клиентские и серверные компоненты, а также их сочетание ^{[3, 4]}.

Перенос работы на сервер меняет архитектуру обмена. Он сам по себе не даёт численного прогноза дохода или скорости конкретного сайта. Например, при сравнении двух конфигураций необходимо сохранить перечень участников либо отдельно учесть его изменение: иначе одновременно меняются и способ подключения, и состав спроса. Это методическое условие сравнения редакции.

Google Open Bidding — отдельная реализация. Ad Manager получает рекламный запрос, обращается к подходящим партнёрам через серверную интеграцию и проводит унифицированный аукцион. Участники сравниваются на чистой основе с учётом доли Ad Manager ^[6]. Названия Open Bidding и header bidding поэтому не следует использовать как взаимозаменяемые инструкции настройки.

Как применяется на практике

Учебный пример: высокая ставка не успела

Сайт продаёт один баннер размером 300 × 250 пикселей. Для примера редакция задаёт упрощённые правила: сбор завершается через 600 мс, принимаются ответы нужного размера, все цены указаны в рублях CPM на одной чистой основе. Среди допущенных вариантов побеждает максимальная цена. Кроме указанной в таблице кампании сервера, других кампаний и особых приоритетов в модели нет.

Б имеет наибольшую ставку в таблице, но приходит на 750 − 600 = 150 мс позже установленной границы. В отвечает вовремя, но предлагает другой размер. Поэтому на окончательном шаге модель сравнивает 180 и 190 рублей CPM: выигрывает другая кампания сервера. Разница составляет 10 рублей CPM, или 0,01 рубля на один условный показ.

Если сохранить те же ответы и изменить ожидание до 800 мс, Б тоже окажется допущен. В заданной модели его 220 рублей превысят 190 рублей другой кампании. Это показывает, как граница ожидания меняет набор вариантов. Пример не доказывает пользу увеличения тайм-аута: в нём не заданы уходы пользователей и возможные потери показов за дополнительные 200 мс ожидания.

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

Российская реализация: Adfox

Яндекс описывает следующую последовательность: код одновременно опрашивает подключённых монетизаторов, ставки поступают в Adfox и сравниваются с CPM кампаний динамической монетизации. Выбранное предложение затем сопоставляется с Рекламной сетью Яндекса, РСЯ ^[8]. Монетизатор здесь — подключённый партнёр, предлагающий рекламу для места.

Справка Adfox также предусматривает отдельные договоры с монетизаторами ^[8]. Наличие подключённого кода поэтому не следует принимать за завершение всей подготовки этой платформы. Это описание её условий, а не универсальное правило договорной работы.

Как измерить или проверить

Сначала восстановить путь одного запроса

Редакция предлагает начать с проверяемой записи для одного рекламного места: идентификатор запроса, время начала, адресованный партнёр, ответ, цена, валюта, формат и результат допуска. Затем запись связывают с решением сервера, состоявшимся показом и учтённым доходом. Такая последовательность помогает поставить конкретный вопрос: предложение не было получено, было отклонено или проиграло после допуска?

Для учебной таблицы выше достаточно проверить три причины. Ответ Б должен быть отмечен опоздавшим, В — несовместимым по размеру, А — уступившим доступной кампании. Если журнал сообщает лишь «три ответа», он не объясняет итог. Если сообщает лишь «А проиграл», он не показывает, почему большая ставка Б не вошла в сравнение. Требуется связь между этапами, а не одинаковое название метрики в нескольких отчётах.

Отличить цену предложения от доходности

eCPM, effective cost per thousand impressions, — эффективная цена тысячи показов. Например, Google определяет Ad server average eCPM через доход от рекламы, доставленной его сервером, и число соответствующих показов ^[11]. Для учебного сравнения здесь используем доход площадки на тысячу учтённых показов:

где $D$ — согласованный доход в рублях за выбранный период, $I$ — число показов, которым этот доход соответствует. При нуле показов отношение не определено. Это расчётная модель сравнения; перед её применением нужно выбрать одинаковое основание дохода и одинаковое определение показа.

Учебный пример. За сопоставимый период контрольный вариант дал 100 000 показов и 15 000 рублей чистого дохода: 15 000 / 100 000 × 1000 = 150 рублей eCPM. Новая конфигурация дала 90 000 показов и 14 400 рублей: 14 400 / 90 000 × 1000 = 160 рублей eCPM.

Доходность тысячи показов выросла на 10 рублей, то есть примерно на 6,67%. Общее число показов уменьшилось на 10%, а доход — на 600 рублей, или на 4%. Поэтому по одному росту eCPM нельзя заключить, что площадка заработала больше. Из этих данных также нельзя установить причину падения показов: сведения о задержках, посещениях и незаполненных запросах отсутствуют.

Сравнивать конфигурации по одному плану

Предлагаемый редакцией план проверки связывает деньги и доставку. Для каждого варианта фиксируют число доступных запросов, состоявшиеся показы, доход на выбранной основе и время до показа. Период, часовой пояс, рекламные места и правила учёта сохраняют сопоставимыми. Долю заполнения рассчитывают по определениям выбранного отчёта, а не подставляют вместо неё долю ответивших партнёров.

Для времени полезно записывать начало сбора, завершение сбора и начало отображения материала. Разность первых двух отметок показывает длительность сбора; разность первой и третьей — весь рассматриваемый путь до отображения. Если эти границы меняются между вариантами, измерения отвечают на разные вопросы.

Например, в учебной записи сбор начался на отметке 0 мс, завершился на 600 мс, а баннер начал отображаться на 900 мс. Сбор занял 600 мс, весь путь — 900 мс; после сбора прошло ещё 300 мс. Приписать все 900 мс ожиданию ставок было бы ошибкой. Эти числа иллюстрируют метод измерения и не задают норматив скорости.

Ошибки, ограничения и спорные вопросы

Считать загрузку библиотеки доказательством работы торгов. При подготовке Prebid разработчики согласуют передаваемые серверу параметры и набор ставок с командой рекламных операций ^[10]. При проверке нужен результат прохождения этапов, а не только наличие файла на странице.

Смешивать валовую и чистую цену. Одинаковая запись «200 CPM» не задаёт одинаковый доход площадке без валюты и условий удержаний. Подтверждённый пример сравнения на чистой основе — унифицированный аукцион Google ^[6]. Его правило нельзя автоматически перенести на чужой отчёт.

Считать победы показами. OpenRTB прямо разграничивает уведомление о выигрыше и доставку либо оплату ^[7]. Счётчик побед отвечает на вопрос о торгах, а не заменяет отчёт о доходе.

Обещать эффект от числа подключений. В учебном примере дополнительная ставка вообще не участвует из-за времени или размера. Для решения об изменении конфигурации нужно наблюдать её фактический результат и стоимость обслуживания.

Считать серверную схему готовым ответом на проблему задержек. Прикладной вопрос — сколько времени занимает весь путь в выбранных условиях. Архитектурная метка помогает описать проверку, но не заменяет измерения на сайте.

Правовой аспект

В России статья 18.1 Федерального закона от 13.03.2006 № 38-ФЗ «О рекламе» в редакции от 04.08.2026 устанавливает требования к интернет-рекламе. Часть 16 требует пометки «реклама» и сведений о рекламодателе: указания на него и (или) сайта либо страницы сайта с информацией о нём. Исключение этой части касается рекламы внутри распространяемых через Интернет телепрограмм и телепередач, а также радиопрограмм и радиопередач ^[9].

Часть 17 отдельно связывает допустимость распространения интернет-рекламы и социальной рекламы с присвоением соответствующего идентификатора оператором рекламных данных. Это уникальное цифровое обозначение для прослеживаемости и учёта; требования к его содержанию, присвоению и размещению устанавливает уполномоченный орган ^[9]. Изменения этой части, внесённые законом № 479-ФЗ от 26.12.2024, действуют с 1 марта 2025 года ^[12]. Исключение из требования о пометке в части 16 нельзя автоматически переносить на отдельное условие части 17.

Таким образом, header bidding описывает выбор рекламы, а не основание освобождения от маркировки и учёта. Участники, подпадающие под условия части 3, обязаны предоставлять либо обеспечивать предоставление информации через операторов рекламных данных согласно частям 3 и 5 ^[9]. В конкретной интеграции нужно отдельно установить роли площадки и партнёров и проверить исполнение применимых требований; одна установка кода этого не подтверждает. Это общее объяснение нормы, а не юридическое заключение по договору.

Частые вопросы

Связанные термины

• Рекламный сервер
• SSP (платформа продавца)
• DSP (платформа покупателя)
• Рекламный инвентарь
• eCPM
• Fill rate (заполняемость инвентаря)