ads.txt

Происхождение и история термина

ADS расшифровывается как Authorized Digital Sellers — «авторизованные продавцы цифровой рекламы». В истории IAB Tech Lab первая версия датирована июнем 2017 года. Стандарт предназначен для публичного объявления разрешённых продавцов и борьбы с продажей инвентаря под чужим именем. ^[1]

Версия 1.1 добавила сведения о владельце и управляющем монетизацией — OWNERDOMAIN и MANAGERDOMAIN. В датировке есть различие: обзорная страница IAB указывает август 2022 года, а журнал изменений самой спецификации — окончательный выпуск в июле 2022 года. ^{[1, 2]} Поэтому точнее говорить об обновлении 2022 года, а при обсуждении даты указывать конкретный документ.

Отдельный этап — развитие связанных механизмов прозрачности. IAB Tech Lab сообщает, что спецификации sellers.json и объекта SupplyChain были окончательно утверждены для внедрения 31 июля 2019 года. Их задача — раскрывать организации и участников продажи, тогда как ads.txt объявляет полномочия. ^[8]

На 20 октября 2026 года официальная страница IAB направляет к спецификациям в GitHub и описывает ads.txt 1.1 как версию для внедрения. ^[1] Дата обновления веб-страницы не является номером новой спецификации. Это важно, когда старая копия документа и свежий обзор оказываются рядом в результатах поиска.

Суть и механизм

В автоматизированной продаже рекламы — программатике — программные системы обмениваются предложениями о рекламных показах. В описании предлагаемого показа указываются площадка и продавец. ads.txt даёт возможность сопоставить продавца с разрешениями площадки. ^[2] Сам файл не проводит торги: это опубликованные данные, которыми пользуются участники закупки.

Рассмотрим полностью учебный пример интернет-газеты. В условной системе exchange.example газета контролирует аккаунт 410. Ещё она разрешает партнёру перепродавать её рекламные места через аккаунт 820 той же системы. В учебном файле это выглядит так:

text exchange.example, 410, DIRECT exchange.example, 820, RESELLER

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

Домены и номера в примере вымышлены. Это объяснение логики, а не конфигурация для копирования. В рабочем файле нужны значения, предоставленные конкретными рекламными партнёрами. ^[6]

Публикация списка и использование списка покупателем — разные действия. В пояснении IAB Tech Lab подчёркивается, что прозрачность помогает бороться с мошенничеством только тогда, когда покупатели действительно применяют эти сведения. ^[7] Поэтому наличие файла не позволяет само по себе объявить каждый показ подлинным и безопасным.

Как прочитать строку

В записи три обязательных поля и четвёртое дополнительное. ^[2] Их удобнее читать как маленькое предложение: «Система такая-то, аккаунт такой-то, отношения с ним такие-то».

Описание полей дано в спецификации 1.1. Четвёртое поле не обязательно; оно относится к рекламной системе, а не служит сертификатом конкретного сайта. Спецификация также указывает на перенос соответствующей идентификации в объект identifiers файла sellers.json. ^[2]

Виды и классификации

DIRECT и RESELLER

В классификации IAB DIRECT означает, что владелец контента непосредственно контролирует указанный аккаунт. RESELLER означает, что владелец разрешил другой организации контролировать аккаунт и перепродавать через него рекламное пространство. ^[2]

Для учебной газеты различие можно проверить вопросом: «Кто управляет именно аккаунтом 410 или 820?» Вопрос «Хороший ли это посредник?» здесь не подходит. Разрешённая перепродажа не превращается в мошенничество от одного присутствия посредника. И наоборот, слово DIRECT не является общей оценкой надёжности любой сделки.

Также не стоит читать DIRECT как обещание отсутствия любых посредников во всей продаже. Поле относится к одному аккаунту. Для разбора полной цепочки нужны сведения о других участниках и о конкретном предложении. ^{[2, 8]}

ads.txt, sellers.json и SupplyChain

Различие следует из описания IAB Tech Lab. SupplyChain состоит из узлов, представляющих участников продажи; sellers.json помогает установить их организации. ^[8] Это не три названия одного документа.

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

OWNERDOMAIN и MANAGERDOMAIN

OWNERDOMAIN указывает деловой домен организации-владельца площадки. MANAGERDOMAIN предназначен для основного или эксклюзивного партнёра, управляющего программатик-монетизацией; он используется только в подходящих случаях. Для управляющего можно обозначить страну, а значение без страны относится к глобальному представительству. ^[2]

