Zurück zum Blog

Was ‚Privacy-First' Tatsächlich in Ihrem Analytics-Stack Bedeutet

Der Begriff ist überall, aber die meisten Tools, die ihn verwenden, speichern weiterhin Identifikatoren, Fingerabdrücke oder gehashte E-Mails. Hier ist, wie ein technisch solides datenschutzfreundliches Datenmodell aussieht.

„Privacy-First" ist zu einem Marketing-Begriff geworden. Tools, die ihn verwenden, reichen von solchen, die tatsächlich keine personenbezogenen Daten speichern, bis zu solchen, die ihre Cookies einfach auf serverseitigen Speicher verschoben und sich für konform erklärt haben. Um den Anspruch zu bewerten, müssen Sie sich drei konkrete Dinge ansehen: was erfasst wird, wie es gespeichert wird und ob es rückgängig gemacht werden kann.

Stufe 1: Was erfasst wird

Jedes Analytics-Tool erfasst etwas. Die Frage ist, ob etwas davon als personenbezogene Daten nach DSGVO, LGPD oder CCPA gilt. Die folgenden sind allgemein sicher — sie sind aggregiert oder für sich allein nicht identifizierbar:

  • Seiten-URL und Pfad
  • Referrer-Domain (nicht die vollständige URL)
  • Land (am Edge aus der IP abgeleitet, niemals gespeichert)
  • Gerätetyp (mobil oder Desktop, abgeleitet aus Bildschirmbreite und breiten User-Agent-Mustern)
  • Browser-Familie (Chrome, Safari, Firefox und andere grobe Familien, serverseitig aus dem User-Agent der Anfrage abgeleitet)

Was diese sicher macht, ist, dass keiner von ihnen, einzeln oder kombiniert, zuverlässig eine bestimmte Person identifiziert. Eine Referrer-Domain sagt Ihnen, dass jemand von Hacker News kam — nicht, welcher Nutzer von Hacker News er ist.

Die Linie wird überschritten, wenn Sie beginnen, IP-Adressen, vollständige User-Agents, Gerätefingerabdrücke oder eine beliebige Art von persistenter Kennung zu speichern — selbst eine gehashte, die Sie über Sitzungen hinweg behalten.

Stufe 2: Wie Daten gespeichert werden

Das sichere Erfassen von Daten ist etwas anderes als das sichere Speichern. Viele Tools behaupten, sie verwenden keine Cookies, speichern dann aber eine Besucher-ID in einer serverseitigen Sitzung, die an eine IP-Adresse gebunden ist. Die IP-Adresse ist personenbezogenes Datum nach der DSGVO. Die Tatsache, dass das Cookie serverseitig verschoben wurde, ändert nichts an dem, was getrackt wird.

Ein wirklich datenschutzfreundlicher Speicher enthält nur das oben Aufgelistete — und eine Besucher-Kennung, die nicht auf eine Einzelperson zurückgeführt werden kann. Der Ansatz von Monoid ist ein täglicher Einweg-Hash:

visitor_hash = SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD)

Drei Eigenschaften machen dies sicher:

Einweg: SHA-256 ist nicht umkehrbar. Sie können die IP-Adresse aus dem Hash nicht wiederherstellen. Gesalzen: Das serverseitige SALT_SECRET bedeutet, dass der Hash nicht durch Rainbow-Table-Angriffe angegriffen werden kann, selbst wenn der Algorithmus bekannt ist. Täglich: Das Datum in der Eingabe bedeutet, dass derselbe Besucher morgen einen anderen Hash erzeugt. Es gibt keine persistente sitzungsübergreifende Kennung.

Der Hash ist nicht nützlich, um eine Person über die Zeit zu verfolgen. Er ist nur nützlich, um Besucher innerhalb eines einzelnen Tages zu deduplizieren — was das Einzige ist, was er tun muss.

Stufe 3: Kann es rückgängig gemacht werden?

Dies ist der Test, der echte Privacy-First-Tools von Marketing-Behauptungen trennt. Wenn ein hinreichend motivierter Angreifer — einschließlich einer Regierung mit einer gerichtlichen Anordnung — Ihre Analytics-Datenbank erhalten würde, was könnte er erfahren?

Mit dem Datenmodell von Monoid: Er könnte erfahren, welche Seiten besucht wurden, aus welchen Ländern, auf welchen Geräten und an welchen Tagen. Er könnte nicht erfahren, welche konkrete Einzelperson welche konkrete Seite besucht hat. Der Hash sagt ihm ohne die ursprüngliche IP, den ursprünglichen User-Agent, den geheimen Salt und das korrekte Datum nichts — und all dies wird nie zusammen gespeichert.

Vergleichen Sie dies mit „anonymisierten" GA4-Daten, die Client-IDs (persistente, cookiebasierte Identifikatoren), Ereignis-Zeitstempel mit Millisekundengenauigkeit und Komponenten von Gerätefingerabdrücken behalten. Diese Daten sind nicht anonym — sie sind bestenfalls pseudonym und mit moderatem Aufwand mit echten Nutzern verknüpfbar.

Wie die Datenbank tatsächlich aussieht

Ein Monoid-Pageview-Datensatz enthält: site_id, path, referrer, country, device, browser_family, visitor_hash (den täglichen Einweg-Hash) und einen timestamp. Das ist der vollständige Datensatz. Es gibt keine IP-Adress-Spalte, keinen vollständigen User-Agent-String, keine Browser-Version, keine persistente Nutzer-ID und kein Sitzungstoken. Es gibt nichts im Schema, das einer echten Person zugeordnet werden kann.

So sieht Privacy-First auf Datenmodell-Ebene aus. Alles andere — Dashboards, Echtzeit-Zählungen, Länder-Aufschlüsselungen — wird aus diesen Feldern berechnet.

Warum die Unterscheidung in der Praxis wichtig ist

Wenn Ihr Analytics-Tool personenbezogene Daten speichert, sind Sie ein DSGVO-Verantwortlicher mit Pflichten: Sie müssen eine Rechtsgrundlage für die Verarbeitung veröffentlichen, ein Verarbeitungsverzeichnis führen und auf Auskunftsersuchen betroffener Personen reagieren. Sie benötigen auch einen Einwilligungsmechanismus, wenn Ihre Rechtsgrundlage die Einwilligung ist.

Wenn Ihr Analytics-Tool nur nicht-personenbezogene aggregierte Daten speichert, gelten diese Pflichten nicht — weil es keine personenbezogenen Daten zu kontrollieren gibt. Der rechtliche Overhead verschwindet zusammen mit dem Einwilligungsbanner.