Der Header-Bidding-Markt hat sich nach der finalen 3PC-Abschaffung in Chrome neu sortiert. Drei Stacks dominieren das DACH-Publisher-Inventar: Prebid.js in der 9.x-Linie als Open-Source-Referenz, Amazons Transparent Ad Marketplace (TAM) als Server-Side-Cloud-Wrapper, und Google Open Bidding als integrierte Lösung innerhalb von Ad Manager. Wer 2026 einen Wrapper-Refresh plant, kommt um eine nüchterne Gegenüberstellung der drei Architekturen nicht herum.

Die zentralen Vergleichsachsen aus Sicht eines Trafficking-Teams sind Auction-Latenz, Bidder-Adapter-Tiefe, Reporting-Discrepancy gegenüber dem nachgelagerten Ad-Server und die Floor-Price-Steuerung. Daneben zählt, wie sauber sich Topics-API-Header, Protected-Audience-Component-Auctions und Fallback-IDs durch den Stack reichen lassen.

Prebid.js 9.x: 350 Adapter, modulare Wrapper-Logik

Prebid.js liegt aktuell in der 9.x-Linie vor. Der Adapter-Katalog umfasst rund 350 aktive Bidder-Module, davon etwa 240 mit dokumentierter SupplyChain-Object-Unterstützung und 180 mit GVL-ID-Mapping für TCF-2.2-Konformität. Die modulare Build-Pipeline erlaubt es, nur die tatsächlich genutzten Adapter in das ausgelieferte JavaScript zu kompilieren — typische Production-Builds liegen bei 110 bis 160 KB minifiziert für einen Wrapper mit acht bis zwölf aktiven Bidders.

Auction-Timeouts werden im Client-Side-Setup üblicherweise auf 1500 bis 2500 ms konfiguriert. Wer Prebid Server vorschaltet — also die Auktion serverseitig auf einem dedizierten Endpoint laufen lässt und nur das Ergebnis zurückspielt — kommt mit 750 bis 1200 ms aus, weil die einzelnen Bidder-Endpunkte parallel im Backend angesprochen werden und der Browser nur einen Round-Trip macht.

Die First-Price-Auktion ist seit der Migration 2019 bis 2021 marktweit Standard. Prebid 9.x kennt keine Second-Price-Modi mehr; alle Adapter liefern die tatsächliche Bid-CPM zurück, das Wrapper-Bid-Cache-Modul hält die höchsten Bids für nachgelagerte Refresh-Zyklen vor.

Was 9.x gegenüber älteren Versionen messbar verbessert hat: die einheitliche Behandlung von User-IDs über das userId-Submodul, das UID 2.0, ID5, RampID, LiveIntent und CriteoID nativ unterstützt und die jeweiligen Identifier in den OpenRTB-Bid-Request unter user.ext.eids einspeist. Damit entfällt das frühere Adapter-für-Adapter-Mapping.

Amazon TAM: Server-Side mit etwa 80 Bidders

Amazons Transparent Ad Marketplace ist konzeptuell ein anderes Tier. TAM läuft als Cloud-Service auf Amazons Infrastruktur; der Publisher integriert eine schmale Client-Bibliothek (apstag.js, rund 18 KB), die einen einzigen Server-Side-Call gegen die Amazon-A9-Auction triggert. In der Cloud-Auktion sind etwa 80 Bidder registriert, davon eine signifikante Untermenge mit Amazon-DSP-Exklusivität.

Der Vorteil ist Latenz. TAM-Auctions schließen typischerweise in 350 bis 600 ms ab, gemessen vom Client-seitigen fetchBids()-Call bis zum zurückgelieferten Bid-Set. Die Aggregations- und Bid-Reduction-Logik läuft serverseitig, der Browser sieht nur das Endergebnis. Für Publisher mit Mobile-Heavy-Inventar, wo jeder Latenz-Sprung über 300 ms in spürbaren Viewability-Drops resultiert, ist das ein harter Vorteil.

Der Nachteil ist Transparenz. Die einzelnen Bidder-Bids sind im Publisher-Reporting nur als TAM-Aggregat sichtbar; die granulare Adapter-für-Adapter-Optimierung, die Prebid-Operatoren gewohnt sind, ist nicht möglich. Wer Yield-Management auf Bidder-Ebene betreibt, verliert mit TAM eine signifikante Steuerungs-Schicht.

In der DACH-Praxis sehen wir TAM überwiegend als Komplement zu Prebid, nicht als Ersatz. Der typische Stack ruft TAM und Prebid parallel auf, ein vorgeschaltetes Resolver-Modul wartet beide Auctions ab und reicht das maximale Gebot an den Ad-Server weiter. Latenz-Profile dieser Hybrid-Setups liegen bei 1100 bis 1600 ms.

Google Open Bidding: 40 Bidders, native Ad-Manager-Integration

Open Bidding (vormals Exchange Bidding in Dynamic Allocation) läuft vollständig innerhalb von Google Ad Manager. Die teilnehmenden SSPs — aktuell rund 40 Yield-Partner — bieten in Echtzeit gegen Google AdX, die Auktion wird serverseitig in Ad Manager entschieden. Der Publisher konfiguriert keine Client-Side-Tags, die Integration besteht aus einer Trafficking-Konfiguration im Ad-Manager-UI.

