«Файл ads.txt превращает домен в публичный реестр доверенных продавцов рекламного инвентаря. Покупатели сверяют входящие заявки с этим списком и отсекают трафик, который не прошёл проверку авторизации. Механизм выглядит простым, но меняет архитектуру программатик-аукционов и защищает бюджет рекламодателей от перенаправления на несанкционированные ресурсы.»
Почему индустрия создала публичный файл авторизации
До появления стандарта покупатели рекламного трафика не имели технической возможности проверить, действительно ли владелец сайта разрешил конкретной бирже продавать свои рекламные места. Злоумышленники или недобросовестные посредники подменяли метаданные доменов в заявках на реальные бренды. Покупатель платил за премиальный инвентарь, а показывал рекламу на сомнительных ресурсах. Механизм подмены доменов нарушал экономику аукционов и снижал доверие к автоматизированным закупкам.
Создатели спецификации вынесли проверку на уровень самого веб-сервера. Владелец размещает текстовый файл по фиксированному пути. Любой покупатель загружает список и сравнивает его с полями входящих заявок. Совпадение подтверждает цепочку авторизации. Несоответствие ведёт к отклонению ставки.
Простота реализации стала ключевым фактором массового внедрения. Не потребовалось менять протоколы аукционов или создавать централизованные реестры. Достаточно разместить файл в корневой директории домена. Я вижу в этом подходе элегантное решение, которое работает без сложных инфраструктурных изменений.
IAB-OpenRTB-Ads.txt-Public-Spec-1.0.2
213 КБПросмотр и масштаб — в отдельной вкладке браузера; здесь только превью страницы.
Как устроен синтаксис ads.txt и что означают поля
Формат данных представляет собой обычный текст с записями в виде строк. Каждая строка содержит параметры, разделённые запятыми. Система игнорирует пробелы вокруг разделителей, но требует точного порядка полей. Ошибка в одном символе заставляет парсер пропустить всю строку.
Первое поле содержит доменное имя рекламной системы. Это каноническое имя сервера, принимающего ставки, например greenexchange.com. Второе поле — идентификатор аккаунта издателя в указанной системе. Уникальный номер продавца, который совпадает со значением в транзакциях.
Третье поле определяет тип отношений. Значение DIRECT говорит о прямом договоре между владельцем контента и рекламной системой. Значение RESELLER указывает на работу через посредника. Покупатель видит разницу и применяет разные стратегии ставок. Прямые партнёры получают приоритет в премиальных сегментах. Посредники проходят дополнительную фильтрацию.
Четвёртый параметр содержит идентификатор сертификации. Это код внешнего реестра доверия, например TAG. Поле необязательное, но повышает уровень доверия к записи.
Комментарии начинаются со знака решётки. Парсер отбрасывает всё, что стоит после этого символа в текущей строке. Дополнительные поля можно добавить после точки с запятой. Подобная конструкция позволяет вендорам хранить внутренние идентификаторы без нарушения совместимости со старыми парсерами.
greenexchange.com, XF7342, DIRECT, 5jyxf8k54
# Строка выше означает прямой договор с greenexchange.com
silverssp.com, 9675, RESELLER
# Вторая строка указывает на перепродажу через silverssp.comЧто происходит на стороне покупателя и продавца
Владелец ресурса размещает файл в корневой директории. Браузер или бот покупателя обращается к адресу по протоколу HTTP или HTTPS. Сервер возвращает статус 200, и парсер загружает содержимое. Отсутствие файла возвращает код 404. Покупатели трактуют этот код как разрешение продавать инвентарь без ограничений. Подобная логика защищает небольшие проекты, которые ещё не настроили авторизацию.
Система кеширует загруженный список. HTTP-заголовки управляют временем жизни копии. Отсутствие инструкций кеширования устанавливает стандартный срок в семь дней. Покупатель сверяет каждую входящую заявку с сохранённой версией. Обновление происходит в фоновом режиме. Владелец ресурса меняет файл, но эффект проявляется только после истечения срока кеша.
Задержка между обновлением и применением правил создаёт временное окно, когда ставки могут проходить по старым правилам. Я считаю этот момент критическим при планировании изменений в партнёрских соглашениях. Внезапное удаление строки без уведомления приводит к резкому падению ставок.
Коды ответов сервера определяют поведение покупателя. Статус 200 OK запускает загрузку и парсинг содержимого. Коды 301 или 302 разрешают переход по ссылке, если новый адрес остаётся в пределах корневого домена. Статус 404 Not Found интерпретируется как отсутствие ограничений авторизации. Код 401 Unauthorized требует запроса ключей доступа или прямого контакта с владельцем. Ошибки 5xx заставляют использовать последнюю успешно загруженную копию.
Перенаправления обрабатываются строго в рамках исходного корневого домена. Один переход на внешний сервер разрешён для делегирования авторизации. Цепочка из двух перенаправлений за пределы домена вызывает ошибку. Парсер игнорирует ответ и продолжает использовать последнюю рабочую версию списка. Подобное ограничение защищает от атак, пытающихся подменить авторизованный список через промежуточные узлы.
Поддомены пустые файлы и распространённые ошибки
Крупные проекты часто разделяют трафик между основными доменами и тематическими разделами. Спецификация разрешает указывать отдельные файлы для подразделов. Переменная subdomain в корневом списке направляет парсер на нужный адрес. Загрузка данных происходит независимо. Правила для основного домена не распространяются на указанные разделы. Ошибка в ссылке приводит к потере авторизации для целого сегмента трафика.
Публикация пустого файла требует особого оформления. Просто оставить документ пустым нельзя. Парсеры не отличают пустой файл от ошибки сервера. Спецификация предлагает использовать строку-заполнитель с фиктивными данными. Подобный маркер подтверждает намеренный отказ от авторизации любых систем. Покупатель получает явный сигнал и прекращает закупку на этом ресурсе.
placeholder.example.com, placeholder, DIRECT, placeholderРаспространённая ошибка возникает при копировании идентификаторов из личных кабинетов рекламных платформ. Некоторые системы используют разные форматы для внутренних баз и внешних API. Вставка несоответствующего номера приводит к постоянным отклонениям ставок. Покупатель видит заявку, проверяет файл, не находит совпадение и снижает цену до минимума или отказывается от показа. Владелец теряет доход, хотя технически всё настроено верно.
Мне приходилось сталкиваться с ситуацией, когда издатель неделями не понимал причину падения дохода. Проблема оказалась в лишнем пробеле внутри идентификатора аккаунта. Парсер отбрасывал строку, но человек при беглом просмотре не замечал ошибку.
Как проверить корректность и избежать потери дохода
Перед публикацией списка полезно запустить валидатор. Инструмент проверяет синтаксис, наличие пробелов, корректность доменных имён и соответствие формату. Ошибки в пунктуации остаются невидимыми для человека, но полностью блокируют парсер. Регулярный аудит выявляет дублирующиеся строки, устаревшие идентификаторы и смешение типов отношений.
Настройка сервера влияет на доступность. Заголовок Content-Type обязан содержать значение text/plain. Серверы, отдающие файл как HTML или JSON, заставляют покупателей игнорировать содержимое. Протокол HTTPS повышает надёжность. Перенаправление HTTP-запросов на защищённый канал защищает от перехвата данных. Отсутствие шифрования оставляет список открытым для модификации в публичных сетях.
Контроль за изменениями требует регулярного мониторинга журналов обращений. Парсеры разных компаний работают с разной частотой. Одни обновляют список каждый день, другие придерживаются недельного цикла. Владелец ресурса обязан учитывать эти задержки при изменении партнёрских соглашений.
Техническая реализация стандарта оставляет пространство для адаптации. Вендоры добавляют собственные поля, используют нестандартные разделители или меняют регистр букв. Покупатели вынуждены писать устойчивые парсеры, которые прощают мелкие нарушения формата. Жёсткая валидация отсекает легитимный трафик. Слишком мягкая проверка пропускает мошеннические схемы. Баланс достигается за счёт логирования расхождений и ручной проверки спорных строк.
Практический чек-лист для настройки:
[√] Файл размещён по пути /ads.txt на корневом домене потому что парсеры ищут файл именно по этому адресу и не будут сканировать другие пути
[√] Заголовок Content-Type text/plain charset=utf-8 активен потому что неправильный тип контента заставляет покупателей игнорировать файл
[√] Все строки соответствуют формату домен, идентификатор, DIRECT или RESELLER, опциональный TAG-ID потому что парсер отбрасывает строки с нарушением синтаксиса
[√] Указаны правильные идентификаторы из документации рекламной платформы потому что несовпадение с транзакционными данными ведёт к отклонению ставок
[√] Поддомены перечислены через переменную subdomain в корневом файле потому что правила основного домена не применяются к подразделам автоматически
[ ] Пустые файлы заменены на строку-заполнитель согласно спецификации потому что пустой файл парсеры могут интерпретировать как ошибку загрузки
[ ] HTTPS перенаправление настроено для защиты от модификации потому что незашифрованный трафик уязвим для перехвата в публичных сетях
Точная настройка требует внимания к деталям. Ошибки в одной строке снижают доход всего домена. Правильная реализация защищает трафик и упрощает взаимодействие между участниками аукциона.
Я заметил интересный момент при анализе внедрения стандарта в разных регионах. В некоторых случаях издатели добавляют в файл всех партнёров, с которыми когда-либо работали, опасаясь потерять потенциальный доход. Такой подход создаёт риск. Каждая запись в ads.txt — это делегирование права продавать инвентарь. Лишняя строка означает лишнего агента с доступом к вашему трафику.
app-ads.txt работает по аналогичному принципу для мобильных приложений. Разница в том, что файл размещается на сайте разработчика, а не в самом приложении. Покупатели извлекают ссылку на сайт из метаданных приложения в магазине и загружают файл авторизации оттуда.
sellers.json дополняет механизм с другой стороны. Если ads.txt показывает, кого издатель уполномочил продавать инвентарь, то sellers.json показывает, кого представляет каждая рекламная платформа. Вместе эти файлы создают двустороннюю проверку цепочки поставок.
Некоторые покупатели требуют наличия обоих файлов для участия в премиальных аукционах. Отсутствие sellers.json не блокирует продажи полностью, но снижает доверие к поставщику. Я рекомендую издателям проверять настройки не только своего ads.txt, но и файлов партнёрских платформ.
Вопрос без ответа остаётся открытым для небольших издателей. Стоит ли тратить время на настройку ads.txt, если трафик не превышает нескольких тысяч показов в день? С одной стороны, стандарт стал де-факто обязательным для участия в программатик-аукционах. С другой, мелкие игроки могут не почувствовать разницы в доходе.