Consent Mode v2 Deep-Dive: Wie Google aus Cookieless Pings Conversions modelliert

Seit März 2024 ist Consent Mode v2 keine Empfehlung mehr, sondern Voraussetzung. Google verlangt die Implementation für alle Werbetreibenden im EWR, die Google Ads Remarketing oder Conversion Tracking nutzen. Ohne Consent Mode v2 verlieren Sie den Zugang zu Modeled Conversions, Remarketing-Audiences und Enhanced Conversions.

Dieser Artikel erklärt nicht nur, was Consent Mode v2 ist (das steht in Googles Dokumentation), sondern wie es technisch funktioniert, welche Daten bei welchem Consent-State fließen, und welche Hebel Sie haben, um die Datenqualität zu maximieren.

Die vier Signale im Detail

Consent Mode v2 arbeitet mit vier Signalen. Jedes Signal steuert eine spezifische Dimension der Datenverarbeitung.

analytics_storage

Funktion: Steuert, ob GA4 Cookies setzen und Analysedaten erfassen darf.

Bei granted: GA4 setzt _ga (Client-ID, 400 Tage), _ga_{STREAM} (Session-ID, 30 Minuten) und weitere Cookies. Vollständige Datenerfassung: Seitenaufrufe, Events, Ecommerce, User Properties.

Bei denied: GA4 setzt keine Cookies. Stattdessen sendet GA4 Cookieless Pings: HTTP-Requests an google-analytics.com ohne Client-ID, ohne Session-ID, ohne User-Identifier. Der Ping enthält: Seitenaufruf-URL, Referrer, User-Agent, Bildschirmauflösung, Spracheinstellung, Consent-State. Google nutzt diese Pings für Behavioral Modeling (dazu später mehr).

Besonderheit: analytics_storage ist das einzige Signal, für das manche Unternehmen eine Sonderbehandlung argumentieren. Die Argumentation: Wenn Daten über First-Party SST laufen und personenbezogene Daten gefiltert werden, könnte analytics_storage: granted unter berechtigtes Interesse fallen. Die Datenschutzkonferenz (DSK) sieht das kritisch. Unser DSGVO-Tracking-Guide behandelt die Rechtsrisiko-Bewertung im Detail.

ad_storage

Funktion: Steuert, ob Google Ads und Floodlight Cookies setzen dürfen.

Bei granted: Google Ads setzt Conversion-Cookies (_gcl_aw, _gcl_dc), die Click-IDs mit Nutzer-Sessions verknüpfen. Floodlight setzt ähnliche Cookies für DV360-Kampagnen. Diese Cookies ermöglichen die direkte Zuordnung von Conversions zu Ad-Klicks.

Bei denied: Keine Cookies. Google Ads sendet Cookieless Pings mit dem gcs-Parameter (Google Consent State), der den Consent-Status codiert. Die Zuordnung von Conversions zu Klicks erfolgt über Modellierung statt über direkte Cookie-Matches.

Impact auf Kampagnen: Ohne ad_storage: granted fehlen direkte Click-to-Conversion-Pfade. Smart Bidding hat weniger Datenpunkte für die Optimierung. Google kompensiert über Behavioral Modeling, aber die Modellqualität hängt direkt von Ihrer Consent Rate ab.

ad_user_data

Funktion: Steuert, ob Nutzerdaten an Google für Werbezwecke gesendet werden dürfen.

Bei granted: Enhanced Conversions funktionieren: gehashte E-Mail-Adressen und Telefonnummern werden an Google gesendet, um Conversions auch ohne Cookies zuzuordnen. Customer Match Audiences können erstellt werden.

Bei denied: Keine Nutzerdaten an Google. Enhanced Conversions sind deaktiviert. Customer Match ist nicht möglich. Die Conversion-Attribution ist auf Cookie-basierte und modellierte Zuordnung beschränkt.

Wichtig: ad_user_data wurde mit Consent Mode v2 eingeführt. Es existierte in v1 nicht. Wenn Ihr Setup nur v1-Signale sendet (analytics_storage und ad_storage), fehlen ad_user_data und ad_personalization. Google behandelt fehlende Signale als denied.

ad_personalization

Funktion: Steuert, ob personalisierte Werbung (Remarketing) erlaubt ist.

