Authorized Digital Seller - Ads.txt - per Datei festlegen, wer Werbung für die eigene Website verkaufen darf - fehlende Datei erlaubt alles, leere Datei und Http-Status 200 verbietet alles

16.12.2017 23:45:14, Jürgen Auer, keine Kommentare

Wer eine Webanwendung betreibt und Einblick in das Protokoll hat, dem werden diese Zugriffe in den letzten Monaten sicherlich schon aufgefallen sein.

Crawler suchen nach einer Datei /ads.txt, die - ähnlich wie die /robots.txt - im Stammverzeichnis der Website gesucht wird.

Was steckt da dahinter? Und: Soll man so eine Datei anlegen?

Das Problem ist einfach: Bei Werbung im Internet gibt es sehr viel an Missbrauch. Große Websites verkaufen ihre Werbung über einen oder mehrere Dienstleister. Diese suchen nach Kunden, die bei ihnen Werbung buchen. Und werben natürlich selbst bsp. damit, daß man bei ihnen Werbung bei der "großen Zeitung XY" buchen könne.

Aber: Stimmt diese Aussage? Praktisch müssen sich die Werbeeinkäufer darauf verlassen, daß solche Behauptungen korrekt sind. Tatsächlich gibt es manches an Betrug. So daß Werbeplätze bsp. bei großen Zeitungen eingekauft werden, dort aber niemals ausgespielt werden. Stattdessen werden die - teuer bezahlten - Anzeigen auf zwielichtigen Seiten ausgespielt und schaden damit der Marke. Oder es sind Fake-Domains, die Klicks stammen von Botnetzen.

So berichtete Google erst vor wenigen Tagen, daß für manche Websites teils 50-mal mehr Werbung verkauft als tatsächlich ausgespielt wurde. Der jährliche Schaden wurde auf etwa 1,27 Milliarden Dollar geschätzt.

Die Lösung dieses Problems: Eine simple Textdatei ads.txt, die im Stammverzeichnis der Website abgelegt wird und die per Crawler abgerufen werden kann. Ads ist die Abkürzung für "Authorized Digital Seller".
.

About ads.txt

https://iabtechlab.com/ads-txt-about/

.
In dieser wird definiert, wer befugt ist, Werbung für diese Website anzubieten. Das können drei verschiedene Typen sein:

> Domain owners who sell on exchanges through their own accounts
> Networks and sales houses who programmatically sell on behalf of domain owners
> Content syndication partnerships where multiple authorized sellers represent the same inventory

Die Domainowner können Werbung direkt verkaufen. Oder Netzwerke, die vom Domaininhaber autorisiert sind, per programmatischem Advertising Werbung für diese Domain anzubieten.

Eine typische ads.txt - Datei kann bsp. so aussehen:

-- Beginn 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
-- Ende ads.txt

Das sind drei oder vier kommagetrennte Ausdrücke. Der erste Ausdruck nennt die Domain, über die Werbung auf example.com gebucht werden darf. Der zweite Ausdruck ist die - eindeutige - Reseller-Id. Der dritte Ausdruck ist der Typ: DIRECT bedeutet, daß der Domaininhaber das System selbst kontrolliert. Das vierte Feld kann eine "certification authority ID" sein und ist optional.

Wer nun Werbung auf der Domain example.com buchen möchte und von dem Unternehmen greenadexchange.com angesprochen wird: Der kann sich sicher sein, daß die Werbung auch auf example.com ausgespielt wurde.

Oder - aus dem obigem Text vor dem ads.txt - Standard:

> While every impression already includes publisher information from the OpenRTB protocol, including the page URL and Publisher.ID, there is no record or information confirming who owns each Publisher.ID, nor any way to confirm the validity of the information sent in the RTB bid request, leaving the door open to counterfeit inventory.

Über das OpenRTB-Protokoll erfährt der Werbebuchende zwar die Publisher ID. Aber er wußte bislang nicht, ob diese Publisher-Id autorisiert ist, Werbung auf der gebuchten Seite zu verkaufen. Diese Informationslücke schließt die ads.txt.

