ads.txt, app-ads.txt und sellers.json erklärt – für Programmatic Buyer

Jede programmatic Transaktion beruht auf einer einfachen Annahme: Der Verkäufer, der die Impression anbietet, ist tatsächlich berechtigt, sie zu verkaufen. Über weite Strecken der Branchengeschichte hatten Käufer keine verlässliche Möglichkeit, diese Annahme zu prüfen, bevor sie Budget dafür ausgaben. Domain Spoofing, bei dem betrügerische Verkäufer sich als Premium-Publisher ausgeben, kostete Advertiser echtes Budget, ohne dass sich das in Echtzeit erkennen ließ.

Drei Dateien haben diese Lücke geschlossen: ads.txt, app-ads.txt und sellers.json. Gemeinsam ermöglichen sie es einem Käufer oder der DSP, die in seinem Auftrag bietet, zu bestätigen, dass ein bestimmter Verkäufer berechtigt ist, das Inventar eines bestimmten Publishers zu verkaufen, und zwar bevor auch nur ein einziges Gebot abgegeben wird. Keine dieser Dateien ist kompliziert, sobald man die einzelnen Bausteine kennt. Die Begriffe überschneiden sich jedoch so stark, dass DSP-Betreiber und Media Buyer die Namen oft synonym verwenden, obwohl jede Datei eine andere Frage beantwortet.

Dieser Leitfaden erklärt, was die einzelnen Dateien tatsächlich sind, wie sie über das OpenRTB-Supply-Chain-Objekt zusammenwirken, wie ein DSP-Betreiber sie in der Praxis prüfen sollte und was mit Kampagnen passiert, die diese Prüfung auslassen.

Was ist ads.txt und warum gibt es die Datei?

ads.txt steht für Authorized Digital Sellers. Es handelt sich um eine einfache Textdatei, die ein Website-Publisher an einem festen, vorhersehbaren Ort bereitstellt: example.com/ads.txt. Die Datei führt jedes Unternehmen auf, das das Werbeinventar dieses Publishers programmatic verkaufen darf, mit einer Zeile pro autorisiertem Verkäufer.

Das IAB Tech Lab führte ads.txt 2017 gezielt ein, um Domain Spoofing zu unterbinden. Dabei gab ein betrügerischer Verkäufer vor, Inventar eines bekannten Publishers weiterzuverkaufen, der ihn nie autorisiert hatte. Vor ads.txt hatte eine DSP keine unabhängige Möglichkeit, diese Behauptung zu überprüfen; sie vertraute entweder der SSP, die den Bid Request weiterleitete, oder eben nicht. Mit ads.txt erhielten Käufer stattdessen eine öffentliche, vom Publisher kontrollierte verlässliche Referenz, anhand derer sie prüfen konnten.

Jede Zeile einer ads.txt-Datei folgt einem festen Format: die Domain der SSP, die Seller-Account-ID des Publishers bei dieser SSP, ein Beziehungstyp (DIRECT oder RESELLER) sowie optional eine Certification-Authority-ID. DIRECT bedeutet, dass der Publisher ein direktes Konto bei dieser SSP hat. RESELLER bedeutet, dass die SSP berechtigt ist, das Inventar im Auftrag eines anderen Intermediärs weiterzuverkaufen, was bei Ad-Network- und Aggregator-Konstellationen üblich ist.

app-ads.txt: Dasselbe Prinzip für mobile Apps

ads.txt wurde für Websites entwickelt, die eine Domain haben, auf der die Datei gehostet werden kann. Mobile Apps haben keine Domain im selben Sinne. Deshalb veröffentlichte das IAB Tech Lab 2019 app-ads.txt, um dieselbe Lücke für In-App-Inventar zu schließen.

Statt in der App selbst liegt eine app-ads.txt-Datei auf der Domain, die im Store-Eintrag der App als Website des Entwicklers angegeben ist, unter developer-domain.com/app-ads.txt. Sie verwendet exakt dasselbe Zeilenformat wie ads.txt: SSP-Domain, Seller-Account-ID, DIRECT oder RESELLER sowie optional eine Certification-ID. Eine DSP, die einen In-App-Bid-Request überprüft, ermittelt die angegebene Website des Entwicklers aus dem im Bid Request referenzierten Store-Eintrag und prüft dann die app-ads.txt-Datei dieser Domain auf die SSP, die den Request sendet.

