Ads.txt: Oder was leistet die Werbebranche gegen Ad Fraud?

Bisher hat die Buyside sich mittels Technologieunternehmen weitestgehend vor unerwünschten Werbeauslieferungen geschützt. Nun zieht die Sellside nach. Das Problem der Publisher ist neben dem unerlaubten Wiederverkauf besonders das Domain Spoofing, also der Missbrauch einer bekannten Domain, um dann auf einer unerwünschten Seite die Werbung auszuliefern. Bislang waren die Publisher nicht in der Lage, den Domainmissbrauch zu stoppen und dadurch Geldströme Richtung Ad Fraud zu unterbinden. Nun leistet die ads.txt Initiative Abhilfe.

Ads.txt: schnelle Transparenz und Sicherheit

Mit der ads.txt Initiative des Initiative des International Advertising Bureau (IAB), werden die Publisher aktiv in den Prozess eingebunden. Mit der Mission von ads.txt verfolgt der IAB ein zentrales Ziel „Increase transparency in the programmatic advertising ecosystem“. Indem die Publisher öffentlich ihre lizensierten Vertriebspartner nennen, erschwert dies den Missbrauch mit den Domainnamen und sorgt für vollständige Klarheit über die Verkäuferbeziehungen.

Entsprechend steht „ads“ für „authorized digital sellers“. Ads.txt gibt dem Publisher die volle Kontrolle darüber, wer mit seinem Inventar handeln darf. Sollten nicht autorisierte Zwischenhändler Impressions im programmatischen Handel kaufen und wiederverkaufen wollen, ist dies nur noch mit ausdrücklichen Erlaubnis des Publishers möglich. So kann die jeweilige Supply Side Plattform / SSP die Herkunft und Autorisation jeder Impression verifizieren, nicht autorisierte Reseller identifizieren und blockieren. Und zwar wie folgt:

Ads.txt ist eine kleine Textdatei, die in den Quellcode der Seite integriert wird und in der die autorisierten Exchanges/SSPs sowie die dazugehörigen einzigartigen IDs der Partner gelistet sind.

Der File beinhaltet folgende Informationen, erklärt

1. Die Exchange/SSP, z.B. google, yieldlab, pubmatic etc.
2. Die Account ID beim Partner
3. Die Partnerbeziehung: DIREKT = Der Publisher hat eine direkte Beziehung zur SSP; RESELLER = Der Publisher hat einen Zwischenhändler autorisiert, über die SSP das Inventar zu verkaufen

Der Einsatz von ads.txt hat sich innerhalb der letzten 12 Monate sehr verbreitet und die meisten deutschen Publisher, haben die Textfiles implementiert. Schaut man sich die reichweitenstarken, werbefinanzierten Seiten im deutschen Markt an, haben fast alle erfolgreich ads.txt eingebaut.

Die Ankündigung großer DSPs, nur noch auf ads.txt nutzenden Seiten auszuliefern, hat sicherlich den relevanten Druck ausgeübt, dass die Implementierung rasches Wachstum auch im deutschen Markt erfuhr und erfährt. Dabei ist die Freiheit der Gestaltung weiterhin gegeben. So nutzt es Youtube für eine klare Aussage:

# youtube.com/ads.txt
#
# YouTube inventory can only be purchased from AdWords and DoubleClick
# Bid Manager (DBM), and cannot be purchased programmatically through
# open exchanges. Therefore there are no authorized sellers or resellers
# listed in this youtube.com/ads.txt file.

Andere haben die Zeit der vergangenen Monate genutzt ihr Listen auszuweiten und versucht, ihre differenzierte Direkt/Reseller Partner sichtbar zu strukturieren. Dadurch kann bei manchen Sites erkannt werden, wer das Video-Inventar, wer das Display-Inventar und wer z.B. Das Mobile-App Inventar vermarkten darf. Dabei wird sehr schnell klar, dass die Listen weniger zum Einblick für den Käufer in Form einer lebenden Person (zu finden unter domainname/ads.txt oder Browser Plugins), sondern für die Systeme zum maschinellen Auslesen geeicht wurden.

Hatte man vor ads.txt im DSP Reporting die Frage, wer wirklich autorisiert ist zu verkaufen, steht man nun vor einem Wust von autorisierten Verkäufern und fragt sich, wie fange ich denn jetzt an, meine Einkaufsstrategie mit der Vielzahl der Partner zu überblicken und sich dabei Fragen zu beantworten, wer denn jetzt genau welches Inventar anbietet, zu welchem Auktionsmodell, 1st oder 2nd Price? Der Trend bei vielen Vermarktern scheint wieder weg von einer klaren, strategischen Struktur hin zu einer Massendistribution zu gehen. Je mehr Partner, desto mehr Umsatzmöglichkeiten.

Im Zeitalter von Headerbidding und AdServer-Priorisierung stellt sich die Frage, mit wie vielen Geboten mittlerweile konkurriert wird.

Leider bieten die meisten DSPs noch nicht die Möglichkeit, auf ads.txt Seiten zu targeten, die Buyer müssen dem Tun der DSPs einfach Vertrauen schenken, was im deutschen Markt der Analytiker schwerfällt.

Nichtsdestotrotz ist ads.txt unbestritten ein wertvoller Beitrag, mit AdFraud umzugehen und die nicht autorisierten Quellen zu eliminieren.

Schwachstelle von ads.txt

Allerdings erlaubt ads.txt nur den BidRequest auszulösen und zu kaufen. Der Inhalt des BidRequests bleibt dabei unbeachtet.

Wir haben schon Fälle gesehen, wo trotz ads.txt Pre-Rolls auf kleinen Medium Rectangles gelaufen sind und die Ableitung, wie das passieren konnte, sehr aufwendig war. Sowas kann ads.txt nicht verhindern, es wird aber weiterhin ein schlechtes Licht auf den programmatischen Einkauf. Dafür hat der IAB die Erweiterung von ads.txt, ads.cert, ins Leben gerufen.

Was macht jetzt ads.cert?

Ads.cert soll den Inhalt des BidRequests zertifizieren, u.a. das Endgerät, die Größe des Players oder der Werbefläche, wo sich der AdSlot auf der Seite befindet übermitteln. Somit kommt weitere Transparenz in die Supply Chain.

Leider ist die Implementierung von ads.cert aufwendiger als die von ads.txt. Es ist noch in der Entwicklungsphase und bedarf eines größeren technischen Aufwands, ist zur Zeit mit IAB’s Open RTB 3.0 kompatible. Daher bleibt zu hoffen, dass mit ads.txt weiterhin unautorisierten Sellern der Zugang zu Umsätzen verwehrt werden kann und sich autorisierte Seller an den Code of Conduct halten bis ads.cert Missstände flächendeckend offenlegen kann.

Bis dahin stehen weiterhin die Technologieunternehmen Gewehr bei Fuß.