sellers.json: реестр продавцов SSP и как его проверять
В sellers.json рекламная система — SSP, биржа или сеть — раскрывает, кому она платит за инвентарь, проданный через нее. Каждая запись связывает seller_id с юридическим лицом, его доменом и ролью: владелец площадки, посредник или и то и другое. Файл лежит на домене системы и открыт всем, так что покупатель узнает, кто стоит за идентификатором в запросе ставки.
Пример файла
Стандарт версии 1.0 вышел в июле 2019 года. Файл размещают в корне домена рекламной системы: https://ssp.example/sellers.json.
{
"version": "1.0",
"contact_email": "adops@ssp.example",
"sellers": [
{ "seller_id": "4815162342", "name": "ООО «Пример Медиа»",
"domain": "media.example", "seller_type": "PUBLISHER" },
{ "seller_id": "pub-0099", "name": "Reseller Example Ltd",
"domain": "reseller.example", "seller_type": "INTERMEDIARY" },
{ "seller_id": "77", "is_confidential": 1, "seller_type": "PUBLISHER" }
]
}
Три типа продавцов
seller_type |
Кто это |
|---|---|
PUBLISHER |
Площадка принадлежит названной компании, система платит ей напрямую |
INTERMEDIARY |
Инвентарь не принадлежит компании или система платит не ей напрямую: посредник, перепродавец |
BOTH |
Через аккаунт идет и собственный, и чужой инвентарь |
У посредника поле domain указывает на корневой домен его собственного sellers.json. По нему покупатель переходит к следующему звену и проверяет, у кого посредник купил показ.
Как один ID связывает три стандарта
Пусть в запросе ставки пришел аккаунт 4815162342 системы ssp.example. Проверка выглядит так:
- ads.txt площадки содержит строку
ssp.example, 4815162342, DIRECT— владелец разрешил эту продажу. - sellers.json на
ssp.exampleсодержитseller_id4815162342с типомPUBLISHERи доменомmedia.example— система платит владельцу напрямую. - schain в запросе начинается с узла
asi: ssp.example,sid: 4815162342— путь показа начинается там же.
Совпали все три — цепочка подтверждена. На практике покупатели ожидают, что DIRECT в ads.txt соответствует PUBLISHER или BOTH, а RESELLER — INTERMEDIARY или BOTH. Это отраслевое правило проверки, а не требование спецификаций IAB. Расхождение — повод разобраться до закупки, а не после.
Ads.txt версии 1.1 добавил переменную OWNERDOMAIN: ее значение должно совпадать с domain в записях этого паблишера в sellers.json систем, через которые он продается.
Что проверяет покупатель
- запись с нужным
seller_idвообще есть; - имя и домен продавца не скрыты и похожи на правду: у
PUBLISHERдомен совпадает с сайтом или разработчиком приложения; - у посредников есть свой sellers.json, и цепочку можно пройти до владельца площадки.
Отсутствующий seller_id — один из признаков перепродажи без разрешения и других видов рекламного фрода.
sellers.json биржи Ibiza
Биржа Ibiza публикует sellers.json по стандарту IAB. Каждая активная площадка, подключенная напрямую, получает запись PUBLISHER с собственным seller_id. Внешние источники, чей трафик биржа перепродает, записаны как INTERMEDIARY. Эти же ID биржа ставит в sid своего узла schain — порядок подключения описан в документации для SSP.
Частые вопросы
Чем sellers.json отличается от ads.txt?
ads.txt публикует владелец площадки: кому он разрешил продавать. sellers.json публикует рекламная система: кому она платит за проданный инвентарь. Вместе они подтверждают одну связь с двух сторон.
Кто должен публиковать sellers.json?
По спецификации IAB Tech Lab — каждая рекламная система, которая упомянута в чьем-то ads.txt или в цепочке schain: SSP, биржи, рекламные сети. Это отраслевой стандарт, а не требование закона.
Что значит is_confidential: 1?
Продавец скрыт: имени и домена в записи нет. Так защищают, например, частных лиц. Проверить такого продавца покупатель не сможет, поэтому много скрытых записей снижает прозрачность источника.