Header Bidding vs. Waterfall: Was Programmatic-Einkäufer wissen sollten

Vor zehn Jahren verkauften Publisher ein und denselben Werbeplatz noch Käufer für Käufer. Eine direkt verkaufte Kampagne hatte den ersten Zugriff, danach kam ein Werbenetzwerk, dann das nächste, und was übrig blieb, ging an den Backfill-Tag mit der niedrigsten Priorität. Jeder Käufer bekam die Impression nur zu sehen, wenn alle vor ihm verzichtet hatten. Diese Abfolge hatte einen Namen – Waterfall – und war über weite Teile der Display-Werbeära schlicht die Art und Weise, wie Publisher ihr Inventar monetarisierten.

Header Bidding hat diese Abfolge durch etwas ersetzt, das einer offenen Auktion deutlich näherkommt: Alle angebundenen Demand-Quellen bewerten dieselbe Impression zur selben Zeit, und der Publisher wählt das höchste Gebot aus, noch bevor die Seite vollständig geladen ist. Für Media Buyer oder DSP-Betreiber ist der Unterschied mehr als nur eine technische Detailfrage. Er bestimmt, welche Impressions Ihre Gebote überhaupt zu sehen bekommen, wie schnell eine Gebotsentscheidung fallen muss und welcher Anteil der Auktion tatsächlich Ihre Plattform erreicht, statt bereits vorgelagert herausgefiltert zu werden.

Dieser Leitfaden erklärt, wie Waterfall und Header Bidding tatsächlich funktionieren, warum sich die Branche weitgehend von sequenziellen Abfragen verabschiedet hat und was DSP-Betreiber oder Media-Buying-Teams darüber wissen sollten, wo ihre Gebote in einer Header-Bidding-Auktion stehen.

Was ist Waterfall Ad Serving?

Waterfall Ad Serving ist eine sequenzielle, nach Priorität geordnete Abfragekette. Der Ad Server des Publishers verwaltet eine Liste von Demand-Quellen, sortiert nach dem Preis, den die jeweilige Quelle in der Vergangenheit bezahlt oder garantiert hat, und fragt diese nacheinander ab. Hat die erste Quelle keine passende Kampagne oder wird ihr Mindestpreis nicht erreicht, leitet der Ad Server die Anfrage an die nächste Quelle weiter. Das setzt sich fort, bis jemand die Impression ausliefert oder die Liste erschöpft ist und der Werbeplatz leer bleibt.

Die Rangfolge in einem Waterfall ist in der Regel statisch und wird manuell von einem Ad-Ops-Team auf Basis historischer Durchschnitts-CPMs festgelegt – nicht anhand des tatsächlichen Werts genau dieser Impression in genau diesem Moment. Eine Demand-Quelle auf Rang vier kann preislich nie gegen die Quelle auf Rang eins antreten; sie kommt nur zum Zug, wenn alle vor ihr ablehnen. Das unterscheidet sich grundlegend von einer RTB-Auktion, bei der alle Teilnehmer gleichzeitig auf dieselbe Impression bieten.

Das Kernproblem des Waterfall-Modells

Die größte Schwäche des Waterfalls besteht darin, dass Preisrang und Prioritätsrang nicht dasselbe sind, die Abfolge sie aber so behandelt, als wären sie es. Eine Demand-Quelle mit historisch niedrigerem Durchschnitts-CPM wäre für diese konkrete Impression möglicherweise bereit, mehr zu zahlen als die vor ihr platzierte Quelle – doch der Waterfall lässt dieses Gebot nie zum Zug kommen. Der Publisher verliert bei jeder Impression Umsatz, bei der eine niedriger eingestufte Quelle mehr gezahlt hätte.

Hinzu kommen Latenzkosten. Jede Stufe im Waterfall ist ein eigener Roundtrip: Anfrage raus, Antwort zurück, dann gegebenenfalls weiter zur nächsten Quelle. Ein Werbeplatz, der fünf oder sechs Quellen durchlaufen muss, bevor er ausgeliefert wird, summiert diese Latenz seriell auf. Das ist ein Grund dafür, warum Seitenladezeiten zu einem sichtbaren Problem wurden, als die Zahl der von Publishern angebundenen Demand-Quellen in den 2010er-Jahren stetig wuchs.

