Своя SSP: когда хватит Prebid Server или арендованной SSP и кто может её построить

SSP, или supply-side платформа, — это софт, который предлагает рекламные места паблишера сразу многим покупателям и платит паблишеру за то, что продано. Паблишеру, который продаёт рекламные места только на собственных сайтах или в приложениях, строить свою SSP нужно редко. Он может продавать через существующие SSP и проводить собственный аукцион между ними с помощью Prebid Server — open-source программы. Своя SSP имеет смысл, когда продажа рекламных мест других паблишеров и есть ваш бизнес. Но даже тогда арендованной SSP может хватать, пока при вашем объёме её плата не станет слишком высокой или вашим паблишерам не понадобится то, чего она не умеет. Если строите, нанимайте компанию, которая передаст вам код и настроит SSP под доменом и названием вашей компании.

Что SSP делает для паблишера?

Страница или приложение паблишера отправляет рекламный запрос каждый раз, когда нужно заполнить рекламное место. SSP превращает этот запрос в запросы на ставку для demand-side платформ (DSP) — софта, через который рекламодатели покупают рекламные места. Она собирает их ставки, выбирает победителя и записывает продажу, чтобы потом расплатиться с паблишером. Паблишер также задаёт в SSP правила, например самую низкую цену, на которую он согласен (её называют floor), и виды рекламы, которые он не принимает.

У каждого аукциона есть дедлайн. IAB Tech Lab, некоммерческая организация, которая разрабатывает технические стандарты цифровой рекламы, публикует OpenRTB — стандарт запросов на ставку. Версия 2.6 (по состоянию на 23 октября 2026 года) определяет поле tmax как «максимальное время в миллисекундах, которое биржа отводит на получение ставок с учётом задержки в интернете, чтобы избежать таймаута». Ставка, пришедшая позже, считается так, будто ставки не было.

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

Хватит ли паблишеру Prebid Server?

Prebid Server может быть достаточно паблишеру, который продаёт только собственные рекламные места, если его эксплуатирует команда паблишера или хостинг-провайдер. Prebid Server создан для header bidding. При header bidding паблишер запрашивает ставки сразу у нескольких SSP и рекламных бирж, прежде чем его ad-сервер решит, какую рекламу показать. Рекламная биржа проводит аукционы за рекламные места примерно так же, как SSP.

На обзорной странице Prebid.org (по состоянию на тот же день) сказано: «Prebid Server — это open-source решение для server-to-server header bidding». По данным страницы, существует «230+ серверных бид-адаптеров» — готовых подключений к источникам ставок, таким как SSP и биржи.

Согласно той же странице, Prebid Server проверяет каждый входящий запрос, применяет правила приватности и вызывает бид-адаптеры. Когда они ответили или «истёк период таймаута», он отправляет свой ответ туда, откуда пришёл запрос, например на веб-страницу или в приложение.

С Prebid Server паблишер проводит аукцион между SSP и биржами, с которыми работает, обычно без собственных договоров с DSP. Каждая SSP по-прежнему платит паблишеру за проданные ею рекламные места, а большинство подключений к DSP остаётся за SSP.

Обзорная страница описывает два типичных сценария: «Технически подкованные паблишеры» и «Провайдеры управляемых услуг: для всех остальных». В ней сказано: «Инструментов настройки open-source сообщество не предоставляет». Ещё страница предупреждает, что установить Prebid Server «далеко не так просто, как Prebid.js», а Prebid.js — это код Prebid для header bidding, который работает в браузере посетителя.

Код prebid-server на GitHub (по состоянию на тот же день) опубликован под Apache License 2.0 — лицензией с открытым исходным кодом. Она позволяет любому использовать и изменять код, в том числе в коммерческих целях. Паблишер может запускать его на собственных серверах или воспользоваться услугами провайдера, который его хостит. Обзорная страница говорит, что хостинг-провайдеры также «предоставляют инструменты для управления stored requests».

Когда нам стоит строить собственную SSP?

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

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

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

Что даёт аренда SSP и что остаётся у вендора?

Аренда означает, что софт эксплуатирует вендор, а вы пользуетесь им по договору, иногда под собственным брендом. Epom, вендор ad-серверов, продаёт свой модуль SSP как дополнение к тарифам ad-сервера. На странице цен Epom (по состоянию на тот же день) тарифы начинаются от 250 долларов в месяц, а «SSP module» стоит «0,001 доллара за 1000 ext.reqs». Модуль позволяет «подключать собственные эндпоинты DSP». Ещё одно дополнение, «White-label solution» за 250 долларов в месяц, позволяет «использовать название, логотип и домен вашей компании вместо стандартных».

Арендованный продукт с вашим брендом всё равно принадлежит вендору. В условиях использования Epom Server (Epom Server Terms and Conditions) по состоянию на тот же день сказано: «Настоящее Соглашение не является продажей и не передаёт никаких прав собственности на Программное обеспечение». В тех же условиях сказано, что клиенту принадлежат его «Данные аккаунта» (Account Data) — сведения об использовании и характер трафика, которые возникают, когда клиент работает с софтом, — и что «все Данные аккаунта удаляются из Программного обеспечения в течение тридцати (30) дней после непродления или досрочного прекращения». Спланируйте выгрузку своих данных до того, как закончится договор.

Другие вендоры пишут договоры по-своему, поэтому прочитайте раздел о праве собственности, прежде чем сравнивать цены. Цены за запрос зависят от того, что вендор считает запросом, а на странице Epom не определено, что такое «ext.reqs». Попросите это определение в письменном виде и спросите, какой домен ваши паблишеры будут указывать как продавца своих рекламных мест.

Какие файлы сообщают покупателям, кто продаёт рекламные места?

