Ein wiederholbarer Testplan, um Ihr CMP- und GTM-Consent-Mode-Setup zu prüfen, Default-denied-Zustände, Consent-Updates, Tag-Feuern und alle vier Signale. Gebaut für Engineering- und Analytics-Teams, die beweisen wollen, dass die Consent-Kette funktioniert, statt es zu hoffen.
Die Änderung vom 15. Juni 2026 hat Consent Mode zur alleinigen Steuerung der Google-Ads-Datenerhebung aus GA4-verknüpften Setups gemacht. Das legt die Last auf die Signal-Schicht, und einer Signal-Schicht kann man nur trauen, wenn man sie in jedem Consent-Zustand testet. Diese Vorlage macht aus „läuft Consent Mode?“ eine Checkliste konkreter, wiederholbarer Testfälle.
Hintergrund-Lektüre: Was die Google-Consent-Mode-Änderung im Juni 2026 für GA4 und Google Ads bedeutet.
Für wen diese Vorlage ist
- Engineers, die GTM / Server-side GTM und die CMP-Verdrahtung implementieren oder pflegen.
- Analytics-Leads, die QA-Nachweise brauchen, bevor sie ein Setup freigeben.
- Agenturen und Partner, die Consent-QA über Kunden-Konten standardisieren.
- Datenschutz- und Rechtsverantwortliche, die Test-Nachweise zur Akte wollen (operativer Nachweis, keine Rechtsberatung).
Warum ein eigener QA-Durchlauf
„Consent Mode ist aktiviert“ ist eine Konfigurations-Aussage. QA ist eine Verhaltens-Aussage. Beide gehen ständig auseinander: Ein Banner erscheint, ein Template ist installiert, der technische Bericht sagt „v2 enabled“, und doch feuern Tags auf Standardeinstellungen, weil das CMP nie wirklich angebunden war oder der Default-Snippet nach der Tag-Library lädt. Ein strukturierter QA-Durchlauf findet die Lücke zwischen konfiguriert und funktionierend.
Was enthalten ist
Eine QA-Tabelle plus Implementierungsnotizen, die die Testmatrix abdecken:
- Zu testende Zustände: initialer (Vor-Entscheidung-)Default, Accept-all, Reject-all sowie granulare/teilweise Entscheidungen.
- Erwartungen je Zustand für jedes der vier Signale,
ad_storage,analytics_storage,ad_user_data,ad_personalization. - Tag-Feuer-Verhalten: welche Tags in jedem Zustand feuern oder blockiert sein sollten.
- Netzwerk-Nachweis: worauf zu achten ist, inklusive des
gcd-Parameters für Default × Update. - Server-seitige Checks: Consent-Zustands-Parität zwischen Client und sGTM.
- Pass/Fail-Log: mit Spalten für Belege (Screenshot/HAR) und Owner.
Die Implementierungsnotizen erklären, wie jedes Ergebnis zu lesen ist und welche Ursachen am häufigsten vorliegen, wenn ein Test fehlschlägt.
Vorschau: Beispiel-Testfälle
| # | Szenario | Erwartetes Ergebnis | Wie verifizieren |
|---|---|---|---|
| 1 | Seitenaufruf, noch keine Entscheidung | Alle vier Signale denied per Default; keine Ad-Cookies | Netzwerk-Panel; gcd zeigt default-denied |
| 2 | Nutzer klickt „Alle akzeptieren“ | Signale springen auf granted; ein Update feuert | Signale vorher/nachher vergleichen; Tag feuert |
| 3 | Nutzer klickt „Alle ablehnen“ | Signale bleiben denied; Ad-Tags blockiert | Keine Ad-Cookies; Tag blockiert |
| 4 | Granular: Analytics ja, Ads nein | analytics_storage granted, Ad-Signale denied | Per-Tracking-Check |
| 5 | Server-seitige Parität | sGTM-Consent-Zustand entspricht Client | sGTM-Container / ausgehende Requests prüfen |
Diese Fälle sind in der Vorlage enthalten; Sie führen sie gegen Ihre eigene Property aus und protokollieren die Belege.
So nutzen Sie sie
- Kopieren Sie die Tabelle und weisen Sie einen Tester/Owner zu.
- Führen Sie jedes Szenario in einer sauberen Session aus (und inkognito für Cookie-Checks).
- Erfassen Sie Belege (Screenshot oder HAR) je Zeile und markieren Sie pass/fail.
- Nutzen Sie bei Fehlern die Implementierungsnotizen, um die Ursache zu finden.
- Testen Sie nach den Fixes erneut; bewahren Sie die ausgefüllte Tabelle als QA-Nachweis auf.
QA-Vorlage holen
Arbeits-E-Mail eintragen, QA-Tabelle und Implementierungsnotizen kommen per Mail. Soft-Gate, keine Wand, der Text oben bleibt vollständig lesbar.
Lieber den QA-Durchlauf gemeinsam? Datascale validiert CMP-, GTM- und Server-side-Consent-Verhalten als Teil eines Measurement & Consent Audit Sprints.