OpenRTB¶

OpenRTB — это открытый протокол (спецификация) для автоматизированной торговли рекламными показами в реальном времени (Real-Time Bidding, RTB) в интернете. Разработанный и поддерживаемый организацией IAB Tech Lab, протокол определяет стандартный формат обмена данными между участниками программной (programmatic) рекламной экосистемы: издателями (владельцами сайтов и приложений), рекламодателями, рекламными биржами (Ad Exchanges), поставщиками данных (Data Management Platforms, DMP) и платформами спроса (Demand-Side Platforms, DSP) и предложения (Supply-Side Platforms, SSP). Основная цель OpenRTB — унификация взаимодействия между всеми сторонами, обеспечение совместимости, прозрачности и эффективности аукционов рекламных показов.

¶История

Протокол OpenRTB был впервые опубликован в 2010 году организацией OpenRTB Consortium, созданной при участии IAB (Interactive Advertising Bureau). Первая версия (OpenRTB 1.0) заложила базовые принципы: структуру запроса (bid request) и ответа (bid response), типы медиа (баннеры, видео, нативные форматы) и механизмы аукциона (первая и вторая цена). С тех пор спецификация активно развивалась.

В 2012 году контроль над протоколом перешёл к IAB Tech Lab, которая выпустила версию 2.0, добавившую поддержку мобильной рекламы, видеорекламы и расширенных таргетингов (геоданные, устройства). Версия 2.1 (2013) ввела объекты для описания приложений (app) и сайтов (site), а также механизмы для работы с приватностью (например, поля для передачи сигналов Do Not Track). Версия 2.2 (2014) расширила возможности для нативной рекламы и добавила поддержку аукционов с несколькими объявлениями (multi-bid).

Версия 2.3 (2015) стала одной из самых значимых: она ввела объект imp (импрессия) с поддержкой нескольких медиатипов в одном запросе, а также объекты pmp (Private Marketplace) для частных аукционов и deal для прямых сделок. Версия 2.4 (2016) добавила поддержку аудио-рекламы и улучшила обработку данных о пользователях (объект user). Версия 2.5 (2017) — текущая стабильная версия — внедрила объекты source (источник трафика) и reqs (требования к запросу), а также улучшила поддержку рекламы в приложениях (in-app). Версия 2.6 (2019) ввела поддержку рекламы в подключённых телевизорах (Connected TV, CTV) и расширила возможности для работы с контекстными данными.

Начиная с 2020 года, IAB Tech Lab активно работает над версией 3.0, которая призвана решить проблемы конфиденциальности (в частности, в связи с отказом от сторонних файлов cookie) и упростить архитектуру. OpenRTB 3.0 вводит концепцию «слоёв» (layers): транспортный слой (JSON), слой безопасности (подпись запросов) и слой рекламного контента (AdCOM — Advertising Common Object Model). Однако на 2025 год версия 3.0 ещё не получила массового внедрения, и индустрия продолжает использовать OpenRTB 2.5/2.6.

¶Архитектура и участники

Экосистема OpenRTB построена на взаимодействии нескольких ключевых участников:

• Издатель (Publisher) — владелец сайта, приложения или другого цифрового ресурса, который продаёт рекламные места (инвентарь).
• Supply-Side Platform (SSP) — платформа предложения, которая управляет инвентарём издателя, подключает его к рекламным биржам и оптимизирует доход.
• Ad Exchange — рекламная биржа, где происходит аукцион. Она получает запросы от SSP и передаёт их DSP.
• Demand-Side Platform (DSP) — платформа спроса, которая от имени рекламодателя покупает показы. DSP анализирует запросы, оценивает ценность каждого показа и отправляет ставки.
• Data Management Platform (DMP) — платформа управления данными, которая предоставляет информацию о пользователях (сегменты, интересы, демография) для таргетинга.
• Рекламодатель (Advertiser) — компания или бренд, заказывающий рекламу.

Взаимодействие происходит по цепочке: издатель → SSP → Ad Exchange → DSP → рекламодатель. OpenRTB стандартизирует сообщения между всеми этими звеньями.

¶Структура сообщений

Протокол OpenRTB использует формат JSON для передачи данных. Основные типы сообщений:

• Bid Request — запрос на ставку, отправляемый от SSP/Ad Exchange к DSP. Содержит:
• id — уникальный идентификатор запроса.
• imp — массив объектов импрессий (рекламных мест). Каждая импрессия описывает тип медиа (баннер, видео, нативный), размеры, минимальную цену (bidfloor), требования к формату.
• site или app — информация об источнике трафика (URL, категория, домен).
• device — данные об устройстве пользователя (тип, ОС, IP-адрес, геолокация, user-agent).
• user — данные о пользователе (ID, сегменты DMP, демография).
• regs — требования к регулированию (например, GDPR, CCPA).
• Bid Response — ответ на запрос, отправляемый от DSP к Ad Exchange. Содержит:
• id — идентификатор, соответствующий запросу.
• seatbid — массив объектов ставок. Каждый объект включает:
• bid — массив ставок. Каждая ставка содержит impid (идентификатор импрессии, на которую сделана ставка), price (цена за клик/показ), adm (рекламный креатив в виде HTML/JavaScript или URL), adomain (домен рекламодателя).
• cur — валюта (обычно USD).
• Win Notice — уведомление о выигрыше, отправляемое от Ad Exchange к DSP после аукциона.
• Loss Notice — уведомление о проигрыше (опционально).
• Bid Request Extensions — расширения, позволяющие добавлять кастомные поля (например, для передачи данных о контексте или приватности).

