Header Bidding ist eine Auktionsmethode im Programmatic Advertising, bei der mehrere SSPs (Supply-Side Platforms) und Ad Exchanges gleichzeitig um einen Werbeplatz bieten, bevor der Ad Server aufgerufen wird. Im Gegensatz zum traditionellen Wasserfall-Modell, bei dem Demand-Quellen nacheinander abgefragt werden, konkurrieren beim Header Bidding alle Bieter in einer parallelen Auktion. Das Ergebnis: höhere Erlöse für Publisher, fairere Preise und vollständige Transparenz darüber, was ein Werbeplatz tatsächlich wert ist.
Warum hat Header Bidding das Wasserfall-Modell abgelöst?
Im klassischen Wasserfall-Modell (Waterfall oder Daisy Chain) ordnete der Publisher seine Demand-Quellen in einer festen Reihenfolge an – typischerweise basierend auf historischen Durchschnitts-CPMs. Die erste Quelle erhielt das Recht, den Werbeplatz zu kaufen. Lehnte sie ab, ging die Anfrage an die nächste Quelle. Das Problem: Eine Demand-Quelle auf Position drei hätte möglicherweise den höchsten Preis geboten, kam aber nie zum Zug, weil Position eins bereits akzeptiert hatte – zu einem niedrigeren Preis.
Header Bidding eliminiert dieses Problem grundlegend. Alle Demand-Quellen bieten gleichzeitig, und das höchste Gebot gewinnt – unabhängig von einer festen Reihenfolge. In der Praxis steigen die CPMs für Publisher um 20 bis 50 Prozent gegenüber dem Wasserfall-Modell. Gleichzeitig verbessert sich die Fill Rate, weil mehr Bieter um jeden einzelnen Impression konkurrieren.
Wie funktioniert Header Bidding technisch?
Der technische Ablauf folgt einem klaren Schema:
Schritt 1 – Wrapper laden: Wenn ein Nutzer eine Webseite aufruft, wird im Header der Seite ein JavaScript-Wrapper geladen. Dieser Wrapper – in den meisten Fällen Prebid.js – koordiniert den gesamten Auktionsprozess.
Schritt 2 – Bid Requests senden: Der Wrapper sendet parallele Bid Requests an alle konfigurierten Demand-Quellen (SSPs, Ad Exchanges, DSPs). Jeder Bieter erhält Informationen über den verfügbaren Werbeplatz: Größe, Position auf der Seite, Nutzerinformationen und Kontextdaten.
Schritt 3 – Gebote sammeln: Innerhalb eines definierten Timeout-Fensters (typischerweise 500 bis 1.500 Millisekunden) geben alle Bieter ihre Gebote ab. Bieter, die nicht rechtzeitig antworten, werden aus der Auktion ausgeschlossen.
Schritt 4 – Höchstes Gebot ermitteln: Der Wrapper vergleicht alle eingegangenen Gebote und identifiziert das höchste. Dieses Gebot wird als Key-Value-Pair an den Ad Server (typischerweise Google Ad Manager) übergeben.
Schritt 5 – Ad Server entscheidet: Der Ad Server vergleicht das Header-Bidding-Gebot mit seinen eigenen Demand-Quellen (z. B. direkt gebuchte Kampagnen oder Google AdX). Das beste Gebot insgesamt gewinnt, und die Anzeige wird ausgeliefert.
Was ist Prebid.js und warum ist es Standard?
Prebid.js ist das führende Open-Source-Framework für Header Bidding, entwickelt von der Prebid.org-Community. Seine Stärke liegt in der modularen Architektur: Über Adapter werden Demand-Quellen eingebunden – für jede SSP oder jeden Exchange gibt es einen eigenen Adapter. Aktuell unterstützt Prebid.js Hunderte von Adaptern.
Die Konfiguration umfasst die Auswahl der Adapter, die Definition der Werbeplätze (Ad Units), Timeout-Einstellungen und die Integration mit dem Ad Server. Prebid.js bietet zudem Module für Consent Management (DSGVO-konform), User-ID-Lösungen und Analytics.
Was unterscheidet Client-Side von Server-Side Header Bidding?
Client-Side Header Bidding ist die ursprüngliche Variante. Der Wrapper läuft im Browser des Nutzers, Bid Requests gehen direkt an die Demand-Quellen. Vorteil: volle Kontrolle und Transparenz. Nachteil: Jeder zusätzliche Bieter erhöht die Ladezeit. Ab fünf bis acht Bietern wird die Latenz spürbar.
Server-Side Header Bidding verlagert die Auktion auf einen externen Server. Der Browser sendet einen einzigen Request, der Server führt die parallelen Bid Requests durch. Vorteil: konstante Seitenladezeit unabhängig von der Bieteranzahl. Nachteil: Weniger Cookie-Zugang für die Demand-Quellen, was zu niedrigeren Geboten führen kann.
In der Praxis setzen viele Publisher eine Hybridlösung ein: Die wichtigsten Bieter laufen Client-Side, zusätzliche Bieter werden Server-Side angebunden.
Welche Kennzahlen sind entscheidend?
Fünf Metriken bestimmen den Erfolg eines Header-Bidding-Setups:
- Bid Rate: Der Prozentsatz der Auktionen, in denen ein Bieter tatsächlich ein Gebot abgibt. Eine niedrige Bid Rate deutet auf Konfigurationsprobleme oder fehlendes Inventarinteresse hin.
- Win Rate: Wie oft ein Bieter die Auktion gewinnt. Zeigt die Wettbewerbsfähigkeit jedes einzelnen Bidders.
- Timeout Rate: Der Anteil der Auktionen, in denen ein Bieter nicht rechtzeitig antwortet. Hohe Timeout-Raten kosten Umsatz, weil Gebote verloren gehen.
- CPM Lift: Der Umsatzzuwachs im Vergleich zum vorherigen Setup (Wasserfall oder weniger Bieter). Zeigt den konkreten wirtschaftlichen Mehrwert.
- Latenz: Die zusätzliche Ladezeit, die Header Bidding verursacht. Muss gegen den CPM-Lift abgewogen werden – höhere Erlöse rechtfertigen keine unzumutbare Nutzererfahrung.
Welche Rolle spielt der Google Ad Manager?
Google Ad Manager (GAM) ist der Ad Server, der in den meisten Header-Bidding-Setups die finale Entscheidung trifft. Die Header-Bidding-Gebote werden als Key-Value-Pairs an GAM übergeben, wo sie gegen direkte Buchungen und Google AdX konkurrieren. Für die Integration werden in GAM Line Items erstellt, die den verschiedenen Preisstufen entsprechen – so konkurriert jedes Gebot fair gegen die internen Demand-Quellen.
Wie funktioniert es in der Praxis?
Ein typisches Header-Bidding-Setup beginnt mit der Analyse des bestehenden Monetarisierungsmodells: Welche Demand-Quellen sind angebunden? Wie hoch sind die aktuellen CPMs und Fill Rates?
Im nächsten Schritt wird Prebid.js implementiert. Fünf bis zehn relevante Adapter werden ausgewählt, für jede Ad Unit konfiguriert und mit Timeout-Werten sowie Floor Prices versehen. Parallel werden die Line Items im Google Ad Manager angelegt – in 10-Cent-Schritten von 0,10 Euro bis zum erwarteten Höchstgebot. Tools wie Prebid Line Item Manager automatisieren diesen Prozess.
Nach dem Launch beginnt die Optimierungsphase. A/B-Tests vergleichen verschiedene Timeout-Einstellungen, Floor-Price-Strategien und Bieter-Kombinationen. Die Performance jedes Bidders wird analysiert: Liefert er hohe Bid Rates? Sind seine CPMs wettbewerbsfähig? Bidder, die mehr Ladezeit kosten als sie Umsatz bringen, werden entfernt. Das Reporting wird in einem zentralen Dashboard zusammengeführt – Header Bidding ist kein Setup-and-Forget, sondern ein kontinuierlicher Optimierungsprozess.
Häufige Fehler
Zu viele Bidder einbinden und Latenz ignorieren: Jeder zusätzliche Client-Side Bidder erhöht die Seitenladezeit. Publisher, die 15 oder mehr Bidder einbinden, riskieren Ladezeiten von mehreren Sekunden. Das verschlechtert die Nutzererfahrung, senkt die Viewability und schadet den Core Web Vitals. Fünf bis acht Client-Side Bidder sind in den meisten Fällen der optimale Kompromiss.
Timeout-Fenster zu kurz konfigurieren: Ein Timeout von 200 Millisekunden klingt performant, führt aber dazu, dass viele Bidder nicht rechtzeitig antworten. Niedrigere Bid Rates und entgangene Umsätze sind die Folge. Ein Timeout zwischen 800 und 1.500 Millisekunden gibt Bietern ausreichend Zeit, ohne die Nutzererfahrung zu beeinträchtigen.
Floor Prices nicht testen: Floor Prices (Mindestgebote) beeinflussen direkt die Erlöse. Zu niedrige Floors verschenken Umsatz, zu hohe Floors schrecken Bieter ab und senken die Fill Rate. Ohne systematisches A/B-Testing von Floor-Price-Strategien bleibt Geld auf dem Tisch. Dynamische Floor Prices, die sich an Tageszeit, Gerät und Zielgruppe anpassen, liefern die besten Ergebnisse.
Mobile Optimierung vernachlässigen: Mobile Nutzer machen den Großteil des Traffics aus, haben aber langsamere Verbindungen. Header-Bidding-Setups, die nur für Desktop optimiert sind, versagen auf Mobile: zu viele Bidder, zu lange Timeouts. Mobile erfordert eine eigenständige Konfiguration mit reduzierter Bidder-Anzahl.
Kein zentrales Reporting aufbauen: Ohne ein Dashboard, das Bid Rates, Win Rates, CPMs und Latenz pro Bieter zusammenführt, fehlt die Grundlage für Optimierungsentscheidungen. Publisher, die sich auf die Reports einzelner SSPs verlassen, sehen nie das Gesamtbild. Ein unabhängiges Reporting-Tool ist unverzichtbar.
Header Bidding mit Think11
Think11 aus Osnabrück implementiert und optimiert Header-Bidding-Setups als Teil ganzheitlicher Monetarisierungsstrategien. Als Google Premium Partner mit Zugang zu Premium-Demand-Quellen setzen wir Prebid.js-basierte Lösungen auf, die den Umsatz maximieren, ohne die Nutzererfahrung zu beeinträchtigen. Von der Bidder-Auswahl über die GAM-Integration bis zum laufenden Reporting begleiten wir Publisher durch den gesamten Prozess. In Kombination mit Programmatic-Advertising-Expertise und datengetriebener Optimierung aus über 3.000 Projekten entstehen Monetarisierungssetups, die nachhaltig mehr Erlöse liefern.