Bei granted: Remarketing-Audiences werden befüllt. Der Nutzer kann in Remarketing-Kampagnen, Similar Audiences und Customer Match Audiences erscheinen.

Bei denied: Kein Remarketing. Der Nutzer wird keiner Audience zugeordnet. Bestehende Audience-Mitgliedschaften für diesen Nutzer werden nicht aktualisiert.

Praxis-Impact: Remarketing ist für viele Shops der profitabelste Kampagnentyp. Jeder Prozentpunkt Consent Rate, den Sie gewinnen, vergrößert Ihre Remarketing-Audiences direkt.

Der gcs-Parameter: Googles Consent-Encoding

Bei jedem Request an Google-Server wird der aktuelle Consent-State als gcs-Parameter mitgesendet. Der Wert ist ein codierter String, der die vier Signale komprimiert:

gcs=G111  → Alle granted
gcs=G100  → analytics_storage granted, Rest denied
gcs=G110  → analytics + ad_storage granted, Rest denied
gcs=G000  → Alle denied

Der gcs-Parameter ist relevant für Server-Side Tracking: Wenn Ihr SST-Container den Request an Google weiterleitet, muss der gcs-Parameter korrekt durchgereicht werden. Fehlt er, weiß Google nicht, welcher Consent-State gilt, und behandelt den Request als "unbekannt", was zu Datenverlusten führt.

gcs in der Praxis prüfen

Chrome DevTools > Network > Filter nach google-analytics.com oder googleads.g.doubleclick.net:

1. Vor Consent: gcs=G000 (alle denied)
2. Nach Consent (alle akzeptiert): gcs=G111
3. Nur Analytics akzeptiert: gcs=G100

Wenn der gcs-Wert nicht dem tatsächlichen Consent-State entspricht, stimmt etwas in Ihrer Consent-Implementierung nicht. Unser Consent-Debugging-Artikel beschreibt die systematische Prüfung.

Behavioral Modeling: Wie Google aus Pings Conversions macht

Behavioral Modeling ist der Mechanismus, mit dem Google Daten aus Cookieless Pings in nutzbare Metriken verwandelt. Google beschreibt den Prozess bewusst vage. Was öffentlich bekannt ist:

Input-Daten

Google nutzt für das Modeling:

1. Cookieless Pings von Nutzern, die nicht eingewilligt haben (enthält URL, Referrer, User-Agent, Zeitstempel, Consent-State)
2. Vollständige Daten von Nutzern, die eingewilligt haben (enthält alles: Client-ID, Session-Daten, Ecommerce-Events)
3. Aggregierte Patterns über alle Websites, die Consent Mode nutzen (globale Conversion-Raten pro Branche, Region, Device-Typ)

Modeling-Logik

Google beobachtet das Verhalten von Nutzern mit Consent und extrapoliert auf Nutzer ohne Consent. Vereinfacht:

Wenn 3 % der eingewilligten Nutzer, die von einer Google Ads Anzeige kommen und die Produktseite sehen, einen Kauf abschließen, modelliert Google eine ähnliche Rate für nicht eingewilligte Nutzer mit vergleichbarem Verhaltensmuster (gleiche Anzeige, gleicher Seitentyp, ähnlicher Zeitraum).

Conversion Recovery Rate

Die Conversion Recovery Rate beschreibt den Anteil der Conversions, die durch Modeling "wiederhergestellt" werden. Google gibt keine exakte Formel, aber aus der Praxis ergeben sich Erfahrungswerte:

Consent Rate	Conversion Recovery	Effektive Datenabdeckung
80 %+	60 bis 70 % der Denied-Conversions	~94 %
60 bis 80 %	50 bis 65 % der Denied-Conversions	~82 %
40 bis 60 %	35 bis 50 % der Denied-Conversions	~70 %
Unter 40 %	20 bis 35 % der Denied-Conversions	~55 %

Die Logik: Je mehr Nutzer einwilligen, desto mehr "echte" Daten hat Google als Basis für das Modeling. Mit einer Consent Rate von 80 % hat Google reichhaltige Daten, aus denen es zuverlässig extrapolieren kann. Bei 30 % Consent Rate wird die Modellierung unsicher.

Mindestvoraussetzungen

Behavioral Modeling in GA4 hat Mindestanforderungen:

