Header Bidding ist derzeit eines der großen Schlagworte im Programmatic Advertising. Um die Entwicklung dieses neuen Ansatzes zu verstehen, muss man sich die Geschichte der AdServer ansehen.
Programmatic Advertising (oder die Automatisierung von Werbung) verbreitet sich unaufhaltsam. Damit einher gehen Entwicklungen der Werbetechnologie, die sich häufig wechselnden Anforderungen anpassen müssen. Nach RTB, RTA, Private Marketplaces, Programmatic Direct und Automatic Guaranteed ist Header Bidding das aktuelle Thema.
Um die Entwicklung dieses neuen Ansatzes zu verstehen, möchte ich etwas ausholen und die Geschichte der AdServer skizzieren. Daraus wird klar, warum Header Bidding in der heutigen Werbelandschaft Sinn macht.
Phase 1: AdServer als Auslieferungs- und Entscheidungstechnologien
Drehen wir die Uhr circa zwanzig Jahre zurück. Das Web war viel einfacher gestrickt und daher auch die digitale Werbung. Einzelne Online Publisher fingen an, Geld mit ihren Websites zu verdienen, in dem sie Anzeigen darauf platzierten. In der einfachsten Form waren das Bilder, versehen mit einem entsprechenden Link auf die Website des Werbungtreibenden. Schnell aber stieg die Nachfrage so stark, dass eine gesonderte Technologie von Nöten war, die sich um die Werbung auf den Seiten der Publisher kümmert.
Unter anderem wollten Publisher ihre Anzeigenplätze an mehr als einen Werbungtreibenden verkaufen. Dafür brauchten sie einen Weg, mehrere Anzeigen auf einem einzigen Platz zu rotieren. Die Lösung: Publisher bauten eine Code-Zeile an die richtige Stelle ein, um eine andere Technologie abzurufen, die dann mehrere Anzeigenmotive beziehungsweise Kampagnen von unterschiedlichen Werbekunden verwaltete. Das war also der AdServer (grob übersetzt: Anzeigen-Auslieferer). Der AdServer reagierte dann auf diesen Abruf und spielte die Anzeigen entsprechend aus. Das ermöglichte es Publishern, einen Anzeigenplatz an mehrere Werbekunden zu verkaufen.
Doch gab es ein Problem: Die Mediabuchungen waren keinesfalls alle gleich, daher reichte eine einfache Rotation der Anzeigen nicht mehr aus. Publisher brauchten eine Möglichkeit, Anzeigen zu priorisieren, damit die AdServer die unterschiedlichen Anforderungen mehrerer Werbekunden bezüglich Anzeigenvolumen und Zielvorgaben erfüllen konnte.
Um dies zu erreichen, bekamen die AdServer ein System zur Definition einer Reihenfolge. Publisher konnten also unterschiedliche Werbekunden priorisieren und zudem Zielvorgaben bestimmten Kampagnen zuordnen. Die Aufgabe eines AdServers wurde also von der reinen Auslieferung von Anzeigenmotiven um eine Entscheidungskomponente erweitert. Der AdServer entschied jetzt, welche Anzeigen auf welchen Webseiten des Publishers für welche Zielgruppen wann ausgespielt werden sollten. Alles basierend auf den Prioritäten und Zielvorgaben der unterschiedlichen Werbekunden und Kampagnen.
Phase 2: Einkaufssysteme Dritter erhalten Zugang zum AdServer
Die digitale Werbelandschaft wurde um einiges komplizierter. Publisher verkauften Werbeplätze nicht nur direkt an Werbungtreibende und Media-Agenturen. Die Impressions, die sie nicht direkt verkaufen konnten, wurden an Anzeigennetzwerke (AdNetworks) zu einem Discount-Preis verkauft. Die AdNetworks bekamen Zugang zum Inventar eines Publishers über eine Code-Zeile im AdServer, genauso wie ein Anzeigenkunde, der direkt beim Publisher gekauft hatte. Da das Network-Modell explizit darauf ausgerichtet war, übrig gebliebenes Inventar zu verkaufen, bekamen die Networks auf dem AdServer die niedrigste Priorität. Schließlich zahlten die Werbekunden, die darüber buchten, auch den geringsten Preis.
Aber es wurde noch spannender. Anstatt nur die unverkauften Inventarplätze für einen bestimmten Preis zu verkaufen, ermöglichten neue Systeme, Gebote für diese übrig gebliebenen Anzeigenplätze abzugeben. Die Auktion war geboren. Um zu bestimmen, wie hoch Anzeigenkäufer für bestimmte Plätze bieten sollten, bewerteten Gebotstechnologien die Attribute der einzelnen Impressions, um so den Wert zu bestimmen, den diese Impression für einen bestimmten Werbekunden haben kann. All das musste natürlich in Echtzeit (Realtime) geschehen. Da die Preisfindung nun dynamisch war, konnte es sein, dass eine Impression über die Auktion einen Preis erzielte, der genauso hoch war wie der Preis, den Anzeigenkunden zahlten, die direkt über den Publisher Premium-Inventar einkauften.
Phase 3: Real-Time-Gelegenheiten werden durch traditionelles Ad-Serving ausgebremst
Diese Entwicklung zeigte sehr genau eine der Hauptschwächen des traditionellen AdServer-Setups auf, die durch Header Bidding gelöst werden sollte. AdServer wurden eingerichtet, um Anzeigen basierend auf bekannten, statischen Preisen und Kampagnenzielen auszuliefern. Sie wurden nicht entwickelt, um dynamische Preise und Realtime-Entscheidungen zu bearbeiten oder einzelne Leitungen zu Netzwerken offen zu halten, über die dann viele unterschiedliche Einkäufer Anfragen stellen.
Das Resultat: Obwohl die digitale Werbung sich prinzipiell dahin entwickelt hatte, dynamische Preisverhandlungen zu ermöglichen, haben Publisher nach wie vor Kampagnen auf ihren AdServern basierend auf statischen Preisen priorisiert. Um RTB-Quellen einzubinden, haben sie geraten, was der durchschnittliche Preis aller dynamisch verhandelten Preise wohl sein könnte. Dabei können diese Preise natürlich extrem unterschiedlich ausfallen.
Für Einkäufer von Anzeigenplätzen bedeutete dies, erst gar keinen Zugriff auf Inventar zu bekommen, das höhere Preise verlangte. Die Verkäufer-Seite verpasste dadurch mögliche hohe Preise, die Werbungtreibende bereit gewesen wären, über automatisierte Systeme für individuelle Impressions zu bezahlen.
Phase 4: Ungleiche Chancen für automatisierten Einkauf von Premium-Zielgruppen
Mal abgesehen davon, dass traditionelle AdServer potenzielle Einnahmen aus RTB-Quellen nicht realisieren konnten, gab es eine weitere wichtige Entwicklung in der digitalen Werbung, die einen viel triftigeren Grund für den Einsatz von Header Bidding darstellten.
Werbungtreibende und Werbetechnologieunternehmen fanden heraus, dass die Technologie, die sie für den Verkauf von übrig gebliebenem Inventar gebaut hatten, auch für Transaktionen auf geschlossenen Marktplätzen einsetzbar war (Private Marketplaces oder PMPs). Damit hatten aber die hochpreisigen Individualkampagnen, die normalerweise direkt mit dem Publisher verhandelt wurden, auf dem AdServer eine geringe Priorität, denn sie liefen über die RTB-Zeilen im Code. De facto konnten sie also gar nicht mit den Kampagnen in den preislichen Wettbewerb treten, die traditionell direkt verkauft wurden, obwohl die Preise für Impressions durchaus gleichwertig waren.
Eine neue, schlaue Methode, direkt verkaufte Kampagnen abzuwickeln wurde durch die seit langem eingesetzte Technologie ausgebremst. Durch Header Bidding soll nun die Priorisierung des AdServers umgangen werden. Da der entsprechende Code sich im Header der Seite befindet, entstand der Name. Alle automatisierten Systeme kommunizieren gleich beim ersten Laden einer Seite.
Eins ist wichtig zu verstehen, wenn man über Header Bidding spricht: Es ist keine Technologie, die unsere Branche mit dem heutigen Kenntnisstand für die Abwicklung von Anzeigenverkäufen entwickelt hätte. Vielmehr ist es ein Weg, die implementierten "alten" Systeme so zu nutzen, dass sie dem neuen Ansatz von automatisierter Werbung Rechnung tragen können.
