Google Consent Mode Update Juni 2026: Einheitliche Steuerung für alle Google-Ads-Daten

Am 15. Juni 2026 strukturiert Google um, wie Werbedaten zwischen Analytics und Google Ads fließen. Der zentrale Wandel: ad_storage im Consent Mode wird zum einzigen Parameter, der bestimmt, welche Werbedaten erhoben und an Ihr Ads-Konto weitergegeben werden. Wenn Sie Conversion-Kampagnen betreiben, Remarketing-Zielgruppen pflegen oder sich darauf verlassen, dass GA4 Daten an Ads liefert, betrifft dieser Übergang unmittelbar Ihre Messung.

Google Consent Mode Update Juni 2026

Was sich am 15. Juni 2026 ändert

Googles Ankündigung besagt: „Ab dem 15. Juni 2026 wird Google Analytics zum Consent Mode (innerhalb von Google Ads) als einheitlicher Datenkontrolle übergehen." Drei unterschiedliche Änderungen sind in diesen Übergang gebündelt.

1. Google Signals verliert die Kontrolle über die Erhebung von Werbedaten

Bisher bestimmten zwei Faktoren gemeinsam, ob Google Ads Werbe-Cookies und Nutzer-IDs von Ihrer Website erhielt: die Google-Signals-Einstellung innerhalb von Google Analytics und der ad_storage-Parameter im Consent Mode. Beide mussten das Tracking zulassen, damit das vollständige Signal übertragen wurde. Dieses Modell der doppelten Kontrolle bot Organisationen eine Möglichkeit, die Weitergabe von Werbedaten auf Analytics-Ebene einzuschränken, ohne ihre Consent-Mode-Konfiguration anzufassen.

Nach dem 15. Juni endet dieses Modell. ad_storage wird zur alleinigen Kontrollinstanz für alle Werbedaten, die für verknüpfte Ads-Konten erhoben werden. Google Signals wird auf reine Analytics-Zwecke beschränkt, insbesondere auf die Zuordnung von Sitzungen zu angemeldeten Nutzern für das Verhaltensreporting innerhalb von GA4. Die gtag-Einstellung allow_google_signals funktioniert für diesen Reporting-Anwendungsfall weiterhin, hat aber keinen Einfluss mehr darauf, was an Google Ads gelangt.

Bisher war das Deaktivieren von Google Signals ein relativ reibungsloser Weg, um den Fluss von Werbedaten einzuschränken. Nach dem Übergang zählt nur noch ein Hebel: ad_storage im Consent Mode, wodurch die CMP-Konfiguration ins Zentrum Ihrer Datengovernance rückt.

2. Die Konsolidierung der Anzeigenpersonalisierung steht bevor

Google hat angekündigt, dass die Kontrollen zur Anzeigenpersonalisierung künftig unter Google Ads zusammengeführt werden, wobei ad_personalization im Consent Mode v2 zum maßgeblichen Parameter dafür wird, ob Analytics-Daten für personalisierte Werbung genutzt werden dürfen. Ein konkretes Datum wurde noch nicht festgelegt; Google hat angegeben, den Zeitpunkt separat mitzuteilen.

Derzeit sind die Personalisierungseinstellungen auf mehrere Ebenen innerhalb von Analytics verteilt (Konto, Property, Ads-Verknüpfung und Ereignis), was Teams eine granulare Kontrolle ermöglicht. Sobald diese Schichtung wegfällt, wird das ad_personalization-Signal Ihres CMP zum einzigen Entscheidungspunkt. Wird es verweigert, funktionieren Zielgruppenbildung aus Analytics-Daten und Remarketing über Google Ads für diese Nutzer nicht mehr – unabhängig von etwaigen Analytics-seitigen Schaltern.

3. IP-Adressen-Verschlüsselung vor der Übermittlung an Google Ads