sellers.json und das Supply-Chain-Objekt: Das Gesamtbild vervollständigen

ads.txt und app-ads.txt beantworten eine Frage: Ist diese SSP berechtigt, das Inventar dieses Publishers zu verkaufen? Für sich genommen verraten sie einem Käufer jedoch nichts über die SSPs und Intermediäre, die zwischen Publisher und DSP stehen, wenn eine Kette von Resellern beteiligt ist. Genau dafür gibt es sellers.json und das OpenRTB-Objekt SupplyChain, häufig als schain abgekürzt.

sellers.json ist eine Datei, die jede SSP oder Exchange auf ihrer eigenen Domain veröffentlicht. Sie listet jeden Seller-Account auf, den sie betreibt oder vertritt, jeweils mit dem Seller-Typ (Publisher, Intermediär oder beides) und optional mit Name und Domain des Verkäufers. Das schain-Objekt wird im Bid Request selbst mitgeführt und listet der Reihe nach jeden Intermediär auf, den die Impression auf ihrem Weg vom Publisher zur DSP durchlaufen hat. Durch den Abgleich der schain-Knoten mit der sellers.json-Datei jeder SSP kann ein Käufer bestätigen, dass jede Station der Kette eine deklarierte, identifizierbare Partei ist und kein unbenannter Durchleiter.

Zusammen eingesetzt ermöglichen diese vier Bausteine der Bidding-Logik einer DSP, bei jedem einzelnen Bid Request zu bestätigen, dass das angebotene Inventar über einen vom Publisher autorisierten Pfad kommt und nicht über einen unverifizierten oder gefälschten.

So prüfen Sie die Autorisierung über ads.txt und sellers.json in der Praxis

Die Prüfung der Supply-Chain-Autorisierung ist keine einmalige Einrichtungsaufgabe. Sie läuft kontinuierlich, idealerweise als automatisierter Schritt in der Bidding-Pipeline statt als manuelles Audit. Ein praxistauglicher Prüfprozess sieht so aus:

1. ads.txt- bzw. app-ads.txt-Dateien der Publisher und Apps, die Traffic senden, abrufen und cachen und den Cache regelmäßig aktualisieren, da Publisher diese Dateien ohne Vorankündigung ändern.
2. Die Publisher-Domain oder das App-Bundle des eingehenden Bid Requests mit der gecachten Datei abgleichen und bestätigen, dass die sendende SSP mit dem korrekten Beziehungstyp aufgeführt ist.
3. sellers.json-Dateien aller angebundenen SSPs abrufen und cachen und auch diese regelmäßig aktualisieren, nicht nur zum Zeitpunkt der Integration.
4. Das schain-Objekt jedes Bid Requests parsen und bestätigen, dass sich jeder Knoten einem Seller-Account zuordnen lässt, der in der entsprechenden sellers.json-Datei aufgeführt ist.
5. Bid Requests markieren oder verwerfen, bei denen die SSP in der ads.txt komplett fehlt, mit dem falschen Beziehungstyp aufgeführt ist oder bei denen sich ein schain-Knoten nicht über sellers.json auflösen lässt.
6. Autorisierungsfehler pro SSP protokollieren, damit ein Muster wiederholter Fehler aus einer Quelle, im Gegensatz zu einem einmaligen Ausreißer, für eine manuelle Überprüfung der Anbindung markiert wird.

Diese Prüfung gehört auf die technische Checkliste, bevor eine neue SSP an eine DSP angebunden wird, und sie sollte nach dem Livegang der Anbindung regelmäßig wiederholt werden, nicht nur einmal beim Onboarding. Supply-Quellen ändern im Laufe der Zeit, was sie repräsentieren, und eine Anbindung, die bei der Einrichtung sauber war, bleibt das nicht zwangsläufig.

