RTB-аукцион

Real-Time Bidding

RTB-аукцион — автоматизированные торги за отдельную возможность показать рекламу, проходящие при обработке рекламного запроса. Системы покупателей оценивают этот показ и предлагают ставки, а система торгов выбирает допустимое предложение по установленным правилам.

RTB расшифровывается как Real-Time Bidding — «торги в реальном времени». IAB Tech Lab, организация по разработке рекламных технологических стандартов, определяет этот способ покупки через аукцион отдельного показа. Поэтому термин описывает конкретный механизм внутри programmatic — автоматизированной торговли рекламой, а не любую её разновидность. [1]

Кратко

  • На торги поступает возможность показа, а не обещание, что человек обязательно увидит объявление. [1, 2]
  • OpenRTB — правила обмена сообщениями между системами, а не рекламная биржа. [7]
  • Для результата важны не только цена, но и своевременность и допустимость ответа. [2, 3]
  • Доля побед зависит от того, что посчитано в знаменателе; учебный пример ниже показывает разницу.

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

В исследовании Шуая Юаня, Цзюня Вана и Сяосюэ Чжао 2013 года развитие рынка описано как переход от прямых договорённостей издателей с рекламодателями к рекламным сетям, а затем к биржам, объединяющим спрос и предложение. Авторы связывают появление RTB в 2009 году с объявлением его поддержки крупными биржами. Это историческая периодизация исследования, а не доказательство первого употребления слов Real-Time Bidding. [6]

Содержательная перемена состояла в том, что покупатель мог заново принять решение для конкретного показа, используя сведения о странице и посетителе. Раньше покупка пакета размещений не давала такого же выбора в момент каждой возможности показа. Работа 2013 года описывает этот переход; её наблюдения о рынке не следует принимать за сегодняшнюю статистику. [6]

Для общения разных систем понадобился общий язык. Проект OpenRTB возник в ноябре 2010 года, а развитие его спецификаций продолжилось позднее. [1] На дату проверки последним опубликованным релизом ветки OpenRTB 2.x указан 2.6-202606. Это версия документа об обмене данными, а не номер поколения всех рекламных аукционов. [8]

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

На стороне рекламодателя работает DSP (Demand-Side Platform) — платформа покупателя, которая оценивает предложения и отвечает ставкой. Издателю может помогать SSP (Supply-Side Platform) — платформа продавца. Биржа связывает участников и проводит торги. Такой набор ролей описан в научной работе о RTB; роли обозначают функции, а не обязательное число отдельных компаний. [6]

Представим читателя, открывающего страницу с рекламным местом. В описании Рекламной сети Яндекса система рассылает запрос участникам, пока загружается страница. Покупатели должны за доли секунды оценить предложение и ответить. Победитель получает право разместить рекламу. [4]

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

Доступные сведения зависят от реализации. Например, Google не заполняет поля, которые недоступны или неприменимы к предложенному показу. Если в запросе отсутствует поддержка соответствующего видеоформата, покупатель не должен отвечать таким видеообъявлением. Поэтому высокая ставка за неподходящий формат не решает задачу размещения. [2]

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

В спецификации OpenRTB есть несколько независимых признаков. Поле at различает аукционы первой цены и второй цены с добавкой; разрешены и собственные типы бирж. Поле private_auction определяет, ограничены ли предложения условиями перечисленных сделок. Это классификация полей протокола, а не утверждение, что любая система поддерживает все варианты. [7]

При первой цене победитель платит свою ставку. В учебной модели второй цены с добавкой платёж определяется следующей допустимой ставкой и заданным шагом; реальные условия нужно читать у организатора торгов. OpenRTB приводит примеры обоих расчётов. [7]

Header bidding, или предварительный сбор предложений до обращения к рекламному серверу, описывает другой признак — организацию получения ставок. В распространённом сценарии Prebid собирает предложения, а окончательный выбор делает рекламный сервер. Следовательно, лучший ответ внутри одного этапа ещё может участвовать в следующем отборе. [3]

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

Условный учебный пример: издатель продаёт один показ баннера. Для простоты установим срок ответа 100 миллисекунд, минимальную цену 60 рублей за тысячу показов и расчёт по первой цене. Эти числа придуманы для разбора, а не взяты из настроек Яндекса или Prebid.

Покупатель А предлагает 120 рублей и отвечает за 80 миллисекунд. Покупатель Б предлагает 150 рублей, но отвечает за 130 миллисекунд. Покупатель В предлагает 100 рублей и успевает за 70 миллисекунд, однако его объявление имеет неподходящий формат. После исключения опоздавшего и недопустимого ответов остаётся А. Он выигрывает, хотя Б прислал большее число.

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

В российской практике справка Яндекса описывает сайты сети как продавцов, а DSP — как представителей рекламодателей. Там же предусмотрен ценовой порог: если подходящих предложений выше порога нет, может вызываться реклама другой баннерной системы. Поэтому отсутствие победителя в одном аукционе не обязательно означает пустое место на странице. [4]

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

CPM (Cost Per Mille) означает стоимость тысячи показов. Такая единица позволяет выражать ставку за один показ удобным числом; сама по себе она не означает покупку обязательного пакета из тысячи. В документации Google отдельно показан перевод цены за тысячу в стоимость одного показа. [2]

