Der blinde Fleck der Cookie-Scanner: Wie man proxied & self-hosted Tracking erkennt — und ehrlich misst

Die meisten DSGVO-Scanner erkennen ein Tracking-Tool an seiner Domain: Feuert eine Anfrage an google-analytics.com oder connect.facebook.net, ist der Fall klar. Aber was, wenn ein Tool gar nicht mehr unter seiner eigenen Domain auftaucht — weil es über die Domain des Kunden geroutet (proxied) oder komplett selbst gehostet wird? Dann sieht ein host-basierter Scanner: nichts. Genau dieser blinde Fleck ist der Grund, warum wir Tracking nicht nur an der Domain erkennen, sondern an seinem Verhalten im Browser. Dieser Artikel zeigt, wie das funktioniert — und, ehrlicher als die meisten Methodik-Texte, wie wir es gemessen haben, ohne uns selbst zu täuschen.

Wie klassische Scanner sehen — und was ihnen entgeht

Der Standard-Ansatz heißt Host-Fingerprinting: Der Scanner führt eine Liste bekannter Tracker-Domains und Pfade und gleicht jede Netzwerk-Anfrage der Website dagegen ab. Das funktioniert für den Großteil der Fälle hervorragend — Google Analytics, Meta Pixel, Hotjar und Co. laden alle von ihren eigenen, gut bekannten Domains. Für diese Tools ist die Domain der Fingerabdruck.

Die Lücke entsteht, sobald ein Tool diese Domain verlässt. Dafür gibt es vier verbreitete Wege:

• Reverse-Proxy: Das Tool wird über einen Pfad der eigenen Domain geroutet — aus eu.posthog.com wird dann deine-domain.de/ingest. PostHog und Plausible dokumentieren das ausdrücklich.
• Self-Hosting: Das Tool läuft auf einer eigenen (Sub-)Domain, oft stats.kundendomain.de oder matomo.agentur.de. Matomo wird praktisch immer selbst gehostet.
• Server-side Tagging (sGTM): Der Google Tag Manager läuft als eigener Server-Container auf einer Kunden-Subdomain — Container, gtag.js und sogar der GA4-Beacon /g/collect kommen dann von metrics.agentur.de statt von Google. Im Agentur-Segment der mit Abstand häufigste First-Party-Weg.
• CNAME-Cloaking: Eine Subdomain des Kunden zeigt per DNS auf den Anbieter — für den Browser sieht alles first-party aus.

Der Treiber dahinter ist meist gar nicht der Datenschutz, sondern das Wettrüsten mit Ad-Blockern: Wer über die eigene Domain ausliefert, wird seltener blockiert. Der Nebeneffekt ist jedoch, dass das Tool auch für host-basierte Scanner unsichtbar wird. Ein Tool auf stats.kundendomain.de oder ein Ingestion-Aufruf an /api/event auf der eigenen Domain matcht keine bekannte Tracker-Domain — und taucht im Bericht eines reinen Fingerprint-Scanners schlicht nicht auf. Datenschutzrechtlich ändert sich dadurch nichts: Ein selbst gehostetes Analyse-Tool, das vor der Einwilligung Cookies setzt, ist genauso einwilligungspflichtig wie eines vom Anbieter-Server.

Self-hosted ist kein Randfall — zumindest nicht bei Agenturen

Im allgemeinen Web ist das ein Nischenphänomen. In unserem Segment — Web-, Marketing- und Dev-Agenturen — nicht: Genau diese Zielgruppe richtet überdurchschnittlich oft datenschutzfreundliche, selbst gehostete Analytics für ihre Kunden ein. In einem Korpus von über 1.000 gescannten, agenturnahen Websites verteilten sich die selbst hostbaren Analyse-Tools so:

Wichtig für die Einordnung: Der Großteil dieser Matomo-Installationen lädt sein Skript noch über einen erkennbaren Pfad und ist damit auch klassisch auffindbar. Die wirklich unsichtbare Teilmenge — umbenanntes Skript, geproxieter Endpunkt, kein verräterischer Domainname — ist klein. Aber genau sie ist der Fall, an dem oberflächliche Scanner scheitern. Und es ist der Fall, der einer Agentur ein falsches „alles grün" liefert, obwohl im Hintergrund ein einwilligungspflichtiges Tool läuft.

Der größte blinde Fleck ist nicht exotisch: Server-side Google Tag Manager