Прежде чем делать ставку, покупатели проверяют, откуда взялось рекламное место. Паблишер перечисляет все системы, которым разрешено продавать его рекламные места, в файле ads.txt на собственном сайте. Для приложений есть парный файл — app-ads.txt. Версия 1.1 спецификации ads.txt (по состоянию на тот же день) определяет первое поле каждой строки как «каноническое доменное имя системы (SSP, биржи, header wrapper и т. п.), к которой подключаются биддеры».

Третье поле строки ads.txt показывает, работает ли паблишер с этой системой напрямую. Спецификация говорит, что «DIRECT» означает: паблишер «напрямую управляет аккаунтом», указанным в строке. Там же добавлено, что это «как правило, означает прямой коммерческий договор между паблишером и рекламной системой».

SSP публикует файл sellers.json, в котором названы все продавцы, чьи рекламные места она продаёт. В версии 1.0 спецификации sellers.json от июля 2019 года (по состоянию на тот же день) сказано: «Рекламным системам следует размещать файл sellers.json на своём корневом домене и, при необходимости, на любых поддоменах».

В файле должны быть перечислены все продавцы: «Все продавцы должны быть включены, даже если они конфиденциальны». Каждый идентификатор продавца обозначает одну компанию. Как сказано в спецификации, «каждый seller_id должен соответствовать только одной организации, которой платят за инвентарь, проданный с этим seller_id».

Домен SSP может появляться и в запросах на ставку. OpenRTB 2.6 рекомендует передавать в каждом запросе на ставку объект SupplyChain — список компаний, которые участвуют в продаже рекламного места и получают оплату по пути; этот список может быть помечен как неполный. Его поле asi определено теми же словами, что и первое поле строки ads.txt: домен системы, к которой подключаются биддеры.

Для рекламных мест, которые показывают людям в ЕС, нужно учесть ещё один фреймворк. IAB Europe, отраслевая организация рекламного рынка, ведёт Transparency and Consent Framework (TCF), который передаёт выбор каждого человека в отношении приватности, например согласие, с сайта или из приложения паблишера AdTech-компаниям. IAB Europe называет TCF «добровольным стандартом». На её странице для вендоров (по состоянию на тот же день) сказано, что вендорами «могут быть ad-серверы, провайдеры измерений, рекламные агентства, DSP, SSP и другие». Там же добавлено: «Чтобы участвовать в TCF, вендоры должны зарегистрироваться».

Чем мы должны владеть, когда SSP построена?

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

• Домен, который указан в строках ads.txt ваших паблишеров и в поле asi, — зарегистрированный на вашу компанию
• Файл sellers.json на этом домене и перечисленные в нём идентификаторы продавцов
• Договоры с каждой DSP, подписанные вашей компанией, а не исполнителем
• Регистрация вендора в TCF на имя вашей компании, если ваша SSP участвует в TCF
• Репозитории кода, скрипты сборки и облачные аккаунты, открытые на вашу компанию
• Логи и отчёты — с проверенным способом их выгрузки

Домен обычно труднее всего поменять потом. Новый домен означает новую строку в файле ads.txt каждого паблишера. Пока паблишер не добавит эту строку, покупатели, которые проверяют ads.txt, могут считать продажи его рекламных мест через вашу SSP неавторизованными.

Попросите исполнителя назвать каждую часть его собственного или стороннего кода, которая остаётся вне вашей собственности, с лицензией на каждую часть. Open-source код внутри SSP, например Prebid Server, сохраняет собственную лицензию. Формулировки договора в целом разбирает статья о том, как проверить выделенную команду и оставить код своим.

Как проверить компанию, которая предлагает построить нашу SSP?

Общие проверки для любого AdTech-подрядчика описаны в статье о том, строить, лицензировать или арендовать DSP или рекламную биржу. Разработка SSP добавляет ещё шесть вопросов:

• Какая из построенных вами SSP или бирж работает сегодня? Какие DSP покупают через неё?
• Можете показать нам запрос на ставку, который отправила ваша система, с заполненным объектом SupplyChain?
• Что происходит со ставкой, которая пришла после tmax, и как паблишер видит, сколько ставок опоздало?
• Как вы сверяете свой подсчёт показанных объявлений с подсчётом каждой DSP, прежде чем кому-либо выставят счёт?
• Кто добавляет нового паблишера в sellers.json и сколько времени занимает это изменение?
• Какие компоненты остаются вашими после передачи?

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

Больше всего времени уделите вопросам о подсчётах, потому что паблишерам платят по цифрам SSP. Где расходятся два набора подсчётов, объясняет статья о расхождениях отчётов с логами биддера.

Сколько будет стоить построить или арендовать SSP?

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

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

Аренда превращает большую часть этих затрат в плату вендору, например в плату за тариф Epom и его цену за 1000 «ext.reqs». Сравните оба варианта при том объёме, который ожидаете через два года. Учтите и стоимость ухода — например, новые строки в ads.txt у каждого паблишера, если домен принадлежит вендору.

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

В списке услуг amBrain есть такая строка: «amBrain строит supply-side платформы (SSP) для паблишеров». В AdTech amBrain также занимается разработкой DSP, платформ real-time bidding и рекламных бирж. RTBBidder — demand-side платформа, которую amBrain построил для клиента.

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

Эта статья — не кейс, и работа для клиентов в ней не описывается. RTBBidder назван только как DSP, которую построил amBrain, и никаких цифр о нём статья не приводит.

Prebid.org, IAB Tech Lab, IAB Europe и Epom приведены как примеры по их собственным страницам, и статья не утверждает, что между amBrain и кем-либо из них есть какие-либо отношения. Цен и сроков amBrain статья не приводит. Это и не юридическая консультация: правила о согласиях и данных различаются по странам, поэтому проверяйте их у юриста.