Analytics-Tags erheben weiterhin IP-Adressen, doch Google wird diese vor der Weiterleitung an verknüpfte Ads-Konten verschlüsseln. Was nach der Verschlüsselung mit diesen Daten geschieht, wird durch die Einstellungen Ihres Google-Ads-Kontos bestimmt und nicht durch etwas innerhalb von Analytics. Google hat angekündigt, weitere Dokumentation zum Umgang mit IP-Adressen außerhalb regulierter Märkte zu veröffentlichen.

Wer am stärksten betroffen ist

Organisationen, die Google Signals aus Datenschutzgründen deaktiviert haben

Das Deaktivieren von Google Signals war eine gängige Taktik, um zu begrenzen, wie Analytics-Daten mit Ads verknüpft werden, ohne den Consent Mode zu verändern. Manche Datenschutz- und Rechtsteams haben diese Wahl gezielt getroffen, um zu verhindern, dass Besucherdaten mit Google-Kontoidentitäten verknüpft werden, und ihre Compliance-Dokumentation entsprechend aufgebaut.

Nach dem 15. Juni verschwindet diese Schutzmaßnahme. Ist ad_storage in Ihrer CMP-Konfiguration erteilt, beginnt Ads unabhängig vom Signals-Schalter damit, Werbedaten mit angemeldeten Nutzern zu verknüpfen. Die Änderung der Datenverarbeitung erfolgt still auf Googles Seite; keine Aktion Ihrerseits löst sie aus. Wenn „Signals aus" in Ihre AVV oder Ihr Datengovernance-Framework eingeflossen ist, prüfen Sie jetzt Ihre ad_storage-Standardwerte, um sicherzustellen, dass sie Ihre tatsächliche Datenschutzabsicht widerspiegeln.

Publisher und Werbetreibende im EWR, im Vereinigten Königreich und in der Schweiz

Das Update verschärft das Einwilligungsergebnis zu einer binären Entscheidung. Wie Analyst Simo Ahava es beschrieb: „Entweder Sie erteilen ad_storage, und Google nutzt alle verfügbaren Ads-Signale (einschließlich der Verknüpfung des Nutzers mit seiner Google-Anmeldung), oder Sie setzen es auf verweigert, und Google greift auf keine Identifikatoren zu außer dem, was in der URL verfügbar ist (z. B. gclid)."

Ist ad_storage verweigert, kann Ads nur mit URL-Parametern wie gclid arbeiten. Die Conversion-Modellierung im Consent Mode v2 gleicht dies teilweise durch aggregierte Schätzungen aus, doch dieser Prozess erfordert einen Mindestpool an eingewilligten Sitzungen, um verlässliche Zahlen zu liefern. In Märkten wie Deutschland, Frankreich und den Niederlanden, wo die Ablehnungsraten hoch sind, erreichen kleinere Konten diese Schwelle möglicherweise nicht, und Kampagnen, die auf Remarketing-Listen oder Ziel-CPA-Gebotsstrategien basieren, werden unmittelbar getroffen.

Für Regionen mit DSGVO-Geltung ist die korrekte Konfiguration, ad_storage und analytics_storage standardmäßig auf denied zu setzen und erst nach aktiver Zustimmung auf granted zu aktualisieren. Dies wird auch durch die EU-Nutzereinwilligungsrichtlinie vorgeschrieben, die Google 2025 strenger durchgesetzt hat, indem die Personalisierung für nicht konforme Konten deaktiviert wurde.

Werbetreibende mit Remarketing-, Conversion-Tracking- oder Attributionskampagnen

Jede Kampagne, die von einer nutzerbezogenen Identität abhängt, ist gefährdet, wenn ad_storage falsch konfiguriert ist. Die Conversion-Modellierung benötigt ein ausreichendes Volumen an Opt-in-Sitzungen, um Ergebnisse für nicht einwilligende Besucher zu schätzen; unterhalb einer bestimmten Schwelle wird sie unzuverlässig. Remarketing-Listen wachsen nicht mehr weiter, sobald ein verweigerter Status erfasst wird. Customer Match, Floodlight, geräteübergreifende Attribution und Enhanced Conversions hängen alle von Identifikatoren ab, die dieser Parameter steuert. Ein Standardwert von granted, obwohl rechtlich denied vorgeschrieben ist, bläht Zielgruppendaten auf und schafft ein Compliance-Risiko. Lücken auf bestimmten Seiten wie Bestätigungsseiten und Subdomains führen zu unerklärlichen Rückgängen bei den gemeldeten Conversions.

