Was der Privacy Sandbox tatsächlich ersetzt

Drittanbieter-Cookies erfüllten vier unterschiedliche Werbefunktionen: interessenbasiertes Targeting, Retargeting, Konversionsmessung und Frequency Capping. Der Privacy Sandbox teilt diese in separate APIs auf, jede mit eigenem Consent-Profil.

Topics API — Interessenbasiertes Targeting

Die Topics API weist jedem Browser eine kleine Gruppe grober Interessenthemen zu — rund fünf Themen pro Woche, aus einer kuratierten Taxonomie von einigen hundert Kategorien gezogen. Wenn ein Publisher document.browsingTopics() aufruft, gibt der Browser bis zu drei Themen zurück, die das Ad-Tech-Ökosystem für kontextuelle Personalisierung ohne jeglichen Cross-Site-Identifikator verwenden kann. Themen werden lokal berechnet, auf dem Gerät gespeichert, rotieren wöchentlich und unterliegen den Benutzereinstellungen in chrome://settings/adPrivacy.

Protected Audience API — Retargeting und Remarketing

Protected Audience, früher FLEDGE, hält Retargeting ohne einen gemeinsamen Cross-Site-Identifikator am Leben. Werbetreibende fügen einen Nutzer auf ihrer eigenen Website einer Interessengruppe hinzu; wenn der Nutzer einen teilnehmenden Publisher besucht, läuft eine gerätebasierte Auktion in einem Fenced Frame und wählt ein Kreativ aus. Die gewinnende Anzeige wird gerendert, ohne dass der Publisher erfährt, welche Interessengruppe übereinstimmte.

Attribution Reporting API — Konversionsmessung

Attribution Reporting ersetzt Konversionspixel für eine Teilmenge von Messanwendungsfällen. Es unterstützt Berichte auf Ereignisebene (verrauscht, verlustreich, pro Konversion) und aggregierte Zusammenfassungsberichte (statistisch entzerrte Rollups). Im Gegensatz zum Legacy-Pixel legt es den individuellen Nutzer-zu-Konversion-Link nicht offen.

Shared Storage und Fenced Frames

Shared Storage ist ein überall beschreibbarer, im Sandbox lesbarer Schlüssel-Wert-Speicher für Cross-Site-Anwendungsfälle wie Frequency Capping und A/B-Experiment-Konsistenz. Fenced Frames sind isolierte iFrames, die verhindern, dass die umgebende Seite die gerenderte Anzeige oder ihre Interaktionsdaten liest.

Benötigt der Privacy Sandbox eine Einwilligung?

Dies ist die am häufigsten missverstandene Frage in der Ad-Tech-Landschaft 2026, und die Antwort ist jurisdiktionsspezifisch.

Unter DSGVO und ePrivacy

Der Europäische Datenschutzausschuss EDPB hat keine allgemeine Position herausgegeben, aber nationale Behörden waren expliziter. Die UK ICO, der italienische Garante und Frankreichs CNIL haben alle die Auffassung vertreten, dass Topics und Protected Audience eine vorherige Opt-in-Einwilligung erfordern, wo sie personenbezogene Daten verarbeiten, einschließlich jeder Verarbeitung, die Zustände auf dem Gerät des Nutzers schreibt oder liest. Die Logik: Der Browser speichert weiterhin lokal Interessenthemen und Interessengruppen, und der document.browsingTopics()-Aufruf überträgt abgeleitete personenbezogene Daten an einen Dritten. Dies wird nach Artikel 5(3) der ePrivacy-Richtlinie reguliert, der eine Einwilligung für jeden Zugriff auf oder jede Speicherung im Endgerät des Nutzers erfordert, der über das für den angeforderten Dienst unbedingt Notwendige hinausgeht.

Googles Position ist permissiver — sie argumentieren, dass die APIs datenschutzsicher nach Design sind und dass Einwilligungsanforderungen in allen Kontexten möglicherweise nicht gelten. Dies ist keine Regulatoren-Position. Den Privacy Sandbox in Europa als einwilligungsbefreit zu behandeln ist eine Hochrisiko-Haltung.

Unter CCPA, CPRA und US-Bundesstaatsgesetzen

