Das Problem: eindeutige Besucher zählen, ohne sie zu verfolgen
Eindeutige Besucher zu zählen ist eines der ältesten Probleme in der Webanalyse. Sie wollen wissen, wie viele verschiedene Personen gestern auf Ihre Seite gekommen sind, wie viele heute zurückgekehrt sind und wie viele zum ersten Mal über eine bestimmte Kampagne kamen. Das sind vernünftige Fragen für jeden, der eine Website betreibt. Um sie zu beantworten, braucht man eine Möglichkeit zu sagen: "Diese beiden Seitenaufrufe kamen von derselben Person, und diese beiden nicht."
Jahrzehntelang lautete die Standardantwort, jedem Besucher einen dauerhaften Identifier zu geben — meist in einem Cookie gespeichert — und diesen Identifier bei jeder Anfrage nachzuschlagen. Ein neuer Besucher bekommt eine neue ID. Ein wiederkehrender Besucher verwendet seine erneut. Eindeutige zu zählen ist dann nur noch eine Frage des Zählens verschiedener IDs.
Dieser Ansatz funktioniert wunderbar für den Ingenieur und furchtbar für den Besucher. Ein dauerhafter Identifier, auf dem Gerät gespeichert, an jede Anfrage gebunden, ist genau die Art von Sache, zu deren Kontrolle die ePrivacy-Richtlinie geschrieben wurde. In der EU erfordert er eine Einwilligung, und er schafft auch dann ein echtes Datenschutzproblem, wenn nicht: Jede Partei mit Zugriff auf diesen Identifier kann daraus ein Verhaltensprofil erstellen.
Moderne cookiefreie Analytics löst dasselbe Zählproblem, ohne etwas auf dem Gerät zu speichern. Der Mechanismus ist die hash-basierte Besucheridentifikation, und er funktioniert, indem ein kurzlebiger serverseitiger Identifier aus Daten berechnet wird, die der Server bereits hat.
Warum Cookies und localStorage es lösten (und rechtliche Probleme schufen)
Der Reiz von Cookies und localStorage für Analytics war offensichtlich: Sie geben Ihnen einen stabilen Identifier, der Anfragen, Tabs und oft Sitzungen überdauert, ohne jeden serverseitigen Zustand. Der Browser erledigt die gesamte Arbeit. Sie setzen beim ersten Besuch ein Cookie, Sie lesen es bei jeder nachfolgenden Anfrage, Sie müssen nie wieder über Identität nachdenken.
Das Problem ist, dass dieser Mechanismus rechtlich reguliert ist. Artikel 5 Absatz 3 der ePrivacy-Richtlinie behandelt die "Speicherung von Informationen" und den "Zugriff auf bereits gespeicherte Informationen" auf dem Gerät des Nutzers als Auslöser für die Einwilligung. Cookies sind das kanonische Beispiel. Ebenso localStorage. Ebenso sessionStorage. Ebenso IndexedDB. Ebenso jede Art von Geräte-Fingerprinting, die stabile Eigenschaften der Hardware oder Software liest.
Das bedeutet, dass jedes Analytics-Tool, das zur Zählung eindeutiger Besucher auf Gerätespeicherung angewiesen ist, entweder ein Einwilligungsbanner benötigt oder sich für eine der engen Ausnahmen qualifizieren muss — was für Analytics typischerweise eine streng erstparteiliche Nutzung, kein seitenübergreifendes Tracking, begrenzte Aufbewahrung und eine bereitwillige Aufsichtsbehörde erfordert. Der Compliance-Spielraum ist schmal, und die Folgen von Fehlern waren schwerwiegend. Französische, deutsche und österreichische Datenschutzbehörden haben allesamt Anordnungen gegen Websites erlassen, die Google Analytics in seiner Standardkonfiguration betreiben.
Der hash-basierte Ansatz umgeht dies vollständig, indem er den Identifier vom Gerät wegverlagert.
Die hash-basierte Alternative
Die Grundidee ist einfach: Anstatt einen Identifier auf dem Gerät zu speichern und ihn bei jeder Anfrage an den Server zurückzusenden, berechnet der Server bei jeder Anfrage einen Identifier von Grund auf neu, unter Verwendung von Attributen, die das HTTP-Protokoll bereits trägt. Der Browser ist nie beteiligt. Nichts wird gespeichert. Nichts wird gelesen.
Damit dies als Besucherzähler funktioniert, muss der berechnete Identifier:
- Stabil über den zu zählenden Zeitraum sein (typischerweise ein Tag)
- Unvorhersehbar für jeden ohne Zugriff auf das serverseitige Geheimnis sein
- Nicht verknüpfbar über Zeiträume oder Websites hinweg sein, damit er nicht zum Aufbau eines langfristigen Profils verwendet werden kann
- Irreversibel sein, sodass der Server (und Angreifer) die ursprünglichen Eingaben aus dem gespeicherten Hash nicht wiederherstellen können
Eine kryptografische Hash-Funktion liefert Ihnen all diese Eigenschaften, wenn Sie sie mit den richtigen Eingaben füttern und die richtigen Komponenten rotieren.
Wie es funktioniert
Hier die allgemeine Form des Algorithmus, den Web-Tracking.eu und ähnliche cookiefreie Analyse-Tools verwenden. Die genauen Details unterscheiden sich zwischen den Anbietern, aber die Bausteine sind dieselben.
function visitorId(request, siteId) {
const ip = request.remoteAddr;
const ua = request.headers['user-agent'];
const date = today('UTC'); // YYYY-MM-DD
const salt = dailySalt(); // random bytes, rotated every day
const input = ip + '|' + ua + '|' + siteId + '|' + date + '|' + salt;
const hash = sha256(input);
// raw inputs are discarded here, only the hash leaves this function
return hash;
}
Das ist der gesamte Mechanismus. Bei jeder eingehenden Anfrage an unseren Tracker-Endpunkt tut der Server Folgendes:
- Nimmt die IP-Adresse und den User-Agent-Header aus der Anfrage
- Hängt das aktuelle UTC-Datum, die Site-ID und das tägliche geheime Salt an
- Lässt das Ganze durch SHA-256 laufen
- Verwendet den resultierenden Hash als Besucher-ID für diese Anfrage
- Verwirft die ursprüngliche IP, den User-Agent und das Salt — nur der Hash wird gespeichert
Der Browser sieht diesen Hash nie. Er wird nicht in ein Cookie geschrieben, nicht in einem Set-Cookie-Header zurückgegeben, nicht in localStorage gespeichert, nicht in irgendeiner Antwort zurückgegeben. Er lebt vollständig in unserer Datenbank als kurze Hex-Zeichenkette, die "den Besucher, der an diesem Tag diese Anfragen gesendet hat" identifiziert.
Warum die tägliche Rotation wichtig ist
Die Datumskomponente der Eingabe ist das wichtigste Stück Datenschutz-Engineering in diesem Schema. Ohne sie würde jede Anfrage vom selben (IP, User-Agent, Site)-Tripel für immer denselben Hash erzeugen. Der Hash wäre effektiv ein dauerhafter, globaler Identifier — genau das, was wir zu vermeiden versuchen.
Mit der täglichen Rotation ändert sich der Hash für einen bestimmten Besucher jeden Tag um Mitternacht UTC. Ein Besucher, der morgen zurückkommt, erzeugt einen völlig anderen Hash, der von einem brandneuen Besucher nicht zu unterscheiden ist. Wir können ihre Montagsbesuche nicht mit ihren Dienstagsbesuchen verknüpfen, da wir keinen Mechanismus haben, um die beiden Hashes zu überbrücken.
Das opfert etwas analytische Leistung. Wir können keine 7-Tage-Zählung eindeutiger Besucher berechnen, indem wir verschiedene Hashes zählen; wir müssen sie aus Tageszählungen und einer Annahme über die Wiederkehrrate schätzen oder tägliche Eindeutige präsentieren und den Betreiber diese interpretieren lassen. Der Kompromiss ist bewusst: Wir dürfen das Publikum messen, ohne eine Tracking-Infrastruktur aufzubauen.
Einige Anbieter rotieren nach einem anderen Zeitplan (wöchentlich, monatlich). Unsere Ansicht ist, dass täglich der richtige Standard ist. Wöchentliche und monatliche Rotation liefern etwas bessere Analysen, aber schwächere Datenschutzgarantien, und jede Datenschutzbehörde, die einen cookiefreien Ansatz in Frage stellt, wird eher ein kurzes Rotationsfenster akzeptieren.
Warum das Salt wichtig ist
Das tägliche geheime Salt tut zwei Dinge. Erstens verhindert es Rainbow-Table-Angriffe: Ohne das Salt könnte ein Angreifer, der eine Liste unserer Hashes in die Hände bekommt, Hashes für gängige (IP, User-Agent)-Kombinationen vorberechnen und Eingaben wiederherstellen. Mit einem geheimen Salt, das wir nie offenlegen, wird der Hash-Raum effektiv randomisiert, und die Vorberechnung ist nutzlos.
Zweitens bedeutet das Salt, dass selbst wenn der genaue Algorithmus und die gesamte Eingabestruktur veröffentlicht würden (wie in diesem Beitrag), niemand außerhalb unserer Server die Besucher-ID für eine bekannte (IP, User-Agent)-Kombination berechnen könnte. Man bräuchte das Salt, und das Salt wird täglich rotiert und verlässt nie den Server.
Das Salt ist lang (32 Byte kryptografisch zufällige Daten), in einem Secret Manager getrennt von der Analytics-Datenbank gespeichert und alle 24 Stunden rotiert. Alte Salts werden nach der Rotation gelöscht, sodass selbst ein vollständiger Datenbank-Dump es Ihnen nicht ermöglichen würde, gestern Salts zu rekonstruieren, um gestrige Hashes zu berechnen.
Welche Daten werden gehasht
Die Zutaten unseres Hashes sind bewusst minimal:
- IP-Adresse — identifiziert den Netzwerkursprung der Anfrage. Innerhalb des Hashes, nie roh gespeichert.
- User-Agent — identifiziert den Browser und das OS in groben Zügen. Innerhalb des Hashes, nie als Identifier roh gespeichert.
- Site-ID — beschränkt den Hash auf eine einzelne Website. Ein Besucher, der auf zwei von Web-Tracking.eu verfolgten Sites erscheint, erzeugt zwei nicht zusammenhängende Hashes.
- Aktuelles UTC-Datum — rotiert den Identifier täglich.
- Geheimes Salt — rotiert den Identifier täglich und verhindert Reverse Engineering.
Wir hashen keine Geräteeigenschaften ein, die eine Lektüre aus dem Browser erfordern würden (Bildschirmgröße, Sprache, Plugins, Schriftarten, Canvas-Rendering usw.). Alles, was der Browser freiwillig in den HTTP-Headern sendet, ist zulässig; alles, was eine JavaScript-Lektüre vom Gerät erfordern würde, ist es nicht.
Das ist eine wichtige Linie. Es bedeutet, dass unser "Fingerabdruck" nur so stabil ist wie die IP-Adresse und der User-Agent. Ein Besucher, der mitten am Tag das Netzwerk wechselt, bekommt einen neuen Hash. Ein Besucher, der seinen Browser aktualisiert, bekommt nach dem Update einen neuen Hash. Ein Besucher, der ein VPN verwendet, das Exit-IPs rotiert, bekommt bei jeder Rotation einen neuen Hash. Wir akzeptieren diese Ungenauigkeit als Preis dafür, keinen echten Fingerabdruck zu erstellen.
Warum dies keine Nutzer identifiziert
Die Hash-Ausgabe ist eine 64 Zeichen lange Hex-Zeichenkette, die so aussieht:
a3f2c9b4e8d1f7a5c6b9e2d4f8a1c3b5e7d9f2a4c6b8e1d3f5a7c9b2e4d6f8a0
Für sich genommen kann diese Zeichenkette keiner Einzelperson zugeordnet werden. Sie kann nicht umgekehrt werden, um die IP oder den User-Agent wiederherzustellen. Sie kann nicht über Tage hinweg korreliert werden, da sich Datum und Salt ändern. Sie kann nicht über Sites hinweg korreliert werden, da sich die Site-ID ändert.
Die Roh-Eingaben (IP und User-Agent) existieren im Speicher für die Millisekunden, die für die Berechnung des Hashes benötigt werden. Sie werden nie auf Festplatte geschrieben, nie in Logs kopiert, nie an Dritte gesendet, nie in irgendeiner Form aufbewahrt. Das Einzige, was bleibt, ist der Hash, und der Hash hat keine der Eigenschaften, die ihn nach DSGVO Artikel 4 Absatz 1 zu personenbezogenen Daten machen würden: Er identifiziert nicht, er kann keine Einzelperson herausgreifen, und er kann ohne Zugriff auf Daten, die wir nicht haben, nicht mit einer identifizierbaren Person verknüpft werden.
Das Gutachten 05/2014 der Artikel-29-Datenschutzgruppe zu Anonymisierungstechniken stellt drei Tests auf: Herausgreifen, Verknüpfbarkeit und Rückschluss. Unser täglich rotierender, site-begrenzter, gesalzener Hash besteht alle drei Tests als Identifier von Individuen nicht, was genau der Punkt ist.
Einschränkungen: Nutzer im selben Haushalt, gemeinsame IPs, VPNs
Hash-basierte Identifikation ist kein perfekter Zähler. Sie tauscht Genauigkeit gegen Datenschutz, und die Wege, auf denen sie unvollkommen ist, sind es wert, verstanden zu werden.
Nutzer im selben Haushalt, die sich eine IP-Adresse teilen und dieselbe Browserversion verwenden, erzeugen denselben Hash. Zwei Personen im selben Heim-WLAN, beide mit Chrome unter Windows, beide am selben Tag auf derselben Site, werden als ein Besucher gezählt. Cookie-basierte Analytics würde sie unterscheiden (jeder bekommt sein eigenes Cookie); hash-basierte Analytics wird das nicht.
Firmennetzwerke hinter einem NAT können viele echte Besucher zu einem einzigen Hash zusammenfallen lassen. Ein Büro mit 200 Personen, das Ihre Site von derselben öffentlichen IP aus aufruft, alle mit demselben IT-gepushten Browser-Build, sieht aus wie ein Besucher. Cookie-basierte Analytics würde sie unterscheiden; hash-basierte Analytics wird das nicht.
VPN- und Tor-Nutzer haben das umgekehrte Problem: Eine einzelne Person, deren Exit-IP rotiert, erzeugt mehrere Hashes und wird mehrfach gezählt. Cookie-basierte Analytics würde sie als einen Besucher sehen; hash-basierte Analytics überzählt.
Nutzer auf mehreren Geräten werden immer getrennt gezählt, weil die Kombination aus IP und User-Agent unterschiedlich ist. Dies ist dieselbe Einschränkung wie bei cookie-basierter Analytics ohne geräteübergreifende Identitätsverknüpfung.
Der Nettoeffekt ist, dass cookiefreie Analytics dazu neigt, in dichten Gemeinschaftsumgebungen zu wenig zu zählen und für datenschutzbewusste Nutzer mit rotierenden IPs zu viel zu zählen. Beide Effekte mitteln sich für die meisten Websites im Aggregat aus, aber wenn Ihr Publikum in Firmennetzwerken konzentriert ist oder stark zu VPN-Nutzern tendiert, können die Zahlen um mehrere Prozent in beide Richtungen von cookie-basierten Zählungen abweichen.
Wir halten das für einen akzeptablen Kompromiss, und die meisten unserer Kunden auch. Analytics sind keine Volkszählungsdaten. Was zählt, ist die Form der Kurve, der Vergleich zwischen Tagen, die Auswirkung einer Kampagne, das Ranking von Seiten. All das wird durch hash-basiertes Zählen perfekt erhalten.
Vergleich mit anderen cookiefreien Ansätzen
Mehrere Analytics-Anbieter sind bei Variationen derselben Grundarchitektur gelandet.
- Plausible verwendete historisch einen site-spezifischen, täglich rotierenden Hash aus IP + User-Agent + Site + Salt. Ihre aktuelle Implementierung kommt dem oben Beschriebenen sehr nahe.
- Fathom verwendet einen ähnlichen hash-basierten Ansatz mit serverseitiger Berechnung und ohne clientseitige Speicherung.
- Pirsch verwendet einen täglich rotierenden Fingerabdruck auf Basis von gesalzener IP + User-Agent.
- Simple Analytics berechnet einen Hash aus IP + User-Agent + Hostname + rotierendem Salt, ebenfalls täglich.
Die Unterschiede liegen hauptsächlich in:
- Der Rotationsfrequenz (täglich ist typisch, aber nicht universell)
- Ob das Salt kundenübergreifend oder pro Site geteilt wird
- Welche genauen Header-Felder in die Hash-Eingabe aufgenommen werden
- Ob IP-Adressen vor dem Hashing gekürzt werden (v4: letztes Oktett, v6: letzte 80 Bit) für zusätzlichen Datenschutz
- Wie lange der resultierende Hash in aggregierter Form aufbewahrt wird
Bemerkenswert ist die Konvergenz. Vor fünf Jahren war datenschutzfreundliche Analytics ein unordentliches Feld mit vielen konkurrierenden Architekturen. Heute verwenden alle ernsthaften Akteure serverseitiges Hashing mit irgendeiner Form der Rotation, weil es die einzige Architektur ist, die den ePrivacy-Auslöser sauber vermeidet, ohne die zentrale analytische Aufgabe zu gefährden.
Das Fazit
Hash-basierte Besucheridentifikation ist kein Hack und kein Workaround. Sie ist eine prinzipielle Lösung für ein reales Problem: eindeutige Besucher zu zählen, ohne etwas auf ihren Geräten zu speichern und ohne rohe Identifier auf dem Server aufzubewahren. Richtig gemacht, mit täglicher Rotation, einem rotierenden geheimen Salt und verworfenen Roh-Eingaben, liefert sie brauchbare Analysen mit starken Datenschutzeigenschaften und ohne ePrivacy-Einwilligungspflicht.
Schlecht gemacht — mit langen Rotationsfenstern, gemeinsam genutzten Salts, aufbewahrten IPs oder zusätzlichem Geräte-Fingerprinting — degeneriert sie zu einem weiteren Tracking-Schema. Der Teufel steckt in den Engineering-Details, weshalb es sich lohnt zu verstehen, was Ihr Analytics-Anbieter tatsächlich unter der Haube tut.
Web-Tracking.eu ist eine cookiefreie Analytics-Plattform. Erfahren Sie mehr über unseren Ansatz in der rechtlichen Erläuterung kein Cookie-Banner.