OpenRTB и история программатик. Как стандарт стал зеркалом развития рынка интерактивной рекламы

10 апреля 2026
OpenRTB принято считать технической основой программатик. Но его эволюция говорит не только о развитии протокола, а о развитии самого рынка. По тому, как менялся OpenRTB, видно, как программатик проходил путь от унификации RTB-аукциона к более сложной системе стандартов, платформенных реализаций и локальных правил.
Стандарт, в котором видно рынок
OpenRTB (или oRTB - стандарт открытого протокола торга рекламного размещения в реальном времени) обычно описывают как техническую базу программатик: формат bid request (запрос ставки) и bid response (тендерное предложение), без которого SSP (ПССП), DSP (ПАПР) и биржи не смогли бы нормально торговать инвентарем.

Если смотреть на протокол не как на набор полей, а как на историю решений, принятых индустрией, становится видно больше: по эволюции стандарта хорошо читается история интерактивной рекламы: от попытки унифицировать цифровой аукцион в 2010–2012 годах до более комплексной системы, где приходится учитывать умное ТВ, прозрачность цепочки поставок и особенности отдельных рынков.

Поэтому стандарт выглядит неровным. У него нет красивой линейной биографии, где каждая следующая версия просто и безболезненно заменяет предыдущую. Напротив, история стандарта полна боковых веток, параллельных логик и решений, которые объясняются не версионированием как таковым, а устройством самой отрасли. Например, сосуществование OpenRTB 3.0, представленного как новая архитектурная линия в 2018 году, и OpenRTB 2.6, который стал практически важным обновлением ветки 2.x уже в 2021–2022 годах.
Зачем вообще понадобился oRTB
Когда RTB (стандарт протокола торга рекламного размещения в реальном времени) только набирал вес, у рынка была довольно приземленная проблема: участникам не хватало общего языка обмена данных. The RTB Project, из которого вырос OpenRTB, собрался в ноябре 2010 года. Первая мобильная спецификация вышла в феврале 2011-го, единый OpenRTB 2.0 — в июне 2011 года, а в январе 2012-го OpenRTB принят как стандарт IAB (Интерактивного рекламного бюро) с выпуском 2.1.

Эти даты показывают исходную функцию стандарта. Он появился не как “идеальная модель программатика”, а как способ снизить хаос интеграций на рынке, который начинал вырастать из своей архитектуры. На момент запуска проекта программатик занимал лишь небольшую часть дисплей-рынка. То есть OpenRTB создавался не как надстройка над зрелой экосистемой, а как инфраструктурный каркас для среды, которая быстро росла и нуждалась в совместимости.
Взрослеем вместе
На раннем этапе programmatic был в первую очередь про дисплейную рекламу. Затем рынок начал быстро включать мобильный, видео и позже нативный сегменты.

Ветвь OpenRTB 2.x можно читать как основную линию взросления классического программатика. Характерные вехи вполне предметны: в январе 2015 года OpenRTB 2.2 усилил приватные сделки по премиальному инвентарю (PMP) и сигналы по нечеловеческому трафику; в июне 2015-го версия 2.3 добавила поддержку нативной рекламы; в декабре 2016-го OpenRTB 2.4 принес audio objects (звуковые объекты), skippability (пропускаемость) и поддержку SSL; в сентябре 2017-го OpenRTB 2.5 закрепил зрелую фазу с внедрением header bidding (технология автоматизированных аукционов), обновленной видеосигнализации и исторических метрик.

Таким образом, oRTB рос не абстрактно, а вместе с рынком. За пару лет индустрии потребовался язык покупки display-инвентаря. Затем — для мобаил и видео. Потом — с нативными форматами, более сложным видео и зрелой аукционной инфраструктурой, сохраняющей обратную совместимость.
Одного протокола мало
Примерно к 2017–2018 годам, когда OpenRTB уже дорос до зрелой ветки 2.5, по-прежнему отвечал за аукционный обмен, но рынок начал требовать прозрачности цепочек и необходимость общей объектной модели.

Так в 2018 году появился oRTB 3.0 и первый AdCOM — общие объектные модели и общий словарь перечислений (enumerations). Иначе говоря, рынок вырос из одного протокола в экосистему спецификаций. Это не бюрократическое усложнение, а отражение того, что сама индустрия цифровой рекламы стала гораздо сложнее: ей уже недостаточно просто быстро торговать инвентарем, ей нужно делать это согласованно, прозрачно и верифицируемо.
Архитектура против внедрения

В рекламных технологиях почти всегда сталкиваются две силы.


Первая — архитектурная. Тянет индустрию к чистой, последовательной и современной модели. Вынести общие объекты, сделать стандарт стройнее, повысить прозрачность, сократить число неявных трактовок.


Вторая — производственная. Напоминает, что у рынка уже есть работающие интеграции, накопленный код, контракты, инфраструктура SSP и DSP и огромный объем инвентаря, который нужно продавать не в будущем, а сейчас.


Из этого следует простая, но важная вещь: стандарты в интерактивной рекламе развиваются не по академической логике, где новая версия полностью заменяет старую. Гораздо чаще новая архитектура появляется раньше, чем рынок готов массово жить внутри нее. А пока этого не произошло, индустрия берет из новой модели отдельные элементы и встраивает их в старую рабочую ветку.


