Ads.txt
Definition: Ads.txt steht für "Authorized Digital Sellers" und ist ein im Jahr 2017 vom Interactive Advertising Bureau (IAB Tech Lab) entwickelter Standard zur Bekämpfung von Werbebetrug im programmatischen Ökosystem. Das Kernprinzip ist denkbar einfach, aber wirkungsvoll: Publisher hinterlegen auf ihrer Domain eine öffentlich zugängliche Textdatei unter dem Pfad domain.com/ads.txt, in der sie alle Unternehmen auflisten, die offiziell berechtigt sind, ihr Werbeinventar zu verkaufen oder weiterzuvermitteln. Werbetreibende und deren Demand-Side-Plattformen (DSPs) können diese Datei automatisch abrufen und prüfen, ob der im Bieterverfahren angebotene Inventarverkäufer tatsächlich vom Publisher autorisiert ist. Wenn eine Impression über einen Verkäufer angeboten wird, der nicht in der Ads.txt-Datei des Publishers steht, handelt es sich mit hoher Wahrscheinlichkeit um gefälschtes oder nicht autorisiertes Inventar. Ads.txt löst damit das Problem des Domain Spoofings, bei dem betrügerische Akteure qualitativ hochwertige Publisher-Domains imitieren, um höhere Preise zu erzielen. Der Standard wurde später durch App-ads.txt für mobile Apps und Sellers.json für die Exchange-Seite ergänzt, um die gesamte Supply Chain transparenter zu gestalten und Invalid Traffic systematisch zu reduzieren.
Erläuterung
Bevor Ads.txt eingeführt wurde, gab es in der programmatischen Werbung keine verlässliche Möglichkeit für Einkäufer, zu verifizieren, ob das in einer Auction angebotene Inventar tatsächlich vom angegebenen Publisher stammte. Betrüger nutzten diese Lücke systematisch aus, indem sie Inventar im Namen renommierter Publisher anboten – in Wirklichkeit aber entweder minderwertiges Traffic-Inventar verkauften oder in SSP-Systemen schlicht eine falsche Domain-Angabe hinterlegten. Werbetreibende zahlten Premium-Preise für vermeintliches Premiuminventar, das in Wirklichkeit wertlos oder gefälscht war. Dieser als Domain Spoofing bekannte Betrug verursachte der Branche Schäden in Milliardenhöhe pro Jahr.
Ads.txt schafft durch Dezentralisierung der Verifikation eine elegante Lösung: Da der Publisher selbst die Datei auf seiner eigenen Domain hostet, kann niemand außer dem tatsächlichen Domain-Betreiber diese Datei manipulieren. Ein Betrüger, der vorgibt, Inventar von spiegel.de zu verkaufen, kann die Datei unter spiegel.de/ads.txt nicht verändern, um sich selbst als autorisierten Verkäufer einzutragen. Käufer rufen daher die Ads.txt-Datei des angeblichen Publishers automatisch ab und gleichen ab, ob der anbietende Verkäufer dort gelistet ist.
Jede Zeile in einer Ads.txt-Datei enthält drei Pflichtfelder und ein optionales viertes: den Domain-Namen des Werbevermarktungssystems (z.B. googlesyndication.com), die Publisher-Account-ID bei diesem System, den Beziehungstyp (DIRECT oder RESELLER) sowie optional eine Zertifizierungs-ID (TAG-ID). DIRECT kennzeichnet eine direkte Vertragsbeziehung zwischen Publisher und dem genannten System. RESELLER bedeutet, dass ein Zwischenhändler das Inventar im Namen des Publishers weiterverkauft, ohne direkte Vertragsbeziehung. Diese Unterscheidung hilft Käufern, die Komplexität der Supply Chain zu beurteilen und kürzere, direktere Wege zu bevorzugen.
Aufbau und technische Implementierung
- Datei-Hosting: Die Datei muss unter der Root-Domain zugänglich sein (example.com/ads.txt). Sie ist eine einfache Textdatei ohne besondere Formatierungsanforderungen außer dem definierten Zeilenformat.
- Zeilenformat: Jeder Eintrag folgt dem Schema: SSP-Domain, Publisher-Account-ID, Beziehungstyp, optionale Autorisiierungs-ID. Beispiel: googlesyndication.com, pub-1234567890, DIRECT, f08c47fec0942fa0
- Crawler-Abfrage durch DSPs: Demand-Side-Plattformen und Verifikationsanbieter crawlen regelmäßig die Ads.txt-Dateien aller bekannten Publisher-Domains und speichern die Ergebnisse in lokalen Datenbanken für den Echtzeit-Abgleich während Auctions.
- Fehlende oder leere Datei: Wenn keine Ads.txt-Datei vorhanden ist, können Käufer das Inventar als ungeprüft behandeln oder gemäß eigener Policy blocken. Eine leere Datei signalisiert explizit, dass kein Verkäufer autorisiert ist.
- App-ads.txt: Die Erweiterung für mobile Apps hostet die Datei auf der Domain des App-Entwicklers und verknüpft sie mit den App-Store-Einträgen, um auch mobiles In-App-Inventar zu verifizieren.
Grenzen und Ergänzungsstandards
- Keine Lösung für alle Betrugsformen: Ads.txt bekämpft Domain Spoofing effektiv, adressiert aber nicht Bot Traffic, Ad Stacking oder Pixel Stuffing. Für diese Probleme sind separate Verifikationslösungen erforderlich.
- Sellers.json als komplementärer Standard: Während Ads.txt auf Publisher-Seite die autorisierten Verkäufer deklariert, listet Sellers.json auf SSP- und Exchange-Seite alle Publisher auf, deren Inventar über die Plattform angeboten wird. Beide Standards gemeinsam ermöglichen eine bidirektionale Verifikation der Supply Chain.
- Supply Chain Object (schain): Das schain-Objekt im OpenRTB-Protokoll ergänzt Ads.txt um eine Echtzeitkomponente, die den gesamten Weitervermittlungspfad einer Impression direkt in der Bid Request dokumentiert und so transparente Nachverfolgung ermöglicht.
- Pflegeaufwand und Fehlerrisiko: Publisher mit vielen SSP-Partnerschaften müssen ihre Ads.txt-Dateien regelmäßig aktualisieren. Veraltete oder unvollständige Einträge führen dazu, dass legitimes Inventar fälschlicherweise geblockt wird und Einnahmen verloren gehen.
- Hohe Adoptionsrate: Die Adoptionsrate von Ads.txt ist unter Premium-Publishern und professionellen Plattformen sehr hoch. Im Long-Tail-Bereich gibt es noch Lücken, die Betrüger nutzen können.