Cookies werden nach Reject weiterhin gesetzt

Warum das wichtig ist

Ein Reject-Button, der optionale Verarbeitung nicht wirklich blockiert, ist eines der klarsten Zeichen dafür, dass der Consent-Mechanismus nicht korrekt durchgesetzt wird.

So prüfen Sie das manuell

1. Lehnen Sie optionale Verarbeitung in einer sauberen Sitzung ab und laden Sie die Seite neu.
2. Prüfen Sie Cookies und Network-Requests nach Reject.
3. Vergleichen Sie das Verhalten vor und nach Reject, um zu bestätigen, ob optionale Speicherung wirklich stoppt.

Typische Ursachen

• Reject aktualisiert nur den Banner-Zustand, überträgt aber keinen denied-Consent-Status.
• Optionale Tags feuern nach dem Reload trotz abgelehnter Wahl erneut.
• Gespeicherte Consent-Werte werden nach Navigation falsch gelesen oder ignoriert.

Behebung in GTM

1. Stellen Sie sicher, dass denied-Consent gelesen wird, bevor Tags nach Reload laufen können.
2. Hängen Sie Consent-Checks an alle optionalen Tags, nicht nur an Events beim ersten Laden.
3. Prüfen Sie im GTM-Preview, dass Reject den denied-Zustand über Reloads hinweg beibehält.

Behebung in WordPress oder CMP-Plugins

1. Prüfen Sie Plugin-Integrationen, die optionale Tags nach Reject weiter laden.
2. Verifizieren Sie, dass das CMP-Plugin denied-Zustand über Seitenaufrufe hinweg speichert und durchsetzt.
3. Entfernen Sie überlappende Tracking-Plugins, die den CMP-Status ignorieren.

Allgemeine Entwicklerkorrektur

1. Behandeln Sie Reject als durchsetzbaren Laufzeitstatus und nicht nur als UI-Aktion.
2. Blockieren Sie optionale Loader auf jeder Seite, wenn der gespeicherte Consent denied ist.
3. Testen Sie Reload-, Revisit- und Cross-Page-Flows statt nur das Verhalten beim ersten Laden.

So bestätigen Sie, dass die Behebung funktioniert

• Reject und Reload: Bestätigen Sie, dass optionale Cookies weiter fehlen.
• Reject und Reload: Bestätigen Sie, dass optionale Requests blockiert bleiben.
• Starten Sie einen neuen Scan und prüfen Sie, dass Reject-Flow-Funde verschwinden.