Latenz ist hier in der Regel kein Differenzierungs-Faktor, weil die gesamte Auktion zwischen GAM und den Open-Bidding-SSPs serverseitig läuft. Der Browser sieht das Ergebnis als regulären Ad-Manager-Response. Das macht Open Bidding zur latenz-leichtesten Variante, aber zu einer mit weniger Buyer-Diversität als Prebid.

Wo Open Bidding strukturell schwächelt: die Auction-Fairness-Frage. Google AdX läuft in derselben Auktion mit, und die SSPs der Open-Bidding-Familie sehen nicht zwangsläufig dieselben Signale wie AdX. Der EU-DMA-Konformitäts-Druck der vergangenen 18 Monate hat hier zu Anpassungen geführt — unter anderem zur Einführung einer Unified-Auction-Logik, die laut Google nun symmetrische Bid-Signale für alle Teilnehmer garantiert. Wie sauber das in der Praxis umgesetzt ist, lässt sich vom Publisher-Reporting aus nicht vollständig prüfen.

Discrepancy: 3 bis 8 Prozent als realistischer Korridor

Eine Frage, die in jedem Trafficking-Review hochkommt: wie groß ist die Diskrepanz zwischen Wrapper-Reporting und Ad-Server-Reporting? Für Prebid-zu-Google-Ad-Manager liegt der typische Korridor in DACH-Inventar bei 3 bis 8 Prozent, gemessen über mindestens 30 Tage und ein Volumen von über 5 Millionen Impressions.

Die Ursachen sind bekannt und überwiegend technischer Natur. Bid-Caching-Mismatches, Timing-Probleme zwischen prebid.cmd.push und googletag.cmd.push, fehlerhafte SafeFrame-Renderings, die zwar als Win gezählt werden, aber kein Impression-Beacon auslösen. Wer die Diskrepanz unter 5 Prozent halten will, braucht ein sauberes Wrapper-Setup mit enableSendAllBids: true, exakter Targeting-Key-Längen-Konfiguration (Ad Manager schneidet Keys über 40 Zeichen ab) und einer GPT-Slot-Reload-Synchronisation, die kein zweites defineSlot() auslöst, bevor das vorige Bid registriert ist.

Bei TAM liegt die Diskrepanz strukturell niedriger, weil die Auktion serverseitig läuft und das Reporting konsolidiert ist. Typische Werte: 1 bis 3 Prozent. Open Bidding sollte rechnerisch null Diskrepanz haben, weil Wrapper und Ad-Server identisch sind; in der Praxis tauchen aber 1 bis 2 Prozent Diff durch nachträgliche Spam-Filterung auf.

Floor-Strategien: Unified Pricing Rules, dynamic floors, sliding floors

Floor-Price-Steuerung ist in den vergangenen 18 Monaten zu einem der wichtigsten Yield-Hebel geworden. Drei Mechanismen kommen in der Praxis vor.

Unified Pricing Rules in Ad Manager setzen statische Floors pro Country, Device, Ad-Unit oder Audience. Sinnvoll als Baseline, aber nicht reaktiv genug für volatile programmatische Nachfrage. Typische Konfiguration: zwei bis drei Pricing-Buckets pro Ad-Unit, halbjährliche Anpassung auf Basis Win-Rate-Analyse.

Dynamic Floors via Magnite, Index Exchange oder PubMatic laufen direkt im SSP-Backend. Der SSP berechnet aus historischer Bid-Density einen Floor, der pro Auction-Slot dynamisch gesetzt wird. Diese Floors sind im Bid-Request für die Buyer sichtbar (imp.bidfloor), was First-Price-Bid-Shading auf Käuferseite ermöglicht.

Sliding Floors sind ein Hybrid: der Publisher setzt einen Mindest-Floor, der SSP optimiert nach oben innerhalb eines definierten Korridors. Funktioniert gut für Premium-Inventar mit verlässlichem Bid-Stack, weniger gut für Long-Tail-Inventar mit volatiler Nachfrage.

In der Wrapper-Migration-Praxis 2026 sehen wir eine klare Empfehlung: Publisher mit über 50 Millionen Monthly Page Views sollten Prebid 9.x als Wrapper-Kern fahren, TAM parallel als Latenz-leichten Ergänzungs-Stack einbinden, und Open Bidding nur dann hinzunehmen, wenn Ad-Manager die primäre Sales-Schicht ist und das Yield-Team mit Google-AdX-zentrischem Reporting leben kann.

Wer dabei Prebid Server in Erwägung zieht, sollte vorher den Origin-Trial-Status für Topics API und Protected Audience prüfen — beide Header werden vom Client zum Server-Endpunkt nur weitergereicht, wenn die Permissions-Policy auf der Publisher-Domain korrekt konfiguriert ist. Ein 1500-ms-Timeout bringt nichts, wenn die Targeting-Signale unterwegs verloren gehen.