Программатик-продажи

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

Документированная история OpenRTB начинается с пилотного проекта ноября 2010 года. Первоначально участники стандартизировали обмен списками ограничений; затем работа охватила запросы и ответы для торгов рекламными показами. Ноябрь 2010 года в этой хронологии относится к запуску технического протокола: датировать им появление всего понятия «программатик» было бы неверно. ^[1]

Спецификация апреля 2022 года полезна как исторический источник, но не как последняя инструкция по интеграции. На 22 октября 2026 года официальный репозиторий отмечает релиз OpenRTB 2.6-202606 от 11 июня 2026 года как последний. Обновления внутри ветки 2.6 получают код даты: одинаковое число «2.6» ещё не означает одинаковый набор положений. ^[8]

Что продаёт площадка и кто покупает

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

Чтобы понять участников, удобно разделить две стороны сделки. На стороне продавца действует площадка и обслуживающие её системы; на стороне покупателя — рекламодатель или агентство и системы покупки. OpenRTB описывает взаимодействие платформ продавца, бирж и сетей с покупателями, в том числе платформами покупателя. SSP означает supply-side platform, платформу стороны предложения; DSP — demand-side platform, платформу стороны спроса. Это роли в обмене, а не обязательный список отдельных компаний для каждой сделки. ^[1]

Рекламная биржа проводит аукцион между участниками, предлагающими цену за размещение. Рекламный сервер помогает выбрать и вернуть рекламный материал для показа; например, эту роль в описанной Google схеме выполняет Ad Manager. Один полученный системой ответ ещё не означает, что материал уже появился на экране. ^{[3, 7]}

Теперь изменим учебную продажу магазину: стороны согласуют предложение внутри системы прямых программатик-сделок, покупатель принимает условия, и система автоматически создаёт кампанию. Именно такой переход от согласования к исполнению описывает Programmatic Direct. Прямая договорённость здесь сохраняется, а ручной перенос заказа заменяется программной обработкой сделки. ^[2]

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

Как запрос превращается в размещение

Рассмотрим конкретную реализацию: Open Bidding в Google Ad Manager. Сначала сайт или приложение отправляет рекламный запрос серверу. Ad Manager определяет подходящих партнёров спроса и передаёт им запросы ставок. Партнёры проводят свой отбор и возвращают предложения; затем Ad Manager сопоставляет их с другими допустимыми вариантами и возвращает выбранный материал площадке. Обмен с партнёрами происходит между серверами. Это последовательность одной системы, а не обязательный алгоритм всех программатик-продаж. ^[3]

В нашей учебной модели запрос означает: «Для этого места нужна реклама с такими условиями». Ответ со ставкой означает: «Покупатель предлагает такую цену и материал». Выбор победителя означает решение системы, но для результата площадки нужен ещё учтённый показ. Различие принципиально: OpenRTB отдельно описывает уведомление о победе и уведомление о наступлении оплачиваемого события. Победа сама по себе не подтверждает доставку, видимость или оплату объявления. ^[7]

Допустим, в учебной системе две ставки подходят по формату, но одна пришла после установленного времени ожидания. Нельзя просто выбрать большее из двух чисел и объявить его результатом торгов: сначала надо проверить право ответа участвовать в отборе. В Prebid.js участник, который не ответил в пределах тайм-аута, исключается из соответствующего аукциона. Тайм-аут — это предел ожидания ответа, а не цена размещения. ^[4]

Для наглядности зададим в учебной модели предел 800 миллисекунд. Ответ А поступил через 600 миллисекунд, ответ Б — через 900. А укладывается в условие модели; Б опоздал на 100 миллисекунд. Этот пример объясняет отсечение по времени, но не рекомендует реальной площадке ждать именно 800 миллисекунд. Увеличив предел до 1000, мы допустим оба ответа в модели, однако этим расчётом ещё ничего не докажем об итоговой выручке или удобстве страницы.

Виды сделок и способы интеграции

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

Пример автоматизированных прямых продаж — Programmatic Direct в Google Ad Manager. В нём покупатель и продавец согласуют условия, после чего система настраивает кампанию для доставки. Google различает Programmatic Guaranteed, где инвентарь резервируется и предусматривается гарантия, и Preferred Deals, где резервирования и гарантии нет. Названия относятся к модели Google; переносить их условия на договор с другим поставщиком без проверки нельзя. ^[2]

RTB расшифровывается как real-time bidding: торги за отдельные возможности показа в реальном времени. OpenRTB — спецификация сообщений для такого взаимодействия. Первое название обозначает механизм, второе — технический язык, на котором могут общаться системы. Совместимость сообщений помогает подключению участников, но не задаёт все коммерческие правила их работы. ^{[1, 7]}

Header bidding — способ собрать предложения спроса для дальнейшего выбора рекламы. В клиентской схеме Prebid.js библиотека JavaScript работает в браузере посетителя; в серверной схеме Prebid Server часть обмена выполняет сервер. Документация допускает сочетание клиентских и серверных обращений. Это выбор устройства интеграции, который сам по себе не отвечает на вопрос о гарантированном объёме продажи. ^[4]

В учебном паспорте подключения поэтому нужны две разные строки. В одной записываем договорённость: например, резервируется ли объём. Во второй — маршрут обмена: какие действия выполняются в браузере, а какие на сервере. Тогда менеджер и разработчик смогут обсуждать одну сделку, не подменяя коммерческие условия устройством программы.

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