Organisationen, die noch Consent Mode v1 nutzen

Google begann im März 2024 damit, Consent Mode v2 für EWR-Traffic durchzusetzen. Version 2 führte ad_user_data und ad_personalization neben den ursprünglichen beiden Parametern ein. Ein CMP, das nur ad_storage und analytics_storage setzt, betreibt eine unvollständige Integration. Sobald die ad_personalization-Konsolidierung greift, wird diese Lücke besonders folgenreich, da dieser Parameter dann ausschließlich das Personalisierungsverhalten insgesamt regelt.

Was ad_storage tatsächlich steuert

Der Umfang dieses Parameters ist größer, als vielen Werbetreibenden bewusst ist.

Ist ad_storage verweigert, lesen oder schreiben Google-Tags keine Werbe-Cookies (einschließlich _gcl_au), erheben oder übermitteln keine Geräte-Identifikatoren, verknüpfen die Sitzung nicht mit einer Google-Kontoidentität und geben keine nutzerbezogenen Daten an Ads weiter. Die einzige Information, die in diesem Zustand Google Ads erreicht, stammt aus bereits auf der Landingpage vorhandenen URL-Parametern, etwa einer per Klick auf eine bezahlte Anzeige angehängten gclid. Nichts anderes gelangt hindurch.

Ist es erteilt, setzen und lesen Tags Werbe-Cookies, erheben Geräte-Identifikatoren, verknüpfen Sitzungen mit angemeldeten Google-Konten und senden vollständige Messsignale an Ads für Attribution und Zielgruppenbildung. Die Verknüpfung mit der Anmeldung, die zuvor Google Signals steuerte, wird nach dem 15. Juni vollständig hier gehandhabt.

Der Parameter wird über gtag('consent', 'default', {...}) initialisiert, bevor Tags geladen werden, und über gtag('consent', 'update', {...}) aktualisiert, sobald der Nutzer eine Wahl trifft. Eine vollständige Anleitung zur Konfiguration dieser Aufrufe finden Sie im gtag-Integrationsleitfaden. Der Default-Wert legt das Verhalten für Besucher fest, die noch nicht mit dem Banner interagiert haben; das Update übermittelt die tatsächliche Entscheidung. Beide müssen auf jeder Seite in der richtigen Reihenfolge ausgeführt werden, bevor Ads- oder Analytics-Tags geladen werden. Ein fehlender Aufruf, ein zu spätes Auslösen oder ein falscher Parameterwert bedeutet, dass Google auf das falsche Signal reagiert.

So prüfen Sie Ihre Konfiguration vor dem 15. Juni

Schritt 1: Prüfen Sie den Standardzustand bei einem unbeeinflussten Besuch

Öffnen Sie Ihre Website in einem privaten Browserfenster, ohne das Consent-Banner zu berühren. Nutzen Sie den GTM-Vorschaumodus oder den Google Tag Assistant, um zu prüfen, welcher Datenschutzstatus gesetzt ist, bevor ein Tag ausgelöst wird. Für DSGVO-reguliertem Traffic (EWR, UK, Schweiz) müssen ad_storage und analytics_storage standardmäßig auf denied stehen. Ein Standardwert von granted vor jeglicher Nutzerinteraktion ist ein bereits bestehendes Compliance-Problem, das sofort behoben werden muss.

Für Besucher aus den USA hängt der richtige Standardwert vom jeweils geltenden Landesrecht ab. Kalifornien fällt unter CCPA und folgt dem Opt-out-Prinzip, sodass granted akzeptabel ist, solange Sie das Signal des Global Privacy Control respektieren. Bundesstaaten mit Opt-in-Anforderungen benötigen einen Ausgangswert von denied. Ein CMP, das nur mit einem globalen Standardwert statt mit rechtsraumspezifischen Regeln konfiguriert ist, sendet möglicherweise granted an Nutzer, für die rechtlich denied gilt – eine Lücke, die nach dem 15. Juni mehr ins Gewicht fällt.

