Wohl der Hauptgrund, der als Argument für Header Bidding genannt wird, ist die Umgehung des Waterfalls, der beim Programmatic Advertising entsteht. Hierbei wird der Kanal, der den meisten Umsatz verspricht, vom Publisher als erstes bedient, die Vergabe der Impression ist fest priorisiert. Wird der Kanal nicht bedient und kann keine volle Auslastung der Werbefläche schaffen, gibt es ein sogenanntes Passback zu dem nächstpriorisierten Abnehmer und so weiter.

Beim Header Bidding werden die Impressions jedoch in einer Art „Superauktion“ angeboten, bei der eine SSP die höchsten Gebote aller anderen angebundenen SSPs sammelt und dann alle Demand-Quellen miteinander vergleicht, um den höchsten Umsatz für den Publisher zu erzielen.

Auf mobilen Internetseiten funktioniert Header Bidding im Prinzip genauso wie auch auf dem Desktop. Hierbei werden zwei Arten des Header Biddings unterschieden: Client- und Server-Side Header Bidding. Beim Client-Side Header Bidding wird im Code der Webseite ein Header Tag implementiert, der die teilnehmenden Ad Networks und Supply-Side-Plattformen (SSPs) für die gemeinsame Auktion miteinander verbindet. Die Auktion läuft dabei über den Client, also den Webbrowser des Nutzers.

Besonders auf mobilen Geräten kann sich hierbei schnell die größte Schwäche des Client-Side Header Biddings offenbaren: die hohe Latenzzeit. Je mehr SSPs ein Publisher anbindet, desto höher steigt das Risiko, die Ladezeit der Seite zu verlängern. Dadurch kann je nach Geschwindigkeit der Internetverbindung nur eine begrenzte Anzahl von Partnern angeschlossen werden. Gerade auf mobilen Geräten entsteht hier schnell ein empfindlicher Flaschenhals, weiß Managing Director von Yieldlove Timo Hagenow: „Im MEW-Bereich sind es vor allem niedrige Bandbreiten und schwache Rechenleistungen der Endgeräte, die als Herausforderungen im Einsatz von Header Bidding zu nennen sind.“

Serverseitiges Header Bidding kann dieses Problem lösen, denn es entlastet die Internetverbindung des Nutzers. Anstatt die Anfrage vom Browser aus zu stellen, sendet der Adserver die Bid Request an die unterschiedlichen SSPs. Die Auktion findet damit außerhalb des Clients auf einem Server statt. Die Anzahl der eingebundenen Partner spielt hier keine Rolle mehr. Nachteil der Auslagerung: Die Möglichkeiten, den Nutzer zu matchen, sind eingeschränkt, wodurch sich unter Umständen die Höhe der Gebote verringert.

Die Geschwindigkeit des Server-seitigen Header Bidding nutzt beispielsweise AppNexus seit Kurzem für die AMP-Seiten von Google. Die AMP-Seiten bieten auf Grund von einer strikten Regelung der erlaubten Werbemittel und einem schlanken Aufbau der Seite eine schnellere Ladezeit als normale mobile Webseiten.

Im In-App-Bereich gibt es die Probleme des client-seitigen Header Biddings nicht. Hier läuft die Auktion über eine Server-to-Server-Verbindung. Strenggenommen handelt es sich bei den angebotenen Lösungen auch nicht um Header Bidding. Die entsprechende Code-Zeile ist hier im Software Development Kit (SDK) der Mobile SSP verbaut. Einen Webseitencode inklusive Header gibt es nicht.

Henrik Basten, CTO von Fyber und Mitgründer von Falk Realtime, erklärt, welche Probleme diese Lösung mit sich bringen kann: „Bei Internetseiten wird das Skript relativ schnell und einfach in den Code der Webseite integriert und es funktioniert. Ebenso schnell lässt es sich bei Problemen wieder abschalten. Wenn es im App-Bereich beispielsweise Probleme mit einem Partner gibt, geht das nicht so schnell. Ein SDK kann nicht mal eben ausgetauscht werden. Das wäre erst bei dem nächsten App-Update möglich.“ Es fehlt dem In-App-Bereich also an Flexibilität. Ebenso wenig werden Fehler in der Implementierung vergeben.