Was schiefgeht, wenn diese Dateien fehlen oder ignoriert werden

Ein Publisher ohne ads.txt-Datei oder eine SSP ohne sellers.json-Datei ist nicht automatisch betrügerisch. Viele kleinere oder neuere Publisher haben die Dateien schlicht noch nicht eingerichtet. Aus Käufersicht hat nicht verifizierbares Inventar jedoch ein Risikoprofil, das eher dem von unverifiziertem Inventar entspricht als dem von Inventar, das eine Prüfung bestanden hat.

DSPs, die die Prüfung ganz auslassen oder nur einmal bei der Integration prüfen und danach nie wieder, stoßen meist auf dieselben wenigen Probleme: Budget fließt in Inventar mit gefälschter Domain, das nie die echte Zielgruppe erreicht, die es vorgibt; eine schain mit nicht auflösbaren oder anonymen Intermediären macht es unmöglich zu wissen, wie viele Parteien zwischen Publisher und DSP einen Anteil am Mediabudget einbehalten; und es kommt zu Brand-Safety-Vorfällen, bei denen ein Advertiser im Nachhinein feststellt, dass seine Anzeigen über einen Reseller-Pfad ausgeliefert wurden, den auf Käuferseite niemand tatsächlich verifiziert hatte.

Keines dieser Ergebnisse setzt voraus, dass auf Käuferseite jemand böswillig handelt. Sie sind schlicht die Standardfolge, wenn ein Verifizierungsschritt, der automatisiert laufen könnte, in der Pipeline fehlt.

Häufige Fehler programmatic Käufer bei der Supply-Verifizierung

• ads.txt einmalig beim SSP-Onboarding prüfen und die gecachte Datei danach nie aktualisieren, sodass spätere Änderungen der Publisher übersehen werden.
• Eine RESELLER-Zeile genauso behandeln wie eine DIRECT-Zeile, ohne zu prüfen, ob die Reseller-Kette in sellers.json tatsächlich korrekt deklariert ist.
• app-ads.txt-Prüfungen bei In-App-Traffic auslassen, weil der Workflow ursprünglich nur für Web-Inventar entwickelt wurde.
• Autorisierungsfehler protokollieren, sie aber nie auswerten, sodass eine wiederholt fehlschlagende SSP-Anbindung monatelang unbemerkt bleibt.
• Annehmen, dass eine große, bekannte SSP nicht so gründlich geprüft werden muss wie eine kleinere, obwohl die Autorisierung unabhängig von der Gesamtgröße der SSP auf Ebene einzelner Seller-Accounts scheitern kann.

Diese Art der Supply-Verifizierung steht neben der übergeordneten Disziplin der Supply Path Optimization, bei der es darum geht, jede Impression über den saubersten verfügbaren Pfad zu leiten, sobald sich mehrere Quellen überschneiden. Die Verifizierung bestätigt, dass ein Pfad legitim ist; die Optimierung entscheidet, welcher legitime Pfad sich lohnt. Eine DSP braucht beides, und keines kann das andere ersetzen.

Warum das für DSP-Betreiber wichtiger ist als für Werbetreibende auf einer Managed-Plattform

Advertiser, die über eine verwaltete DSP eines Drittanbieters einkaufen, vertrauen in der Regel darauf, dass die Plattform diese Prüfungen für sie durchführt, ohne viel Einblick in deren Gründlichkeit zu haben. Ein DSP-Betreiber hat diese Abstraktionsebene nicht. Die Verifizierungs-Pipeline ist entweder in die Bidding-Logik der Plattform integriert oder nicht, und wenn nicht, übernimmt jede Kampagne, die über die Plattform läuft, diese Lücke.

Das ist einer der praktischen Gründe, warum Plattformbetreiber, die den Weg über White Label, Lizenz oder Übernahme mit einer Plattform gehen, in deren Bidding-Pipeline die Verifizierung über ads.txt, app-ads.txt und sellers.json bereits integriert ist, von einer grundlegend anderen Ausgangsposition starten als jemand, der die Prüflogik von Grund auf neu entwickelt. Die Plattformen von AdTech Europe führen diese Prüfungen für die mehr als 1.000 SSP-Integrationen durch, die vorkonfiguriert mitgeliefert werden, und derselbe Supply-Onboarding-Prozess, über den eine neue SSP in die Plattform aufgenommen wird, umfasst die Bestätigung, dass ihre sellers.json vorhanden ist, bevor Traffic fließt.