Schritt 2: Prüfen Sie, ob alle vier Parameter vorhanden sind

Überprüfen Sie, ob sowohl der Default- als auch der Update-Aufruf ad_storage, analytics_storage, ad_user_data und ad_personalization enthalten. Ältere Integrationen übermitteln häufig nur die ersten beiden. Das Flag ad_user_data steuert speziell, ob Erstanbieter-Daten wie E-Mail-Adressen zum gehashten Abgleich an Google gesendet werden dürfen; ohne dieses Flag funktionieren Enhanced Conversions nicht korrekt, selbst wenn ad_storage erteilt ist.

Schritt 3: Prüfen Sie die Abdeckung über jeden Seitentyp hinweg

Ein Datenschutzsignal ist nur dann aussagekräftig, wenn es auf jeder Seite vor den Tags geladen wird, nicht nur auf der Startseite. Bestätigungsseiten nach dem Checkout übersehen dies häufig, weil sie Ads-Conversion-Tags über einen separaten Code-Pfad oder Container einbinden. Subdomains mit eigenen GTM-Instanzen benötigen jeweils eine eigenständige Integration. AMP-Seiten benötigen eine dedizierte Implementierung mit der amp-consent-Komponente, die anders funktioniert als der Standard-gtag-Ansatz. Single-Page-Anwendungen benötigen besondere Aufmerksamkeit, damit die gespeicherte Präferenz über clientseitige Routenwechsel hinweg erhalten bleibt, ohne den Default unnötig erneut auszuführen.

Schritt 4: Testen Sie den Update-Aufruf bei Erst- und Wiederholungsbesuchen

Der Update-Aufruf muss ausgelöst werden, nachdem der Nutzer mit dem Banner interagiert hat, nicht davor. Der häufigste Fehler ist eine Race Condition: GTM hat Ads-Tags bereits ausgeliefert, bevor der Callback des CMP eintrifft, sodass diese Tags unter dem Default-Wert statt der tatsächlichen Nutzerentscheidung ausgeführt werden. Das ist besonders relevant, wenn der Default denied ist und der Nutzer zustimmt, da die erste Pageview-Auslösung dieses Zeitfenster bereits verpasst hat.

Ebenso wichtig: Prüfen Sie, ob das Update auch bei Wiederholungsbesuchen ausgelöst wird, wenn die gespeicherte Präferenz aus einem Cookie ausgelesen wird. Manche CMPs lösen den Callback nur auf der Seite aus, auf der die ursprüngliche Wahl getroffen wurde, und erwarten, dass das Cookie den Zustand bei späteren Besuchen stillschweigend übermittelt. Fehlt diese Bestätigung auf jenen späteren Seiten, behandelt GTM die Sitzungen unter Umständen weiterhin als nicht eingewilligt. Testen Sie beide Abläufe im GTM-Vorschaumodus: einen neuen Besuch mit einer Zustimmungsaktion und einen Wiederholungsbesuch, bei dem die vorherige Wahl automatisch respektiert werden sollte.

Schritt 5: Prüfen Sie die Verknüpfung von GA4 und Ads-Konto

Das neue Modell mit einer einzigen Kontrollinstanz gilt speziell für Properties, die zwischen GA4 und Google Ads verknüpft sind. Prüfen Sie unter GA4-Admin > Google-Ads-Verknüpfungen, ob diese Verknüpfung vorhanden ist und auf das richtige Konto verweist. Eine fehlerhafte oder falsch zugeordnete Verknüpfung bedeutet, dass die Änderungen vom 15. Juni möglicherweise nicht wie erwartet greifen und Ihre Daten das neue Verhalten nicht korrekt widerspiegeln.

