Jede neue Technologie stößt irgendwann an Grenzen, die eine Weiterentwicklung notwendig machen. Man stelle sich beispielsweise vor, wie das Internet wäre, wenn wir heute noch Mosaic, den Vorläufer der heute gängigen Internetbrowser, nutzen würden. Knapp ein Vierteljahrhundert ist es her, da galt diese Technologie als Revolution: Mit Mosaic wurden erstmals Darstellungen von Grafiken und anderer Multimediainhalte im bis dahin rein textbasierten Internet möglich. Die Inhalte heutiger Webseiten könnte dieser aber gar nicht mehr darstellen, geschweige denn die heute geschätzten nahezu 5 Milliarden Webseiten verarbeiten. Dies zeigt, dass selbst die innovativsten Technologien ihrer Zeit immer wieder Weiterentwicklungen erfahren müssen, damit diese praktikabel sind. Das recht neue Header Bidding ist keine Ausnahme.

Der Grundsatz hinter Header Bidding ist, dass Publisher mit dieser Lösung ihr Inventar parallel mehreren Nachfragern zur Verfügung stellen können, bevor eine Anfrage an den Adserver gesendet wird. Der gesteigerte Wettbewerb führt zu bestmöglichem Ertrag für jede einzelne Impression. Neben der Yield Optimization sind die dynamische Preisgestaltung und das Ausschließen von Pass Backs durch den Adserver weitere gewichtige Vorteile. Die Komplexität dieser Technologielösung steigt mit der Anzahl der Teilnehmer und Mitspieler auf diesem Feld. Header-Bidding-Container haben sich hier als ideales Mittel der Weiterentwicklung angeboten, um gleichzeitig mehr als nur einen Partner der Nachfrageseite effizient managen zu können. Diese Container fallen in zwei unterschiedliche Kategorien: browser- oder clientseitige Lösungen auf der einen und serverseitige Lösungen auf der anderen Seite.

Da hier die Fragestellung tatsächlich ein Entweder-oder ist, macht es Sinn, sich genau anzusehen, welche Aspekte in die Entscheidungsfindung einfließen sollten. Insgesamt sechs wichtige Kriterien sollten bei diesen Überlegungen eine Rolle spielen:

1. An erster Stelle und auch in der Wichtigkeit ganz oben ist es empfehlenswert, an die User Experience zu denken. Jede Technologielösung, die die Latenz erhöht, wirkt negativ auf die User Experience und sollte nur vorsichtig genutzt werden. Jedoch sei darauf hingewiesen, dass Werbung die Ladezeiten weniger beeinflusst als die Inhalte einer Webseite selbst.

2. Komplexität spielt eine wesentliche Rolle: sowohl auf der operativen als auch auf der technischen Ebene. Das Ziel eines Header-Bidding-Containers ist, den Prozess des Hinzufügens von Header-Bidding-Partnern so einfach wie möglich zu gestalten und sicherzustellen, so dass der Code problemlos mit dem auf der Webseite interagiert.

3. Zuverlässigkeit ist ein weiteres Schlüsselkriterium. Da Header Bidding im Vergleich doch noch eine relativ neue Technologielösung ist und alle Integrationen individuell variieren können, ist es mehr als sinnvoll, dass Publisher einen zuverlässigen Technologiepartner wählen, der nachweislich mehrere Nachfrageseiten gleichberechtigt managen kann.

4. Transparenz ist im Online-Marketing auf allen Ebenen immens wichtig und Header Bidding ist hier keine Ausnahme. Für Publisher ist es wichtig, eine Lösung zu wählen, die ohne Ausnahme alle Gebote gleichzeitig zum Adserver weiterleitet und nicht nur das erfolgreiche Gebot. Dies könnte im Extremfall die Tür für Manipulationen öffnen.

5. Reporting wird sehr viel komplexer, wenn die Anzahl der Partner im Header Bidding steigt. Es ist definitiv von Vorteil, wenn die Header-Bidding-Lösung ein einziges Reporting über alle Partner hinweg liefern kann.

6. Zu guter Letzt besteht die Möglichkeit, dass eine Vielzahl an Demand-Partnern das Risiko erhöhen, die Qualität der Anzeigen zu senken. Ein Anbieter für Header-Bidding-Container-Lösungen sollte in der Lage sein, dieses Thema sowohl pro- als auch reaktiv anzugehen und Lösungswege aufzuzeigen.

Die clientseitige Lösung wird in den Browser des Users integriert. Anfragen und Partner der Demand-Seite werden aus dieser Position heraus verwaltet. Diese Container bieten die Option, Timeouts zu definieren. Das bietet zwar Kontrolle über die Latenz, hat jedoch keinerlei Auswirkungen auf die Zeit des eigentlichen Seitenaufbaus. Hintergrund ist, dass browserseitige Container die Internetverbindung zwischen User und den Demand-Partnern nutzen und dabei verlassen sie sich auf offene Browser-Calls, um mit dem Web zu kommunizieren. Browser haben jedoch eine limitierte Anzahl an Slots – Google Chrome hat beispielsweise nur 10 – dies kann den Zeitraum für den Seitenaufbau drastisch beeinflussen und sich negativ auf die User Experience auswirken.

