Tracking & Einwilligung

Tracker-Kennungen wurden bereits vor der Einwilligung gesetzt

Üblicher Schweregrad: hoch · Aufwand: mittel

Woran du es erkennst

Zwischen Seitenaufruf und der ersten Wahl im Consent-Banner wurden bekannte Tracking-Cookies oder Tracker-Schlüssel im Web-Storage neu geschrieben (z. B. _ga, _fbp, amplitude-/mixpanel-Kennungen) — bevor der Besucher irgendeine Entscheidung treffen konnte. Gemessen als Diff zweier Speicher-Schnappschüsse, keine Heuristik.

Warum es zählt

§ 25 TTDSG verlangt für das Speichern nicht-essentieller Kennungen im Endgerät eine Einwilligung — das Setzen zählt genauso wie das Senden von Beacons. Wer Tracker-IDs ablegt, bevor überhaupt eine Wahl möglich war, handelt belegbar ohne Rechtsgrundlage; das Banner nützt dann nichts, weil die Kennung längst existiert.

So behebst du es

  1. Blocke einwilligungspflichtige Tags vollständig, bis eine ausdrückliche Zustimmung vorliegt: Vor der Wahl dürfen sie weder Cookies setzen noch Storage-Schlüssel schreiben — initialisiere die SDKs erst nach dem Consent-Signal.
  2. Richte Google Consent Mode v2 mit Standard „denied" ein und binde GTM-Tags an Consent-Initialisierungs-Trigger statt an „Alle Seiten".
  3. Lade die CMP vor allen anderen Skripten, damit kein Tag die CMP überholt und seine Kennung schon beim Seitenaufruf ablegt.
  4. Teste im Inkognito-Fenster (DevTools → Application → Cookies und Local/Session Storage): Vor jeder Banner-Wahl dürfen keine Tracker-Kennungen existieren.

Zum Nachlesen