Bereit, programmatic Inventar über verifizierte Supply-Pfade einzukaufen?

AdTech Europe unterstützt Agenturen, Ad Networks und Media-Buying-Teams dabei, eine eigene DSP zu besitzen, statt nur Zugang zu einer zu mieten, mit Supply-Chain-Verifizierung über ads.txt, app-ads.txt und sellers.json, die vom ersten Tag an in die Bidding-Pipeline der Plattform integriert ist. Ob vollständig verwaltete White-Label-Plattform, lizenzierte DSP oder vollständige Übernahme des Quellcodes: Die aktuellen Preise für jedes Eigentumsmodell sind veröffentlicht und werden laufend aktualisiert.

Wenn Sie sehen möchten, wie die Supply-Chain-Verifizierung innerhalb der Plattform abläuft, oder ein Setup für Brand Safety und Betrugsprävention für einen konkreten Anwendungsfall besprechen möchten, vereinbaren Sie ein Strategiegespräch zu Programmatic mit dem Team von AdTech Europe.

FAQs

Was ist der Unterschied zwischen ads.txt und sellers.json?

ads.txt wird von einem Publisher veröffentlicht und listet auf, welche SSPs das Inventar dieses Publishers verkaufen dürfen. sellers.json wird von einer SSP veröffentlicht und listet auf, welche Seller-Accounts diese SSP betreibt oder vertritt. Ein Käufer prüft in der Regel beide Dateien zusammen mit dem schain-Objekt, um einen vollständigen Transaktionspfad zu verifizieren.

Ist app-ads.txt für Inventar in mobilen Apps vorgeschrieben?

Gesetzlich vorgeschrieben ist sie nicht, sie ist jedoch der Branchenstandard zur Verifizierung autorisierter Verkäufer bei In-App-Inventar, und die meisten großen SSPs und DSPs behandeln App-Traffic ohne gültigen app-ads.txt-Eintrag als unverifiziert.

Was bedeuten DIRECT und RESELLER in einer ads.txt-Datei?

DIRECT bedeutet, dass der Publisher eine direkte Kontobeziehung zu dieser SSP hat. RESELLER bedeutet, dass die SSP berechtigt ist, das Inventar im Auftrag eines anderen Intermediärs weiterzuverkaufen. Das ist üblich, wenn Inventar über ein Ad Network oder einen Aggregator läuft, bevor es die SSP erreicht.

Was ist das SupplyChain-Objekt (schain)?

Das schain-Objekt ist ein Feld im OpenRTB-Bid-Request, das der Reihe nach jeden Intermediär auflistet, den eine Impression zwischen dem Publisher und der SSP, die den Bid Request sendet, durchlaufen hat. So kann ein Käufer den vollständigen Supply-Pfad nachverfolgen und nicht nur die letzte Station.

Garantiert eine ads.txt, dass der Traffic frei von Betrug ist?

Nein. ads.txt bestätigt die Autorisierung, nicht die Traffic-Qualität. Auch ein ordnungsgemäß autorisierter Verkäufer kann minderwertigen oder ungültigen Traffic senden. Deshalb wird die Supply-Chain-Verifizierung in der Regel mit separaten Maßnahmen zur Traffic-Qualität und Betrugserkennung kombiniert und nicht als deren Ersatz betrachtet.

Wer ist für die Prüfung von ads.txt und sellers.json verantwortlich, die DSP oder die SSP?

In der Praxis liegt die Verantwortung auf der Käuferseite, da die DSP entscheidet, ob geboten wird. Manche SSPs führen eigene Prüfungen durch, bevor sie Bid Requests weiterleiten. Eine DSP, die sich ausschließlich auf die Filterung der SSP verlässt, verfügt jedoch über keine eigene, unabhängige Verifizierung.