что такое header bidding в adfox
Взаимодействие кода Header Bidding с другими кодами вставки
С 20 июля 2021 года код вставки ADFOX разделен на 2 части: единый код загрузчика рекламы и код баннера. В связи с переходом на раздельный код вставки рекомендуем обновить код Header Bidding на сайте и проверить, что он размещен корректно.
Шаг 1. Замените URL скрипта.
| Старый url | Новый url |
|---|---|
| https://yastatic.net/pcode/adfox/header-bidding.js | https://yandex.ru/ads/system/header-bidding.js |
| Старый url | Новый url |
|---|---|
| https://yastatic.net/pcode/adfox/header-bidding.js | https://yandex.ru/ads/system/header-bidding.js |
Код Header Bidding должен стоять перед кодом загрузчика рекламы. Так загрузчик рекламы сможет определить, что на странице есть Header Bidding и какие объявления ждут ставок от других монетизаторов. Рекомендуем такой порядок подключения кодов:
Header bidding: что это и как это работает
Недавно наши коллеги из Admixer Technologies написали отличную статью о превратностях моделей закупок, где подробно описаны все преимущества и недостатки header bidding. Ниже приводим ее перевод.
Adtech постоянно стремится к оптимизации сделок между рекламодателями и паблишерами. Несмотря на все достижения в индустрии, рынку цифровой рекламы все же еще не хватает слаженности действий. Так паблишеры вынуждены буквально жонглировать различными платформами и источниками монетизации, чтобы получить максимальную отдачу от своего рекламного инвентаря.
Header bidding появился в качестве решения для борьбы с этим отсутствием слаженности. Он обеспечивает более эффективный механизм для того, чтобы паблишеры монетизировали свой рекламный инвентарь. В последние годы header bidding обрел популярность и широкое распространение. Тем не менее внутренняя работа системы может всё еще вызывать вопросы.
Что такое header bidding?
Header bidding – это технология автоматизированных аукционов, позволяющая паблишерам давать доступ к своему инвентарю разным DSP и получать ставки от нескольких рекламодателей одновременно. Это аукцион, на котором все DSP имеют равный доступ к участию в торгах, в отличие от «водопада» (waterfall) и открытого RTB, где участие в аукционе происходит поочередно.
Header bidding убирает недопонимание между паблишером и рекламодателем в отношении ценности трафика. Это позволяет сайтам получать справедливую цену за свое рекламное пространство.
Владельцы white-label решений от Admixer.Network теперь могут использовать весь потенциал технологии header bidding, повышая общую эффективность программатик-продаж и получая большую прибыль.
Сравниваем header bidding, waterfall (водопад) и RTB
До появления модели аукциона header bidding, паблишеры продавали свой инвентарь через аукционы типа «водопад» или RTB.
«Водопад» — это метод последовательной продажи активов паблишеров, использующий один источник спроса (demand) за один раз. При таком сценарии паблишер устанавливает предпочтительный порядок для рекламных сетей рекламодателей и устанавливает минимальный допустимый размер цены для определенного размещения рекламы.
Паблишер предлагает инвентарь последовательно demand-партнерам в установленном порядке в соответствии с их исторической доходностью. Как только конкретный рекламодатель достигает минимально-необходимой цены, показ продается этому рекламодателю.
Как работает header bidding?
Header bidding работает через строку кода JavaScript, встроенную в заголовок веб-сайта паблишера (отсюда, собственно, и название header bidding). Заголовок является HTML-элементом, невидимым для читателя; обычно хранит навигационные ссылки, информацию об авторстве и т д.
Строка кода соединяет сайт с различными источниками, заинтересованными в покупке рекламного инвентаря. При каждой загрузке страницы источники спроса (demand) могут делать ставки на каждый показ на той страничке.
Эта процедура повышает прозрачность, позволяя DSP или SSP знать, какие demand-платформы делают ставки, а также повышает стоимость их предложения, максимизируя цену за тысячу показов.
Процесс header bidding со стороны клиента:
Пользователь видит рекламу с выигрышной ставкой. Все происходит в течение миллисекунд.
Два вида header bidding: client-side и server-side
Процесс, описанный выше, является примером client-side header bidding — когда аукцион проводится на самом сайте. Но также существует и другой вариант этой технологии с реализацией на стороне сервера.
Header bidding на стороне сервера следует таким же процессам и протоколам, как и client-side, но с одним существенным отличием. Server-side header bidding перенаправляет все рекламные запросы на отдельный сервер, только после этого сервер отправляет запросы на рекламные биржи (AdExchange). После того, как сервер получает ставку, он отправляет ее обратно в браузер.
Модель биддинга на стороне сервера решает основную проблему header bidding — задержку загрузки страницы, потому что процесс аукциона происходит на выделенном сервере, а не в браузере.
С другой стороны этой модели не хватает прозрачности. Поскольку торги проводятся на стороннем сервере, у паблишеров могут возникнуть вопросы с оценкой результатов аукциона. Вдобавок из-за того, что аукцион проходит вне браузера, файлы cookie могут быть потеряны, что затрудняет идентификацию пользователей для рекламодателей.
Преимущества header bidding
Большая доходность
Вместо того, чтобы полагаться на предыдущие данные для определения минимального уровня цен, header bidding позволяет увидеть, сколько рекламодатели готовы заплатить за показ заранее, до размещения рекламы. Паблишер определяет, сколько стоит показ рекламы сразу для множества рекламодателей одновременно. Demand-платформа с самой высокой ставкой в конечном итоге выигрывает в аукционе за показ.
Header bidding — это горячая тема в мире программатик, поскольку это позволяет сайтам повысить контроль над своим инвентарем и сделками и, следовательно, увеличить доход. С помощью header bidding паблишеры могут найти лучшего покупателя для каждого показа, монетизировать свой контент и предоставить его читателям почти или абсолютно бесплатно.
Этот сдвиг в управлении инвентарем дает паблишерам значительные преимущества, но также требует быстрых и обоснованных решений. Интегрированные комплексные решения имеют решающее значение для их создания, особенно когда речь идет о возможностях отчетности и аналитики.
Лиз Токарева, VP Client Services в SmartyAds
Более высокие уровни распроданности инвентаря
Помимо более высокой доходности от рекламного инвентаря header bidding также обеспечивает более высокие показатели заполненности инвентаря рекламой. У паблишера есть четкое понимание осуществит ли SSP показы в полном объеме или нет. Header bidding устраняет риск не заполненности, связанный с последовательными торгами на нескольких уровнях, сводя его к объединенному аукциону, где SSP заполняет весь доступный инвентарь. При использовании header bidding нет ручной работы по настройке последовательных цепочек аукциона на стороне cайта.
Cookie matching
Поскольку процесс назначения ставок происходит в браузере, SSP и DSP могут синхронизировать свои cookie-файлы, что позволяет рекламодателям идентифицировать пользователя на веб-сайте паблишера.
Возможность отслеживать историю пользователей дает возможность рекламодателю запускать целевые кампании и ретаргетинг объявлений, что позволяет лучше контролировать аудиторию. В то же время паблишеры получают больший доход от идентифицированной аудитории, т.к. по такой аудитории зачастую больше ставок.
Контроль и прозрачность
Строка JavaScript в заголовке работает как система управления для паблишера. С помощью header bidding паблишеры могут без труда установить временные рамки для ставок, а также удалить и добавить новых партнеров для проведения аукциона.
Тем не менее смена технологического решения header bidding не является легкой задачей и требует опыта, т.к. корректная настройка этого модуля достаточно сложная. Но header bidding полностью оправдывает время, потраченное на его установку т.к. обеспечивают большую прозрачность для паблишера с точки зрения ценообразования и контроля над источниками спроса.
Возможные недостатки header bidding
Проблема с задержкой (latency)
Header bidding был разработан, чтобы нивелировать неэффективность аукционов-«водопадов», в особенности неэффективность возврата показов (passback). Однако реализация header bidding не является безупречной.
Header bidding добавляет больше скриптов в заголовок страницы, увеличивая время загрузки страницы, возможно, негативно сказываясь на опыте пользователя и потенциально приводя к меньшему количеству отображаемых показов.
Кроме того, поскольку header bidding влечет за собой многочисленные соединения с серверами и платформами, это замедляет скорость интернет-соединения.
Ограниченное количество рекламных запросов
Количество запросов, которые браузер может выполнить при загрузке одной страницы ограниченно, что означает, что header bidding также может отправлять ограниченное количество рекламных запросов. В связи с этим количество demand-партнеров, которые могут делать ставки на рекламное место, также ограничено.
Совместимость
Поскольку header bidding работает через браузер, у него должна быть обратная совместимость с различными браузерами и версиями, что может создавать сложности. Некоторые браузеры отдают низкий приоритет для внешних пикселей. В результате браузер может полностью блокировать header-bidding, что сделает аукцион неэффективными.
В завершение
Благодаря внедрению header bidding паблишеры получают больше предложений от более разнообразного пула рекламодателей. Это приводит к более высокому совокупному спросу, который повышает цену за размещение рекламы и, как результат, доход для паблишеров.
Тем не менее настройка header bidding модуля сложнее, чем настройка простого рекламного кода, поэтому к выбору технического партнера для этой задачи нужно подойти со всей серьезностью.
Header bidding становится новым стандартом в индустрии, в то время как открытый RTB остается жизнеспособной стратегией для паблишеров, которые хотят приоритезировать определенный список рекламодателей. Если вы хотите получить лучшее из обоих моделей аукциона, Admixer предлагает гибридную модель, которая объединяет header bidding и открытый RTB.
Проверка настроек и отчеты
Инструмент для проверки ставок покупателей
В результате загрузки одной страницы сайта, запросы ставок к покупателям могут быть отправлены неоднократно, а именно в случаях:
Метод getLastBidsReceived позволяет получить ставки с последнего опроса покупателей.
В ответе получаем массив, заполненный объектами Bid для каждой пары рекламное место + покупатель.
Объект может содержать только одно из полей:
Рисунок 1. Пример вызова метода в консоли браузера
| Код ошибки | Значение |
|---|---|
| 0 | Неизвестная ошибка. |
| 1 | Отсутствие ставки/ответа. |
| 2 | Некорректный ответ. |
| 3 | Таймаут. |
| 4 | Ошибка HTTP протокола. |
| 5 | Некорректные пользовательские данные в конфигурационном скрипте. |
| 6 | Некорректные настройки биддера (только для Facebook). |
| 7 | Биддер прислал Id контейнера, отличный от Id в запросе. |
| 8 | Биддер прислал корректный ответ без статуса. |
| 9 | В ответе биддера отсутствует или некорректный codeType |
| Код ошибки | Значение |
|---|---|
| 0 | Неизвестная ошибка. |
| 1 | Отсутствие ставки/ответа. |
| 2 | Некорректный ответ. |
| 3 | Таймаут. |
| 4 | Ошибка HTTP протокола. |
| 5 | Некорректные пользовательские данные в конфигурационном скрипте. |
| 6 | Некорректные настройки биддера (только для Facebook). |
| 7 | Биддер прислал Id контейнера, отличный от Id в запросе. |
| 8 | Биддер прислал корректный ответ без статуса. |
| 9 | В ответе биддера отсутствует или некорректный codeType |
Отчеты по Header Bidding
В аккаунте, в котором подключены монетизаторы, на уровне сайта и на уровне аккаунта доступны отчеты по Header Bidding. Подробнее см. раздел Отчеты по монетизации.
Проверка настроек и отчеты
Инструмент для проверки ставок покупателей
В результате загрузки одной страницы сайта, запросы ставок к покупателям могут быть отправлены неоднократно, а именно в случаях:
Метод getLastBidsReceived позволяет получить ставки с последнего опроса покупателей.
В ответе получаем массив, заполненный объектами Bid для каждой пары рекламное место + покупатель.
Объект может содержать только одно из полей:
Рисунок 1. Пример вызова метода в консоли браузера 
| Код ошибки | Значение |
|---|---|
| 0 | Неизвестная ошибка. |
| 1 | Отсутствие ставки/ответа. |
| 2 | Некорректный ответ. |
| 3 | Таймаут. |
| 4 | Ошибка HTTP протокола. |
| 5 | Некорректные пользовательские данные в конфигурационном скрипте. |
| 6 | Некорректные настройки биддера (только для Facebook). |
| 7 | Биддер прислал Id контейнера, отличный от Id в запросе. |
| 8 | Биддер прислал корректный ответ без статуса. |
| 9 | В ответе биддера отсутствует или некорректный codeType |
| Код ошибки | Значение |
|---|---|
| 0 | Неизвестная ошибка. |
| 1 | Отсутствие ставки/ответа. |
| 2 | Некорректный ответ. |
| 3 | Таймаут. |
| 4 | Ошибка HTTP протокола. |
| 5 | Некорректные пользовательские данные в конфигурационном скрипте. |
| 6 | Некорректные настройки биддера (только для Facebook). |
| 7 | Биддер прислал Id контейнера, отличный от Id в запросе. |
| 8 | Биддер прислал корректный ответ без статуса. |
| 9 | В ответе биддера отсутствует или некорректный codeType |
Отчеты по Header Bidding
В аккаунте, в котором подключены монетизаторы, на уровне сайта и на уровне аккаунта доступны отчеты по Header Bidding. Подробнее см. раздел Отчеты по монетизации.
Внешняя монетизация
Внешние монетизаторы — это покупатели трафика, такие как Google ADX, Mytarget, HPMD, Criteo и др.
Обычно при установке кодов других систем возникают вопросы о том, как правильно поставить сторонний код, будет ли он работать и что делать, чтобы вернуть показ в ADFOX, если сторонняя система не подобрала баннер.
Как работает внешняя монетизация?
РСЯ не сможет выкупить показы по цене ниже, чем пороговый CPM соревнующихся кампаний издателя или внешних монетизаторов.
Рисунок 1. Алгоритм выбора кампании уровня Динамической монетизации
Отличие Header Bidding от размещения монетизаторов по коду вставки
В случае применения Header Bidding покупатели сделали свои ставки еще до отправки запроса за баннером и при победе кампании такого покупателя, его баннер будет отправлен на сайт пользователю, после чего процесс выбора рекламы будет остановлен.
Если же покупатель размещается с помощью кодов вставки (например, Google ADX или DFP), то, в случае победы кампании такого покупателя, баннер с кодом вставки будет отправлен на сайт пользователю.
Внешняя монетизация
Внешние монетизаторы — это покупатели трафика, такие как Google ADX, Mytarget, HPMD, Criteo и др.
Обычно при установке кодов других систем возникают вопросы о том, как правильно поставить сторонний код, будет ли он работать и что делать, чтобы вернуть показ в ADFOX, если сторонняя система не подобрала баннер.
Как работает внешняя монетизация?
РСЯ не сможет выкупить показы по цене ниже, чем пороговый CPM соревнующихся кампаний издателя или внешних монетизаторов.
Рисунок 1. Алгоритм выбора кампании уровня Динамической монетизации 
Отличие Header Bidding от размещения монетизаторов по коду вставки
В случае применения Header Bidding покупатели сделали свои ставки еще до отправки запроса за баннером и при победе кампании такого покупателя, его баннер будет отправлен на сайт пользователю, после чего процесс выбора рекламы будет остановлен.
Если же покупатель размещается с помощью кодов вставки (например, Google ADX или DFP), то, в случае победы кампании такого покупателя, баннер с кодом вставки будет отправлен на сайт пользователю.
Что такое header bidding в adfox
В едином RTB-блоке появилась возможность показывать видеорекламу внешних монетизаторов с помощью Header Bidding. Теперь один блок позволяет заполнять рекламное место тремя форматами объявлений из прямых кампаний, РСЯ и внешних рекламных систем.
Ранее в RTB-блоке от внешних монетизаторов были доступны только контекстные и медийные объявления. Сегодня список пополнила видеореклама, через Header Bidding её можно добавить в аукцион сразу от нескольких рекламных платформ:
В RTB-блоке видеореклама из этих систем будет конкурировать с объявлениями от других внешних монетизаторов, РСЯ и прямых кампаний. Это изменение делает RTB-блоки полноценной заменой inPage за счёт:
Повышенной заполняемости. RTB-блок поддерживает больше форматов и может принимать видеорекламу, контекстные и медийные объявления. По сравнению с InPage-блоками, у RTB c видео показатель заполняемости инвентаря (fill rate) выше, а значит — увеличивается число рекламных показов.
Максимизации дохода от рекламных мест. Единый аукцион между разными форматами, включая прямые продажи рекламы, позволяет алгоритму сравнивать ставки среди большего числа объявлений, а издателям — максимизировать доход от каждого рекламного блока.
Для быстрой замены блоков InPage на RTB-блоки c видео есть простой скрипт. Пример подключения скриптов и настройки конфигурационного скрипта c InPage и баннерной рекламой в едином блоке — в Справке сервиса.
Как подключить
К существующим RTB-блокам достаточно подключить Header Bidding по инструкции.
Если у вас еще нет RTB-блоков с видео, добавьте их через интерфейс ADFOX: