Programmatic для сети экранов цифровой наружной рекламы: продавать через DOOH SSP, взять white-label стек или построить свою платформу

Programmatic-продажи — это когда ваши рекламные места продаёт софт. Каждый раз, когда появляется свободный слот, системы закупки рекламодателей делают на него ставки на автоматическом аукционе. У сети цифровой наружной рекламы (DOOH) есть экраны в таких местах, как торговые центры, вокзалы, спортзалы и офисы. Она может продавать их через programmatic с помощью DOOH supply-side платформы (SSP), которая предлагает покупателям экраны многих сетей. Ещё она может запустить софт вендора под собственным брендом (white-label стек) или построить свою платформу. Выбор зависит от того, какую часть продаж вы хотите контролировать и кто будет каждый день эксплуатировать технологию.

Что меняется, когда сеть экранов продаёт через programmatic?

Часть покупателей начинает делать ставки на отдельные выходы рекламы через софт, вместо того чтобы бронировать кампании у вашего отдела продаж. При прямой продаже этот отдел согласует с рекламодателем даты, экраны и цену. Затем кто-то загружает рекламу в вашу систему управления контентом (CMS) — софт, который решает, что и когда показывает каждый экран.

Programmatic-ставки поступают от demand-side платформы (DSP) — системы, через которую рекламодатели и агентства покупают рекламу. Системы покупателей и продавцов обычно обмениваются этими ставками в формате OpenRTB — общем формате сообщений. IAB Tech Lab, которая разрабатывает технические стандарты для цифровой рекламы, поддерживает этот формат и в ноябре 2022 года добавила в OpenRTB 2.6 поддержку экранов.

Статья опирается на эту спецификацию и на руководство IAB Tech Lab по её внедрению. Кроме того, в ней используются таксономия площадок OpenOOH — общий список типов площадок — и стандарты Media Rating Council (MRC) по измерению наружной рекламы. Все источники открывались 4 ноября 2026 года.

Начните со своей CMS или плеера — устройства или софта, на котором работает каждый экран. Цикл (loop) — это последовательность контента и рекламы заданной длины, которая проигрывается снова и снова. Если ваши экраны работают по такому циклу, часть слотов в нём должна оставаться открытой для programmatic. Плеер должен загружать для них рекламу и отчитываться о том, что вышло на экран. Если реклама не пришла, плееру нужно, что показать вместо неё.

Аукцион может пройти задолго до выхода рекламы. Руководство IAB Tech Lab объясняет, что большинство экранов подключается через мобильные сети, а связь в них в часы пик может пропадать. Поэтому некоторые сети экранов загружают рекламу заранее. В руководстве сказано: «Принятый сейчас в отрасли интервал от „подтверждения ставки“ до „показа“ может доходить до 1–2 часов».

Как один выход рекламы на экране превращается во множество показов?

Каждый запрос на ставку (bid request) — сообщение, в котором DSP предлагают сделать ставку, — указывает, сколько показов стоит выход рекламы. На сайте показ — это одно объявление, показанное одному человеку. А выход рекламы на экране, как сказано в руководстве IAB Tech Lab, «виден всем, кто находится поблизости от показываемой рекламы».

Это число — множитель показов (impression multiplier), то есть аудитория, которая засчитывается за каждый выход. OpenRTB 2.6 определяет его как «количество оплачиваемых событий, которые будут считаться произошедшими, если этот элемент будет куплен». Проще говоря, это то, за что платит покупатель.

Множитель может быть меньше единицы — так бывает, например, ночью у экрана в малолюдном месте. В руководстве сказано, что «дробные значения (например, 0,32 показа на одно воспроизведение рекламы) встречаются часто». Там же добавлено, что это число может меняться от часа к часу или поступать из «данных датчиков в реальном времени».

Цены по-прежнему указываются в CPM — цене за тысячу показов. В руководстве приведён расчётный пример, а не рыночная цена: если ставка с CPM 2,50 доллара выигрывает выход, который стоит 30,3 показа, сумма счёта составит 0,07575 доллара. Там же предупреждают, что умножение на дробные числа «может приводить к расхождениям, когда „сторона покупки“ и „сторона продажи“ отбрасывают знаки после запятой». Договоритесь об округлении с каждой SSP и каждым покупателем до первой кампании.

Откуда берётся цифра аудитории?

Запрос на ставку может сообщать и то, кто предоставил эту цифру. Спецификация AdCOM от IAB Tech Lab называет три источника: провайдер измерений, паблишер (вы) или биржа (SSP).

Покупатели спросят, что именно измеряет эта цифра. MRC — американская отраслевая организация, которая проводит аудит и аккредитацию измерений в медиа. Её стандарты для наружной рекламы, окончательная версия которых вышла в декабре 2025 года, описывают лестницу от трафика в месте размещения до аудитории, которая, вероятно, видела рекламу. Каждая ступень добавляет условия, и в стандартах отмечается, что «валовые показы (Gross Impressions) отражают максимальную потенциальную оценку аудитории».

Как доказать, что реклама действительно вышла на экран?

Подтверждение выхода (proof of play) — это лог плеера экрана, который показывает, какая реклама вышла, на каком экране и когда. В стандартах MRC сказано: «Должны быть веские доказательства выхода рекламы (proof-of-play, PoP), подтверждающие отчётность по валовым показам или оценкам аудитории».

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

В OpenRTB есть уведомление о биллинге — сообщение, которое говорит покупателю, что за показ можно выставить счёт. Уведомление о выигрыше — это другое сообщение, и оно говорит лишь о том, что ставка выиграла. Руководство IAB Tech Lab настоятельно рекомендует разделять эти два уведомления и отправлять уведомление о биллинге, когда «креатив отрисован на экране и показ[ы] подлежат оплате». Креатив — это сам рекламный файл.

Какими тремя способами можно продавать наши экраны через programmatic?

• Продавать через DOOH SSP. Вы подключаете свою CMS или плееры к SSP и загружаете туда свои экраны и цифры аудитории. SSP предлагает их DSP, с которыми работает, проводит аукцион и выплачивает вам то, что остаётся после её комиссии.
• Взять white-label стек. Вендор лицензирует вам свой ad-сервер и софт, через который рекламные места продаются DSP. Ad-сервер — это система, которая выбирает, какая реклама выйдет, и считает выходы. Платформа работает под вашим брендом, а код поддерживает вендор.
• Построить свою платформу. Ваша команда или нанятая вами компания строит ad-сервер, подключение к DSP и отчёты. Вам принадлежат код и каждое правило в нём, и эксплуатируете систему вы сами.

Пути можно сочетать: например, вести прямые кампании на собственном ad-сервере, а оставшиеся выходы продавать через SSP.

Когда достаточно продавать через DOOH SSP?

Используйте SSP, если верно большинство из следующего:

• Вы хотите понять, станут ли programmatic-покупатели платить за ваши экраны, прежде чем тратиться на технологии
• Ваша CMS или плееры уже работают с этой SSP, или SSP поможет их подключить
• Programmatic будет заполнять слоты, которые не продаёт ваш отдел продаж
• У вас нет инженеров, чтобы круглосуточно эксплуатировать рекламную платформу

Загвоздка — в контроле. Покупатели находят ваши экраны в маркетплейсе SSP рядом с другими сетями, а цены и сделки работают так, как позволяет её софт.

Когда имеет смысл white-label стек?

Берите его, когда:

• Агентства должны покупать у вашего бренда и вашего отдела продаж, а не на маркетплейсе
• Вам нужны собственные правила для цен, сделок и того, какая реклама может выходить на какой площадке
• Вы можете набрать команду, которая ведёт кампании, но не команду, которая пишет и эксплуатирует рекламный софт

Код арендованный. Новые функции появляются по графику вендора, а лицензионные платежи могут расти вместе с вашим объёмом. Если вы уйдёте, экраны, сделки и аккаунты покупателей, возможно, придётся заново настраивать в другом месте.

Когда собственная платформа оправдана?

Собственная разработка окупается в таких случаях:

• Programmatic приносит большую долю вашей выручки, и комиссии обходятся дороже, чем команда, которая эксплуатировала бы вашу собственную систему
• Вашим экранам нужны правила, которые не могут поддержать вендоры, с которыми вы говорили, например реклама, которая меняется в зависимости от расписания поездов на вокзале
• Вы продаёте и экраны других сетей, поэтому платформа — часть того, что вы продаёте
• Данные об аудитории ваших площадок должны оставаться в ваших собственных системах

На этом пути каждая DSP обычно должна согласиться подключиться к вашей платформе и протестировать ваши запросы на ставку, прежде чем её покупатели увидят ваши экраны. Кто-то должен следить за системой и сверять отчёты с покупателями. К тому же OpenRTB продолжает меняться: с тех пор как в него добавили экраны, IAB Tech Lab выпустила семь обновлений версии 2.6. Если в вашей команде никто не возьмёт эту работу на себя, начните с SSP или white-label стека.

Какая работа остаётся за нашей командой на любом пути?

Вот что решает и поддерживает ваша команда:

• Данные об экранах и площадках: идентификатор, местоположение, размер, часы работы и тип площадки для каждого экрана. Таксономия площадок — это общий список типов площадок, благодаря которому спортзал означает одно и то же для каждого покупателя. Если в запросе не указана другая таксономия, OpenRTB 2.6 исходит из таксономии площадок OpenOOH (OpenOOH Venue Taxonomy). Она распределяет площадки по уровням, например «Retail» (ритейл), а затем «Retail / Malls» (торговые центры).
• Оценки аудитории и их источник: какую ступень лестницы MRC измеряет ваша цифра, кто её измерил и как часто она меняется
• Одобрение креативов и правила для контента: в руководстве IAB Tech Lab сказано, что реклама в крупных коммерческих сетях «должна предварительно одобряться вручную», в некоторых случаях — ещё и арендодателями площадок. Там же предупреждают, что одна неподходящая реклама, показанная «тысячам людей в общественном месте», ставит под угрозу имеющийся у сети «договор/разрешение на показ рекламы». Ведите письменный список того, что разрешает каждый владелец площадки.
• Логи выходов и сверка: ведите собственные логи подтверждения выходов, даже если их собирает SSP. Экраны уходят в офлайн, а дробные значения округляются по-разному, поэтому кто-то должен каждый месяц сверять ваши логи с отчётом каждого покупателя.
• Минимальные цены и прямые сделки: минимальная цена (floor) — это самая низкая ставка, которую вы принимаете, и задаётся она в CPM, как и сами ставки. Сделка private marketplace — это аукцион, открытый только для покупателей, которых вы пригласили. В запросе на ставку такая сделка помечается кодом, который называется deal ID. Решите, что побеждает, когда на один и тот же слот претендуют прямая кампания и programmatic-ставка.

Что проверить до подписания договора с SSP или white-label вендором?

• Кому принадлежат список экранов, данные о площадках и цифры аудитории, которые мы загружаем, и можем ли мы выгрузить их в любой момент?
• Чья цифра аудитории попадает в каждый запрос на ставку и как помечается её источник?
• Какую долю каждой продажи вы оставляете себе и показывают ли наши отчёты и валовую, и чистую сумму?
• Какие DSP подключены сегодня и какие из них покупали выходы DOOH за последние три месяца?
• Можем ли мы продолжать продавать прямые кампании и одновременно работать с другими SSP?
• Кто одобряет каждый креатив и можем ли мы заблокировать рекламу только для одной площадки?
• Что будет, если мы уйдём: какой срок уведомления о расторжении и какие сделки, аккаунты, логи и отчёты мы сможем забрать с собой?

Кому принадлежат код, данные и отношения с покупателями?

SSP владеет своей платформой и своими договорами с DSP. Данные о ваших экранах и аудитории должны оставаться вашими, и это должно быть прописано в договоре. Сделки, настроенные внутри SSP, могут не перейти вместе с вами.

White-label вендор владеет кодом, а бренд — ваш. Проверьте, на чьё имя оформлены аккаунты покупателей и подключения к DSP: на вашу компанию или на вендора.

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

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

Что спросить у компании, которая будет строить нашу платформу для экранов?

• Как платформа будет подключаться к нашей CMS и плеерам и что пойдёт на экране, если реклама не придёт вовремя?
• Как каждый запрос на ставку будет передавать местоположение экрана, тип площадки, аудиторию на один выход и источник этой цифры?
• Как будут записываться подтверждения выходов и сверяться с отчётами покупателей?
• Будут ли покупатели отправлять креативы на одобрение через Ad Management API от IAB Tech Lab — стандарт, который в её руководстве назван «настоятельно рекомендуемым» для DOOH?
• Как будут задаваться минимальные цены и сделки private marketplace для каждого экрана, площадки и часа?
• Какие DSP вы подключите первыми и кто ведёт с ними переговоры?
• Можете показать это в действии в системе, которая работает сегодня?

Где здесь место amBrain?

amBrain ведёт этот блог. Три его собственных утверждения описывают системы, которые сеть строит на третьем пути. Одно звучит так: «amBrain строит supply-side платформы (SSP) для паблишеров». Другое: «amBrain строит ad-серверы: таргетинг, ограничение частоты показов и отчётность». Третье: «amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним». Четвёртое, со стороны покупки, гласит: «RTBBidder, demand-side платформа, которую мы построили для клиента».

amBrain делает софт с 2019 года. О том, как компания работает с клиентами, она говорит: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». До подписания попросите поимённый список этих компонентов.

Эта статья — не кейс. Кроме упоминания RTBBidder, работа для клиентов в ней не описывается. В ней не утверждается, что amBrain строил DOOH-платформу, подключал сеть экранов к SSP или измерял аудиторию для какого-либо клиента. Цен и сроков amBrain в ней тоже нет. Цитаты IAB Tech Lab, таксономии OpenOOH и MRC взяты из их опубликованных документов, и статья не утверждает, что между amBrain и кем-либо из них есть какие-либо отношения.

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