Darüber hinaus sind Waterfall-Setups für Käufer intransparent. Eine DSP, die in der Prioritätsreihenfolge weit unten steht, hat kaum Einblick darin, wie oft sie tatsächlich den gesamten Pool verfügbarer Impressions sieht – oder nur jene, die niemand vor ihr wollte. Win Rate und Bid Rate lassen sich kaum interpretieren, wenn Sie nicht wissen, welcher Anteil der gesamten Möglichkeiten Ihnen überhaupt angeboten wurde.

Was ist Header Bidding?

Header Bidding ist ein Auktionsverfahren, bei dem ein Publisher dieselbe Impression mehreren Demand-Quellen gleichzeitig anbietet, noch bevor der primäre Ad Server der Seite überhaupt aufgerufen wird. Der Name geht auf den Ort der ursprünglichen Implementierung zurück: ein kleines JavaScript im HTML-Header der Seite, das gleichzeitig Bid Requests an alle angebundenen Supply-Side-Plattformen und Exchanges sendet, die Antworten innerhalb eines kurzen Timeout-Fensters einsammelt und das höchste Gebot als Line Item an den Ad Server übergibt.

Statt einer festen Rangfolge konkurrieren alle Demand-Quellen parallel und innerhalb derselben wenigen Hundert Millisekunden mit dem tatsächlichen Preis, den sie für genau diese Impression zu zahlen bereit sind. Der Ad Server des Publishers führt anschließend einen letzten Vergleich zwischen dem siegreichen Header-Gebot und etwaigen direkt verkauften oder Programmatic-Guaranteed-Line-Items durch – und das tatsächlich höchste Angebot erhält den Werbeplatz.

Für eine DSP bedeutet die Anbindung an eine Header-Bidding-Auktion in der Praxis, dass sie bei dieser konkreten Impression preislich gegen alle anderen Teilnehmer antritt – und nicht um eine Rangposition konkurriert, die vorab auf Grundlage sachfremder historischer Durchschnittswerte festgelegt wurde.

So läuft eine Header-Bidding-Auktion tatsächlich ab

Ein Header-Bidding-Aufruf durchläuft stets dieselben Schritte, unabhängig davon, welchen Wrapper oder welche Implementierung ein Publisher nutzt:

• Die Seite beginnt zu laden, und das Header-Bidding-Skript sendet gleichzeitig Bid Requests an alle angebundenen Demand-Quellen.
• Jede Quelle – einschließlich angebundener DSPs – prüft die Anfrage gegen aktive Kampagnen und gibt innerhalb des Timeout-Fensters der Auktion ein Gebot ab, in der Regel innerhalb weniger Hundert Millisekunden.
• Gebote, die nach Ablauf des Timeouts eintreffen, werden vollständig verworfen. Die Antwortgeschwindigkeit einer DSP entscheidet also direkt darüber, ob sie überhaupt mitbieten kann.
• Der Header-Bidding-Wrapper sammelt alle gültigen Gebote und übergibt das höchste als dynamisch bepreistes Line Item an den Ad Server des Publishers – neben etwaigen Direkt- oder Garantie-Deals.
• Der Ad Server führt einen letzten Vergleich über alle infrage kommenden Line Items durch und rendert das tatsächlich siegreiche Werbemittel.

Da jeder Schritt dieser Abfolge abgeschlossen sein muss, bevor der Werbeplatz gerendert wird, ist das Timeout-Fenster die harte Grenze. Eine DSP, die ein Gebot nicht innerhalb dieses Fensters empfangen, bewerten und zurückgeben kann, wird schlicht nicht berücksichtigt. Genau dieser Druck ist der Grund, warum unbegrenzte QPS und eine Infrastruktur mit niedriger Latenz für jede Plattform entscheidend sind, die breit in Header-Bidding-Auktionen mitbieten will.

Client-Side vs. Server-Side Header Bidding

Als Publisher begannen, Header Bidding in großem Maßstab einzusetzen, entwickelten sich zwei Implementierungsmodelle – und der Unterschied ist relevant dafür, wie viel Latenz die Auktion einer Seite hinzufügt.

Viele Publisher setzen heute auf ein hybrides Setup: Eine kleinere Gruppe hochwertiger Demand-Quellen wird aus Transparenzgründen client-seitig abgefragt, der Rest läuft server-seitig, damit die Seite auch bei wachsender Zahl angebundener Exchanges und DSPs schnell lädt. Für DSP-Betreiber sind server-seitige Header-Bidding-Integrationen in der Regel die Quelle für höheres und gleichmäßigeres Gebotsvolumen, da sie nicht dadurch begrenzt werden, wie viele client-seitige Aufrufe ein Browser realistischerweise ausführen kann, bevor sich die Seite träge anfühlt.

