sellers.json

Откуда появился формат

sellers.json возник как дополнение к ads.txt. Последний позволял издателю перечислить уполномоченные каналы продажи показов, но не раскрывал, какие организации стоят за номерами аккаунтов в рекламных системах. Для покупателя оставался вопрос: он взаимодействует с владельцем площадки или с очередным посредником? Эту задачу IAB Tech Lab связал с прозрачностью цепочки продаж. ^[1]

31 июля 2019 года рабочая группа OpenRTB завершила подготовку sellers.json и SupplyChain для внедрения отраслью. В журнале спецификации sellers.json первая версия также датирована июлем 2019 года. ^[1] Вместе документы дали два связанных способа описания сделки: справочник продавцов и последовательность её участников. Это дата стандартизации, а не утверждение, что все рекламные системы начали пользоваться форматом одновременно.

Что находится в файле

JSON расшифровывается как JavaScript Object Notation. В данном случае это текстовый формат, в котором сведения записаны как именованные поля и списки. Рекламная система публикует ресурс по пути /sellers.json; он содержит версию формата и список sellers. Текущая опубликованная спецификация указывает значение версии 1.0. ^[1] Версия статьи и версия формата — разные числа.

В записи обязательны seller_id — строковый идентификатор аккаунта — и seller_type — его тип. Поле name содержит имя организации, получающей оплату. domain означает её деловой домен. При is_confidential=1 имя и домен разрешено не раскрывать; при открытой записи имя обязательно, а домен обязателен, если у продавца есть присутствие в вебе. Саму конфиденциальную запись из списка не исключают. ^[1]

Google отдельно поясняет практический смысл делового домена: это домен организации, который не обязан совпадать с адресом сайта, где показывают рекламу. ^[3] Поэтому проверяющий сначала устанавливает получателя оплаты, а затем сопоставляет его с площадкой. Автоматическая замена корпоративного домена адресом новостного сайта может исказить сведения.

Спецификация IAB различает три значения seller_type. Они описывают аккаунт и характер продаваемого через него инвентаря. ^[1]

Из значения BOTH нельзя выбрать один из двух вариантов для конкретного показа: для этого нужны сведения о самой продаже. Флаг конфиденциальности тоже отвечает на отдельный вопрос — какие сведения раскрыты, а не кому принадлежит площадка.

Как связаны три документа

Представим, что покупатель получил запрос на приобретение рекламного показа. В объекте SupplyChain, который передаётся вместе с запросом, перечислены узлы — участники цепочки. У каждого есть asi, домен рекламной системы, и sid, идентификатор продавца в этой системе. Такой идентификатор должен соответствовать seller_id в её sellers.json. ^{[1, 2]}

Порядок узлов важен. В полной цепочке первым указан исходный участник, связанный с владельцем площадки, а последним — отправитель запроса. Поле complete сообщает, заявлена ли полнота цепочки: 1 означает полную, 0 — неполную. В неполной цепочке первый элемент обозначает первого известного участника. ^[2] Это утверждение отправителя, которое нужно сопоставлять с другими данными.

Удобно разделить проверку на три вопроса:

Таблица — поясняющее сопоставление по двум спецификациям IAB. ^{[1, 2]} Совпадение в одном документе не заменяет ответов на остальные вопросы.

Учебный пример проверки

Пусть в запросе указаны условная рекламная система exchange.example и аккаунт seller-17. В её sellers.json покупатель находит запись с таким идентификатором, названием «Редакция Север» и типом PUBLISHER. Следующий шаг — сопоставить запись с договорными сведениями, разрешёнными продавцами издателя и цепочкой запроса. Пока выполнен только поиск записи, вывод «контрагент полностью проверен» преждевременен.

Если seller-17 встретится в другой системе, поиск нужно выполнить заново. Идентификатор имеет значение внутри своей системы: одна запись не может обозначать несколько получателей оплаты, но один получатель может иметь несколько идентификаторов. ^{[1, 2]} В учебном примере одинаковый текст аккаунта не доказывает связь двух компаний.

Предположим теперь, что имя отсутствует, а is_confidential равно 1. Это повод зафиксировать ограничение публичной идентификации, а не автоматически назвать продавца мошенником. Если же два документа дают противоречащие названия, полезно записать конкретное расхождение и запросить объяснение у партнёра. Так проверка приводит к проверяемому вопросу, а не к оценке по одному признаку.

Международная практика реализации

В Google Ad Manager описаны собственные настройки прозрачности, поля файла Google и способ поиска своей записи по идентификатору. ^[3] Эти инструкции помогают пользователю продукта, но не задают устройство аккаунтов всех рекламных систем.

Другой пример даёт Prebid.js, программное средство для рекламных интеграций. Его документация различает общую цепочку для запросов и настройки для отдельных участников торгов. С версии 10 модуль переносит сведения schain в общий объект данных запроса. Проверку корректности этих данных выполняет отдельный модуль валидации, если он включён в сборку и проверка не отключена. ^[4] Поэтому наличие настройки ещё не доказывает, что проверка включена в конкретной сборке. При внедрении нужны документация используемой версии и проверка фактически сформированного запроса.

Как оценить результат проверки

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

Учебный расчёт. Команда заранее выбрала сто различных пар «рекламная система — аккаунт» и нашла девяносто записей. Покрытие поиска равно числу найденных пар, делённому на число выбранных пар и умноженному на сто процентов: 90 / 100 × 100% = 90%. Десять ненайденных пар остаются отдельными случаями для разбора. Повторные запросы одной пары не должны увеличивать знаменатель этой модели.

Если список пуст, доля не определена: делить на ноль нельзя. Если все записи найдены, покрытие равно 100%, но это всё ещё результат поиска, а не доля качественных или законных рекламных показов. Для оценки показов потребовались бы другие данные и другой знаменатель.

В журнале проверки полезно сохранить время получения и использованную копию файла. Спецификация предусматривает кеширование, то есть временное сохранение данных, и проверку свежести копии. ^[1] Если партнёр исправил запись сегодня, вчерашний файл не показывает результат исправления.

Российский правовой контекст

Части 1, 3 и 5 статьи 18.1 закона №38-ФЗ «О рекламе» предусматривают учёт интернет-рекламы и передачу сведений через операторов рекламных данных для лиц и материалов, подпадающих под норму. Использована редакция закона от 04.08.2026. ^[5] Оператор рекламных данных — участник этой установленной законом процедуры, а не просто рекламная система, опубликовавшая sellers.json.

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

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

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

• ads-txt
• programmatic-guaranteed
• ssp-platforma-prodavtsa
• programmatic
• erir