In den Vereinigten Staaten werden Privacy-Sandbox-Flows im Allgemeinen als Weitergabe persönlicher Informationen für kontextübergreifende Verhaltenswerbung nach CPRA behandelt. Das bedeutet, dass sie das Opt-out-Recht auslösen und durch Global Privacy Control-Signale und andere universelle Opt-out-Mechanismen respektiert werden müssen. Die Tatsache, dass Topics-Daten vom Browser abgeleitet werden, anstatt von einem Drittanbieter-Broker verkauft zu werden, befreit sie nicht.

Chromes eigene Steuerungen

Chrome stellt nutzerorientierte Schalter in chrome://settings/adPrivacy für Topics, Protected Audience und Attribution Reporting bereit. Diese Benutzeroptionen stehen neben — nicht anstelle von — dem Einwilligungsstatus Ihres CMP. Ein Nutzer, der in Ihrem Banner nein zu Werbe-Cookies gesagt hat, aber ja zu Topics in Chromes globalen Einstellungen, hat Ihnen durch das Banner trotzdem nein gesagt. Ihr Stack muss das Strengere der beiden Signale respektieren.

Die Consent-Schicht, die Sie tatsächlich benötigen

Ein produktionsreifer Consent-Stack 2026 behandelt Privacy-Sandbox-APIs als separate Verarbeitungstätigkeiten, die jeweils über IAB-TCF-Zwecke oder gleichwertige bundesstaatliche Rechtskategorien gesteuert werden.

Zuordnung von Sandbox-APIs zu TCF-Zwecken

• Topics API — IAB TCF Zweck 2 (Grundlegende Anzeigen auswählen) und Zweck 3 (Ein personalisiertes Anzeigenprofil erstellen) mindestens; Zweck 4 (Personalisierte Anzeigen auswählen), wenn die Themen das Targeting befeuern.
• Protected Audience — Zweck 3 und 4, plus Zweck 7 (Anzeigenleistung messen), wenn die Auktion Ergebnisdaten verwendet.
• Attribution Reporting — Zweck 7 (Anzeigenleistung messen) und Zweck 9 (Zielgruppen durch Statistiken verstehen).
• Shared Storage für Frequency Capping — Zweck 3, wo es Personalisierung speist, oder eine Grundlage berechtigten Interesses, wo es reine Frequenzkontrolle ist.

Zuordnung zu Google Consent Mode v2

Google Consent Mode v2-Signale werden dem Privacy-Sandbox-Verhalten zugeordnet:

• ad_storage verweigert — Topics- und Protected-Audience-API-Aufrufe vollständig deaktivieren
• ad_user_data verweigert — Attribution Reporting daran hindern, nutzerbezogene Daten zu senden
• ad_personalization verweigert — Topics-Eingaben in die Targeting-Logik überspringen

Verarbeitung von US-Bundesstaats-Signalen

Für US-Traffic sollte Ihre Consent-Schicht den Global Privacy Control und anwendbare Bundesstaats-Opt-out-Signale prüfen. Wenn ein US-Nutzer die Weitergabe abgelehnt hat, unterdrücken Sie document.browsingTopics(), rufen Sie joinAdInterestGroup nicht auf und entfernen Sie Attribution-Reporting-Registrierungs-Header.

Praktische Implementierungsmuster

Publisher, die Privacy Sandbox bereits eingeführt haben, folgen im Allgemeinen einem von zwei Architekturmustern.

Muster 1: Serverseitige Orchestrierung

Ein First-Party-Tag-Manager auf Ihrem Origin sammelt den Einwilligungsstatus, die Nutzerjurisdiktion und eventuelle Signal-Überschreibungen und rendert dann bedingt die Privacy-Sandbox-Hooks in die Seite. Der Ad-Server und SSP erhalten Einwilligungs-Flags über die Bid-Anfrage und entscheiden, ob Topics, Protected Audience oder keines aufgerufen werden soll. Dieses Muster zentralisiert die Logik und hält den Einwilligungsstatus autoritativ.

Muster 2: Header-Bidding-Wrapper-Integration

