Sell-side (сторона продавца рекламы)

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

Буквально sell side означает «сторона продажи». В рекламе это удобный способ рассматривать сделку со стороны тех, кто предлагает размещение. Единственный автор и дата появления термина в использованных документах не установлены. Даты появления отдельных технологий поэтому не следует принимать за день рождения самой роли продавца.

Документированная история инструментов включает несколько вех. По истории Prebid, библиотека Prebid.js появилась в 2015 году как совместная разработка компаний рекламных технологий. Она помогла издателям организовать header bidding — получение предложений от нескольких покупателей или их технологических партнёров перед выбором рекламы. ^[3] Первая версия ads.txt вышла в июне 2017 года, а sellers.json версии 1.0 — в июле 2019 года. ^{[1, 2]}

Эти документы решают разные задачи: Prebid описывает получение ставок, а стандарты IAB — прозрачность участников продажи. На дату проверки IAB направляет к спецификациям в своём репозитории GitHub; опубликованные там документы обозначены как sellers.json 1.0 и ads.txt 1.1. Последняя из этих версий добавила сведения о доменах владельца и управляющего монетизацией. ^{[1, 2, 10]}

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

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

Если издатель поручает продажу другой компании, возникает посредник. Право участвовать в продаже не означает, что посреднику принадлежит сайт. В sellers.json эти роли разделяются; Google также различает монетизацию собственного и чужого инвентаря. ^{[1, 4]} Это позволяет сформулировать два разных вопроса: «Кому принадлежит площадка?» и «Кто представляет её показы в данной рекламной системе?» Ответы могут указывать на разные организации.

Техническое обслуживание размещения выполняет рекламный сервер. На примере Google Ad Manager видно, что выбор объявления зависит не только от цены: учитываются тип и приоритет позиции заказа — line item, то есть набора условий доставки рекламы. У гарантированной позиции Standard задаются объём показов и сроки; у Sponsorship — доля показов и сроки. ^[5] Таким образом, уже принятые обязательства входят в задачу распределения рекламы.

Для получения нескольких предложений издатель может использовать Prebid.js. Эта библиотека отправляет запросы выбранным участникам параллельно и ждёт их до установленного предела времени. Опоздавшая ставка в аукцион не попадает. Ожидание имеет цену: посетитель может уйти раньше показа рекламы. Поэтому увеличение числа подключённых партнёров создаёт компромисс между конкуренцией и задержкой, который прямо описан в документации Prebid. ^[3]

В нашем учебном случае это означает следующее: обещанные покупателю показы нужно сопоставлять с тем, что действительно доставлено, а возможности новых партнёров — с условиями уже принятой кампании. Даже дорогая отдельная ставка не отвечает на вопрос, исполнен ли недельный заказ. Sell-side объединяет эти коммерческие и технические решения; название одной SSP рассказывает только о части схемы.

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

Полезно разделять классификацию участников и классификацию сделок. В справке Google для sellers.json предусмотрены три значения типа продавца. PUBLISHER монетизирует собственный инвентарь и получает выплату непосредственно от Google. INTERMEDIARY монетизирует чужой инвентарь либо не получает прямой выплаты Google. BOTH совмещает собственный и сторонний инвентарь. Это правила конкретного поля Google, а не юридические определения для всех стран. ^[4]

Ниже — учебная редакционная группировка вопросов, а не ещё один отраслевой стандарт.

Эти признаки нельзя свести к выбору «прямые продажи или технологии». Google описывает непосредственно проданные кампании внутри рекламного сервера. ^[5] В Adfox перечислены прямые продажи, собственные промокампании, Рекламная сеть Яндекса — РСЯ — и внешние сети. ^[6] Прямой договор описывает отношения сторон; программное обеспечение описывает способ исполнения. Один признак не исключает другой.

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

Международная и российская документация показывают, как в одной работе встречаются договорённости о размещении и техническое управление. Google Ad Manager объясняет типы доставки, Adfox — работу с несколькими источниками рекламы. Следующая таблица сопоставляет только эти документированные возможности, без вывода об одинаковых аукционах или результатах. ^{[5, 6]}

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

В карточке сделки команда также разделяет площадку и компанию, которая получает деньги. Это согласуется с пояснением Google: business domain в sellers.json относится к организации и не обязательно совпадает с доменом сайта, где показывается реклама. ^[4] В учебной карточке поэтому будут отдельные поля «сайт показа» и «компания продавца». Разные адреса в них сами по себе ещё не означают ошибку.

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

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

