Что ads.txt и sellers.json говорят о продавцах и посредниках и чего не доказывают?

Что записано в ads.txt и app-ads.txt?

IAB Tech Lab разработала спецификацию ads.txt в 2017 году, действующая версия 1.1 принята в июле 2022 года. Файл лежит по адресу /ads.txt на корневом домене сайта, и каждая строка продавца описывает одно разрешение:

Кроме строк продавцов, в файле бывают переменные. CONTACT даёт контакт владельца файла, SUBDOMAIN отсылает к поддомену со своим списком, INVENTORYPARTNERDOMAIN указывает домен партнёра, которому принадлежит часть рекламных мест на сайте или в приложении, обычно владельца показанного там контента: эту переменную добавили ради CTV, рекламы на подключённых телевизорах, и похожих случаев. Версия 1.1 ввела OWNERDOMAIN, бизнес-домен компании-владельца сайта, и MANAGERDOMAIN, домен основного или эксклюзивного партнёра по монетизации, если владелец не продаёт инвентарь сам; его можно задать для отдельной страны.

Отсутствие файла не означает запрета. При ответе 404 система, по спецификации, может считать, что неавторизованных продавцов у сайта нет. Сайт, который не разрешает продажу никому, публикует строку-заглушку placeholder.example.com, placeholder, DIRECT, placeholder: пустой файл с 1 марта 2020 года системы должны игнорировать.

Файл app-ads.txt устроен так же, но для приложений из мобильных и телевизионных магазинов. Его размещают на сайте разработчика, адрес которого записан в карточке приложения в магазине. Проверяющая система берёт ссылку на магазин из прошлых запросов, находит по карточке сайт разработчика и сравнивает идентификаторы приложения из карточки (bundle ID и ID в магазине) с теми, что пришли в запросе; переменная SUBDOMAIN в app-ads.txt не действует.

Что значат DIRECT и RESELLER?

DIRECT по спецификации значит, что аккаунтом из второго поля в системе из первого поля управляет сам владелец контента; обычно за этим стоит прямой договор площадки с рекламной системой. RESELLER значит, что владелец разрешил другой компании управлять этим аккаунтом и перепродавать свои рекламные места через эту систему. Справки Рекламной сети Яндекса и Рекламной сети VK для партнёров объясняют то же по-русски: DIRECT для сетей, с которыми площадка работает напрямую, RESELLER для посредников.

Из определений следуют три правила чтения:

• разрешение выдано паре «система и ID», а не компании вообще: строка с той же системой, но с другим ID продажу через этот аккаунт не разрешает;
• RESELLER не признак фрода, а объявленный посредник, и каждый такой посредник добавляет звено между площадкой и покупателем;
• пометку ставит владелец сайта, а кто стоит за аккаунтом, ads.txt не раскрывает: для этого есть sellers.json.

Что показывает sellers.json?

Этот файл рекламная система выкладывает по адресу /sellers.json на своём корневом домене. По спецификации 1.0 (июль 2019 года) его должна выложить каждая система, которая упомянута в чьём-либо ads.txt или в узле цепочки SupplyChain, и в нём перечислены все её продавцы, конфиденциальные тоже.

Связку двух файлов задаёт OWNERDOMAIN: по версии 1.1 он должен совпадать с доменом этого издателя в sellers.json, а в полной цепочке SupplyChain первый узел должен вести к продавцу с тем же доменом. Если переменной нет, владельцем считают домен, на котором лежит ads.txt. Спецификации sellers.json и SupplyChain рабочая группа OpenRTB утвердила для отрасли 31 июля 2019 года.

Что такое SupplyChain (schain)?

Это не файл, а объект внутри запроса на показ: в OpenRTB 2.6 он стоит в source.schain, в 2.5 в source.ext.schain. Цепочка состоит из узлов, и каждый узел описывает одного участника оплаты показа:

• asi: домен рекламной системы, тот же, что в ads.txt;
• sid: ID продавца в этой системе, тот же, что в sellers.json;
• hp: участвует ли узел в оплате, в версии 1.0 всегда 1;
• rid, name, domain: ID запроса у этого продавца, а имя и домен, только если их нет в sellers.json.