В нашем учебном аукционе платёж по первой цене составляет 120 рублей CPM. Для одного оплачиваемого показа это 120 / 1000 = 0,12 рубля. Комиссии и налоги в учебную модель не включены. Если бы все три предложения были допустимыми и своевременными, победил бы Б; при первой цене его платёж составил бы 0,15 рубля за показ. Так видно, какое именно условие меняет результат.

Теперь условно отправим одному покупателю 100 запросов, каждый ровно на один показ. Он вернул 60 ответов со ставками, из которых 20 выиграли. Доля ответов — число ответов, делённое на число запросов: 60 / 100 × 100% = 60%. Доля побед среди ответов — 20 / 60 × 100% ≈ 33,33%. Если знаменателем сделать запросы, получится 20%. Оба последних расчёта правильны, но отвечают на разные вопросы: как часто выигрывает отправленная ставка и как часто запрос заканчивается победой.

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

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

Открытый протокол не делает подключения одинаковыми. Руководство Google описывает собственные расширения OpenRTB. Поэтому совместимость проверяют по поддерживаемым сообщениям и полям, а не только по названию стандарта. [2]

Увеличение времени ожидания тоже имеет цену. По документации Prebid, задержка сбора ставок может привести к потере показов посетителям, которые быстро ушли со страницы. Большее число покупателей даёт больше потенциальных предложений, но подходящие настройки требуют испытаний. Универсального срока ответа для любого сайта из этого не следует. [3]

Наконец, двадцать выигранных ставок в учебном расчёте не означают двадцать разных людей. Повторные обращения одного посетителя модель не различает. Для учёта фактических показов нужны отдельные события: Google специально описывает уведомление о показе, считающемся оплачиваемым, и предупреждает о расхождениях при предварительной загрузке объявления без его отображения. [2]

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

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

Это требование действует с 1 сентября 2022 года: дату устанавливает статья 2 закона №347-ФЗ для пункта 3 статьи 1, которым введена статья 18.1. [9] Способ выбора объявления через аукцион не заменяет маркировку. Здесь разобрано только одно требование; обязанности по учёту рекламы и обработке данных требуют отдельного рассмотрения и юридической проверки.

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

OpenRTB самостоятельно покупает рекламу?

Нет, он описывает взаимодействие систем покупателей и продавцов. Решения принимают эти системы. [7]

Побеждает ли самая высокая отправленная ставка?

В учебном примере сначала исключены поздние и неподходящие ответы. Без проверки допуска сравнивать все суммы недостаточно. [2, 3]

Можно ли узнать охват из доли побед?

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

Header bidding и RTB означают одно и то же?

Нет. Первый термин описывает предварительный сбор предложений, второй — торги за отдельный показ; эти механизмы могут использоваться совместно. [1, 3]

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

Источники

  1. IAB Tech Lab. (2024, January 23). OpenRTB (Real-time bidding). https://iabtechlab.com/standards/openrtb/ (дата обращения: 30.10.2026). ↑ а б в г
  2. Google. (n.d.). OpenRTB integration. Authorized Buyers. https://developers.google.com/authorized-buyers/rtb/openrtb-guide (дата обращения: 30.10.2026). ↑ а б в г д е ж з
  3. Prebid.org. (n.d.). Introduction to Prebid for header bidding. https://docs.prebid.org/overview/intro.html (дата обращения: 30.10.2026). ↑ а б в г д е
  4. Яндекс. Real-Time Bidding : справка Рекламной сети Яндекса. — Б. д. — URL: https://yandex.ru/support/partner/ru/technologies/rtb (дата обращения: 30.10.2026). ↑ а б
  5. О рекламе : Федеральный закон от 13.03.2006 №38-ФЗ : в ред. от 04.08.2026 : ст.18.1, ч.16. — URL: https://www.consultant.ru/document/cons_doc_LAW_58968/2c4537e4796f6ff8b2736ed1b0d4fef08e14458e/ (дата обращения: 30.10.2026). ↑
  6. Yuan, S., Wang, J., & Zhao, X. (2013). Real-time bidding for online advertising: Measurement and analysis. In Proceedings of ADKDD '13. ACM. https://doi.org/10.1145/2501040.2501980. Прочитанная авторская версия: https://arxiv.org/pdf/1306.6542, с.1–4 (дата обращения: 30.10.2026). ↑ а б в
  7. IAB Tech Lab. (n.d.). OpenRTB 2.6 specification. https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md (дата обращения: 30.10.2026). ↑ а б в г д
  8. IAB Tech Lab. (2026). OpenRTB 2.x release notes: OpenRTB v2.6-202606. https://github.com/InteractiveAdvertisingBureau/openrtb2.x/releases (дата обращения: 30.10.2026). ↑
  9. О внесении изменений в Федеральный закон «О рекламе» : Федеральный закон от 02.07.2021 №347-ФЗ : в ред. от 14.07.2022 : ст.1, п.3; ст.2. — URL: https://www.consultant.ru/document/cons_doc_LAW_389115/3d0cac60971a511280cbba229d9b6329c07731f7/ ; https://www.consultant.ru/document/cons_doc_LAW_389115/b004fed0b70d0f223e4a81f8ad6cd92af90a7e3b/ (дата обращения: 30.10.2026). ↑

Служебный блок

Версия
2.0
Факты проверены
Подготовка
Редакция Медиатрона
Публикация
утверждена владельцем издания 4 ноября 2026 г.

Редакция Медиатрона. Факты сверены с первоисточниками на дату проверки, публикация утверждена владельцем издания.

Нашли ошибку? info@mediatrone.ru