Один из показателей продавца — eCPM, эффективный доход на тысячу показов. Например, Google рассчитывает Ad server average eCPM через доход от обслуженных сервером объявлений и соответствующие показы, умножая отношение на тысячу. Состав включаемого дохода зависит от выбранной метрики и настроек отчёта. ^[9] Для собственного расчёта нужно явно назвать числитель, знаменатель, валюту и период.

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

Учебный расчёт: два канала одной площадки

Все числа ниже придуманы для объяснения. За одну неделю сайт засчитал 300 000 оплачиваемых показов. Из них 100 000 пришлись на прямую кампанию по 120 рублей за тысячу. Остальные 200 000 проданы через партнёра по 80 рублей за тысячу до удержания его вознаграждения. По условиям примера партнёр удерживает 25% только своей суммы; у прямой кампании такого удержания нет. Налоги, обязательные отчисления и прочие расходы здесь не моделируются.

Прямое размещение даёт 12 000 рублей: сто тысяч показов составляют сто пакетов по тысяче показов, каждый по 120 рублей. По партнёрскому каналу начислено 16 000 рублей. Четверть этой суммы, 4 000 рублей, составляет удержание; площадке остаётся 12 000 рублей. Итого учитываемый доход сайта после заданного удержания — 24 000 рублей.

Эти 80 рублей — средний результат для всех оплачиваемых показов в примере. Партнёрский канал после удержания приносит 60 рублей на тысячу, прямой — 120. Простое среднее двух ставок дало бы 90 рублей, но это ошибочный итог: объёмы каналов различаются. Общий показатель учитывает, что через партнёра прошло вдвое больше показов.

Теперь предположим, что за ту же неделю сайт зарегистрировал ещё 100 000 запросов, которые не завершились учитываемым оплачиваемым показом. По дополнительному условию примера каждому из 300 000 оплачиваемых показов соответствует ровно один запрос; всего запросов получается 400 000. Доход на тысячу таких запросов составит 60 рублей. Это другой показатель с другим знаменателем. Он не опровергает результат 80 рублей на тысячу показов: оба числа правильно описывают разные события одной учебной недели.

Сумма 24 000 рублей также не означает автоматически, что столько денег уже поступило на банковский счёт. В модели это начисленный доход после одного заданного вычета. Если выплата состоится позже, дата денежного поступления будет другой. Поэтому подпись «доход» без пояснения не позволяет отличить начисление за неделю от выплаты в течение недели.

Что проверяют файлы прозрачности

В ads.txt владелец площадки публикует разрешённые аккаунты рекламных систем. Значение DIRECT указывает на прямой контроль издателем указанного аккаунта; RESELLER — на разрешение другой организации управлять аккаунтом и перепродавать размещения. DIRECT здесь не означает, что конкретный рекламодатель заключил прямой договор с издателем. ^[10]

sellers.json рекламной системы помогает связать идентификатор аккаунта со сведениями о продавце; вместе с объектом SupplyChain в запросе он позволяет раскрывать участников цепочки. ^[1] Из назначения этих документов следует ограничение: проверка разрешений и идентичности не заменяет проверку фактических показов или расчётов. В учебной сверке успешное совпадение идентификаторов не является доказательством поступления 24 000 рублей.

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

Смешение sell-side и SSP скрывает часть работы издателя: в нашем примере согласование недельного объёма и сверка оплаты остаются отдельными задачами, каким бы способом ни собирались ставки. IAB UK определяет SSP именно как технологическую платформу для поставщиков рекламы. ^[8] Поэтому описание технологии полезно дополнять описанием участников сделки.

Другая ошибка — выбирать решение по самому высокому eCPM. Рассмотрим ещё одно чисто арифметическое сравнение. При 300 000 показов и 80 рублях на тысячу доход равен 24 000 рублей. При 200 000 показов и 100 рублях на тысячу он равен 20 000 рублей. Ставка выросла, сумма уменьшилась на 4 000 рублей. Это не исследование причин падения показов и не оценка реального партнёра; пример показывает, почему одного отношения недостаточно.

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

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

Для интернет-рекламы в России применима статья 18.1 закона № 38-ФЗ «О рекламе», в редакции от 04.08.2026, действующей с 01.09.2026. Её часть 16 требует пометку «реклама» и указание на рекламодателя и (или) сайт либо страницу с информацией о нём. В этой части предусмотрено исключение для рекламы в теле- и радиопрограммах и передачах, распространяемых через интернет. ^[7]

Часть 17 связывает распространение рекламы и социальной рекламы с присвоением соответствующего идентификатора оператором рекламных данных. Исключение из части 16 не следует автоматически переносить в часть 17. ^[7] Первоначальная статья 18.1 введена с 01.09.2022; используемая поправка, включившая социальную рекламу в часть 17, действует с 01.03.2025. ^{[11, 12]}

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

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

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

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