Prebid.js und andere Header-Bidding-Wrapper unterstützen jetzt Privacy-Sandbox-Module. Der Wrapper liest das Einwilligungssignal, konfiguriert das Topics-Aufrufverhalten und leitet das Auktionsergebnis durch Protected Audience weiter, wenn erlaubt. Dieser Ansatz ist leichter zu implementieren, verlagert aber mehr Logik in den Client und strafft Ihre Abhängigkeit vom Wrapper-Release-Rhythmus.

Was zu auditieren ist

• Bestätigen Sie, dass document.browsingTopics() nur aufgerufen wird, wenn der Werbe-Consent des CMP positiv ist und kein Opt-out-Signal vorliegt
• Bestätigen Sie, dass joinAdInterestGroup und runAdAuction durch dieselben Bedingungen gesteuert werden
• Bestätigen Sie, dass Attribution-Reporting-Registrierungs-Header nur in Antworten für Nutzer gesendet werden, deren Einwilligungsstatus Messung erlaubt
• Bestätigen Sie, dass Ihre Anbieterliste im TCF-String noch mit den SSPs und DSPs übereinstimmt, die Sandbox-APIs in Ihrem Inventar verwenden
• Bestätigen Sie, dass Ihre Datenschutzerklärung Topics, Protected Audience und Attribution Reporting als separate Verarbeitungstätigkeiten mit Rechtsgrundlage und Aufbewahrungsdauer beschreibt

Was der Privacy Sandbox nicht tut

Mehrere gängige Missverständnisse müssen sterben, bevor Sie dagegen budgetieren.

Es ist keine Einwilligungsumgehung

Die APIs reduzieren die Werbetreibenden offengelegten personenbezogenen Daten, befreien aber die zugrundeliegende Verarbeitung nicht von der Einwilligungspflicht nach europäischem Recht. Die Compliance-Theorie, dass die Sandbox-Einführung Ihnen erlaubt, einen CMP zu überspringen, ist in jeder EU/EEA-Jurisdiktion falsch.

Es ist heute kein vollständiger Cookie-Ersatz

Topics liefert ein grobkörniges, verlustreiches Targeting-Signal, das typischerweise schwächer ist als Cookie-basierte Zielgruppen. Die Retargeting-Skalen von Protected Audience reifen noch. Attribution Reporting hat Messlärm-Untergrenzen, die kleine Konversionsanstiege verbergen können. Ein Publisher, der heute alle Monetarisierung auf Sandbox umstellt, sollte RPM-Rückgänge von 10–30 Prozent gegenüber einem Cookie-basierten Stack bei typischem Inventar erwarten.

Es ist nicht dauerhaft in seiner aktuellen Form

Die Privacy-Sandbox-Spezifikation entwickelt sich noch. Die Topics-Taxonomie erweitert sich, die Interessengruppen-Grenzen von Protected Audience werden überarbeitet, und die regulatorische Reaktion ist noch im Gange. Entwerfen Sie Ihre Consent-Schicht so, dass sie konfigurationsgesteuert ist, nicht hart auf die aktuelle Spezifikation kodiert.

Die richtige Haltung für 2026

Privacy Sandbox ist am besten als eine Schicht einer breiteren Cookie-freien Strategie zu verstehen, neben First-Party-Daten, vom Verkäufer definierten Zielgruppen, kontextuellem Targeting und serverseitigem Header Bidding. Die Publisher, die 2026 gewinnen werden, sind diejenigen, die Einwilligung als Schiedsrichter behandeln, nicht als Hindernis — Sandbox-APIs nur speisen, wo Gesetz und Nutzerentscheidung es erlauben, überall sonst sauber auf Kontextuell zurückfallen und Ergebnisse auf beiden Wegen mit Werkzeugen messen, die keine Identität voraussetzen.

Die schlechteste Haltung ist die abwartende. Regulatoren schreiben bereits die nächste Welle von Regeln — die Sandbox-Verpflichtungen der UK Competition and Markets Authority, laufende CNIL-Leitlinien und die Profilierungsbestimmungen des EU AI Act berühren alle dieses Terrain. Publisher, die Privacy Sandbox 2026 in einen ordnungsgemäß gesteuerten Consent-Stack einbauen, werden für diese Regeln gerüstet sein. Diejenigen, die es als Last-Minute-Cookie-Ersatz hinzufügen, werden sich dabei ertappen, unter Druck umzuschreiben.