Окончательная версия спецификации 1.0.2. Март 2019
О ads.txt
Спецификация ads.txt была разработана весной 2017 года. Этот документ является окончательной Спецификацией ads.txt Версия 1.0.2; рецензируемый стандарт, разработанный при поддержке рабочей группы OpenRTB. Этот документ доступен по адресу https://iabtechlab.com/ads-txt.
Спецификация ads.txt фокусируется на защите рекламных ресурсов, размещаемых на веб-сайте, публикующем файл ads.txt. Чтобы удовлетворить требования к программным приложениям, распространяемым через магазины мобильных приложений, подключенные магазины телевизионных приложений и другие каналы распространения такого рода, обратитесь к спецификации companion app-ads.txt, также доступной по адресу https://iabtechlab.com/ads-txt.
О IAB Tech Lab
IAB Technology Laboratory — это некоммерческий консорциум по исследованиям и разработкам, занимающийся производством и оказанием помощи компаниям во внедрении глобальных отраслевых технических стандартов и решений. Задача Технической лаборатории — уменьшить трения, связанные с цепочкой поставок цифровой рекламы и маркетинга, способствуя безопасному росту отрасли.
Техническая лаборатория IAB возглавляет разработку технических стандартов, создает и поддерживает библиотеку кода для быстрого и экономически эффективного внедрения стандартов IAB, а также создает платформу для тестирования компаний для оценки совместимости их технологических решений со стандартами IAB, которая в течение 18 лет была основой для взаимодействия и прибыльного роста в цепочке поставок цифровой рекламы. Более подробную информацию о IAB Technology Lab можно найти по адресу https://iabtechlab.com.
Лицензия
Ads.txt рабочей группой OpenRTB лицензируется по лицензии Creative Commons Attribution 3.0. Чтобы просмотреть копию этой лицензии, посетите сайт creativecommons.org/licenses/by/3.0/ или напишите Creative Commons, 171 Second Street, Suite 300, Сан-Франциско, Калифорния 94105, США.
Авторы
Нил Рихтер (Neal Richter), технический директор, Rakuten Marketing и сопредседатель IAB Tech Lab OpenRTB
Джордж Левит (George Levitte), менеджер по продукту, Google
Оглавление
About ads.txt
About IAB Tech Lab
1. Аннотация
2. Введение
2.1 Журнал изменений
3. Спецификация
3.1 Метод доступа
3.2 Формат файла
3.2.1 Файлы без утверждённых рекламных систем
3.3 Запись данных
3.4 Синтаксическое определение
3.4.1 Комментарии
3.4.2 Запись
3.4.3 Области расширения
3.5 Записи переменных объявления
3.5.1 Поддерживаемые переменные
3.6 Истечение
4. Примеры
4.1 Единая система директа
4.2 Продавец одной системы
4.3 Несколько систем и продавцов
4.4 Контактные записи
4.5 Направления поддомена
4.6 Файл без разрешённых рекламных систем
5. Замечания исполнителя
5.1 Версия
5.2 Руководство по партии
5.2.1 SSP/EXCHANGE
5.2.2 DSP
5.2.3 Издатели
5.3 Совместимость
5.4 Безопасность
5.5 Поддомены
5.6 ADS.TXT обходчики
6. Сфера и будущие направления
6.1 Сфера
6.2 Открытые вопросы
6.3 Будущие направления
7. Благодарности
8. Ссылки
1. Аннотация
В рамках более широких усилий по устранению возможности получения прибыли от контрафактной инвентаризации в открытой цифровой рекламной экосистеме создайте механизм, позволяющий владельцам контента объявлять, кому разрешено продавать свои ресурсы.
2. Введение
Для краткости предположим, что читатели уже знакомы с проблемой мошенничества в рекламных технологиях и ее масштабами [1] [2] [3]. Мошенничество может проявляться в различных формах. Здесь мы концентрируемся на форме, в которой рекламные ресурсы предлагаются покупателям с неверно представленным ярлыком и учетной записью в процессе торгов в режиме реального времени. Обычно домен веб-страницы или идентификатор мобильного приложения фальсифицируется, чтобы выглядеть как сайт или приложение, на которое у них нет разрешения на продажу.
Здесь мы предлагаем новый стандарт, позволяющий владельцам контента явно объявлять набор рекламных систем и реселлеров, которым разрешено продавать свои ресурсы. Это позволит покупателям приобретать рекламные площади через безопасные цепочки поставок через уполномоченные органы.
2.1 Журнал изменений
Версия 1.0 — (27 июня 2017 года). Первая версия.
Версия 1.0.1 — (30 августа 2017 г.). Незначительные изменения, основанные на отзывах сообщества. Разъяснения в 3.1 и добавление поддержки переменных контакта и поддоменов в 3.2 3.5, 4.4, 4.5 и 5.5.
Версия 1.0.2 — (4 марта 2019 г.). Незначительные изменения, основанные на отзывах сообщества. Добавляет 3.2.1 и 4.6, содержащие руководство по использованию записи заполнителя для указания намерения пустого файла ads.txt, исключая предыдущий метод. Добавляет различие между ads.txt и app-ads.txt в разделе «о» (“about”).
3. Спецификация
В этом меморандуме указан механизм, позволяющий распространителям контента издателей публично объявлять свои авторизованные рекламные системы и идентификаторы в этих системах. Также описывается формат для кодирования инструкций, которые будут использоваться рекламными системами и их клиентами. Рекламные системы должны получить эти объявления перед покупкой или продажей рекламы, утверждающей, что она находится на сайте.
Эта спецификация основана на стандарте robots.txt [5] [6]. Ключевым атрибутом является то, что файл публикуется в системе веб-обслуживания контента, тем самым подтверждая, что сайт является автором файла. Мы отсылаем читателя к различным другим спецификациям API рекламы, таким как OpenRTB [7] от IAB Tech Lab и API AdX [8] от Google для продаж рекламного пространства в реальном времени и OpenDirect [9] от Lab для продаж не в реальном времени.
3.1 Метод доступа
Издатели должны публиковать файл «/ads.txt» в своем корневом домене и любых поддоменах по мере необходимости. Для целей данного документа «корневой домен» определяется как «общедоступный суффикс» плюс одна строка в имени. Сканеры должны включить Public Suffix list [16] для получения корневого домена.
Объявления должны быть доступны через HTTP и / или HTTPS с веб-сайта, к которому должны применяться инструкции, по стандартному относительному пути на хосте сервера: «/ads.txt» и заголовку HTTP-запроса, содержащему «Content-Type: text/plain». Может быть целесообразно дополнительно использовать «Content-Type: text / plain; charset = utf-8», чтобы сигнализировать о поддержке UTF8.
Также желательно, чтобы при сканировании файлов ads.txt предпочтение отдавалось соединениям HTTPS, а не HTTP. В любом случае, когда данные доступны по HTTPS и HTTP-соединению для одного и того же URL, предпочтительнее использовать данные из HTTPS.
Для удобства мы будем называть этот ресурс файлом «/ads.txt», хотя на самом деле этот ресурс не должен происходить из файловой системы.
Если в ответе сервера указано «Успешно» (код состояния HTTP 2xx), рекламная система должна прочитать содержимое, проанализировать его и использовать объявления.
Если ответ сервера указывает на перенаправление HTTP / HTTPS (301, 302, 307 кодов состояния), рекламная система должна следовать за перенаправлением и использовать данные в качестве доверенных для источника перенаправления, если и только если перенаправление находится в пределах объема исходный корневой домен, как определено выше. Многократные перенаправления действительны, пока каждое местоположение перенаправления остается в пределах исходного корневого домена. Например, допустимо перенаправление HTTP на HTTPS в том же корневом домене.
Только одно перенаправление HTTP к месту назначения за пределами исходного корневого домена разрешено для упрощения делегирования полномочий в один переход к домену веб-сервера третьей стороны. Если стороннее местоположение возвращает перенаправление, то рекламная система должна воспринимать ответ как ошибку. В будущей версии может быть указано другое делегирование полномочий стороннему веб-серверу. Любое другое перенаправление должно быть интерпретировано как ошибка и проигнорировано.
Если в ответе сервера указано, что ресурс ограничен (HTTP 401), рекламная система должна искать прямой контакт с сайтом для получения ключей авторизации или разъяснений.
Если в ответе сервера указано, что ресурс не существует (код состояния HTTP 404), рекламная система может предположить, что объявлений не существует, и что ни одна рекламная система не имеет права покупать и продавать рекламу на сайте. Для любой другой ошибки HTTP, обнаруженной для URL, для которого искатель ранее обнаружил данные, следует использовать последний успешно полученный набор данных.
3.2 Формат файла
Данные кодируются как отформатированный текстовый объект, описанный здесь. Тип содержимого HTTP должен быть «text/plain», а все остальные типы содержимого следует рассматривать как ошибку, а содержимое игнорировать. Полное описание синтаксиса этого формата приведено в разделе 3.4 ниже.
Формат логически состоит из:
- Непустой набор записей, разделенных переносами строк. Записи состоят из набора строк вида: <FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4> или <VARIABLE>=<VALUE>
- Строки, начинающиеся с символа #, считаются комментариями и игнорируются.
- Строки, содержащие формат данных, имеют синтаксис, определенный в разделе 3.4.
- Строки, содержащие формат переменной, имеют синтаксис, определенный в разделе 3.5.
3.2.1 Файлы без утверждённых рекламных систем
Некоторые издатели могут предпочесть не авторизовать какую-либо рекламную систему, опубликовав пустой файл ads.txt, указывающий, что ни одна рекламная система не имеет права покупать и продавать рекламу на веб-сайте. Чтобы потребляющие системы правильно считывали и интерпретировали пустой файл (различая веб-серверы, возвращающие страницы с ошибками для URL-адреса /ads.txt), должна быть включена как минимум одна строка в надлежащем формате, соответствующая описанной выше спецификации формата. Для файлов, которые в противном случае не содержат разрешенных записей рекламной системы, используйте следующую запись «заполнитель», чтобы указать, что файл соответствует спецификации ads.txt:
placeholder.example.com, placeholder, DIRECT, placeholder
Домен «example.com» не имеет значения: он используется здесь, чтобы строка начиналась с правильно отформатированного, зарезервированного на постоянной основе (https://tools.ietf.org/html/rfc6761) альтернативного домена реальной рекламной системе.
В предыдущих версиях спецификации ads.txt указывалось, что издатели могут просто использовать пустой файл ads.txt, чтобы указать, что ни одна рекламная система не имеет права покупать или продавать рекламу на веб-сайте. Этот метод в настоящее время считается устаревшим из-за неясностей, которые он создает, и его следует игнорировать потребляющим системам после 1 марта 2020 года.
3.3 Запись данных
Далее определяется содержимое каждого поля. При необходимости мы ссылаемся на спецификации IAB OpenRTB [7] и IAB OpenDirect [9].
Field #1 (Доменное имя рекламной системы)
(Обязательно) Каноническое доменное имя системы SSP, Exchange, Header Wrapper и т. д., К которой подключаются участники торгов. Это может быть операционный домен системы, если он отличается от родительского корпоративного домена, чтобы упростить WHOIS и обратный поиск IP для установления четкого владения системой делегатов. В идеале SSP или Exchange публикует документ с подробным описанием того, какое доменное имя использовать.
Field #2 (Идентификатор учетной записи издателя)
(Обязательно) Идентификатор, связанный с учетной записью продавца или посредника в рекламной системе в поле № 1. Он должен содержать то же значение, которое использовалось в транзакциях (то есть запросы заявок OpenRTB) в поле, указанном SSP / exchange. Обычно в OpenRTB это publisher.id. Для OpenDirect это, как правило, идентификатор организации издателя.
Field #3 (Тип учетной записи / отношения)
(Обязательно) Перечисление типа учетной записи. Значение «DIRECT» указывает, что издатель (владелец контента) напрямую контролирует учетную запись, указанную в поле № 2 системы в поле № 1. Это означает прямой бизнес-контракт между издателем и рекламной системой. Значение «RESELLER» указывает, что издатель уполномочил другую организацию управлять учетной записью, указанной в поле # 2, и перепродавать свое рекламное пространство через систему в поле # 1. Другие типы могут быть добавлены в будущем. Обратите внимание, что это поле следует рассматривать как нечувствительное к регистру при интерпретации данных.
Field #4 (Идентификатор удостоверяющего центра)
(Необязательно) Идентификатор, который однозначно идентифицирует рекламную систему в центре сертификации (этот идентификатор сопоставляется с объектом, указанным в поле # 1). Текущим органом по сертификации является Группа достоверной отчетности (также известная как TAG), и TAGID будет включен сюда [11].
3.4 Синтаксическое определение
3.4.1 Комментарии
Комментарий обозначается символом «#». Любая строка, содержащая «#», должна информировать потребителя данных об игнорировании данных после символа «#» до конца строки.
3.4.2 Запись
Основной синтаксис — это разделенный запятыми формат с тремя определенными полями и одной записью на строку.
Потребительские системы должны игнорировать любую последовательность пробелов или табуляции. Если данные явно повреждены или искажены, содержимое файла следует игнорировать. Ни одно поле не должно содержать табуляции, запятых или пробелов, в противном случае его следует экранировать с помощью URL-кодировки [13].
Отдельные записи разделяются маркером конца строки. Потребительские системы должны свободно интерпретировать CR, CRLF и т. Д. Как разделитель записей.
Разрешенные идентификаторы в поле # 1 и по определению предполагаются действительными доменными именами DNS, подчиняющимися RFC 1123 [10], соответствующим ошибкам для RFC 1123 или относящимся к RFC.
Идентификаторы в поле № 2 могут быть строками или целыми числами. Для справки: OpenRTB publisher.id [14] является строковым полем.
3.4.3 Области расширения
Поля расширения разрешены исполнителями и их потребителями, если они используют отдельное поле конечного разделителя «;» перед добавлением данных расширения к каждой записи.
3.5 Записи переменных объявления
Любая строка, содержащая шаблон <VARIABLE> = <VALUE>, должна интерпретироваться как объявление переменной, и сканер должен хранить данные, связанные с корневым доменом.
<VARIABLE> — это строковый идентификатор без внутреннего пробела. Единственный поддерживаемый разделитель — это знак равенства ‘=’. <VALUE> — это открытая строка, которая может содержать произвольные данные.
Строка объявления заканчивается маркером конца строки. Потребительские системы должны свободно интерпретировать CR, CRLF и т. д. Как разделитель строк.
Для удобства чтения рекомендуется объявлять переменные в конце файла, но это не является строгим требованием и не должно приниматься сканерами.
3.5.1 Поддерживаемые переменные
Следующие переменные официально поддерживаются. Другие переменные могут быть добавлены в будущем. Если сканер находит несколько строк с одной и той же переменной, он должен прочитать и сохранить все из них, связанные с корневым доменом.
Переменная CONTACT — Значение Контакты
(Необязательно) Некоторая информация, читаемая человеком, для владельца файла. Это может быть контакт команды отдела рекламных операций на сайте. Это может быть адрес электронной почты, номер телефона, ссылка на контактную форму или другое подходящее средство связи.
Переменная SUBDOMAIN — Указатель на файл субдомена
(Необязательно). Машиночитаемый указатель субдомена на поддомен в корневом домене, в котором можно найти файл ads.txt. Искатель должен извлекать и использовать данные, связанные с поддоменом, а не с текущим доменом. Это направление должно быть освобождено от процесса усечения общедоступных суффиксов. Только корневые домены должны относить сканеры к поддоменам. Субдомены не должны ссылаться на другие субдомены.
3.6 Истечение
Системы, использующие файл /ads.txt, должны кэшировать файлы, но если они это делают, они должны периодически проверять, что кэшированная копия свежая, прежде чем использовать ее содержимое.
Стандартные механизмы контроля кэша HTTP могут использоваться как исходным сервером, так и роботами, чтобы влиять на кэширование файла /ads.txt. В частности, пользователям и репликаторам следует принять к сведению заголовок HTTP Expires, установленный исходным сервером.
Если директивы управления кэшем отсутствуют, для систем-потребителей по умолчанию истекает 7 дней.
4. Примеры
Как определено выше, есть три обязательных поля. Необязательное поле ID удостоверяющего центра включено в некоторые примеры.
4.1 Единая система директа
Первый пример — это веб-сайт с единственной авторизованной системой, которая напрямую контролируется / управляется владельцем веб-сайта.
http://example.com/ads.txt
greenadexchange.com, XF7342, DIRECT, 5jyxf8k54
4.2 Продавец одной системы
Второй пример — это веб-сайт с единственной авторизованной системой, которой управляет отдельная компания, занимающаяся перепродажей запасов. Их рекламная система не прошла независимую сертификацию, поэтому необязательное четвертое поле опущено.
http://example.com/ads.txt
redssp.com, 57013, RESELLER
4.3 Несколько систем и продавцов
Третий пример — веб-сайт с несколькими авторизованными системами и несколькими торговыми посредниками. Некоторые из их авторизованных рекламных систем проходят независимую сертификацию и имеют удостоверение личности.
http://example.com/ads.txt
# ads.txt file for example.com:
greenadexchange.com, 12345, DIRECT, d75815a79
silverssp.com, 9675, RESELLER, f496211
blueadexchange.com, XF436, DIRECT
orangeexchange.com, 45678, RESELLER
silverssp.com, ABE679, RESELLER
4.4 Контактные записи
Четвертый пример — это веб-сайт с несколькими авторизованными системами и несколькими контактами.
http://example.com/ads.txt
# ads.txt file for example.com:
greenadexchange.com, 12345, DIRECT, d75815a79
blueadexchange.com, XF436, DIRECT
contact=adops@example.com
contact=http://example.com/contact-us
4.5 Направления поддомена
Пятый пример — это веб-сайт, который направляет сканер к поддомену с другим набором авторизованных систем. Искатель должен использовать поддомен в качестве другого URL-адреса для извлечения данных и связывания с поддоменом, а НЕ с родительским доменом.
http://example.com/ads.txt
# ads.txt file for example.com:
greenadexchange.com, 12345, DIRECT, d75815a79
blueadexchange.com, XF436, DIRECT
subdomain=divisionone.example.comhttp://divisionone.example.com/ads.txt
# ads.txt file for divisionone.example.com:
silverssp.com, 5569, DIRECT, f496211
orangeexchange.com, AB345, RESELLER
4.6 Файл без разрешённых рекламных систем
Шестым примером является веб-сайт, который не публикует никаких авторизованных рекламных систем, отражая это намерение в правильно отформатированном файле ads.txt.
http://example.com/ads.txt
placeholder.example.com, placeholder, DIRECT, placeholder
5. Замечания исполнителя
5.1 Версия
Это версия 1.0.1 спецификации, и будут сделаны все попытки сделать будущие версии обратно совместимыми, если это возможно.
5.2 Руководство по партии
5.2.1 SSP/EXCHANGE
Поставщики общих услуг и биржи должны решить, какой канонический домен они хотят использовать в поле # 1. Они должны сделать документацию доступной для издателей и DSP. В документации к издателю должно быть указано, как издатели могут получить соответствующий идентификатор для поля № 2. Документация по DSPfacing должна указывать, какое поле в запросах ставок должно использоваться DSP для проверки по файлу ads.txt.
Рекомендуется, чтобы любая система, создающая запросы ставок OpenRTB, помещала идентификатор учетной записи продавца в поле Publisher.ID. Также убедитесь, что поле Site.Domain заполнено доменом, в котором размещен файл ads.txt, где публикуется идентификатор учетной записи.
В идеале реализация SSP / бирж должна предоставлять инструмент для генерации точных строк, которые издатель должен разместить в файле ads.txt. SSP / биржи должны также учитывать сканирование доменов издателей и уведомление издателей (например, предупреждение на панели издателей, электронная почта и т. д.) Об отсутствии файла ads.txt или об отсутствии соответствующих объявлений в файле.
5.2.2 DSP
DSP должны ознакомиться с документацией, предоставленной поставщиками общих услуг / биржами, относительно канонического домена, используемого биржей (поле # 1), и соответствующего поля в запросах ставок, которое должно быть сверено с ads.txt (поле # 2).
5.2.3 Издатели
Издатели должны ознакомиться с документацией, предоставленной поставщиками общих услуг / биржами, относительно канонического домена, используемого биржей (поле № 1), и соответствующего идентификатора для размещения в поле № 2.
5.3 Совместимость
Разработчики должны обратить особое внимание на надежность анализа файла /ads.txt. Ожидается, что файлы /ads.txt создаются с помощью автоматизированных систем или ручных текстовых редакторов, ориентированных на платформу. Потребители данных должны быть свободны в приеме файлов с различными соглашениями в конце строки, в частности, CR и LF в дополнение к CRLF и различные пробелы или символы разделения поля.
5.4 Безопасность
Объявления /ads.txt извлекаются и применяются в отдельных, возможно неаутентифицированных HTTP-транзакциях, и возможно, что один сервер может выдать себя за другой или иным образом перехватить запрос для /ads.txt и предоставить системе-потребителю ложную информацию.
Если это вызывает беспокойство, то владелец веб-сайта должен перенаправить незащищенные http-запросы на https-запросы для файла /ads.txt.
5.5 Поддомены
При написании сканеров разработчики должны запрашивать /ads.txt из корневых доменов, которые вызывают значительные запросы на рекламу. Издатели всегда должны публиковать файл /ads.txt в своем корневом домене. Сканер должен удалить субдомены при создании списка URL-адресов искателя. Публичный список суффиксов [12] [16] должен использоваться при реализации удаления поддоменов.
В тех случаях, когда определенные субдомены имеют разные авторизованные рекламные системы, издатель должен публиковать файлы ads.txt только на этих субдоменах и явно объявлять каждый из этих субдоменов в ads.txt в корневом домене с помощью переменной «subdomain =». Искатели должны сканировать только файлы ads.txt на поддоменах, которые перечислены с помощью переменной «subdomain =» в файле ads.txt в корневом домене.
Когда ads.txt в корневом домене объявляет субдомен и в этом субдомене существует ads.txt, только рекламные системы, перечисленные в субдомене ads.txt, имеют право продавать ресурсы на этом субдомене. Когда ads.txt в корневом домене не объявляет поддомен или ads.txt не существует на поддомене, только рекламные системы, перечисленные в корневом домене ads.txt, имеют право продавать ресурсы на этом поддомене.
5.6 ADS.TXT обходчики
Эталонную реализацию сканера данных ads.txt можно найти на github [15].
Сканеры, которые могут захотеть сканировать контент издателя за пределами ads.txt и читать и отображать контент издателя, рекламные объявления и связанные метаданные, могут сделать это, если это не запрещено инструкциями в файле robots.txt.
6. Сфера и будущие направления
6.1 Сфера
Целью этой первоначальной версии этого стандарта является определение механизма определения авторизованных продавцов веб-контента с точки зрения владельца домена с целью рассмотрения некоторых сценариев мошенничества, связанных с контрафактной инвентаризацией.
6.2 Открытые вопросы
Об открытых проблемах, которые будут рассмотрены для решения в будущей версии спецификации, следует обратить на себя внимание, связавшись с openrtb@iabtechlab.com или в списке рассылки openrtb-dev@googlegroups.com.
6.3 Будущие направления
Будущие направления включают в себя покрытие разрешенных форматов рекламы, распространение и делегирование полномочий третьей стороне.
7. Благодарности
Авторы хотели бы поблагодарить оригинальных авторов файла robots.txt [5] [6] за предоставленную информацию. Мы также хотели бы поблагодарить многочисленных людей из технической лаборатории IAB, TAG и нескольких компаний за их комментарии к ранним проектам и поддержку этой инициативы.
8. Ссылки
1. https://techcrunch.com/2016/01/06/the-8-2-billion-adtech-fraud-problem-that-everyone-is-ignoring/
2. http://adage.com/article/digital/ana-report-7-2-billion-lost-ad-fraud-2015/302201/
3. http://boingboing.net/2016/12/21/methbot-a-3m-5mday-video-a.html
4. https://www.emarketer.com/Article/Ad-Industrys-Focus-on-Fraud-HasIntensified/1014430
5. http://www.robotstxt.org/norobots-rfc.txt
6. https://en.wikipedia.org/wiki/Robots_exclusion_standard
7. https://www.iab.com/guidelines/real-time-bidding-rtb-project/
8. https://developers.google.com/ad-exchange/rtb/downloads
9. https://www.iab.com/guidelines/iab-opendirect-specification/
10. https://tools.ietf.org/html/rfc1123
11. https://www.tagtoday.net
12. https://publicsuffix.org/
13. https://www.w3schools.com/tags/ref_urlencode.asp
14. http://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf
15. https://github.com/InteractiveAdvertisingBureau/adstxtcrawler
16. https://publicsuffix.org/list/public_suffix_list.dat