Wo DSPs im Header-Bidding-Stack verortet sind

Eine DSP führt selbst keine Header-Bidding-Auktion durch – das übernehmen Publisher und ihre Wrapper. Die DSP ist vielmehr eine der angebundenen Demand-Quellen: Sie empfängt die gleichzeitigen Bid Requests, die ein Header-Bidding-Aufruf erzeugt, und antwortet über die jeweilige SSP- oder Exchange-Anbindung, über die das Inventar des Publishers geleitet wird.

Da eine einzelne Impression eine DSP heute über mehrere Wege gleichzeitig erreichen kann, hat Header Bidding auch die Supply Path Optimization deutlich wichtiger gemacht, als sie es zu Waterfall-Zeiten war. Derselbe Werbeplatz eines Publishers kann einer DSP gleichzeitig über drei oder vier verschiedene SSPs angeboten werden, die jeweils ihren eigenen Anteil einbehalten. DSP-Betreiber, die erkennen und steuern können, über welche Pfade sie bieten, statt standardmäßig jede doppelte Route zu akzeptieren, lenken einen größeren Teil ihres Budgets in tatsächliche Medialeistung statt in redundante Intermediärsgebühren.

Abwägungen, die Programmatic-Einkäufer im Blick behalten sollten

Header Bidding hat das Problem der Prioritätsränge gelöst, bringt aber eigene Herausforderungen mit sich, die Media Buyer oder DSP-Betreiber aktiv managen müssen, statt sie zu ignorieren.

Die Seitenlatenz ist die offensichtlichste. Jede zusätzliche client-seitige Demand-Quelle verlängert die Zeit, bis die Seite vollständig interaktiv ist. Publisher, die ohne Disziplin zu viele Anbindungen stapeln, können ihrer eigenen User Experience schaden – und in der Folge auch ihrer Ad Viewability. Käufer, die die Inventarqualität eines Publishers bewerten, sollten daher berücksichtigen, wie schwergewichtig dessen Header-Bidding-Wrapper ist, und nicht nur auf das reine Gebotsvolumen schauen.

Die zweite Herausforderung sind doppelte Bid Requests. Da Header Bidding es Publishern ermöglicht, dieselbe DSP über mehrere SSP-Pfade anzubinden, kann eine einzelne Impression innerhalb derselben Auktion mehrere nahezu identische Bid Requests an dieselbe DSP auslösen. Bleibt das ungesteuert, steigt das Bid-Request-Volumen, ohne dass echte Gelegenheiten hinzukommen. Das ist einer der Gründe, warum es Transparenzmaßnahmen wie ads.txt und sellers.json gibt: Damit kann eine DSP überprüfen, welche Pfade autorisiert sind und bei welchen es sich um redundante oder nicht autorisierte Reseller handelt.

Header Bidding vs. Waterfall: Was ist für Sie als Einkäufer relevant?

Der Großteil des Premium-Publisher-Inventars ist bereits auf Header Bidding umgestellt. In der Praxis wählen Media Buyer oder DSP-Betreiber also nicht zwischen den beiden Modellen, sondern stellen sicher, dass ihre Plattform für das heute übliche Modell ausgelegt ist. Das bedeutet: schnelle, zuverlässige Gebotsantworten innerhalb enger Timeout-Fenster, Anbindungen, die breit genug sind, um in die Wrapper vieler Publisher eingebunden zu werden, und ausreichend Einblick in Supply Paths, um keine redundanten Gebühren für doppelte Routen zur selben Impression zu zahlen.

Praktisch relevant bleibt die Unterscheidung bei der Bewertung einer DSP-Plattform selbst. Eine Plattform, die die Queries per Second drosselt oder die Zahl der Exchange-Anbindungen begrenzt, wird in Header-Bidding-Auktionen strukturell den Kürzeren ziehen – so wie früher eine niedrig eingestufte Quelle im Waterfall, nur aus einem anderen Grund: Sie kann nicht rechtzeitig auf jeden gleichzeitigen Bid Request antworten, statt gar nicht erst abgefragt zu werden.

Bereit, in jeder Auktion mitzubieten – nicht nur in denen, zu denen Sie aufgerufen werden?