Die unbequemste Erkenntnis unserer eigenen Analyse: Der häufigste First-Party-Fall ist gar nicht das geproxiete Nischen-Tool, sondern der ganz normale Google-Stack über Server-side Tagging. Beim sGTM-Setup liefert eine Kunden-Subdomain den Tag-Container, die GA4-Bibliothek und den Mess-Beacon aus — kein einziger Request berührt eine Google-Domain. Als wir unsere gespeicherten Scan-Timelines gezielt danach durchsucht haben, fanden sich in gut 1.000 Websites 29 Setups mit first-party ausgeliefertem GTM/GA4 — 17 davon für eine reine Host-Erkennung komplett unsichtbar. Google fehlte dort in jeder Tool-Liste, und damit auch im Verarbeitungsverzeichnis, im AVV-Tracker und in der Datenschutzerklärung. Zum Vergleich: Die geproxieten PostHog-/Plausible-Installationen, für die wir die Erkennung ursprünglich gebaut hatten, waren eine Handvoll.

Ehrlich dazu: Unsere eigene erste Messung konnte diese Lücke strukturell nicht sehen, weil sie zählte, welche erkannten Tools auf welchen Sites laufen — was die Erkennung verfehlt, taucht in so einer Zählung naturgemäß nicht auf. Erst die Suche in den rohen Netzwerk-Timelines (statt in den Erkennungsergebnissen) hat den blinden Fleck sichtbar gemacht. Auch das gehört zur Methodik-Ehrlichkeit: Die gefährlichste Lücke ist die, die die eigene Statistik nicht anzeigen kann.

