Die letzten Chrome-Stable-Channels, die einen klassischen Third-Party-Cookie-Header noch akzeptieren, sind seit Anfang Juni 2026 ausgerollt. Wer auf den entsprechenden Telemetrie-Dashboards von Prebid Server oder den großen SSPs in den vergangenen vier Wochen mitgelesen hat, sieht eine klare Linie: die Cookie-Match-Rate gegen die etablierten DSPs liegt im Median bei 11 bis 13 Prozent, gestützt fast ausschließlich durch Safari- und Firefox-Restvolumen sowie einen schmalen Sliver an Chrome-Enterprise-Installationen mit explizitem Policy-Override. Vor dem Tracking-Protection-Rollout 2024 lag dieselbe Match-Rate je nach Region bei 68 bis 74 Prozent.

Die Konsequenz ist nicht der oft beschworene Markteinbruch, sondern eine Umverteilung. Wer in den vergangenen 24 Monaten konsequent gegen die Privacy Sandbox getestet, Fallback-IDs onboardet und Server-Side-Pipelines aufgebaut hat, sieht in den eigenen Yield-Reports einen ECPM-Rückgang im einstelligen Prozentbereich. Wer das nicht getan hat, verliert auf inkonsistenten Audience-Stacks zweistellig.

Topics API: 470 Kategorien, drei Wochen Fenster

Die Topics API ist in der produktiv ausgespielten Version inzwischen auf die IAB Audience Taxonomy v2.x gemappt. Konkret stehen rund 470 Topics zur Verfügung, die On-Device auf Basis der zuletzt besuchten Hostnamen klassifiziert werden. Das Beobachtungsfenster beträgt 21 Tage; pro Epoche (eine Woche) werden bis zu fünf Topics berechnet, davon drei pro document.browsingTopics()-Aufruf zurückgegeben. Ein Topic enthält einen 5-Prozent-Random-Noise, der pro Nutzer und Epoche deterministisch ist.

Für Publisher bedeutet das: Targeting auf hochgranulare Interest-Segmente wie „Performance Computing → Workstation Cooling” funktioniert nicht. Was funktioniert sind Top-Level-Cluster wie „Arts & Entertainment → Music”, „Finance → Investing” oder „Autos & Vehicles → Custom & Performance Vehicles”. Die typische Reach-Verteilung in DACH-Inventar zeigt zehn bis zwölf dominierende Topics, die zusammen etwa 60 Prozent aller Impressions abdecken. Der Long-Tail darunter ist programmatisch handelbar, aber selten skalierungsfähig.

Praktisch wichtig: Topics werden nicht im Bid-Request mitgeführt, solange der Publisher nicht aktiv Permissions-Policy: browsing-topics=* setzt und der Bidder den entsprechenden Sec-Browsing-Topics-Header anfordert. SSP-seitig haben Magnite, Index Exchange und PubMatic den Header inzwischen flächendeckend an die nachgelagerten DSPs durchgereicht; Xandr (jetzt Microsoft Advertising) reicht ihn nur an ausgewählte Buyer-Cluster weiter.

Protected Audience API: Custom Audiences ohne Cross-Site-State

Was vor zwei Jahren noch unter dem Arbeitstitel FLEDGE lief, ist seit der finalen Origin-Trial-Phase im Q4 2025 als Protected Audience API stabil. Der Mechanismus ist konzeptuell sauber, in der Trafficking-Praxis aber anspruchsvoll: Interest Groups werden im Browser registriert (navigator.joinAdInterestGroup), Bid-Logik läuft als JavaScript-Worklet on-device, Auction-Logik des Sellers ebenso. Ein klassischer Cookie-Sync zwischen DSP und SSP existiert nicht mehr.

Für klassisches Retargeting heißt das: der Advertiser-Tag setzt beim Site-Visit eine Interest Group mit einer TTL von typischerweise 30 Tagen. Auf der Publisher-Seite triggert der Ad-Server eine runAdAuction()-Komponentenauktion, die parallel zu Header Bidding läuft. Der Ad-Slot wird in einer Fenced Frame ausgeliefert, ohne dass der eingebettete Werbe-Server Zugriff auf den umgebenden DOM hat.

Die Latenz-Bilanz ist messbar geworden. Eine Component Auction mit drei bis vier registrierten Buyern liegt im Median bei 280 bis 420 ms; die p95-Werte schieben sich je nach Worklet-Komplexität auf 600 bis 850 ms. Wer Protected Audience parallel zu Prebid in einer einheitlichen Wrapper-Auktion betreibt, schneidet die Gesamt-Auction-Timeout entsprechend auf 2000 ms hoch.

Operativ kritisch ist die K-Anonymity-Schwelle: Eine Creative-Render-URL muss mindestens 50 Nutzer in den vergangenen sieben Tagen angesprochen haben, sonst wird sie nicht gerendert. Für tief segmentiertes Retargeting mit kleinen Audiences führt das zu Delivery-Lücken, die im Reporting als Win-aber-kein-Render auftauchen.

Attribution Reporting API: Differential Privacy als Bias-Quelle