Bestätigen Sie außerdem, dass das Auto-Tagging in Google Ads aktiv ist. Der von Ads an Ziel-URLs angehängte gclid-Parameter ist das einzige verfügbare Signal in einem verweigerten Zustand, was diese Einstellung wichtiger denn je macht.

Schritt 6: Überprüfen Sie Diagnosen und Ads-Kontoeinstellungen

Die Tag-Diagnose im GA4-Consent-Hub deckt Signallücken auf und markiert falsch konfigurierte Tags. Navigieren Sie zu Verwaltung, dann Einwilligung, dann Tag-Diagnose. Der UniConsent Consent Data Validator bietet eine unabhängige Ansicht außerhalb der GA4-Oberfläche. Beide Tools weisen eine Verzögerung von 48 bis 72 Stunden auf, beginnen Sie also mindestens zwei Wochen im Voraus mit der Prüfung, damit genug Zeit bleibt, bis Korrekturen vor dem Übergang in den Daten sichtbar werden.

Überprüfen Sie auf der Ads-Seite die kontoweiten Einstellungen zu IP-Anonymisierung, Kundendatenkonfiguration und Personalisierung. Nach dem 15. Juni haben diese Kontoeinstellungen mehr Gewicht als alles innerhalb von Analytics, daher müssen sie zu Ihrer beabsichtigten Konfiguration für jeden von Ihnen bedienten Markt passen.

Das größere Muster

Dieser Übergang ist Teil eines bewussten Vorstoßes von Google, fragmentierte Datenschutzkontrollen zu reduzieren. Mitte 2025 wurde die Tag-Diagnose zum Consent-Hub von Analytics hinzugefügt. Im Juli 2025 verschärfte Google die Durchsetzung der EU-Nutzereinwilligungsrichtlinie und schnitt die Personalisierung für Konten ab, die keine korrekten EWR-Signale übermittelten. Um Dezember 2025 erschienen versteckte Kontrollen zur Datenübermittlung in den Google-Tag-Einstellungen. Im Februar 2026 wurden der Sitzungsattribut- und IP-Adressen-Import aus der Google-Ads-API entfernt, wodurch diese Verantwortung in Richtung des nun im Juni eintreffenden Verschlüsselungsansatzes verlagert wurde.

Das Muster ist eindeutig: produktbezogene Sonderregelungen werden entfernt, Entscheidungen über weniger maßgebliche Kanäle geleitet, und die Datenschutzkontrolle näher an den Ort gerückt, an dem Daten tatsächlich verwendet werden. Für Publisher und Werbetreibende macht dies das CMP zur zentralen Schnittstelle zwischen den Entscheidungen der Nutzer und dem, was der gesamte Google-Stack erhält.

Wie UniConsent hilft

UniConsent CMP ist eine von Google zertifizierte Consent-Management-Plattform mit vollständiger Unterstützung für alle vier Consent-Mode-v2-Parameter. Sie leitet Nutzerentscheidungen automatisch an den Google Tag Manager weiter, wendet rechtsraumspezifische Standardwerte für EWR, UK, die Schweiz und US-Bundesstaaten an und hält Signale über Web, AMP und mobile Umgebungen hinweg konsistent. Zustimmungsraten, Signalintegrität und Compliance-Prüfprotokolle sind allesamt über ein einziges Dashboard zugänglich.

Die Frist vom 15. Juni rückt näher. Wenn Sie Ihre ad_storage-Konfiguration noch nicht geprüft und die Vollständigkeit Ihrer Consent-Mode-v2-Integration noch nicht bestätigt haben, ist jetzt der richtige Zeitpunkt dafür.

Über UniConsent

UniConsent CMP ist eine weltweit anerkannte und von Google zertifizierte Consent-Management-Plattform, die führende Publisher und täglich zig Millionen Nutzer bedient. UniConsent unterstützt Unternehmen dabei, die DSGVO, US-amerikanische Datenschutzgesetze der Bundesstaaten und die Richtlinienanforderungen von Google einzuhalten.

Kontaktieren Sie uns, um mehr zu erfahren: hello@uniconsent.com