Adzine Top-Stories per Newsletter
ADTECH

Open RTB Standard, warum eigentlich?

Von Frederik Timm, 11. Mai 2016
Foto: complize / photocase.de Foto: complize / photocase.de

Wer heutzutage sein Mediageschäft programmatisch abwickelt, der spricht häufig nur noch scherzhaft über die typischen Faxe im Anzeigengeschäft. Ist ein Deal zustande gekommen, wurden früher die Details meist per Fax mit dem Partner kommuniziert und besiegelt. Im Programmatic Advertising haben jedoch die Maschinen die Oberhand. Hier wird nicht das Faxgerät bemüht, sondern der Programmcode, um in möglichst kurzer Zeit – im Bruchteil von Sekunden – über Anzeigenplätze zu verhandeln und Werbemittel auszuliefern. Die Teilnehmer dieses Gesprächs sind SSPs, DSPs, DMPs, Exchanges, häufig sogar in mehrfacher Ausführung und von verschiedenen Anbietern. Wie kommunizieren so viele Systeme fehlerlos miteinander? Hat nicht jede Firma ihre eigenen Programmierer, die unterschiedliche Herangehensweisen an den Code dieser Maschinen haben? Die Antwort: der Open RTB Standard.

Die Entstehung: Elementare Prozesse vereinfachen

Als Programmatic noch in den Kinderschuhen steckte, verständigten sich häufig die Unternehmen von Supply und Demand Side untereinander, um ihre Plattformen mittels eines bestimmten Codes miteinander zu verbinden und Daten auszutauschen. Da dieses System jedoch für einen wachsenden Markt mit immer mehr Anbietern zu unökonomisch war, entwickelte eine Gruppe aus mehreren Firmen sowohl aufseiten von Demand als auch Supply Side gemeinsam den Open RTB Standard. Richard Hector, Director Sales Central Europe bei AppNexus, zu den Gründen:

Foto: Richard Hector Richard Hector

Als Anbieter einer DSP oder SSP möchte man für die Serverkommunikation zu verschiedenen Plattformen ein Minimum an individuellem Entwicklungsaufwand haben, um Entwicklungsressourcen möglichst in Alleinstellungsmerkmale zu investieren. Man möchte eigentlich nur die Server miteinander verbinden. Der Entwicklungsaufwand bei dieser Verbindung der beiden Plattformen bietet i. d. R. wenig ökonomischen Mehrwert für die jeweiligen Firmen, solange der Standard alle Varianten/Plattformen und Formate zulässt.

(Richard Hector, AppNexus)

Die Unternehmen haben mit diesem Open Source Code eine Möglichkeit geschaffen, dass alle Systeme miteinander kommunizieren können, ohne dass es individuelle Absprachen geben muss. Über die Jahre hinweg wurde der Code immer wieder erweitert. Mittlerweile ist er bei Version 2.4 angelangt und umfasst Standards für alle gängigen Formate wie Video-, Display-, Native- und neuerdings auch Audio-Ads. Das IAB Technology Lab überwacht die ständige Weiterentwicklung. Wenn Firmen Anregungen und Verbesserungsvorschläge haben, können sie diese einreichen und eine Kommission entscheidet darüber, ob und wie man den Standard weiterentwickelt. Berit Block, Marketing Leiterin EMEA von der programmatischen Einkaufs- und Marketingplattform DataXu:

Berit Block

Das OpenRTB Projekt wurde nicht geschaffen, um die Branche zu regulieren, sondern um Integrationen und die Zusammenanarbeit zu vereinfachen und dadurch Innovation und Wachstum innerhalb der Branche anzukurbeln. Open RTB führte dazu, dass Hürden beseitigt wurden, die das Wachstum der Branche zurückhielten.

(Berit Block, DataXu)

Individualität: Möglich, aber nicht nötig

Eigenbrötler haben durch den Standard schlechte Karten. Durch den offenen Code gibt es jedoch Möglichkeiten der individuellen Anpassung. „Man kann prinzipiell die Serverkommunikation auch selbst anpassen und verändern, solange beide Parteien, also SSP und DSP, diese Änderungen vornehmen und der Code der beiden weiterhin kompatibel ist. Ein spannendes Beispiel hierfür stellt zuletzt Programmatic Audio dar, wo zuerst zwei Plattformen individuelle Anpassungen auf Basis des Videostandards vorgenommen hatten, um die Transaktion von Audio zu ermöglichen. Es empfiehlt sich allerdings, möglichst nah am Open RTB Standard zu bleiben oder neue Funktionen in den Open RTB Standard einzubringen, was beispielsweise mit Audio in der Version 2.4 geschehen ist“, sagt Hector. Kurzfristig lassen sich also auch individuelle Funktionen aus Testzwecken einbauen, allerdings machen diese neuen Funktionen langfristig nur Sinn, wenn Sie in den Open RTB Standard aufgenommen werden.