Die Attribution Reporting API liefert zwei Report-Typen: event-level reports mit grober Conversion-Granularität (3 Bit für Klick-Attribution, 1 Bit für View-Attribution) und summary reports, die aggregiert über Aggregation Services laufen und Differential-Privacy-Noise enthalten.

Der Epsilon-Parameter steuert den Trade-off zwischen Privacy-Garantie und Mess-Genauigkeit. Praktisch arbeiten die meisten Buyer mit Epsilon-Werten zwischen 10 und 64, wobei Google in der Coordinator-Konfiguration aktuell ein Budget von Epsilon=64 pro Source-Site und Tag freigibt. Der eingespeiste Laplace-Noise hat eine Standardabweichung, die für eine Kampagne mit 10.000 Conversions im niedrigen zweistelligen Bereich liegt. Bei kleineren Kampagnen unter 500 Conversions verschwindet das Signal im Rauschen.

Für Performance-Teams ergibt sich daraus eine pragmatische Regel: Attribution Reporting ist für Brand-Lift-Studien und große, langlaufende Performance-Kampagnen brauchbar. Für taktische Wochen-Optimierung auf Long-Tail-Creatives bleibt es untauglich, weil die Noise die Optimierungs-Signale überdeckt.

Fallback-IDs: UID 2.0, ID5, RampID im Bid-Stream

Ohne Cookie-Sync braucht der programmatische Markt ein deterministisches oder probabilistisches ID-Substrat. Drei Anbieter haben sich in den vergangenen 24 Monaten durchgesetzt:

ID-Lösung	Trägermedium	Coverage DACH	DSGVO-Basis
UID 2.0	Email-Hash (SHA-256, gesalzen)	18-22 %	Consent + Login
ID5	Probabilistisch + Email-Hash	35-48 %	Consent + LegInt mixed
RampID	Email/Phone-Hash, LiveRamp Graph	12-16 %	Consent + Login

UID 2.0 und RampID setzen auf authentifizierte Identifier, die der Publisher beim Login-Event hasht und in den Bid-Request einspeist. ID5 mischt probabilistische Signale (User-Agent, IP-Range, Spracheinstellungen) mit deterministischen Email-Hashes, wo verfügbar.

Die DSGVO-Bewertung ist nicht trivial. Authentifizierte ID-Lösungen lassen sich als „Legitimate Interest” bei Login-fähigen Publishern argumentieren, sofern die Privacy Notice transparent ist und ein Opt-Out funktioniert. Probabilistische Komponenten erfordern in der überwiegenden Praxis Consent nach Art. 6 Abs. 1 lit. a DSGVO in Verbindung mit § 25 Abs. 1 TTDSG, weil sie auf nicht-strikt-notwendige Endgeräte-Information zugreifen.

Server-Side-Tracking als Ergänzung

Was sich parallel etabliert hat: Server-Side-Container für First-Party-Ereignisse. Google Tag Manager Server-Side, Tealium EventStream und Segment Connections übernehmen das Conversion-Event-Forwarding an Ads-Plattformen direkt vom Server, ohne dass die Browser-zu-Drittanbieter-Kommunikation noch nötig ist.

Die Architektur sieht in der Praxis so aus: Der Browser sendet ein Event an die First-Party-Endpoint (collect.publisher-domain.de), die ihrerseits via Server-to-Server-Aufruf an Google Ads, Meta Conversions API oder TikTok Events API weiterleitet. Vorteil: die Datenhoheit bleibt beim Publisher, der Hash-und-Match-Prozess läuft serverseitig, Browser-seitige Cookie-Restriktionen greifen nicht. Nachteil: der Trafficking-Aufwand steigt deutlich, weil jeder Event-Sink eine eigene Mapping-Konfiguration braucht.

Was Publisher gelernt haben

Die 24 Monate Tracking Protection haben drei stabile Erkenntnisse hinterlassen. Erstens: Authenticated Traffic ist die wichtigste Yield-Lever. Publisher, die ihre Login-Rate von 8 auf 25 Prozent gehoben haben, verdienen pro authentifizierter Impression das Zweieinhalbfache einer anonymen Impression bei programmatischen Buyern, die UID 2.0 oder RampID prozessieren.

Zweitens: Contextual Targeting ist zurück. IAB Content Taxonomy v3 mit ihren rund 700 Kategorien wird im Bid-Request mitgeführt, semantische Page-Analyse über GumGum, Seedtag und Peer39 ist nachfragesigniert. ECPMs für sauber kontextualisiertes Inventar liegen bei 60 bis 80 Prozent des Niveaus authentifizierter Cookie-Equivalente.

Drittens: Die Konsolidierung schreitet voran. Kleine SSPs ohne signifikante Topics-API-Integration und ohne Protected-Audience-Worklet-Support verlieren Bid-Density. Wer als Publisher mehr als sechs SSPs in der Header-Bidding-Wrapper betreibt, ohne klares Auction-Dynamics-Reporting, verbrennt Latenz für Yield, der sich am Ende nicht materialisiert.

Der Juni-Cutover ist keine Stunde Null. Er ist die Bestätigung dessen, was die Pipeline-Telemetrie seit Mitte 2025 zeigt: der programmatische Markt ist messbar, identifizierbar und steuerbar, aber er ist anders strukturiert als 2023.