Флаг complete говорит, доходит ли цепочка до владельца площадки: при 1 первый узел и есть владелец сайта или приложения, при 0 это лишь первый известный участник. Последний узел всегда тот, кто отправил запрос. Перепродавец копирует полученную цепочку и дописывает себя в конец, не трогая complete; если он себя не добавил, объекта в его запросе быть не должно вовсе, а если цепочки не было, он создаёт её сам с complete, равным 0. Когда реклама вызывается тегом или ссылкой VAST, стандарта IAB для видеорекламы, а не по OpenRTB, цепочку передают строкой; параметр для неё спецификация советует называть schain.

Как прочитать цепочку по трём источникам?

Пример условный, домены вымышленные. Покупатель получил запрос на показ на сайте news.example от биржи ssp-b.example, ID продавца в запросе b-77.

Если бы в шаге 1 пары ssp-b.example и b-77 не нашлось, этот аккаунт сайт не уполномочивал. При complete, равном 0, неизвестно, кто стоит до первого узла, и это вопрос к продавцу. Если узлов больше, чем подразумевает медиаплан с прямыми сделками, вы видите, сколько компаний на самом деле участвуют в оплате показа.

Чего эти файлы не доказывают?

В стандарте АРИР (Ассоциации развития интерактивной рекламы) по классификации сложного недействительного трафика (SIVT), опубликованном в августе 2026 года, искажение сведений об источнике и продавце инвентаря стоит среди сценариев категории «Манипуляции с инвентарём и измерениями». Детерминированно подтверждать авторизованный источник, по тому же стандарту, позволила бы криптографическая подпись показов, но это записано как цель рынка, а не действующее требование.

Как проверить цепочку на своей кампании?

1. Получите данные закупки. Попросите у агентства или DSP (платформы, через которую идёт закупка) по каждому размещению домен или bundle ID, домен биржи, ID продавца и schain, если он передаётся. По OpenRTB 2.6 ID продавца в запросе соответствует seller_id в sellers.json биржи. Без этих полей проверить можно только, какие системы перечислены в файле площадки.
2. Найдите пару в ads.txt. Для сайта откройте домен/ads.txt, для приложения сайт разработчика из карточки в магазине и app-ads.txt на нём. Нужна строка с той же системой и тем же ID; для поддомена смотрите переменную SUBDOMAIN в корневом файле.
3. Найдите продавца в sellers.json. Посмотрите тип, имя и домен; скрытую запись и тип BOTH обсудите с продавцом.
4. Сверьте владельца. Сравните OWNERDOMAIN из ads.txt с доменом продавца-издателя в sellers.json; если площадку продаёт эксклюзивный партнёр, с доменом первого узла цепочки должен совпасть MANAGERDOMAIN.
5. Пройдите schain. Проверьте complete, посчитайте узлы и найдите sid каждого узла в sellers.json системы, указанной в его asi. Если медиаплан обещал прямые сделки, лишние звенья видны здесь.
6. Сохраните файлы с датой. Строки меняются, поэтому обсуждать находку с площадкой удобнее по копии файла на день показов; порядок такого разговора описан на странице для тех, кто получил отчёт о фроде.
7. Добавьте данные о показах. Совпадает ли заявленный домен с местом показа и сколько на площадке невалидного трафика, файлы не скажут: это видно только по замеру, а признаки подмены в отчёте по доменам собраны на странице о подмене домена.

Для сотен доменов ручная сверка долгая: у IAB Tech Lab есть агрегатор ads.txt, который даёт подписчикам сводные данные о разрешённых продавцах.

Что сказано в справках Яндекса, VK и Adfox?

По справкам и документации на 16 октября 2026 года:

Как это связано с подменой домена?

При подмене домена показ продают под адресом чужой площадки, и ads.txt с app-ads.txt позволяют покупающей системе отказать продавцу, которого настоящий сайт не уполномочил. Но сверяются они с адресом и ID, заявленными в запросе, а не с местом, где реклама открылась. Поэтому файлы сужают круг подозрительных продавцов, а саму подмену показывает расхождение заявленного и фактического домена в данных о показах. Как это расхождение выглядит в отчёте и чем подмена отличается от сайта-призрака, показано в разборе подмены домена; подмену ID приложения и другие схемы в приложениях описывает разбор фрода в приложениях.

Источники, открытые 16 октября 2026 года: спецификации IAB Tech Lab ads.txt 1.1, app-ads.txt, sellers.json 1.0 и SupplyChain 1.0, OpenRTB 2.6, стандарт АРИР по SIVT (август 2026), справки Рекламной сети Яндекса, VK Рекламы и Adfox, документация Яндекса по протоколу аукциона.