В историческом пояснении IAB разобрана причина такого разделения: управляющую компанию легко принять за лишнего посредника, хотя она может быть наиболее прямым путём покупки рекламы конкретной площадки. ^[7] Учебный медиахолдинг, например, владеет газетой, а продажи передаёт отдельной компании. Домен газетного сайта, деловой домен владельца и домен управляющего тогда обозначают разные сущности. Их не следует механически делать одинаковыми.

Как применяется на практике

Российская практика: Рекламная сеть Яндекса

Справка РСЯ предлагает получить индивидуальные строки в разделе «Настройки → Общие» по кнопке ads.txt. Если сайт сотрудничает с несколькими сетями, собирают строки от каждой. Яндекс не рекомендует добавлять компании, с которыми площадка не работает. ^[6]

Для небольшой редакции это означает разделение ролей: сотрудник, отвечающий за рекламу, подтверждает партнёров и аккаунты, а технический специалист публикует согласованный текст. Это предложенная организация работы, а не требование РСЯ. Она помогает избежать ситуации, когда администратору присылают неизвестный список с просьбой «просто заменить файл».

Яндекс рекомендует обновлять содержимое не реже одного раза в месяц, поскольку состав партнёров может меняться. ^[6] Этот срок относится к рекомендации конкретной платформы. Он не означает, что любую смену аккаунта следует откладывать до очередной ежемесячной проверки.

Google Ad Manager: что делает генератор

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

В учебной газете уже могут быть строки двух партнёров. Новый файл, выгруженный только из одного интерфейса, не обязательно содержит весь нужный список. Поэтому перед заменой полезно сравнить версии: что исчезает, что добавляется и кто подтвердил изменение. Это редакционное предложение контроля, основанное на ограничениях генератора, а не дополнительная функция самого Ad Manager.

Сопоставление касается документации, а не условий подключения или коммерческой доступности платформ в конкретной стране.

Где размещается файл

Google указывает корневой домен как место публикации. В этом значении корневой домен — регистрируемое доменное имя над публичным суффиксом, а не обязательно имя из двух частей. Для нескольких таких доменов файлы размещают отдельно. Для поддомена предусмотрен вариант со ссылкой на него из файла корневого домена. ^[5]

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

Спецификация предусматривает адрес /ads.txt и текстовый тип содержимого text/plain. ^[2] Поэтому красивая HTML-страница с таблицей продавцов не равнозначна нужному ресурсу. Существенно не то, как список выглядит для человека, а то, какой текст получает система по предусмотренному адресу.

Как измерить или проверить

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

В Google Ad Manager ошибка формата может мешать работе записи. Предупреждение, например о точном дубликате, имеет иной смысл. Кроме того, интерфейс показывает последнюю просканированную версию файла: недавно опубликованное изменение ещё может отсутствовать в диагностике. ^[4] Значит, два разных текста на экране не обязательно говорят о неудачной загрузке — сначала нужно сопоставить версии и время проверки.

Для внутреннего контроля можно использовать учебную метрику полноты. Пусть R — число записей, которые должны присутствовать по согласованному реестру, а V — число этих записей, найденных и подтверждённых в опубликованном файле. Тогда:

Полнота = V / R × 100%.

Если согласованы 12 записей, а найдены 9, результат равен 9 / 12 × 100% = 75%. Это доля необходимых записей, а не доля качественных показов, предотвращённого мошенничества или дохода. При R = 0 процент не рассчитывают: сначала нужно выяснить, действительно ли действующих продавцов нет или реестр ещё не составлен.

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

Учебный пример приёмки изменения

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

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

Ошибки, ограничения и спорные вопросы

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

Количество строк тоже не равно качеству. В учебном файле из двух записей может быть всё необходимое, а в файле из двухсот — отсутствовать единственный действующий аккаунт. Сокращение списка без понимания отношений способно удалить нужное разрешение; увеличение списка без подтверждения добавляет неопределённость.

ads.txt не измеряет аудиторию и не наблюдает каждый рекламный показ: его предмет — опубликованные полномочия. ^[1] Вопросы о ботах, фактической видимости объявления и действиях пользователей требуют иных данных. Техническую авторизацию также не следует читать как юридическое заключение о рекламе: спецификация IAB отдельно не гарантирует соблюдения применимых законов. ^[2]

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

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

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

• sellers.json
• Программатик-продажи
• SSP (платформа продавца)
• Рекламный инвентарь
• Рекламная биржа
• Видимость рекламы (viewability)