Tool
CMP- und GTM-Consent-QA-Vorlage
Eine QA-Vorlage, um Default-denied-Zustände, Consent-Updates und Tag-Feuern für ad_storage, analytics_storage, ad_user_data und ad_personalization in GTM zu testen.
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-Signal-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
Geben Sie Ihre Angaben ein, um die QA-Tabelle + Implementierungsnotizen zu erhalten. Soft-Gate — Download auf der nächsten Seite.
Formularfelder: Geschäftliche E-Mail · Unternehmen · Rolle · Aktueller Stack (GA4 / Google Ads / GTM / Server-side GTM / CMP / BigQuery / Sonstiges) · Consent-Checkbox.
Lieber den QA-Durchlauf gemeinsam? Datascale validiert CMP-, GTM- und Server-side-Consent-Verhalten als Teil eines Measurement & Consent Audit Sprints.
Ersetzt das die Audit-Checkliste?
Nein. Die Checkliste deckt das gesamte 7-Schichten-Setup ab; diese Vorlage ist der tiefe, wiederholbare QA-Durchlauf speziell für das CMP- und GTM-Signalverhalten.
Mit welchen CMPs funktioniert sie?
Mit jedem CMP, das sich in Consent Mode integriert. Die Testfälle sind CMP-agnostisch; die Notizen nennen gängige Muster für Usercentrics, Cookiebot und OneTrust.
Brauche ich Server-side GTM?
Nein, aber es gibt einen eigenen Paritäts-Abschnitt, falls Sie es nutzen, um den Abgleich von Client- und Server-Consent-Zustand zu bestätigen.
Ist das eine rechtliche Freigabe?
Nein. Es ist technischer QA-Nachweis. Rechts- und Datenschutzprüfung sollten mit qualifizierten Beratern erfolgen.
Mehr als 2 rote Checks?
Ein Audit Sprint liefert in zwei Wochen einen priorisierten Handlungsplan.
Audit Sprint anfragen →