Header bidding для паблишеров и рекламных сетей: управляемый wrapper, открытый Prebid или собственный слой

Header bidding позволяет паблишеру одновременно спросить цену у многих рекламных покупателей, прежде чем ad-сервер выберет, что показать. Все покупатели при этом соревнуются за одно и то же место. Получить его можно тремя способами. Первый — управляемый wrapper, то есть размещённая у поставщика версия кода вместе с настройками. Второй — бесплатное программное обеспечение с открытым кодом Prebid, которое запускает ваша собственная команда. Третий — слой, который вы пишете сами. Различаются они в основном тем, кто занимается сопровождением и кто видит необработанные данные об аукционах.

Что делает header bidding?

Когда на странице есть место под рекламу, небольшой фрагмент кода отправляет запрос ставок нескольким покупателям. В запросе сказано, какое место продаётся и на какой странице. Prebid.org публикует для этого бесплатное программное обеспечение с открытым кодом. Обычную схему там описывают так: «Prebid собирает ставки до обращения к ad-серверу, а окончательное решение принимает ad-сервер». Участники торгов — supply-side платформы (SSP), demand-side платформы и рекламные биржи, и каждая возвращает цену. Код передаёт лучшие цены ad-серверу, а тот сравнивает их с вашими прямыми сделками. Все страницы, процитированные в этой статье, были открыты 10 ноября 2026 года.

Wrapper — это оболочка вокруг этого кода: список покупателей, лимит времени на ответ, ценовые правила и связь с ad-сервером. Prebid.org пишет, что его программа — самый распространённый wrapper такого рода. Там же сказано, что Prebid «можно использовать и как полноценную библиотеку торгов»: победителя выбирают на странице, а любой ad-сервер делает ставку в ней наравне с остальным спросом.

Что header bidding меняет в доходе?

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

У этого есть цена. На странице Prebid сказано: «Задерживая показ рекламы, вы можете терять показы тех пользователей, которые очень быстро уходят со страницы». Чем меньше участников, тем быстрее аукцион, «но меньше партнёров по спросу — это и меньше шансов получить оптимальную ставку». Измеряйте доход на тысячу просмотров страниц (page RPM) и скорость страницы вместе.

Клиентский или серверный аукцион, и что со скоростью страницы?

В клиентском аукционе запросы ставок отправляет браузер посетителя. Это делает Prebid.js, «библиотека JavaScript, которая работает в браузере». В серверном аукционе браузер отправляет один запрос на сервер, а тот уже опрашивает покупателей. Серверный продукт Prebid называется Prebid Server. Prebid.org пишет, что передача нагрузки серверу «может быть быстрее, чем запуск на стороне клиента, из браузера», и что возможно сочетание обоих способов. Там советуют проверять на своих страницах «число участников торгов, значения тайм-аута и клиентский или серверный вариант».

Prebid.org пишет, что серверные торги «необходимы в средах, где нет раздела заголовков HTML, в который можно поместить JavaScript, например в мобильных приложениях и на сайтах Accelerated Mobile Pages (AMP)». Для трафика из приложений это частично решает выбор.

Что входит в управляемый wrapper?

Управляемый wrapper — это услуга, при которой поставщик сам создаёт, размещает и обновляет настройку header bidding. Prebid.org пишет, что паблишеры без инженеров могут воспользоваться «компанией, предоставляющей управляемый сервис, которая может интегрировать и поддерживать Prebid за вас», и приводит их список. В его каталоге названы Adapex, Aditude, AdPushup, Assertive Yield, Freestar, Livewrapped, Magnite, Media.net, Microsoft Monetize, PubMatic, Setupad и другие.

У разных поставщиков состав услуги разный. Magnite пишет, что его Prebid как услуга позволяет крупным паблишерам «внедрять и контролировать собственные реализации header bidding без написания кода». Это утверждение самого Magnite. Ожидайте какого-то сочетания из перечисленного и спрашивайте, что входит в цену:

• Код wrapper, список покупателей и лимит времени в актуальном состоянии, плюс настройка ad-сервера
• Экран для изменения настроек без разработчика и отчёты
• Подключение к системе согласий и размещённый Prebid Server, если вам нужны серверные аукционы

От чего вы отказываетесь с управляемым wrapper?

Издержки делятся на деньги, контроль и данные, и договор может ограничить каждую из них.

• Деньги. За управляемые сервисы могут брать ежемесячную плату, долю выручки, маржу внутри пакета с собственным спросом поставщика или сочетание этого. На страницах поставщиков, которые мы прочли, цен нет, поэтому просите точную формулу и отчёт о выручке за вычетом всех удержаний.
• Контроль. Поставщик может сам решать, каких покупателей подключить, как настроить аукцион и какое обновление выпустить. Спросите, можно ли переопределять настройки и ведётся ли журнал изменений.
• Данные. Многие отчёты показывают итоги, а не отдельные аукционы. Чтобы проверить поставщика, нужна запись о каждом аукционе: кого спросили, кто ответил, по какой цене и как быстро. Спросите, получите ли вы её, в каком формате и на какой срок.

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