Die Mobile SSP Fyber hat jüngst selbst eine Header-Bidding-Lösung zur In-App-Monetarisierung veröffentlicht. Basten erklärt, dass die SDKs von Fyber etwa im 2-wöchigen Rhythmus veröffentlicht werden und auf diese Weise bei Updates ihren Weg in die Apps finden.

Die Auktionen, in denen im Real-Time Bidding um Impressions geboten wird, setzen auf zwei unterschiedliche Auktionsmodelle: First und Second Price Auctions. Klassisch wird die Second Price Auction verwendet, in der der Gewinner der Auktion den Preis des zweithöchsten Gebots plus einen kleinen Zusatz, meist ein Cent, zahlt. Gerade im Header Bidding setzt sich jedoch immer häufiger die First Price Auction durch. Hier zahlt der Auktionsgewinner den tatsächlich gebotenen Preis, egal wie hoch das Gebot des Zweitplatzierten ist. Für Publisher ist die Motivation hinter der Umstellung klar. Sie können auf höhere Erlöse hoffen, da das zu zahlende Gebot nicht abgewertet wird.

Abgesehen davon würde eine First Price Auction im Bereich des In-App Header Bidding Sinn machen, meint Basten, besonders wenn verschiedene Formen des Demands miteinander gemischt würden: „Auf der einen Seite haben wir klassische Mediation, dann Direct Demand und Programmatic Demand mit unterschiedlichen Auktionsmodellen. Wir denken, dass sich der Markt in Richtung eines First-Price Auktionsmodells entwickeln wird, das komplette Transparenz erlaubt. Allerdings kann ein hybrides Modell genauso gut funktionieren, solange es von Plattformen gemanagt wird, denen man vertrauen kann, da sie auf volle Transparenz setzen.“ Die klassische Mediation und Direct Demand liefen ohnehin nur über First Price mit einem gesetzten TKP. Um es mit dem Programmatic-Bereich vergleichbar zu machen, böte sich die First Price Auction an.

Henrik Basten nennt jedoch auch ein Argument, das aus der Sicht von Werbetreibenden für eine First Price Auction spricht: „Second Price Auctions können auch fair sein. Allerdings sind viele Plattformen nicht transparent und arbeiten mit versteckten Fees. Das bedeutet, dass im Falle von Second Price Auctions unseriöse Geschäftspartner mit diesen versteckten Fees unbemerkt davonkommen, wenn die Zahlen nicht genau im Auge gehalten werden. Advertiser können dieses Risiko vermeiden, indem sie transparente Reports einfordern.“

Werbetreibende haben bei einer klassischen Second Price Auction keine Einsicht, wie hoch tatsächlich das Gebot des Zweitplatzierten ist. In der Spanne zwischen höchstem und zweithöchstem Gebot können sich also auch unerwünschte und nicht verzeichnete Gebühren verstecken.

„Diesbezüglich bietet das OpenRTB-Protokoll keine vollständige Transparenz. Nichtsdestotrotz ist es wichtig festzustellen, dass es keine grundsätzlichen Probleme mit der Technologie und der Auktion gibt. Das Problem sind vielmehr Unternehmen, die sich dieses Schlupfloch zu Nutze machen und dadurch das Vertrauen und die gesamte Industrie unterminieren“, erklärt Basten.

Timo Hagenow ergänzt: „Grundsätzlich ist die First-Price-Auktionslogik dem Second-Price-Modell vorzuziehen, da es hier dazu kommen kann, dass ein Advertiser die Auktion nicht gewinnt, obwohl der das höchste Gebot abgegeben hat, da die SSP nur das Second-Preis-Auktionsergebnis an den Wrapper übergibt.“

Derzeit scheint der Markt sich hin zu mehr First Price Auctions zu entwickeln – im In-App-Bereich wie auch für Webseiten. Für Einkäufer bringt die Auktionsform zwar mehr Kostentransparenz, aber auch mehr Arbeit mit sich. Die Zeiten mit einem eingebuchten Höchstpreis für die Impression wären damit vorbei. Ständig müsste der Preis in Abhängigkeit zur Konkurrenz optimiert werden, um nicht zu viel zu zahlen – eine neue Aufgabe für künstliche Intelligenzen.