Natürlich reduzieren diese Container auch die Komplexität auf der operativen Ebene ohne Einfluss auf den Webseitencode. Vom technischen Standpunkt aus besteht jedoch tatsächlich die Möglichkeit, dass Container- und Partnercodes so interagieren, dass die Seite zusammenbricht. Noch gibt es hier nur wenige Beispiele mehrfacher Implementierungen, so dass die Frage, wie sich die Container langfristig in diesem Fall verhalten, schlussendlich noch nicht beantwortet werden kann.

Der Einfachheit halber sollte auch ein Reporting über alle Partner hinweg möglich sein, so dass alle Anfragen einsehbar sind. Die Transparenz wird so erhöht. Leider zeigen viele Umsetzungen grundsätzlich nur das erfolgreiche Gebot, so dass Publisher alle Werte einzeln anfordern müssen, wenn sie mit clientseitigen Containerlösungen arbeiten. Gleichzeitig bekommen die angeschlossenen SSP häufig keine Informationen über verlorene Gebote, was eine Optimierung auf SSP-Seite massiv erschwert. Und letztendlich können diese browserbasierten Container auch keine weitere Instanz zur Prüfung der Anzeigenqualität bieten. Denn wenn die Schlüsselwerte an den Server weitergegeben werden, ist der browserseitige Container nicht in der Lage, Information über die Anzeige selbst zu verarbeiten. Qualitätskontrollen im Hinblick auf die Anzeigen sind so nicht mehr möglich.

Gleichberechtigung in der Anfrage der SSPs ist ein weiterer Aspekt. Jede SSP benötigt eine bestimmte Zeitspanne, um den Request der Website zu verarbeiten und die Ad Impression erfolgreich zu versteigern. Ist dieser Slot zu kurz, kommt kein Gebot zustande bzw. fällt niedriger aus. Da die Browser-Calls vom Client nacheinander abgearbeitet werden, hat der ein oder andere SSP-Partner nur wenig oder gar keine Zeit die Impression zu versteigern, was den eTKP des erfolgreichen Gebots reduzieren kann. Es ist also wichtig, darauf zu achten, dass die Zahl der Partner überschaubar bleibt und ggf. auch einmal die Reihenfolge der Anfragen an SSP-Partner zu variieren, um die leistungsfähigsten Partner zuerst anzufragen. Hier entsteht für den Publisher und Vermarkter leider wieder zusätzlicher Aufwand.

Im Gegensatz zu den browserbasierten Lösungen werden die serverseitigen Container im jeweiligen Server des Technologiedienstleisters implementiert. Durch einen Code auf der Webseite, die der User aufruft, erhält der Server automatisch alle notwendigen Informationen. Dadurch ist der Prozess nicht von der Internetverbindung zwischen User und den jeweiligen Partnern abhängig, der Browser wird also weniger beansprucht. Alle Demand-Partner werden mit einer unglaublichen Geschwindigkeit vom Server angefragt, was dem Publisher die Option gibt, Ladezeiten zu verkürzen und so die User Experience zu verbessern oder das Time-out so zu belassen und den Auktionen noch mehr Zeit zu verschaffen.

Genau wie die browserbasierte Containerlösung reduziert auch die serverbasierte Lösung die operative Komplexität um ein Vielfaches, gerade in Bezug auf die operative Einbindung der Partner durch den Publisher. Zusätzlich vereinfachen sich die technischen Anforderungen, indem auf OpenRTB-Standards zurückgegriffen wird. Diese sind allgemein bekannt und genießen Vertrauen innerhalb der Industrie.

Reportings können in beiden Fällen die gleiche Leistung in Bezug auf Datenanalyse erbringen, allerdings kann sich das Setup maßgeblich unterscheiden und browserbasierte Lösungen sind in dieser Hinsicht arbeitsintensiv.

Der größte Unterschied zwischen den beiden Containerlösungen liegt beim Thema Qualität. Der OpenRTB-Ansatz der serverseitigen Lösung erlaubt Demand-Partnern, nicht nur ein Preisgebot abzugeben, sondern auch gleich die Anzeigeninformationen zu übermitteln. Dies ermöglicht es, eine proaktive Anwendung von Qualitätsregeln für Werbemittel zu realisieren und unerwünschte Anzeigen auszuschließen. White- und Blacklistings können effektiv und zentral verwalten werden – eine Möglichkeit, die gerade in Deutschland besonders geschätzt wird.

Header Bidding an sich hat das Potential, die digitale Werbelandschaft zu transformieren, und die Containerlösungen sind elementarer Bestandteil im dem Bestreben, das Inventar bestmöglich und erfolgreich zu monetarisieren. Indem der Container vom Browser des Users auf den Server des Technologiedienstleisters „umgezogen“ wird, können Publisher sich auf bewährte Standards, wie OpenRTB, verlassen. Header Bidding wird so für alle Beteiligten einfacher in der Umsetzung, Qualitätsstandards lassen sich erhöhen und die User Experience optimieren.