Что требует самостоятельный запуск Prebid?

Лицензия на программу ничего не стоит: Prebid.org пишет, что «Prebid бесплатен для всех, кто хочет им пользоваться». Платить приходится временем сотрудников:

• Обновления. Prebid.org пишет: «Мы советуем обновляться как минимум раз в полгода». В выпусках приходят «исправления ошибок, улучшения производительности, новые функции, лучшая поддержка регулирования», а каждый покупатель подключается через адаптер, небольшой модуль, который с ним взаимодействует.
• Сборка и тестирование. Модули покупателей и аналитики вы выбираете в своём файле Prebid.js, пересобираете его и перед каждым выпуском проверяете на реальных страницах в нескольких браузерах.
• Отчётность. Prebid.org перечисляет «множество плагинов-адаптеров аналитики». Вы выбираете один, подключаете его и решаете, что хранить. Именно отсюда берутся записи на уровне отдельных аукционов.
• Настройка ad-сервера. Line items, то есть записи ad-сервера о каждом ценовом уровне, и ценовые правила должны совпадать с тем, что отправляет код, иначе выручка незаметно утекает.
• Серверный хостинг, если вы его используете. В руководстве Prebid по хостингу сказано: «Prebid Server — это не готовое решение под ключ». Дальше: «Вы должны обязаться проверять наличие обновлений не реже раза в квартал. Новые выпуски выходят почти каждую неделю». Обзор серверного продукта Prebid тоже предупреждает, что его установка «далеко не так проста, как Prebid.js».

Промежуточный путь — нанять фирму, которая настроит и будет сопровождать Prebid под принадлежащими вам аккаунтами. Код и данные остаются у вас.

Где вступают в силу правила о согласии и конфиденциальности?

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

В ЕС запись о согласии обычно оформляется как строка Transparency and Consent Framework (TCF) от IAB Europe. Её создаёт платформа управления согласием (CMP), то есть всплывающее окно, в котором посетителей спрашивают. На странице IAB Europe сказано, что TCF v2.3 запущен в апреле 2025 года и что «участники TCF должны перейти на TCF v2.3 до 28 февраля 2026 года». В уведомлении IAB Europe от 16 июля 2026 года CMP дан срок до 23 октября 2026 года для внедрения новых раскрытий TCF v2.4 в вебе. Для приложений и подключённого телевидения срок — 23 февраля 2027 года. В пресс-релизе Суда Европейского союза о решении от 7 марта 2024 года по делу C-604/22 сказано, что строка «содержит сведения об идентифицируемом пользователе и поэтому является персональными данными в смысле GDPR». Там же указано, что если строка связана с идентификатором, например IP-адресом, эти сведения могут позволить определить пользователя. Относитесь к ней в своих журналах как к персональным данным. Для Google Ad Manager на справочной странице Google сказано: «при показе персонализированной рекламы пользователям в ЕЭЗ и Великобритании требуется сертифицированная CMP, интегрированная с TCF».

В США правила различаются по штатам. На странице генерального прокурора Калифорнии указано «право отказаться от продажи или передачи своих персональных данных, в том числе через GPC». GPC — это Global Privacy Control, настройка в некоторых браузерах или расширение браузера, которое сообщает сайту, что продажу или передачу данных человека нужно прекратить. В Prebid есть модули, которые считывают сигналы согласия из CMP и передают их покупателям, в том числе модуль для Global Privacy Platform от IAB. Их предел Prebid описывает так: «Функциональность Prebid, созданная для выполнения нормативных требований, не заменяет обязанность каждой стороны самостоятельно определить свои юридические обязательства и соблюдать все применимые законы».

При управляемом wrapper спросите, кто является контролёром данных об аукционах и кто подписывает условия обработки данных.

Как идентификаторы и cookie влияют на header bidding?

Покупатели могут платить больше за посетителя, которого узнают. Модуль User ID в Prebid настраивает общие псевдонимные идентификаторы, и на его странице они названы «важным способом повысить ценность header bidding». Модули идентификаторов выбираете вы, а об уведомлении для посетителей стоит получить юридическую консультацию.

Серверные аукционы добавляют ещё один шаг. В руководстве по Prebid Server сказано: «Многие участники торгов отслеживают свои идентификаторы пользователей через cookie» и что эти cookie «должны быть объединены под доменом Prebid Server». Это называется синхронизацией cookie, и она выполняется только «если это позволяют правила о конфиденциальности». Там, где синхронизации нет, покупатель может не узнать посетителя.

