SSP (платформа продавца)

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

Английское supply-side означает сторону предложения. Для SSP это сторона владельца рекламного места. Такое распределение ролей отражено и в профессиональном руководстве IAB Digital Media Sales Certification: в нём отдельно описаны SSP, платформы покупателей, рекламные биржи и сети. Руководство полезно как историческое свидетельство закрепившейся терминологии, но не устанавливает автора аббревиатуры или дату её первого употребления. ^[6]

Одна из конкретных вех развития способов подключения покупателей — запуск Prebid.js в 2015 году. Разработчики создали общий открытый программный слой для header bidding: получения предложений нескольких участников до окончательного выбора рекламы. Эта дата относится к проекту Prebid.js, а не к возникновению всех SSP. ^[3]

В России Яндекс 3 октября 2024 года объявил о переходе своей SSP на Open Bidding для DSP-партнёров. В сообщении последовательный вызов партнёров сопоставлен с их участием в едином аукционе. Речь шла о доступе к инвентарю через SDK Яндекса — программный компонент, который встраивают в приложение. Это исторический пример изменения конкретной системы, а не описание обязательного устройства любой SSP. ^[7]

Суть и механизм

Что происходит с рекламным местом

Представим учебную ситуацию: читатель открывает новость, рядом с которой предусмотрено место для баннера. У владельца сайта есть возможность показать там рекламу. Чтобы предложить её покупателям, система площадки передаёт запрос SSP. Та обращается к DSP — системам, которые делают ставки от имени рекламодателей. В описании IAB Tech Lab SSP затем либо определяет объявление на своём аукционе, либо возвращает ставку системе header bidding издателя. Поэтому победа внутри одной SSP ещё не обязательно означает окончательный выбор рекламы на странице. ^[1]

В этой упрощённой модели удобно разделить три вопроса. Первый: кому предложили место? Второй: какое предложение выбрали? Третий: была ли реклама доставлена и какой доход учли? Они связаны, но ответ на первый вопрос не заменяет два остальных. Например, получить приглашение к торгам и действительно предложить цену — разные действия; ниже это различие видно в документации отчётных полей Google. ^[4]

Кто за что отвечает

В таблице приведено функциональное различение из учебного руководства IAB. Оно помогает понять сделку, даже если при обсуждении конкретного продукта встречается сразу несколько названий. ^[6]

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

Виды и классификации

Удобнее классифицировать способы подключения, чем делить все SSP на несколько жёстких типов. Следующая группировка — редакционная схема чтения документации; её основания взяты из описаний IAB Tech Lab, Prebid и Яндекса. ^{[1, 3, 8]}

Первое различие — откуда приходит запрос: непосредственно от площадки или от её системы сбора ставок. Второе — что возвращает SSP: выбранное объявление или предложение для дальнейшего сравнения. Эти признаки относятся к разным этапам работы. Зная только источник запроса, нельзя автоматически определить, где будет сделан окончательный выбор. ^[1]

Третье различие — где работает программный компонент интеграции. В документации Prebid.js описан как библиотека JavaScript в браузере, а Prebid Server — как серверное решение для header bidding. Перенос части обращений на сервер меняет распределение работы между браузером и сервером; это характеристика способа подключения, а не самостоятельный источник рекламных бюджетов. ^[3]

Четвёртое различие — среда размещения. Глоссарий Рекламной сети Яндекса относит SSP к системам на стороне владельцев сайтов, мобильных приложений и приложений Smart TV. Следовательно, термин не ограничивается баннером на настольном сайте. При разборе продукта среду нужно назвать явно: схема для веб-страницы не описывает автоматически интеграцию внутри приложения. ^[8]

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

Несколько каналов продажи в Adfox

Документация Adfox описывает управление монетизацией от уровня аккаунта до отдельной площадки. В разделе доступны настройки Рекламной сети Яндекса, внешних монетизаторов и конфигурации Header Bidding. Это конкретный пример того, как издатель организует несколько способов продажи вокруг своего инвентаря. ^[9]

Издателю полезно рассматривать такое подключение через задачу, которую оно решает. В учебной ситуации один рекламный блок уже получает предложения через канал A; к нему добавляют канал B. Вопрос состоит не только в том, появился ли B в настройках. Нужно установить, поступают ли от него предложения, участвуют ли они в выборе и меняется ли итоговый доход на сопоставимом объёме. Разбор этих событий позволяет отличить технически выполненное подключение от его экономического результата.

Полномочия продавца и путь предложения

Для проверки цепочки продажи применяются разные инструменты IAB Tech Lab. Файл ads.txt позволяет владельцу сайта публично указать уполномоченных продавцов. Его задача — раскрыть разрешённые пути продажи инвентаря. Текущая страница проекта ссылается на спецификацию версии 1.1. ^[10]

Файл sellers.json публикует рекламная система: он связывает идентификаторы продавцов с информацией о них. Это помогает понять, кто стоит за учётной записью в цепочке. Однако спецификация допускает конфиденциальные записи, в которых имя организации может отсутствовать; обещать полное раскрытие всех участников по одному наличию файла было бы неверно. ^[11]

Объект SupplyChain передаёт сведения об участниках продажи конкретного рекламного запроса. Вместе эти механизмы позволяют сопоставить разрешение площадки, сведения о продавце и путь предложения. Они решают разные задачи, поэтому один файл не заменяет остальные. ^[12]

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