Международные примеры выше показывают разные задачи: Google документирует согласование сделок и отбор рекламы, а Prebid — компоненты подключения спроса. Для российской практики показателен Adfox: справка описывает торги в реальном времени через Рекламную сеть Яндекса и перечисляет собственные продажи, монетизацию Яндексом, внешнюю монетизацию и собственное промо. Промо означает продвижение самой площадки; его наличие в перечне не делает каждый показ оплаченной продажей внешнему рекламодателю. ^{[2, 3, 4, 5]}

Практический порядок ниже — предложение редакции для разбора подключения, а не стандарт платформы. Вернёмся к городскому сайту. Сначала составим список мест, которые можно включить в тест, и отделим уже обещанные магазину размещения. Затем запишем, кто принимает коммерческие решения, кто меняет код и кто сверяет отчёты. Так у любого сбоя появится конкретный адресат: вопрос о неполученном ответе не затеряется среди вопросов о договоре.

Далее выберем ограниченный участок для проверки: например, один баннерный формат в одном разделе. В паспорте теста укажем период, устройство посетителя, партнёра, настройки ожидания и источник каждого показателя. Если одновременно заменить место баннера, подключить новый спрос и изменить набор страниц, результат будет трудно объяснить: сравнение покажет совокупность перемен, а не вклад одной интеграции.

На этом этапе полезно пройти один сценарий целиком. Есть ли запрос? Пришёл ли допустимый ответ? Какое объявление выбрано? Появилось ли соответствующее событие в отчёте? Эти вопросы превращают абстрактное «подключение работает» в проверяемое описание. Отдельно остаются качество материала, исполнение договорённостей и законность размещения: успешный обмен сообщениями не решает их автоматически.

Как измерить результат

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

За выбранный период отправлено 10 000 запросов, из них на 7000 получен хотя бы один допустимый своевременный ответ. Числитель — запросы с таким ответом; знаменатель — все отправленные запросы в той же выборке. Доля равна 70 процентам. Мы не складываем несколько ставок внутри одного ответа и не называем полученную долю заполнением рекламы.

Доля запросов с ответом = 7000 / 10 000 × 100% = 70%.

Продолжим тот же учебный сценарий: из этих запросов 6000 закончились выбранным объявлением, а 5400 — подтверждённым показом по принятому в примере правилу учёта. От первоначальных запросов до показов дошло 54 процента. Среди выбранных объявлений показатель составляет 90 процентов. Оба числа верны, но отвечают на разные вопросы: первое описывает весь путь, второе — только переход после выбора.

Показов на запросы = 5400 / 10 000 × 100% = 54%. Показов на выбранные объявления = 5400 / 6000 × 100% = 90%.

Отдельно посчитаем доход. В другом учебном примере отчёт содержит 50 000 подтверждённых показов и 4000 рублей начисленного дохода за них. Чтобы получить средний доход на тысячу этих показов, делим рубли на количество показов и умножаем на тысячу. Получаются 80 рублей. Это отношение двух заданных величин, а не рыночная цена, тариф платформы или прогноз будущих заработков.

Доход на тысячу показов = 4000 / 50 000 × 1000 = 80 рублей.

Если 4000 рублей указаны до комиссий и других расходов, результат нельзя называть чистой прибылью. При нуле показов отношение не определено; вывод «ноль рублей на тысячу» исказил бы смысл деления. Если доход ещё предварительный, это свойство должно сопровождать результат, иначе окончательный отчёт будет выглядеть как необъяснимое изменение.

Рост дохода на тысячу тоже не гарантирует рост общей суммы. Пусть в следующем учебном периоде получены 40 000 показов по 90 рублей на тысячу. Общий доход составит 3600 рублей: показатель на тысячу вырос, а сумма оказалась на 400 рублей меньше прежних 4000. Сопоставление полезно только при одинаковом определении дохода и показов.

Доход второго периода = 40 000 / 1000 × 90 = 3600 рублей.

Для разбора расхождений редакция предлагает начинать с одинакового периода, часового пояса, валюты, состава страниц и события учёта. Например, 6000 выборов объявления и 5400 показов в нашем сценарии — не два конкурирующих ответа на один вопрос. Ошибка возникнет, если подписать обе величины одним словом «показы» и начать искать потерянные деньги до выяснения смысла столбцов.

Ошибки и ограничения

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

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

Третья ошибка — объявлять лучший вариант интеграции заранее. Документация Prebid рекомендует проверять число участников, предел ожидания и клиентскую либо серверную схему на конкретных страницах. ^[4] Результат такого сравнения следует описывать вместе с условиями теста: вывод для одного формата не становится обещанием для всего сайта.

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

Автоматизация не заменяет требования к интернет-рекламе в России. В статье 18.1 закона № 38-ФЗ, редакция от 04.08.2026, часть 16 устанавливает пометку «реклама» и сведения о рекламодателе либо ссылку на сайт или страницу с ними. Исключение в этой части касается рекламы в распространяемых через интернет теле- и радиопрограммах и передачах. Часть 17 отдельно требует присвоения идентификатора оператором рекламных данных; она охватывает также социальную рекламу. ^[6]

Оператор рекламных данных — уполномоченный участник учёта рекламы; его функция отличается от выбора победившей ставки. Пометка сообщает читателю рекламный характер материала, а идентификатор обеспечивает прослеживаемость. Исходные положения статьи 18.1 введены с 1 сентября 2022 года; использованное расширение на социальную рекламу действует с 1 марта 2025 года. ^{[6, 9, 10]}

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

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

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

• SSP (платформа продавца)
• DSP (платформа покупателя)
• Рекламная биржа
• Header bidding
• Рекламный сервер
• Рекламный инвентарь