• Consent Mode muss korrekt implementiert sein. Defaults vor dem ersten Tag, Updates nach Consent-Änderung.
• Mindestens 1.000 Events pro Tag mit analytics_storage: denied über mindestens 7 Tage.
• Mindestens 1.000 Nutzer pro Tag mit analytics_storage: granted über mindestens 7 Tage.

Wenn Ihr Shop diese Schwellen nicht erreicht, zeigt GA4 die originalen (unmodellierten) Daten. Für kleine Shops mit unter 500 täglichen Besuchern greift das Modeling nicht.

Default vs. Update: Timing ist alles

Consent Mode arbeitet mit zwei Befehlen:

consent default

gtag('consent', 'default', {
  'analytics_storage': 'denied',
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

Dieser Befehl muss vor dem GTM-Script und vor jeder anderen Google-Ressource stehen. Er definiert den Ausgangszustand. Wenn kein consent update folgt (z.B. weil der Nutzer den Banner ignoriert), bleiben diese Werte aktiv.

wait_for_update: Sagt Google-Tags, dass sie bis zu 500 Millisekunden auf ein Consent-Update warten sollen, bevor sie feuern. Das ist wichtig, wenn der Banner schnell geladen wird und der Nutzer sofort klickt. Ohne wait_for_update feuern Tags sofort mit den Default-Werten.

consent update

gtag('consent', 'update', {
  'analytics_storage': 'granted',
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

Dieser Befehl wird nach der Consent-Entscheidung gesendet. Bei Akzeptieren: alle relevanten Signale auf granted. Bei Ablehnen: alle auf denied (oder ein Update ist gar nicht nötig, weil die Defaults bereits denied sind).

Häufige Timing-Fehler

GTM vor Consent Defaults. Wenn das GTM-Script vor dem consent default-Befehl lädt, feuern Tags ohne Consent-Signal. Google behandelt das als "unknown" und setzt eigene Defaults (die je nach Tag-Typ variieren).

wait_for_update fehlt. Ohne wait_for_update feuern Tags sofort mit dem Default-State (denied). Wenn der Nutzer 300ms später einwilligt, hat der erste Pageview bereits ohne Consent gefeuert. Das ergibt Cookieless Pings, obwohl der Nutzer eingewilligt hat.

Consent Update nach Page Reload. Der Nutzer akzeptiert auf Seite A. Auf Seite B muss der gespeicherte Consent sofort als consent update gesetzt werden, bevor Tags feuern. Wenn der Banner den Consent erst nach dem Seitenaufbau aus dem Cookie liest und dann das Update sendet, feuern Tags für 200 bis 500 ms mit denied.

Implementation mit Shopify

Shopify Customer Privacy API als Consent-Quelle

Shopifys Customer Privacy API ist die sauberste Consent-Quelle für Shopify-Shops:

// 1. Privacy API laden
Shopify.loadFeatures([{ name: 'consent-tracking-api', version: 0.1 }], function() {

  // 2. Region prüfen
  const region = Shopify.customerPrivacy.getRegion();

  // 3. Consent Defaults setzen (vor GTM)
  const isEU = EU_REGIONS.includes(region);
  const defaultState = isEU ? 'denied' : 'granted';

  gtag('consent', 'default', {
    'analytics_storage': defaultState,
    'ad_storage': defaultState,
    'ad_user_data': defaultState,
    'ad_personalization': defaultState,
    'wait_for_update': isEU ? 500 : 0
  });

  // 4. Auf Consent-Entscheidung reagieren
  document.addEventListener('visitorConsentCollected', function() {
    const analytics = Shopify.customerPrivacy.analyticsProcessingAllowed();
    const marketing = Shopify.customerPrivacy.marketingAllowed();

    gtag('consent', 'update', {
      'analytics_storage': analytics ? 'granted' : 'denied',
      'ad_storage': marketing ? 'granted' : 'denied',
      'ad_user_data': marketing ? 'granted' : 'denied',
      'ad_personalization': marketing ? 'granted' : 'denied'
    });
  });
});

Consent Mode in GTM Server Container

Der GTM Server Container empfängt Requests vom Browser. Der gcs-Parameter wird automatisch im GA4-Request mitgesendet. Der GA4-Client im Server Container liest diesen Parameter und macht ihn für Server-Tags verfügbar.

Drei Punkte, die schiefgehen können:

1. Custom Server-Tags ignorieren den Consent-State. Wenn ein Tag im Server Container keinen Consent-Check hat, feuert er unabhängig vom gcs-Wert. Lösung: Consent-Einstellungen für jeden Server-Tag konfigurieren.

2. gcs-Parameter wird gefiltert. Manche Proxy-Konfigurationen oder WAFs filtern unbekannte URL-Parameter. Prüfen Sie, ob der gcs-Parameter im Server Container ankommt.

3. Timing-Mismatch. Der Browser sendet ein Event mit gcs=G000 (vor Consent). Zwei Sekunden später sendet er dasselbe Event mit gcs=G111 (nach Consent). Der Server Container sieht zwei Events. Das ist kein Deduplizierungsproblem (verschiedene Consent-States), aber es kann zu doppelten Pageviews führen.

Consent Rate optimieren

Die Qualität von Behavioral Modeling steht und fällt mit der Consent Rate. Jeder Prozentpunkt mehr Consent bedeutet bessere Modellierung und genauere Daten.

Legitime Optimierungen

Banner-Design. "Akzeptieren" und "Ablehnen" gleichwertig darstellen (DSGVO-Pflicht), aber der Banner selbst kann klar und schnell verständlich sein. Je weniger Text, desto schneller entscheidet der Nutzer.

Banner-Timing. Sofortiges Laden des Banners nach dem Seitenaufbau. Jede Verzögerung erhöht die Wahrscheinlichkeit, dass der Nutzer den Banner ignoriert oder die Seite verlässt.

Regionsbasierter Consent. Besucher aus Regionen ohne DSGVO-Pflicht brauchen keinen Banner. Details in unserem Artikel zu regionsbasiertem Consent Management.

Verbotene Optimierungen

Dark Patterns. "Ablehnen" verstecken, kleiner darstellen oder mehr Klicks erfordern. Das ist ein DSGVO-Verstoß und Aufsichtsbehörden ahnden es zunehmend.

Forced Consent. Content erst nach Akzeptieren anzeigen. Das ist keine freie Entscheidung und damit keine gültige Einwilligung.

Consent Wall. Den Zugang zur Website komplett sperren, bis der Nutzer einwilligt. Rechtlich umstritten, in vielen Jurisdiktionen unzulässig.

GA4 Reports: Modellierte vs. beobachtete Daten

GA4 kennzeichnet modellierte Daten in Reports mit einem Dreieck-Icon. In BigQuery-Exporten sind modellierte Daten nicht separat gekennzeichnet.

Wo Modeling sichtbar wird

• Realtime Report: Zeigt nur beobachtete (nicht modellierte) Daten
• Standard Reports: Enthalten modellierte Daten (wenn Modeling aktiviert und Schwellenwerte erreicht)
• Explorations: Können modellierte Daten enthalten
• BigQuery Export: Enthält alle Events, aber ohne Kennzeichnung ob modelliert oder beobachtet

Reporting-Strategie

Für Kampagnen-Reporting empfehlen wir: Google Ads als Conversion-Quelle nutzen (nicht GA4), weil Google Ads sein eigenes Modeling hat, das auf Kampagnendaten optimiert ist. GA4 für Website-Analytics und User-Journey-Analyse. Und die Shopify-Bestellungen als Ground Truth für die Validierung beider Quellen.

Fazit

Consent Mode v2 ist kein On/Off-Schalter. Es ist ein komplexes System aus vier Signalen, Timing-Anforderungen und einem Modeling-Mechanismus, dessen Qualität von Ihrer Consent Rate abhängt. Die korrekte Implementation erfordert Verständnis für Defaults, Updates, den gcs-Parameter und die Interaktion mit Server-Side Tracking.

Die gute Nachricht: Wenn Consent Mode v2 korrekt implementiert ist, verlieren Sie bei typischen Consent Rates von 60 bis 70 % nicht 30 bis 40 % Ihrer Daten, sondern nur 10 bis 15 %. Behavioral Modeling schließt die Lücke, wenn auch nicht vollständig.

Ist Ihr Consent Mode korrekt implementiert? Unser DSGVO & Compliance Audit prüft die Implementation im Detail: Defaults, Updates, Timing, gcs-Parameter, Server-Side-Weiterleitung.