Как измерить или проверить

Сначала определить, какие события посчитаны

В Google Ad Manager для Open Bidding различаются обращения к партнёрам, успешные ответы, полученные ставки, ставки в аукционе, победы и показы. Успешный ответ может содержать отказ от ставки. Число ставок способно превышать число обращений: один покупатель может вернуть несколько предложений. Некоторые ставки не допускаются до аукциона, например из-за отсутствующих обязательных полей. ^[4]

Поэтому ряд этих показателей нельзя безусловно рисовать как сужающуюся воронку. Сначала нужно выяснить, что является единицей счёта в каждой колонке: запрос, ответ или отдельная ставка. Нельзя также подставлять любое число показов в показатель с привычным названием. Например, в глоссарии Яндекса Fill rate означает долю подборов рекламы среди запросов, а не долю любых зарегистрированных показов. ^[8]

Учебный пример. Допустим, каждому запросу соответствует не более одной ставки. Отправлено 10 000 запросов, получено 8000 ответов; 3000 ответов содержали ставку, допущенную к торгам, и 600 ставок победили. В рамках этих условий доля ответов равна 80%, доля запросов с допустимой ставкой — 30%, а доля побед среди допустимых ставок — 20%.

Общая формула каждого процента — число выбранных событий, делённое на размер соответствующей базы и умноженное на сто. Для последнего показателя база равна 3000 ставкам. Если вместо неё взять 8000 ответов, получится 7,5% — доля побед относительно ответов. Арифметика верна в обоих случаях, но смысл разный. Если допустимых ставок вообще нет, доля побед среди них не определена: делить на ноль нельзя, и нулём такой результат подменять не следует.

Сравнить доход на одинаковой базе

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

Здесь D — доход издателя в рублях после одинакового для обоих вариантов набора удержаний, N — число исходных возможностей, а результат измеряется в рублях на тысячу возможностей. Это определённый для примера показатель: название в рекламном кабинете может быть другим. Для N требуется положительное значение.

Учебный пример. В каждом варианте есть 100 000 исходных возможностей. В A получено 80 000 оплачиваемых показов и 8000 рублей дохода. В B — 60 000 показов и 9000 рублей. Доход на тысячу исходных возможностей составляет соответственно 80 и 90 рублей. В B оплачена меньшая часть исходного объёма, но доход на общей базе выше на 10 рублей, или на 12,5% относительно A.

Для проверки можно выполнить второй расчёт. На тысячу оплаченных показов приходится 100 рублей в A и 150 рублей в B. Умножение этих величин на долю оплаченных возможностей — 0,8 и 0,6 — возвращает 80 и 90 рублей. Так видно, почему одной высокой доли заполнения недостаточно для вывода о выручке. Все суммы и доли здесь придуманы для объяснения, а не взяты из отчёта рекламной платформы.

Учесть состав трафика и минимальную цену

Даже одинаковое число запросов не делает два периода полностью сопоставимыми. Это показывает ещё один учебный пример. Пусть в разделе «Спорт» доход на тысячу возможностей равен 100 рублям, а в разделе «Культура» — 40 рублям. В первом периоде из 100 000 возможностей по половине приходится на каждый раздел: доход составляет 5000 плюс 2000, всего 7000 рублей.

Во втором периоде «Спорт» даёт 25 000 возможностей, а «Культура» — 75 000. При неизменной доходности каждого раздела получается 2500 плюс 3000, всего 5500 рублей. Общая сумма уменьшилась на 1500 рублей исключительно из-за изменения пропорций в этой модели. Приписывать это снижение новой SSP было бы ошибкой. Сначала нужно сравнить одинаковые части предложения и выяснить, что именно изменилось внутри них.

Ещё один параметр — минимальная цена, ниже которой предложение не принимается. Google предупреждает: чрезмерно высокий порог создаёт риск незаполненных возможностей, а слишком низкий позволяет покупателям выигрывать с меньшими ставками. Это объясняет компромисс, но не задаёт оптимальную цену для другой платформы. ^[5]

Ошибки, ограничения и спорные вопросы

Количество подключений само по себе не измеряет разнообразие покупателей. В учебной модели один покупатель может быть доступен через A и B. Два пути в этом случае не превращают его в двух покупателей. Поэтому вывод о новом спросе требует сведений о составе участников, а не только списка подключённых систем.

Столь же важно различать цену предложения и доход площадки. В модели можно назначить ставку в 120 рублей за тысячу показов, но доход после условного удержания 20% составит 96 рублей. Сравнение 120 рублей до удержания с 110 рублями после удержания даст ложный порядок предпочтений: 110 больше 96. Это пример арифметической ошибки, а не утверждение о комиссии какой-либо SSP.

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

Наконец, инструменты прозрачности подтверждают сведения о продаже в пределах своей задачи. Из разрешения в ads.txt не следует, что посетитель увидел объявление, а из сведений о продавце — что площадка получила определённый доход. Эти результаты проверяют по соответствующим событиям и расчётам, не подменяя их проверкой файла. ^{[10, 11]}

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

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

• DSP (платформа покупателя)
• Рекламная биржа
• Рекламный инвентарь
• Header bidding
• ads.txt
• sellers.json
• Рекламный сервер