Ein Scanner meldet „Kritisch: Google Analytics feuert vor dem Cookie-Consent." Du gibst das an deinen Kunden weiter — und bekommst zurück: „Das kann nicht sein, wir haben doch ein Cookie-Banner." Jetzt musst du den Befund erklären können. Ein roter Punkt im Dashboard ist keine Beweisführung. Was du brauchst, ist die exakte Anfrage, die gefeuert hat, der Zeitpunkt relativ zum Consent-Klick und der Beleg, dass es kein Fehlalarm war. Genau das ist der Zweck von Beweis-Snapshots.
Das Vertrauensproblem automatisierter Scanner
Jeder automatische DSGVO-Scanner hat dasselbe Glaubwürdigkeitsproblem: Er ist eine Blackbox, die ein Urteil ausspricht. „Verstoß" oder „kein Verstoß" — ohne dass nachvollziehbar wäre, worauf das Urteil beruht. Für eine Agentur, die diesen Befund an einen Kunden weitergibt, ist das ein doppeltes Risiko: Ein falsch-positiver Befund kostet Glaubwürdigkeit, sobald der Kunde widerspricht. Ein nicht belegbarer Befund ist im Ernstfall — Behördenanfrage, Abmahnung, Kunden-Audit — wertlos, weil er sich nicht reproduzieren lässt.
Die Konsequenz: Ein Scan-Ergebnis ist nur so viel wert wie die Evidenz, die es mitliefert. Genau genommen geht es bei solchen Pre-Consent-Anfragen oft um unzulässigen Zugriff auf das Endgerät nach § 25 TDDDG, dessen Einwilligungsanforderungen auf die DSGVO verweisen — der geläufige „DSGVO-Verstoß" ist die Kurzform dafür. Wie sich Tracking vor dem Consent überhaupt einschleicht, haben wir an anderer Stelle erklärt — hier geht es um die Frage danach: Wie beweist man, dass es passiert ist?
Eingefroren zum Zeitpunkt des Befunds — nicht nachträglich abgeleitet
Die Antwort beginnt mit einer Architektur-Entscheidung, die den entscheidenden Unterschied zu einem bloßen Scanner-Urteil ausmacht: Jeder netzwerkbasierte Befund trägt einen Beweis-Block, der in dem Moment eingefroren wird, in dem der Befund entsteht — nicht erst dann erzeugt, wenn jemand ihn aufruft. Der Grund liegt in der Lebensdauer der Daten. Ein To-Do bleibt dauerhaft bestehen, bis es gelöst ist. Ein Scan-Ergebnis dagegen wird beim nächsten wöchentlichen Re-Scan überschrieben.
Würde man die Evidenz erst beim Öffnen aus dem aktuellen Scan ableiten, wäre sie nach dem ersten Re-Scan verfälscht oder verschwunden — ausgerechnet bei dem Befund, der ein Problem belegt, das der Kunde inzwischen vielleicht behoben hat. Die Evidenz muss an genau den Scan gebunden bleiben, der den Befund ausgelöst hat. Deshalb der Snapshot: Er konserviert den Zustand, der das To-Do erzeugt hat, unabhängig davon, was spätere Scans zeigen.
Was ein Beweis-Snapshot festhält
Was hält dieser Block konkret fest? Er zeigt nicht abstrakt „ein Tool hat gefeuert", sondern dokumentiert pro Befund die konkreten Anfragen, die der Scan tatsächlich gesehen hat — gekappt auf die fünf aussagekräftigsten nach festen Kriterien: die erste Pre-Consent-Anfrage je Tool, die höchste Fingerprint-Sicherheit und eindeutige Hosts. So entsteht kein Cherry-Picking, sondern ein reproduzierbarer Ausschnitt. Jede einzelne Anfrage enthält:
- Die Phase: ob die Anfrage vor dem Consent (
pre), nach dem Consent (post), im Grenzbereich direkt nach dem Klick oder mit Consent-Mode-Signal erfolgte. - Den zeitlichen Abstand zum Consent-Klick in Millisekunden — ein negativer Wert bedeutet: Die Anfrage ging raus, bevor der Nutzer überhaupt zustimmen konnte. Das ist der eigentliche Kern des Beweises.
- Die gematchte Fingerprint-Regel — also welches bekannte Muster
(z. B.
google-analytics.com/g/collect) die Anfrage als bestimmtes Tool identifiziert hat. - Host, Ressourcentyp und die Seite, auf der die Anfrage ausgelöst wurde.
- Das decodierte Consent-Signal, falls vorhanden — dazu gleich mehr.
Dazu kommt der Kontext des gesamten Scans: die Gesamtzahl der Anfragen und die betroffenen Seiten. Aus „irgendwas stimmt nicht" wird so ein konkreter, nachvollziehbarer Befund: Diese Anfrage an diesen Host ging 3.210 Millisekunden vor dem Consent-Klick raus, auf dieser Seite, und entspricht dem Fingerprint von Google Analytics.
Nicht jeder Befund ist ein Verstoß: die Confidence-Labels
Der häufigste Grund, warum Agenturen automatischen Scannern misstrauen, sind Fehlalarme. Ein ehrliches Beweissystem muss deshalb zwischen Sicherheit und Unsicherheit unterscheiden — und darf nicht alles rot färben, was eine externe Anfrage auslöst. Jeder Beweis-Snapshot trägt daher ein Confidence-Label, das einordnet, wie belastbar der Befund ist:
- Bestätigter Verstoß (
confirmed_violation): Ein bekanntes Tracking-Tool feuerte nachweislich vor dem Consent. Klarer Fall. - Unbekannter Dienst (
unknown_service): Eine externe Anfrage, die zu keinem bekannten Fingerprint passt. Auffällig, aber kein automatisches Urteil — das gehört geprüft, nicht vorverurteilt. - Funktionaler CDN / AVV-Thema (
functional_cdn_avv): Ein funktional notwendiger Dienst wie ein CDN — kein Tracking-Verstoß, aber möglicherweise AVV-pflichtig. - Grenzfall (
boundary_review): Eine Anfrage im zeitlichen Graubereich rund um den Consent-Klick — wird zur menschlichen Prüfung markiert statt fälschlich als Verstoß gewertet. - Consent-Mode in Ordnung (
consent_mode_ok): Der wichtigste Fall gegen Fehlalarme — dazu der nächste Absatz.
Der Consent-Mode-Fall zeigt, warum diese Differenzierung Sorgfalt verlangt. Google Consent Mode
kodiert den Einwilligungsstatus direkt in den Anfrage-Parametern (etwa gcs und
gcd). Eine Anfrage, die vor dem Consent feuert, aber das Signal
analytics_storage: denied mitträgt, ist nicht automatisch ein
Pre-Consent-Tracking-Verstoß: In diesem Zustand werden laut Google keine Analytics-Cookies
gelesen oder geschrieben, sondern nur ein cookieloser Ping gesendet.
„Cookielos" heißt allerdings nicht „datenfrei". Solche Pings können weiterhin IP-Adresse,
User-Agent und Bildschirmauflösung übertragen, und selbst gesetzte Felder wie eine
user_id oder Custom Dimensions würden ebenfalls mitgesendet. Der Snapshot decodiert
das Consent-Signal deshalb und stuft den Befund nur dann als consent_mode_ok ein,
wenn keine identifizierenden Zusatzparameter oder eigenen IDs übermittelt werden — andernfalls
landet er als boundary_review in der menschlichen Prüfung statt als stiller
Freibrief. Genau diese Unterscheidung trennt einen brauchbaren Scanner von einem, der bei jedem
Google-Ping rot blinkt.
Datenschutz im Beweis selbst: redigierte URLs
Ein DSGVO-Werkzeug, das zur Beweisführung selbst sensible Daten hortet, wäre ein Widerspruch in sich. Anfrage-URLs können personenbezogene Parameter enthalten — Client-IDs, Suchbegriffe, Pfadinformationen. Deshalb wird im Snapshot nie die rohe URL gespeichert. Stattdessen:
- Es bleiben nur Parameter aus einer engen Allowlist erhalten — die
Consent-relevanten Signale wie
gcs,gcdundnpa. Alles Übrige inklusive Fragment wird entfernt. - Von der vollständigen URL wird höchstens eine gekürzte, nicht rückrechenbare HMAC-Referenz abgelegt — genug, um zwei Anfragen zu unterscheiden, ohne den Inhalt zu konservieren.
Das Ergebnis ist eine Evidenz, die genau das belegt, worauf es ankommt — welches Signal wann feuerte — ohne selbst zur Datenhalde zu werden. Datensparsamkeit gilt auch für den Beweis.
Was das für die Agentur-Kunden-Beziehung bedeutet
In der Praxis verschiebt das die Position der Agentur. Statt „unser Tool sagt, da ist ein Problem" kannst du dem Kunden zeigen: Diese konkrete Anfrage ging zu diesem Zeitpunkt vor der Einwilligung raus, hier ist die Seite, hier das Tool. Der Widerspruch „wir haben doch ein Banner" löst sich auf, weil der Beweis zeigt, dass das Banner das Tracking eben nicht blockiert hat.
Gleichzeitig schützt das System die Glaubwürdigkeit der Agentur in die andere Richtung: Weil Grenzfälle und Consent-Mode-konforme Pings nicht als Verstöße ausgewiesen werden, präsentierst du keinen Befund, der bei der ersten Nachfrage zusammenbricht. Beides zusammen — belastbarer Beweis bei echten Verstößen, ehrliche Zurückhaltung bei Grenzfällen — macht aus einem Scan-Ergebnis einen Befund, der vor dem Kunden und gegenüber einer Behörde auditierbar und deutlich belastbarer ist.
Fazit: Ein Befund ist nur so stark wie sein Beweis
Automatische Compliance-Scanner sind nur dann ein Werkzeug und keine Haftungsfalle, wenn ihre Befunde überprüfbar sind. Ein eingefrorener Beweis-Snapshot pro Befund leistet genau das: Er bindet die konkrete Netzwerk-Evidenz an den Scan, der sie ausgelöst hat, ordnet ihre Belastbarkeit über Confidence-Labels ehrlich ein und hält dabei selbst die Datensparsamkeit ein, die er anderswo einfordert.
Für Agenturen heißt das: weniger Fehlalarme, die Vertrauen kosten — und ein belastbarer Beleg in der Hand, wenn ein Kunde, eine Behörde oder im Streitfall ein Anwalt fragt: „Woher wissen Sie das?"