AdTech Europe bietet Agenturen, Werbenetzwerken und Media-Buying-Teams eine vollständig eigene DSP, die für die simultanen, volumenstarken Auktionen des Header Biddings entwickelt wurde – mit unbegrenzten QPS und ohne Drosselung, ob als White-Label-Miete, als Lizenz oder als vollständiger Erwerb des Quellcodes. Jeder Plan ist ab Werk mit über 1,000+ SSP-Integrationen verbunden, sodass das Gebotsvolumen mit den auf der Plattform laufenden Kampagnen skaliert statt mit dem festen Kontingent eines gemieteten Seats. Die aktuellen Preise für alle drei Eigentumsmodelle finden Sie auf der Preisseite.

Wenn Sie besprechen möchten, wie Ihr aktuelles Setup mit dem Header-Bidding-Volumen umgeht, oder erfahren möchten, was sich durch eine eigene Plattform ändern würde, vereinbaren Sie ein Programmatic-Strategiegespräch mit dem Team von AdTech Europe.

FAQs

Was ist der Unterschied zwischen Header Bidding und Waterfall?

Beim Waterfall werden Demand-Quellen nacheinander in einer festen Prioritätsreihenfolge abgefragt; eine niedriger eingestufte Quelle kommt also nur zum Zug, wenn alle vor ihr verzichten. Beim Header Bidding werden alle angebundenen Demand-Quellen gleichzeitig abgefragt, und das höchste tatsächliche Gebot gewinnt – unabhängig vom historischen Rang.

Warum haben sich Publisher vom Waterfall Ad Serving abgewandt?

Durch die feste Prioritätsreihenfolge im Waterfall konnte eine niedriger eingestufte Quelle eine höher eingestufte bei einer bestimmten Impression nie überbieten, selbst wenn sie bereit war, mehr zu zahlen. Dadurch blieb Umsatz liegen, und die Seiten wurden langsamer, weil sich immer mehr sequenzielle Aufrufe aneinanderreihten.

Was ist der Unterschied zwischen Client-Side und Server-Side Header Bidding?

Beim Client-Side Header Bidding läuft die Auktion im Browser des Nutzers. Das ist einfach zu prüfen, verlängert aber die Ladezeit, je mehr Demand-Quellen hinzukommen. Beim Server-Side Header Bidding läuft die Auktion auf einem Server, sodass die Seite schnell bleibt, der Publisher jedoch weniger direkten Einblick in die einzelnen Gebote hat.

Verlangsamt Header Bidding die Ladezeiten von Seiten?

Das kann passieren, insbesondere bei schwergewichtigen Client-Side-Setups mit vielen angebundenen Demand-Quellen, da jede davon einen Roundtrip hinzufügt, bevor die Auktion abgeschlossen ist. Server-Side- und Hybrid-Implementierungen gibt es vor allem, um diesen Effekt zu verringern und dennoch eine breite Nachfrage zu erreichen.

Wie wirkt sich Header Bidding auf das Gebotsvolumen einer DSP aus?

Durch Header Bidding erhält eine DSP gleichzeitig Zugang zu jeder Impression eines angebundenen Publishers – nicht nur zu denen, die ein Waterfall an sie weitergereicht hat. Das erhöht in der Regel das Gebotsvolumen, allerdings nur, wenn die DSP auch in großem Maßstab innerhalb des Timeout-Fensters der Auktion antworten kann.

Was ist Supply Path Optimization und welcher Zusammenhang besteht mit Header Bidding?

Supply Path Optimization bezeichnet die Praxis, bei mehreren verfügbaren Pfaden den direktesten und kosteneffizientesten Weg zu einer Impression zu identifizieren und zu bevorzugen. Header Bidding hat diese Praxis wichtiger gemacht, da dieselbe Impression eine DSP heute gleichzeitig über mehrere SSP-Anbindungen erreichen kann, die jeweils eigene Gebühren erheben.

Müssen DSP-Betreiber etwas konfigurieren, damit Header Bidding funktioniert?

Eine DSP hat keinen Einfluss auf den Header-Bidding-Wrapper des Publishers. Sie benötigt jedoch schnelle, zuverlässige Anbindungen und ausreichend Query-Kapazität, um innerhalb des Timeout-Fensters der Auktion auf gleichzeitige Bid Requests zu antworten, sowie Einblick in die Supply Paths, um nicht auf redundante doppelte Routen zu bieten.