Google ist nun voll dabei

Googles Full-Stack-Lösung für Programmatic Advertising hat mit DoubleClick Bid Manager eine eigene DSP, die mit der Google Exchange AdX fest verbunden ist und setzt daher eigentlich auf eigene Standards. Doch mittlerweile unterstützt das Unternehmen nun zusätzlich den Open RTB Standard. "Google ist mittlerweile offiziell Mitglied dieses Projektes. Einer der Google Engineers steht voll hinter dem Projekt. Angebtrieben durch die Nachfrage der Kunden, kann man heute in Googles AdX Exchange Open RTB als Real-Time Bidding Protokoll, neben Googles eigenem RTB Protokoll, auswählen", berichtet Block.

Auch das Header-Bidding-Protokoll ist frei verfügbar

Header Bidding? Das hört man in letzter Zeit ja immer wieder. Was ist überhaupt Header Bidding? Die Kurzform: Header Bidding oder auch Pre Bidding ist ein Verfahren, bei dem ein Publisher sein Inventar mehreren SSP-Anbietern und Marktplätzen gleichzeitig zur Verfügung stellt. Auf diese Weise können die Publisher ihre Impression über mehrere Angebotsplattformen einer Vielzahl von DSPs simultan anbieten. Das erhöht die Wahrscheinlichkeit, einen besseren Preis für den Werbeplatz zu erzielen, da eine höhere Nachfrage für die Impression generiert wird. Beim Header-Bidding-Skript handelt es sich nur um einen kurzen Code in der Kopfseite einer Website – daher der Name Header Bidding. Dieser Programmcode ist nicht mit dem Adserver des Publishers verbunden. Aus diesem Grund entstehen auch keine Latenzzeiten durch Passbacks. Zudem wird das gesamte Inventar eines Publishers bei dieser „Vor-Auktion“ zunächst einmal gleichbehandelt, d. h., die Unterscheidung zwischen Premiuminventar, festeingebundenem Direct Deal auf Adserverebene oder Restplatz findet auf dieser Ebene noch nicht statt. Dies erhöht abermals die Wahrscheinlichkeit des Publishers, für den Nutzerkontakt höhere Werbeerlöse zu erzielen.

Wie der Open RTB Standard ist auch Header Bidding frei verfügbar. Die Initiative PreBid.org, die von AppNexus ins Leben gerufen wurde, bietet dazu ein Protokoll. Die Hintergründe dieses Projektes sind jedoch völlig andere als die des Open RTB Standards. Hier geht es auch um eigene Interessen des Initiators und anderen SSP-Anbietern, die das Protokoll aus PreBid.org nutzen, um im harten Wettbewerb mit Google zu bestehen. Es handelt sich also nicht um ein gemeinnütziges Projekt im engeren Sinne, das die Kommunikation der verschiedenen Plattformen nur erleichtern soll, sondern stellt vielmehr einen direkten Angriff auf Google dar.

Denn Google hatte bereits, bevor die Header Bidding Initiative ins Leben gerufen worden ist, eine ähnliche Yieldoptimierungsfunktion für Publisher entwickelt, die über den Google Adserver „DoubleClick for Publishers" (DFP) und der googleeigenen Marktplatzlösung Google Adexchange (AdX) ihr Inventar vermarkten. Die Rede ist von Dynamic Allocation (zu Deutsch:Dynamische Zuordnung). Über Dynamic Allocation können die Publisher jede Werbebuchung, die über die AdX hereinkommt, auf Impression-Ebene in Echtzeit konkurrieren lassen, um so den maximalen Yield zu erzielen.

Voraussetzung ist allerdings (noch), dass der Publisher a) DFP und b) Google AdX als SSP- bzw. Marktplatzlösung zum Anschluss an die Demand-Seite einsetzt. Genau dieser Umstand hat AppNexus auf den Plan gerufen, um Header Bidding zu initiieren, damit andere Marktplatz- und SSP-Anbieter ihren Publisherkunden eine Alternative zu Dynamic Allocation bieten können. Header Bidding hat im Laufe der letzten Monate einen solchen Siegeszug erfahren, dass Google sich nun genötigt sieht, sich zu öffnen und Dynamic Allocation nun auch außerhalb der Google AdX anzubieten. Erste Tests mit Rubicon Project sind bereits gelaufen.

Das Beispiel von Header Bidding macht klar, dass offene Initiativen im Programmatic Advertising auch von einzelnen Interessengruppen angestoßen werden können, ohne dabei einen echten Branchenstandard darzustellen. Denn ein solcher erfordert immer die Unterstützung aller relevanten Marktteilnehmer.