¶Типы аукционов

OpenRTB поддерживает несколько моделей аукционов:

• First-Price Auction (аукцион первой цены) — победитель платит свою ставку. Эта модель стала доминирующей в индустрии после 2019 года.
• Second-Price Auction (аукцион второй цены) — победитель платит ставку второго по величине участника. Ранее была стандартом, но сейчас используется реже из-за проблем с прозрачностью.
• Private Marketplace (PMP) — частные аукционы, где издатель приглашает ограниченный круг DSP. Используются для премиального инвентаря.
• Programmatic Guaranteed (PG) — прямые сделки с фиксированной ценой и объёмом, без аукциона. В OpenRTB реализуются через объект deal.

¶Поддержка медиатипов

OpenRTB 2.5/2.6 определяет стандартные типы рекламы:

• Баннеры — статические или анимированные изображения, HTML5-баннеры. Параметры: ширина, высота, тип (display, interstitial).
• Видео — in-stream (внутри видеоплеера) и out-stream (автономное видео). Параметры: длительность, форматы (VAST, VPAID), протоколы (DASH, HLS).
• Нативная реклама — реклама, встроенная в контент (например, «рекомендовано»). Параметры: заголовок, описание, изображение, ссылка. Поддерживается через объект native.
• Аудио — реклама в аудиопотоках (подкасты, музыкальные сервисы). Параметры: длительность, формат (MP3, AAC).
• Connected TV (CTV) — реклама на телевизорах с интернет-подключением. Поддерживается с версии 2.6.

¶Конфиденциальность и регулирование

OpenRTB активно адаптируется к требованиям законодательства о конфиденциальности:

• GDPR (General Data Protection Regulation) — в версии 2.5 добавлены поля regs.gdpr (1 — применяется, 0 — нет) и user.ext.consent (строка согласия, передаваемая через Transparency & Consent Framework).
• CCPA (California Consumer Privacy Act) — поле regs.coppa (0 — не применяется, 1 — применяется) и user.ext.us_privacy (код обработки данных).
• COPPA (Children's Online Privacy Protection Act) — поле regs.coppa для защиты детей.
• Российское регулирование — в РФ рекламная деятельность регулируется Федеральным законом «О рекламе» (№ 38-ФЗ) и законом «О персональных данных» (№ 152-ФЗ). OpenRTB может использоваться в российской экосистеме, но с учётом требований к локализации данных (хранение на территории РФ) и маркировке рекламы (включая интернет-рекламу). С 2023 года в РФ действует Единый реестр интернет-рекламы (ЕРИР), требующий передачи данных о всех рекламных показах, что может потребовать адаптации протокола.

¶Критика и ограничения

• Прозрачность — OpenRTB не гарантирует полную прозрачность цепочки поставок. Возможны ситуации, когда издатель не знает, кто купил его инвентарь (адфрод, скрытые комиссии).
• Безопасность — протокол уязвим для атак (например, подмена креативов, click fraud). Версия 3.0 вводит подписи запросов для защиты.
• Приватность — передача данных о пользователях (user.id, IP) в открытом виде вызывает опасения. Регуляторы (GDPR, CCPA) требуют ограничений.
• Сложность внедрения — для DSP и SSP требуется дорогостоящая инфраструктура для обработки миллионов запросов в секунду.
• Зависимость от cookie — OpenRTB 2.x сильно опирается на сторонние cookie для идентификации пользователей. С отказом от них (например, в браузерах Safari и Firefox) протокол теряет эффективность. Решения на основе идентификаторов (UID 2.0, ID5) пока не стандартизированы.

¶Применение в России

В России OpenRTB используется крупными рекламными платформами, такими как Яндекс.Директ, VK Реклама, SberAds, а также международными DSP (Google Ads, The Trade Desk) и SSP (PubMatic, Magnite). Однако из-за санкций и регуляторных требований (закон о суверенном Рунете, ЕРИР) многие международные платформы ограничили работу в РФ. Российские участники рынка разрабатывают собственные реализации OpenRTB, адаптированные под локальные законы (например, обязательная маркировка рекламы через ЕРИР). С 2022 года наблюдается тренд на импортозамещение в программной рекламе, включая разработку альтернативных протоколов (например, протоколы от Яндекса).

¶Источники

• IAB Tech Lab. OpenRTB Specification Version 2.5. 2017.
• IAB Tech Lab. OpenRTB Specification Version 2.6. 2019.
• IAB Tech Lab. OpenRTB 3.0 Draft. 2020.
• Федеральный закон «О рекламе» № 38-ФЗ (с изменениями).
• Федеральный закон «О персональных данных» № 152-ФЗ.
• IAB Russia. Обзор рынка programmatic-рекламы в РФ. 2023.
• Статьи на портале AdIndex и Sostav о развитии RTB в России.