Wirkung: Der Werbebuchende kann die ads.txt crawlen. Und damit prüfen, ob das Versprechen des Vermittlers "Bei uns können Sie Werbung für die Zeitung XY buchen" auch erfüllbar ist.

Im Juni 2017 gab es die Version 1.0, seit September 2017 gibt es die Version 1.0.1.

Ads.txt – Authorized Digital Sellers

https://iabtechlab.com/ads-txt/

Die Spezifikation: Ads.txt Specification Version 1.0.1

https://iabtechlab.com/wp-content/uploads/2017/09/IABOpenRTB_Ads.txt_Public_Spec_V1-0-1.pdf

Diese in Kürze:

Man legt eine einfache Textdatei /ads.txt im Stammverzeichnis an. Analog zur robots.txt. Der Content-Type kann Content "text/plain" oder "text/plain; charset=utf-8" sein. Diese enthält Zeilen nach dem obigen Muster. Alle Zeilen, die mit # beginnen, sind Kommentare. In der Version 1.0.1 ist neu ein Kontaktfeld dazugekommen.

contact=info@sql-und-xml.de
contact=https://beispiel.server-daten.de/kontakt.html

Wenn die Datei mit einem Http-Status 200 ausgeliefert wird, muß sie geparst und beachtet werden. Fehlt die Datei und wird ein Http-Status 404 ausgeliefert, dann gilt (Seite 6 PDF):

> If the server response indicates the resource does not exist (HTTP Status Code 404), the advertising system can assume no declarations exist and that no advertising system is unauthorized to buy and sell ads on the website.

Sprich: Fehlt die Datei, dann gibt es keine Einschränkungen. Jeder kann - angeblich oder tatsächlich - für diese Website Werbung verkaufen.

Die Konsequenz: Eine leere ads.txt anlegen bzw. eine ads.txt definieren, die nur eine Zeile mit einem Kommentar (führendes #) enthält. Das sorgt dafür, daß niemand für die eigene Website Werbung anbieten darf.

Nach der Lektüre dieser Information hatte ich mir für die www.sql-und-xml.de und die www.server-daten.de sowie alle Kundensubdomains so eine Logik angelegt. Es wird eine Datei mit einem Kommentar und Kontaktinformationen, aber ohne Informationen zu zulässigen Werbenetzwerken ausgeliefert. Etwa hier zum Blog:

https://blog.server-daten.de/ads.txt

Wenn man bei großen Zeitungen (nytimes.com, tagesspiegel.de, welt.de) testet, dann finden sich diverse Informationen und teils sehr lange Listen. Wobei es auch Fehler gibt - die New York Times leitet Benutzer auf die https-Version um. Die ads.txt wird aber umgekehrt auf die unverschlüsselte Version umgeleitet. Das sollte höchstens umgekehrt sein.

Der Hinweis zu den geschätzt 1,27 Milliarden Dollar Schaden und der Google-Untersuchung fand sich hier:

Google: Werbebetrüger kassierten 1,27 Milliarden Dollar pro Jahr

https://www.heise.de/newsticker/meldung/Google-Werbebetrueger-kassierten-1-27-Milliarden-Dollar-pro-Jahr-3916667.html

Praktisch könnten solche Betrugsmaschen per ads.txt massiv gestoppt werden. Insofern ist jede vorhandene ads.txt ein Signal an mögliche Betrüger: "Diese Domain sollte man lieber nicht anbieten. Das könnte ins Auge gehen".

Laut einem Artikel vom 22.11.2017

Report: Mäßiger Etablierungsgrad von Ads.txt in Deutschland

https://www.adzine.de/2017/11/report-maessiger-etablierungsgrad-von-ads-txt-in-deutschland/

sind ads.txt - Dateien bei deutschen Websites noch sehr gering verbreitet. Bei weltweit 2 Millionen Domains, davon 59.000 aus Deutschland, hatten nur etwa 2,5 % der deutschen Publisher eine ads.txt implementiert. Den höchsten Wert gibt es für Schweden mit 8,9 % Verbreitung. Deutschland liegt auf Platz 28. Mit etwa 1.400 Domains.

*
* (wird nicht angezeigt)
Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.