ibiza
CPM · CTR …
/

sellers.json: реестр продавцов SSP и как его проверять

≈ 2 мин чтения · обновлено

В 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. Проверка выглядит так:

  1. ads.txt площадки содержит строку ssp.example, 4815162342, DIRECT — владелец разрешил эту продажу.
  2. sellers.json на ssp.example содержит seller_id 4815162342 с типом PUBLISHER и доменом media.example — система платит владельцу напрямую.
  3. 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?

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