Prebid

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

Документация проекта относит запуск Prebid.js к 2015 году и описывает его как совместную разработку нескольких рекламно-технологических компаний. ^[1] Это дата проекта, а не начало header bidding вообще; первенство термина из источников не установлено. Позднее линейка выросла: появились серверный компонент Prebid Server и SDK Prebid Mobile для iOS и Android. ^[1]

Prebid не следует смешивать с OpenRTB. IAB Tech Lab ведёт OpenRTB как открытую спецификацию протокола для автоматизированного обмена между продавцами и покупателями цифровой рекламы. ^[4] Протокол задаёт язык обмена, а Prebid предоставляет исполняемые компоненты и интеграционные модули. Поддержка OpenRTB сама по себе не гарантирует совместимость любых реализаций во всех полях и версиях.

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

Типовой браузерный маршрут состоит из пяти шагов. ^[2]

1. Издатель описывает рекламные места: формат, размеры и партнёров, которым разрешено отвечать.
2. Prebid.js вызывает выбранные адаптеры. Адаптер формирует запрос конкретному участнику и затем извлекает из ответа цену, креатив и другие данные. ^{[1] [2]}
3. Библиотека ждёт ответы до заданного издателем тайм-аута. Ответы, пришедшие после завершения отбора, уже не участвуют в нём. ^[2]
4. Prebid.js кодирует сведения о ставках в пары «ключ — значение» и добавляет их в запросы по соответствующим рекламным местам. ^[2]
5. Основной рекламный сервер сопоставляет спрос Prebid с прямыми кампаниями и другими источниками. Если он выбирает вариант Prebid, возвращённый код запускает отрисовку объявления. ^[2]

Поэтому выражение «аукцион Prebid» требует контекста: библиотека собирает и обрабатывает предложения, но в типовой интеграции финальный выбор делает рекламный сервер. Даже самая высокая ставка среди ответов Prebid может не стать показом. Например, Google Ad Manager учитывает тип и приоритет позиции, а цена служит лишь одним из факторов отбора. ^[5] Это правило конкретного рекламного сервера нельзя автоматически переносить на любой другой.

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

Модули различаются по функции. Bidder adapter общается с участником торгов; analytics adapter получает события для аналитики. Документация также перечисляет модули идентификаторов, валют, ценовых порогов и тестирования. ^[1] Наличие модуля означает техническую возможность, а не автоматическую корректность настройки или правовое соответствие.

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

Издатель связывает идентификатор рекламного места с форматами, размерами и партнёрами, задаёт тайм-аут, собирает нужную сборку Prebid.js и настраивает рекламный сервер на приём ключей. Сбой удобно искать по этапам: заявка не создана, партнёр не ответил, ответ отклонён, ключи не переданы, сервер выбрал другой спрос или креатив не отрисовался.

Российская реализация может иметь свои ограничения. В справке Adfox приведён единый сценарий для Yandex Header Bidding и Prebid.js: библиотеку устанавливают отдельно, а в конфигурации сопоставляют контейнеры, размеры и параметры монетизаторов. ^[6] Для монетизаторов, интегрированных через Prebid в этой схеме, справка указывает только тип Banner. ^[6] Это ограничение описанной Adfox-интеграции, а не всего семейства Prebid.

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

pbjs.getEvents() возвращает события, накопленные после загрузки страницы, но их аргументы устроены по-разному. ^[3] bidRequested содержит объект запроса участнику и массив отдельных заявок bids[]; bidResponse несёт отдельный объект ответа; bidTimeout — массив просроченных заявок. В документации адаптера bidId назван уникальным среди рекламных мест и участников, а ответ связывается с заявкой через requestId. Поле auctionId помогает ограничить торги, когда оно заполнено; его доступность зависит от версии и конфигурации. ^[9]

Ниже приведена редакционная диагностическая модель, а не готовая метрика Prebid. Сначала каждое bidRequested.args.bids[] разворачивают в отдельную строку. Основной ключ строки — bidId; при заполненном auctionId его сохраняют как дополнительную область торгов. Дубликаты по ключу удаляют. Ответ присоединяют, когда bidResponse.args.requestId совпадает с bidId, а каждый элемент bidTimeout.args[] присоединяют отдельно. Названия и наличие полей сверяют с закреплённой версией сборки. Строки без надёжного ключа не подмешивают в доли, а считают отдельно.

Для одного периода, набора мест и версии конфигурации вводят:

• N_req — число уникальных строк заявок;
• N_resp — число этих строк с сопоставленным ответом до завершения торгов;
• N_timeout — число этих строк, попавших в массив тайм-аута без своевременного ответа;
• N_other = N_req − N_resp − N_timeout — остальные строки, которые ещё нужно классифицировать.

Тогда доля ответов равна N_resp / N_req × 100%, доля тайм-аутов — N_timeout / N_req × 100%, остаток — N_other / N_req × 100%. Если сырые данные относят один ключ и к своевременному ответу, и к тайм-ауту, такую строку помечают как конфликт и не считают дважды до выяснения причины.

Учебный пример: после разворачивания и дедупликации получено 1000 заявок. С 620 сопоставлен своевременный ответ, 80 отнесены к тайм-ауту, 300 остались в прочих исходах. Получаются 620 / 1000 = 62%, 80 / 1000 = 8% и 300 / 1000 = 30%; сумма исходов — 100%.

События bidWon и adRenderSucceeded образуют другую когорту. Их нельзя делить на все bidResponse без дополнительной модели рекламного сервера. Если интеграция использует рендер Prebid и события надёжно соединяются по adId, можно отдельно посчитать долю успешного запуска рендера: N_render / N_won × 100%. При 140 сопоставленных победах и 130 событиях успеха это 130 / 140 ≈ 92,9%. Показатель относится только к этой соединённой когорте: adRenderSucceeded означает отсутствие ошибки функции рендера и не гарантирует регистрацию трекинга или оплаченного показа. ^[3]

Выручку нельзя вывести из этих событий. Если команда использует расчёт eCPM, она должна заранее закрепить одну валюту, учёт комиссии и определение оплачиваемого показа. Формула R / I × 1000, где R — признанная выручка в выбранной валюте, а I — показы по одному согласованному правилу учёта, здесь является редакционной моделью сверки, а не метрикой API Prebid.

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

Prebid не поставляет весь спрос сам: партнёров и коммерческие отношения выбирает издатель. Открытый исходный код не означает нулевых затрат — сборку, рекламный сервер, мониторинг и обновления нужно поддерживать.

Нельзя обещать универсальный рост выручки или ускорение страницы. Дополнительные участники могут усилить конкуренцию, но также увеличить число запросов и сложность интеграции. Результат зависит от инвентаря, спроса, тайм-аута и правил рекламного сервера. Событие bidResponse также не стоит называть «допустимым ответом» без отдельного правила: API различает bidResponse, bidRejected и, в некоторых версиях, bidAccepted. ^[3]

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

Если конфигурация обрабатывает сведения, относящиеся к определяемому физическому лицу, открытая лицензия Prebid не создаёт правового основания для такой обработки. Часть 1 статьи 6 Федерального закона от 27.07.2006 № 152-ФЗ допускает обработку при наличии одного из перечисленных законом оснований; согласие — лишь одно из них. ^[7] На 24 октября 2026 года использована редакция от 26.07.2026; закон № 265-ФЗ от этой даты изменяет статью 12 о трансграничной передаче, а не применённую здесь статью 6. ^[8]

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

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

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

• header-bidding
• ssp-platforma-prodavtsa
• rtb-auktsion
• reklamnyy-server
• floor-price-minimalnaya-tsena