Eine wichtige Fairness-Regel beim Erkennen von sGTM: Ein first-party /g/collect, der per Google Consent Mode signalisiert, dass nichts gewährt wurde, ist das korrekt konfigurierte Setup — ein Consent-Signal, kein Tracking-Beacon. Den werten wir bewusst nicht als Datenübertragung. Wer sGTM mit sauberem Consent Mode betreibt, wird nicht fürs Richtigmachen markiert. Und der Tag-Container selbst ist Infrastruktur, kein Tracker — er erzeugt bei uns einen Inventar-Hinweis („prüfen, welche Tags darüber laufen"), nie automatisch einen Verstoß.

Erkennung am Verhalten, nicht an der Domain

Wenn die Domain nichts mehr verrät, muss die Erkennung tiefer ansetzen: bei den Spuren, die ein Tool im Browser hinterlässt, sobald sein Skript läuft. Diese Spuren kann ein Proxy nicht verstecken, denn das Tool muss im window-Objekt arbeiten, Speicher schreiben und seine Daten irgendwohin senden. Wir werten dafür drei Klassen von DOM-Signalen aus:

• JavaScript-Globals — die charakteristischen Objekte, die ein Tool im Browser anlegt (etwa window.matomo / _paq oder window.plausible). Sie überstehen jeden Reverse-Proxy.
• Tool-spezifische Speicher-Schlüssel — Cookie- und localStorage-Einträge mit eindeutigen Präfixen, die ein Tool zuverlässig identifizieren.
• Der kanonische Ingestion-Endpunkt — der typische Sammel-Pfad, an den das Tool seine Messdaten schickt, auch wenn er auf der eigenen Domain liegt.

Entscheidend ist die Konservativität dieser Auswertung. Ein einzelnes schwaches Signal — etwa nur ein generischer Pfad — reicht nie für ein Urteil; ein solcher Befund landet höchstens als „manuelle Prüfung empfohlen" (Info), nie als automatischer Verstoß. Erst wenn mindestens zwei unabhängige Signalklassen zusammenkommen, sprechen wir von einem wahrscheinlichen Tool. So vermeiden wir Fehlalarme, die das Vertrauen in jeden Scanner zersetzen. (Die genauen Signaturen und Gewichte behalten wir bewusst für uns — das Prinzip ist hier wichtiger als das Rezept.)

Zwei Rechtsgründe, die man nicht verwechseln darf: § 25 TDDDG und Art. 6 DSGVO

An dieser Stelle wird es juristisch — und hier über-claimen viele Tools. Ein selbst gehostetes Analyse-Tool berührt potenziell zwei verschiedene Tatbestände, die man sauber trennen muss:

• § 25 TDDDG regelt den Zugriff auf das Endgerät — also das Setzen oder Lesen von Cookies und localStorage. Einwilligungspflichtig ist dabei jeder Zugriff, der nicht unbedingt erforderlich ist; Analyse- und Tracking-Cookies gelten nach der Rechtsprechung (u. a. BGH, Urteil v. 28.05.2020 – I ZR 7/16, „Cookie-Einwilligung II") nie als unbedingt erforderlich. Wird vor der Einwilligung ein solches Cookie gesetzt, ist das der klassische, einwilligungspflichtige Endgeräte-Zugriff.
• Art. 6 DSGVO betrifft die Datenübertragung selbst — die Anfrage, die (mit der IP-Adresse) an den Sammel-Endpunkt rausgeht.

Der Unterschied ist praktisch relevant: Ein Tool, das cookielos konfiguriert ist und vor der Einwilligung keinen Endgeräte-Speicher anfasst, ist nach § 25 erst einmal unauffällig — das Endgerät wurde nicht berührt. Die Frage der Datenübertragung (Art. 6) bleibt davon unberührt und ist separat zu bewerten. Deshalb trennen wir auch die Evidenz im Bericht: Der Endgeräte-Speicher-Block (gesetzte Cookies, § 25) steht getrennt von den beobachteten Netzwerk-Anfragen (Datenübertragung, Art. 6). Und wir rufen nicht „Verstoß", nur weil ein cookieloses Tool vorhanden ist. Diese Zurückhaltung ist kein Zeichen von Schwäche — sie ist der Unterschied zwischen einem belastbaren Befund und einem, der beim ersten Widerspruch des Kunden zusammenbricht. Wie wir Befunde generell mit eingefrorenen Beweis-Snapshots nachvollziehbar machen, haben wir an anderer Stelle beschrieben.

Ebene 2: die Konfiguration direkt auslesen

Die verhaltensbasierte Erkennung (Vergleich des Zustands vor und nach dem Consent-Klick) hat eine Schwäche: Sie hängt davon ab, dass der Einwilligungs-Klick zuverlässig durchgeht — und Cookie-Banner sind technisch launisch. Deshalb gehen wir einen Schritt weiter und lesen, wo möglich, die Konfiguration des Tools direkt aus. Meldet ein Matomo-Tracker etwa selbst, dass er mit disableCookies oder requireConsent läuft, ist das ein klick-unabhängiger Beleg für eine cookielose / einwilligungsgesteuerte Konfiguration — robuster, als es aus einem (möglicherweise fehlgeschlagenen) Klick abzuleiten.

Eine wichtige Reihenfolge dabei: Die Beobachtung schlägt die Selbstauskunft. Sehen wir vor der Einwilligung tatsächlich ein Cookie, dann gilt der Verstoß — auch wenn die Konfiguration „cookielos" behauptet. Eine deklarierte Einstellung kann irren oder geschönt sein; ein gemessenes Cookie ist eine Tatsache.

Und weil auch dieser Mechanismus eine Behauptung ist, die man prüfen muss: Wir haben die Config-Auslese gegen ein echtes, unverändertes posthog-js in einem realen Browser validiert — in beide Richtungen. Eine Installation mit persistence: 'memory' wird korrekt als cookielos erkannt (und schreibt nachweislich keinen Endgeräte-Speicher), während die Gegenprobe mit Standard-Einstellungen eben nicht als cookielos gemeldet wird — dort erscheinen sofort die ph_-Schlüssel, die die verhaltensbasierte Ebene fängt. Ein Auslese-Mechanismus, der immer „cookielos" sagt, wäre wertlos; einer, der nachweislich unterscheidet, ist ein Beleg.

Der ehrliche Teil: wie misst man so etwas, ohne sich zu täuschen?

Eine Erkennung zu bauen ist das eine. Zu beweisen, dass sie funktioniert, das andere — und hier lauert eine Falle, in die erstaunlich viele Methodik-Berichte tappen: die Zirkularität. Wer seinen Test-Korpus aus „Websites, auf denen unsere Erkennung angeschlagen hat" zusammenstellt, misst eine Trefferquote von 100 % — per Konstruktion, und damit völlig wertlos.

Wir haben deshalb mit einem unabhängigen Orakel gemessen: einer Regel, die die Anwesenheit eines Tools nach einem anderen Kriterium beurteilt als unser eigentlicher Detektor. Konkret: der Treffer eines tool-typischen Sammel-Endpunkts auf einer fremden, nicht zum Anbieter gehörenden Domain. Detektor und Orakel widersprechen sich also bewusst — und überall dort, wo das Orakel „Tool vorhanden" sagt und der Detektor „nichts gefunden", liegt ein echter, ungeschönter Fehlschuss.

Dass diese Disziplin nötig ist, hat sich sofort gezeigt. Unser erster Lauf meldete fünf vermeintliche Fehlschüsse. Bei der Prüfung stellte sich heraus: Vier davon waren gar keine — es handelte sich um ein anderes Produkt (eine Web-Analytics aus einem fremden Anbieter-Haus), das denselben /api/event-Pfad nachbaut. Unser Orakel hatte diese fremde Cloud fälschlich als „selbst gehostetes Plausible" gezählt. Hätten wir der Rohzahl vertraut, hätten wir eine schlechtere Trefferquote berichtet, als wir tatsächlich haben — der Detektor lag bei diesen vier Fällen völlig richtig. Wir haben das Orakel korrigiert (die fremde Anbieter-Domain ausgeschlossen). Der eine verbleibende, echte Fehlschuss — ein umbenanntes Skript mit geproxietem Endpunkt und ohne erkennbares Global — war eine reale Lücke, die wir geschlossen haben: Ein kanonischer Ingestion-Endpunkt auf der eigenen Domain zählt seither als starkes Einzelsignal.

Die belastbaren Zahlen, ohne Schönfärberei: Auf 173 realen Websites mit selbst hostbarer Analytics lag die Gesamterkennung bei rund 98–100 %. Auf dem kuratierten Prüfsatz der fingerprint-unsichtbaren Installs erkennt ein reiner Host-Fingerprinter naturgemäß 0 % — die DOM-Signal-Erkennung holt sie zurück. Die wichtigste Erkenntnis steckt aber nicht in der Zahl, sondern im Weg dorthin: Eine Zahl, die man nicht ernsthaft zu widerlegen versucht hat, ist keine Messung. Wir hätten beinahe eine falsche berichtet — und genau die Disziplin, das zu verhindern, ist es, die die richtige vertrauenswürdig macht.

Was wir bewusst nicht behaupten

• Es ist die Ausnahme, nicht die Regel. Fingerprint-umgehendes First-Party-Tracking betraf in unserem Agentur-Korpus rund 2 % der Websites — davon der Großteil Server-side GTM, der Rest geproxiete bzw. unauffindbar selbst gehostete Analytics. Der Großteil der Verstöße wird weiterhin auf dem klassischen Weg gefunden — diese Erkennung ist die Tiefenschicht, nicht der Hauptweg.
• Die Stichprobe ist klein. Die proxied-spezifische Trefferquote beruht auf einer überschaubaren Zahl unabhängig verifizierter Fälle — wir verkaufen sie nicht als Millionen-Studie.
• Es ist kein Zaubertrick. Der Vorsprung ist Sorgfalt und Genauigkeit, kein struktureller Graben — andere könnten nachziehen. Der Anspruch ist, genauer zu bleiben.
• Cookielos ist kein Verstoß. Ein selbst gehostetes, cookielos konfiguriertes Tool markieren wir nicht automatisch als § 25-Verstoß. Alles andere wäre genau das Over-Claiming, das wir anderen vorwerfen.

Was das für Agenturen bedeutet

Der praktische Wert liegt nicht in der Menge, sondern im Vertrauen. Es sind die wenigen Mandanten, bei denen der Scanner eines Wettbewerbers „sauber" meldet, während im Hintergrund leise ein selbst gehostetes Tool läuft — das ist die trügerische Sicherheit, die ein gründlicher Scan ausräumt. Und weil der Anteil geproxieter Auslieferung mit dem Ad-Blocker-Wettrüsten und dem Trend zu privacy-first Analytics wächst, ist diese Tiefenschicht zugleich Zukunftssicherung.

Wie sich Tracking überhaupt vor dem Cookie-Consent einschleicht, und wie jeder Befund mit Beweis-Snapshots nachvollziehbar wird, vertiefen wir in den verlinkten Artikeln. Der Kern dieses hier ist einfach: Das Ziel ist nicht, mehr Verstöße zu finden — sondern dem grünen Häkchen vertrauen zu können.