gdpr-tracking-cookie-pre-consent
Tracking-Cookie vor Einwilligung gesetzt
Ein Tracking-Cookie wurde beim ersten Seitenaufruf in den Browser geschrieben, bevor eine Einwilligung erteilt war. Rechtlich derselbe Verstoß wie ein Tracker-Skript, und genauso einfach zu beheben.
Worum es geht
Der Scanner hat beim ersten Seitenaufruf mindestens einen Cookie
mit bekanntem Tracker-Muster im Browser gesehen, bevor ein
Consent-Banner hätte geklickt sein können. Häufige Cookie-Namen,
die den Befund auslösen, sind _ga, _gid, _gat und _ga_*
(Google Analytics), _fbp und fr (Facebook), _pin_unauth
(Pinterest), _hjSession* (Hotjar), mp_* (Mixpanel),
intercom-* (Intercom) sowie __hstc (HubSpot).
Solche Cookies werden entweder von einem vor der Einwilligung geladenen Drittanbieter-Skript gesetzt (siehe unseren Skript-vor-Einwilligung-Artikel), oder direkt von Ihrem serverseitigen Code, der den Consent-Fluss umgeht.
Warum das wichtig ist
Rechtlich gilt dieselbe Analyse wie bei Tracker-Skripten, mit einer Verschärfung. Ein Cookie ist unzweifelhaft “Speicherung auf dem Endgerät”. Daran gibt es keinerlei akademische Diskussion. TDDDG §25 regelt es. Art. 5(3) ePrivacy regelt es. Sämtliche Aufsichtsbehörden-Hinweise regeln es.
Was den Befund besonders häufig macht: Cookie-Banner werden meist nachträglich auf bestehende Seiten aufgesetzt. Die Cookies waren schon da, als der Banner live ging, und das Team, das den Banner konfiguriert, vergisst oft, die bestehenden Tracker für die Löschung beim Ablehnen zu registrieren. Besucher:innen sehen dann einen Banner, der nach Einwilligung fragt, während der Browser genau die Cookies, die der Banner schützen soll, längst gespeichert hat.
So beheben Sie das
Zwei Dinge müssen passieren.
-
Cookie-Erzeugung vor Einwilligung stoppen. Quelle des Cookies zurückverfolgen. Ist es
_ga, ist die Quelle das GA/GTM-Skript (siehe Skript-vor-Einwilligung-Artikel). Ist es ein First-Party-Cookie aus Ihrem eigenen Backend (session_id,analytics_id), strukturieren Sie den Code so um, dass das Cookie erst nach Einwilligung gesetzt wird. -
Bestandscookies bei Ablehnung löschen. Im “Ablehnen”-Handler Ihrer Consent-Plattform eine Anweisung ergänzen, die die Tracker-Cookies mit
Max-Age=0(oderExpiresin der Vergangenheit) überschreibt. Die meisten modernen Plattformen erledigen das automatisch, sobald die Cookies in ihrer Konfiguration registriert sind.
Prüfen in einem frischen Inkognito-Fenster. Entwicklertools
öffnen, auf den Tab “Anwendung” gehen, dann Cookies, dann Ihre
Domain. Vor dem “Akzeptieren” dürfen nur die Plattform-eigenen
Cookies (typisch: cookieyes-consent, borlabs-cookie,
CookieConsent) plus für die Seite zwingend erforderliche Cookies
(CSRF-Token, Session, Sprachauswahl) sichtbar sein. Alles, was
mit _ga, _fbp, _hjSession* oder _pin_* beginnt, ist ein
Befund.
Hinweis zu eigener serverseitiger Analytics
Selbst gehostete, IP-anonymisierende Analytics-Lösungen (Plausible, datenschutzfreundlich konfiguriertes Matomo, Umami) auf einer eigenen Subdomain brauchen typischerweise keine Einwilligung. Sie verwenden keine Cookies und übertragen keine personenbezogenen Daten an Dritte. Der blueredix-Scanner schließt solche Muster vom Befund explizit aus. Wenn Sie den Befund sehen, ist mindestens ein Cookie zu einem bekannten Drittanbieter-Tracker zugeordnet, nicht zu einer datenschutzfreundlichen Eigenlösung.