22 апреля 2025 года Google написал, что «сохранит нынешний подход, при котором пользователям в Chrome предлагается выбор в отношении сторонних cookie, и не будет вводить новое отдельное окно запроса о сторонних cookie». 17 октября 2025 года Google сообщил, что «прекратит поддержку следующих технологий Privacy Sandbox», среди них Topics и Protected Audience, два браузерных инструмента таргетинга рекламы. На его страницах о cookie по-прежнему сказано, что cookie «могут блокироваться из-за устройства браузера, корпоративной политики или выбора пользователя». В примечаниях к выпуску Chrome версии 153, стабильный выпуск которой запланирован на 8 сентября 2026 года, по-прежнему приводится заявление Chrome «о том, что нынешний подход к сторонним cookie будет сохранён». Более позднего заявления Google, которое меняло бы это, для статьи найти не удалось.

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

Как сравнить варианты контролируемым тестом?

Обещанный прирост — это надежда поставщика. На странице Assertive Yield в каталоге сказано, что он показал «заметный рост дохода от посетителей, превышающий существующие решения для монетизации более чем на 20%». Это его собственное утверждение, и оно ничего не говорит о ваших страницах.

• Разделите трафик случайным образом между текущей настройкой и новой. Запустите обе одновременно, на одних и тех же страницах, на целые недели, а при небольшом трафике — дольше.
• Сначала зафиксируйте вопрос: доход на тысячу просмотров страниц для каждой группы за вычетом всех комиссий, а рядом скорость страницы и показатель отказов. Длительность и порог успеха определите до начала.
• Берите цифры из собственного ad-сервера и своих записей, а не только из панели поставщика.
• Включите трудные случаи: медленные соединения, посетителей, которые отказались от согласия, приложения и трафик из ЕС.

Когда оправдан собственный слой?

Редко, и обычно не с нуля. Prebid.org пишет, что код и документация на его сайте «выпущены по лицензии Apache», так что фирма может строить поверх Prebid. Любое из этих условий может оправдать собственную разработку:

• Вы управляете рекламной сетью или SSP, и сам аукцион — ваш продукт, со своими правилами для минимальных цен, сделок и того, какие покупатели видят какое место.
• Договоры или правила работы с данными требуют, чтобы каждая запись об аукционе оставалась внутри ваших систем.
• У вас необычный инвентарь, например экраны или форматы приложений, которые Prebid покрывает плохо.
• При вашем объёме комиссии поставщика обходятся дороже, чем команда, поддерживающая ваш собственный код.

Не стройте только потому, что отчёт поставщика расходится с вашим: новая система добавит ещё один набор цифр. Не стройте ради экономии комиссии на одном сайте с обычной медийной рекламой.

Что у вас останется, если вы уйдёте от поставщика?

Несколько поставщиков из каталога Prebid сами строят свои решения на Prebid. Например, Magnite пишет, что его сервис работает «через Prebid.js, Prebid Mobile и Prebid Server», поэтому переход между настройками на основе Prebid должен быть меньшей задачей, чем уход от закрытой системы. Запросите письменно:

• Ваши собственные аккаунты у каждой SSP и биржи, чтобы отношения с покупателями и платежи остались у вас
• Полную конфигурацию wrapper в читаемом виде: покупатели, лимиты времени, минимальные цены и настройки по страницам
• Записи на уровне аукционов, выгруженные в хранилище под вашим контролем, за весь срок договора
• Записи о согласиях, настройки идентификаторов пользователей и line items ad-сервера, которые уже должны быть в вашем аккаунте
• Срок уведомления и план передачи, включая то, кто уберёт скрипт поставщика с ваших страниц

Фирма, которая это построит, должна оставить вам репозиторий, шаги сборки и тестовые страницы.

О чём спросить поставщика или фирму, которая будет это строить?

• Что именно вы берёте и что удерживается до того, как вы называете нам итоговую выручку?
• Продаёте ли вы ещё и спрос, и как вы не даёте этому влиять на то, какая ставка выигрывает?
• Построено ли это на открытом Prebid, и какая версия у нас сейчас? Как часто вы обновляете?
• Можем ли мы выгружать записи на уровне аукционов, в каком формате, за какую плату и как долго они хранятся?
• Какую платформу согласия и какие сигналы вы поддерживаете для ЕС и для штатов США?
• Как это работает для посетителя без cookie и в мобильном приложении?
• Проведёте ли вы сплит-тест на нашем трафике с цифрами из нашего собственного ad-сервера?
• Что остаётся у нас и что вы передаёте, если мы уйдём?

Где здесь место amBrain?

Этот блог публикует amBrain. Сама компания пишет: «amBrain создаёт supply-side платформы (SSP) для паблишеров». Вторая строка касается данных о рекламных событиях: «amBrain создаёт конвейеры аналитики событий для рекламных технологий: сбор, обработку и отчётность по событиям показов и кликов».

amBrain делает софт с 2019 года. О том, как компания работает с клиентами, она говорит: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». До подписания попросите поимённый список этих компонентов.

Эта статья не кейс и не описывает работу для клиентов. Строки выше не называют ни одного клиента, и ничто здесь не говорит о том, что amBrain создавал продукт для header bidding для какой-либо компании. В статье нет цен и сроков amBrain, и она не заявляет о каких-либо отношениях с названными поставщиками. Каждый внешний источник цитируется по его собственной странице.

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