OpenRTB 3.0 был архитектурным шагом вперед. Но сама же IAB Tech Lab позднее признала, что OpenRTB 3.0 не получил широкого внедрения по экосистеме, тогда как элементы AdCOM и связанные с ним листы получили широкое применение в мире OpenRTB 2.x.

Грандиозное возвращение телевизора
oRTB 2.6 важен не только как “живое продолжение” 2.x. В 2021–2022 годах зарубежный рекламный рынок уже всерьез заинтересовался Умным ТВ. В классическом веб-аукционе рынок мыслит отдельным показом. На Умном ТВ этого уже недостаточно: здесь нужно описывать последовательность рекламных блоков, длину рекламного блока и более сложный контентный контекст, учитываемый oRTB 2.6.

То есть 2.6 нужно понимать не как случайный хвост старой ветки, а как практический ответ на новую среду инвентаря. Парадокс “3.0 раньше, 2.6 позже” поэтому на самом деле не парадокс. Это обычная форма жизни зрелого технологического рынка, где архитектурное будущее и производственное настоящее движутся с разной скоростью.

Несмотря на всесторонний интерес к рекламе на Умном ТВ в России, рынок всё ещё не полностью перешёл на последнюю версию стандарта, поскольку oRTB 2.6 также поддерживает обратную совместимость с более старыми версиями стандарта.

Однако, UMG поддерживает oRTB 2.6 и работает с полноценным ТВ-инвентарем — рекламными паузами на телеканалах и в приложениях на Умных ТВ для более точного описания среды, где важны не только показы, но и сама структура рекламного блока.

Заинтересовало?

Мы не сомневались! Свяжитесь с нами, чтобы обсудить условия подключения нашей programmatic-экосистемы

Что ещё происходит на локальных рынках
В российском контексте oRTB почти никогда не работает как «чистый» глобальный стандарт в его учебном виде: сам протокол по-прежнему отвечает за обмен ставок, но реальная сделка здесь встроена в обязательный контур учета и маркировки интернет-рекламы.

После введения статьи 18.1 закона «О рекламе» рынок обязан обеспечивать прослеживаемость размещений: информация о рекламе передается в Роскомнадзор через операторов рекламных данных, а сами ОРД не только выдают идентификатор рекламы, но и принимают и передают необходимые сведения в ЕРИР, причем делают это как через интерфейсы, так и через API, уже интегрированные в крупные российские рекламные системы.

Поэтому на практике локальная специфика использования oRTB в России требует поверх универсального аукционного языка неизбежного появления дополнительного слоя локальных требований: креатив нужно связать с erid, отчетность с показом, а платформенную логику закупки с передачей сведений о рекламодателе, участниках цепочки, договорах, актах и статистике размещения.
Стандарт как путеводитель
Если собрать всю эту историю вместе, OpenRTB оказывается полезен не только как техническая база RTB-аукциона. Он работает как карта напряжений внутри индустрии. В 2010–2012 годах он отражает потребность в унификации. В 2015–2017 — рост рынка в сторону мобильной, видео и нативной рекламы. В 2018 году — переход от одного протокола к более сложной экосистеме стандартов с oRTB 3.0 и AdCOM 1.0. В 2021–2023 — возвращение прикладных обновлений в ветку 2.x через 2.6 и CTV-фокус. А на локальных рынках — еще и наложение глобального стандарта на конкретную платформенную и регуляторную среду.

Поэтому история OpenRTB не складывается в красивую линейку версий. Но именно этим она и ценна. Она показывает, что programmatic развивается не как чистая инженерная система, а как рынок компромиссов — между универсальным стандартом, реальным внедрением, новыми типами инвентаря и правилами конкретных юрисдикций. И если смотреть на OpenRTB именно так, то даты в этой истории нужны не ради календаря, а ради понимания: когда рынок менялся и почему стандарт менялся вместе с ним.
Запишитесь на демонстрацию или предложите формат сотрудничества – будем рады познакомиться ближе.
Начните свой путь к успеху с нами
Ставки сотрудников при доработке продукта
Ставка, /час
Специалист
Директор по продукту
Бизнес-аналитик
Специалист клиентской части (Frontend)
Специалист серверной части (Backend)
Специалист пользовательского интерфейса и опыта (UI/UX)
C++ специалист
Инженер программного оперирования (DevOps)
Инженер контроля качества (Q&A)
Технический директор
5500
6500
8500
6500
7000
7000
8000
18000
20000
Мы используем куки
для улучшения сервиса
Ок
Общество с ограниченной ответственностью «ЮЭМДЖИ ГРУПП»

ИНН: 9 724 057 015, КПП: 773 101 001, ОГРН: 1 217 700 408 056, ОКПО: 49 811 678

Юридический адрес: 121205, г. Москва, вн. тер. г. муниципальный округ Можайский, территория. Инновационного Центра «Сколково», Большой бульвар, д. 42, стр. 1

Адрес для направления корреспонденции: 115191, г. Москва, вн. тер. г. муниципальный округ Даниловский, Варшавское шоссе, д. 1, стр. 6, офис А 215

Телефон: +7 495 369-18-13

Электронный адрес: hello@umg.team

Генеральный Директор: Адамов Всеволод Владимирович

Остальные данные, требуемые Приказом Минцифры №511 от 02.06.2025 >
Close
У вас есть вопросы? Свяжитесь с нами!
Нажимая на кнопку, вы соглашаетесь с политикой конфиденциальности