ads.txt и sellers.json: как проверить продавцов рекламы

ads.txt и sellers.json помогают проверить, кто уполномочен продавать рекламный инвентарь и какая компания стоит за аккаунтом продавца. Для сверки сопоставляют домен рекламной системы и идентификатор аккаунта, затем изучают фактический путь продажи. Результат — подтверждённые соответствия и список расхождений для разбирательства. Наличие файлов само по себе не гарантирует качественную аудиторию, видимость рекламы или продажи.

Когда нужна проверка ads.txt и sellers.json

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

У издателя другая задача: поддерживать актуальный перечень разрешений и вовремя согласовывать изменения с партнёрами. Обычному сайту, который не продаёт рекламный инвентарь через такие системы, не следует добавлять случайные строки ради SEO. Это сведения о продаже рекламы, а не способ улучшить поисковые позиции.

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

Чем отличаются ads.txt, sellers.json и SupplyChain

Материалы IAB Tech Lab об ads.txt описывают публичное объявление разрешённых продавцов. Но разрешение и фактическое участие в продаже — разные вопросы. Общий файл может содержать много партнёров, из которых в выбранном запросе участвуют лишь некоторые.

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

Как читать строку ads.txt

В спецификации ads.txt три обязательных поля: домен рекламной системы, идентификатор аккаунта и отношение DIRECT либо RESELLER. Необязательное четвёртое поле относится к идентификации рекламной системы органом сертификации, а не к номеру аккаунта издателя.

Учебная строка exchange.example, 00042, DIRECT использует вымышленный домен и аккаунт. Её нельзя копировать в рабочий файл. В ней нужно проверить пару exchange.example и 00042, а не просто присутствие знакомого названия биржи где-либо на странице.

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

DIRECT указывает, что издатель непосредственно контролирует обозначенный аккаунт. RESELLER обозначает разрешение другому участнику контролировать аккаунт и перепродавать место. Эти значения не являются оценкой цены, качества аудитории или числа всех посредников в закупке.

Не требуйте заменить RESELLER на DIRECT только ради красивого отчёта. Сначала выясните реальные отношения сторон. Неверная подпись не делает путь короче. Для операционного решения важнее согласованность опубликованных сведений с устройством сделки и понятное объяснение поставщика.

Почему нельзя терять ведущие нули

Сохраняйте ID как строку. Табличный редактор способен превратить 00042 в 42, после чего автоматическая сверка покажет другое значение. Не исправляйте это догадкой: получите исходную запись и подтвердите её с партнёром. Название поля «идентификатор» не означает, что его можно безопасно преобразовать в число.

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

Как сопоставить аккаунт с sellers.json

Найдите реестр соответствующей рекламной системы и нужный seller_id. Спецификация sellers.json связывает этот идентификатор с продавцом. У записи проверяют тип PUBLISHER, INTERMEDIARY или BOTH, а также доступные имя и бизнес-домен организации.

Тип продавца в sellers.json и отношение в ads.txt отвечают на разные вопросы. Не сравнивайте слова DIRECT и PUBLISHER как одинаковые метки. Вместо этого проверьте, какое объяснение роли дают документы и партнёр, есть ли противоречие и какие сведения нужны для его разрешения.

При is_confidential=1 часть сведений о личности может быть скрыта. Сам по себе этот признак не доказывает мошенничество. Однако для закупки с обязательным раскрытием контрагента такого уровня информации может быть недостаточно. Решение зависит от заранее принятых требований, а не от попытки угадать скрытое имя.

Сохраняйте основания совпадения

Полезная строка рабочего реестра содержит площадку, систему, аккаунт, адрес источника, время получения и результат сопоставления. Для спорной записи добавьте пояснение и ответственного. Скриншот знакомого логотипа без исходного ID не позволяет восстановить ход проверки.

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

Как проверить фактический путь через SupplyChain

Попросите технического партнёра предоставить обезличенный пример запроса по согласованному пути. В описании SupplyChain узел содержит домен системы asi и ID sid. Сопоставьте эти пары с соответствующими реестрами. Флаг complete=0 обозначает неполную цепочку; значение 1 является заявлением полноты, которое тоже требует проверки.

Не ограничивайтесь демонстрационным запросом, который никак не связан с рассматриваемой закупкой. Попросите указать, какой маршрут он представляет, когда был получен и какие случаи не покрывает. Внутренние правила выборки должны позволять повторить проверку при смене поставщика.

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

Что делать при расхождениях ads.txt и sellers.json

Заведите разные статусы: «сопоставлено», «есть расхождение» и «недостаточно данных». Они требуют разных действий. Если всё объединить в красную колонку «фрод», команда потеряет возможность отличить техническую ошибку, устаревшие сведения и действительно необъяснимый путь.

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

Проверяйте доступность и дату данных

Опубликованный ресурс должен отдавать ожидаемое содержимое: для ads.txt — текст, для sellers.json — JSON. Страница ошибки или форма входа с успешным кодом ответа не заменяет реестр. Проверяйте содержимое, а не только зелёный индикатор доступности адреса.

Системы используют кеширование. Изменение на сервере не означает, что все покупатели сразу читают новую версию. При споре сохраните время проверки и уточните дату обновления у потребляющей системы. Сравнение файлов, полученных в разные моменты, способно объяснить часть расхождений.

Как организовать поддержку разрешений у издателя

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

• Сверьте запрос с действующим партнёрством.
• Подтвердите точные домен и ID аккаунта.
• Согласуйте отношение DIRECT или RESELLER.
• Сохраните предыдущую версию перед изменением.
• Проверьте опубликованный ресурс после загрузки.
• Получите подтверждение, что партнёр видит нужные сведения.

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

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

Как считать результат проверки

Учебный пример: в перечне 100 пар «система — аккаунт». У 80 соответствие подтверждено, у 12 найдено расхождение, по 8 недостаточно данных. Получается 80%, 12% и 8% перечня соответственно. Это классификация записей, а не измеренная доля мошеннических показов.

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

Отчёт должен давать возможность действовать: какие пары проверены, какие вопросы открыты, кто отвечает и какое решение принято по каждому существенному случаю. Отдельно перечислите недоступные источники. Большой процент совпадений не компенсирует непрозрачность самого важного для кампании пути.

Вопросы и ответы