Kostenloser PII Datenschutz Check für Google Analytics

Personenbezogene Daten wie Namen, Mailadressen, Anschriften etc. (AKA "PII" - Personally identifiable information) haben in Google Analytics nichts verloren. Das ist nicht erst seit der DSGVO so. Google hatte schon immer etwas dagegen und gibt die Verantwortung dafür schon immer in den Nutzungsbedingungen ab. Seit GA4 gibt es erfreulicherweise auch Funktionen zum Redigieren von Mailadressen in URLs oder gezieltem Entfernen von Daten. Aber das reicht nicht unbedingt. Was ist mit Mailadressen in Ereignisparametern oder Nutzereigenschaften? Aus diesem Grund habe ich den PII-Check bei Analytrix nach vielen Jahren wieder aufleben lassen, denn ich treffe immer wieder auf Fundstellen an Orten, an denen ich keine Personenbezogenen Daten vermuten würde. Selbst wenn ein automatisierter Check nicht alles finden kann, hat diese Wiederbelebung m. E. einen Sinn. Und so lebt das Tool wieder, mit dem jeder nach Autorisierung des Zugriffs anhand verschiedener Muster in seinen Daten nach Spuren von problematischen Eigenschaften suchen kann. Nicht nur (aber auch) in URLs.

Ein Tool mit Historie

Schon im März 2018 ist dieser Check erstmals in Analytrix als kostenlose Analyse auf Basis von Universal Analytics umgesetzt worden. PII in URLs war an der Tagesordnung, die DSGVO hat das Thema aber dringlicher für viele gemacht. Nach dem Wegfall von UA ist allerdings auf doppelte Weise ein Loch entstanden: Man konnte anfangs weder Parameter ausschließen (es es jetzt wieder geht) oder gar redigieren, noch war dieses Tool weiter nützlich, ohne auf GA4 umgestellt zu werden.

Mit "URL Cleaner" genannten Tag Manager Variablen-Vorlagen für Web und Server habe ich damals die ersten Mittel zur Behandlung von URL Parametern geschaffen, die ich auch heute noch sinnvoll finde, da man damit das Problem vor dem Senden behandeln kann, statt erst beim Empfänger. Ein neuer PII-Check war aber anfangs nicht vorgesehen. Ersatzweise prüfte sowohl der GA4-Audit als auch der Parametercheck "nebenbei", ob Mailadressen in URLs zu finden sind und beide weisen diese als Problem aus. Das tun beide auch immer noch. Da dies aber keine Parameter und Eigenschaften von Events, sondern nur URLs behandelt, ist der Check wieder zurück.

Das passiert beim Check

Der PII-Check läuft vollständig im Browser ab und speichert keine Daten auf dem Server, so dass man sich bei der Suche nach Datenschutzproblemen keine neuen einfangen muss 😉 Wird er für einen wählbaren Zeitraum gestartet, wird per API in den Berichten zu URLs, Nutzereigenschaften und Eventparametern (nicht nur, aber auch interne Suchanfagen, Link URLs, Seitentiteln etc.) nach Treffern gesucht, die Spuren von personenbezogenen Daten haben. Das sind:

• E-Mail-Adressen (Erkennung anhand eines Musters; alle Daten)
• Bankdaten (wenn als Parameter verwendet, in URLs)
• Postanschriften (wenn als Parameter verwendet, in URLs)
• IBAN (Erkennung anhand eines Musters; alle Daten)

Dabei kann eine Erkennung von Anschriften und Namen etc. nur anhand von URL Parameternamen "vermutet" werden; eine Prüfung auf Namen ist - außer mit unvollständigen Stichproben - kaum per Regelwerk möglich, ohne dazu z. B. Machine Learning zur Hilfe zu nehmen.

Ergebnisse des Checks

Idealerweise besteht das Ergebnis eines Checks daraus, dass nichts gefunden wurde.

Damit hat man natürlich weder alle denkbaren Szenarien abgedeckt, noch durch intime Kenntnis des Systems die richtigen Parameter erwischt... und auch eine Suche in den echten Daten nach typischen Vornamen, Mustern von Telefonnummern etc. ist unabhängig von diesem Check eine gute Idee, denn diese sind nicht so leicht wie die oben genannten Kandidaten anhand von Suchmustern zu identifizieren, die allgemein gültig sind und bei Verwendung möglichst wenig falsche Treffer zurück liefern.

Es ist aber auf jeden Fall ein guter Anfang... und da ich im Laufe der Jahre eine ganze Menge an Analytics-Properties analysieren konnte, kann ich auch behaupten, dass es einen nennenswerten Anteil an Analytics-Konten mit solchen Problemen gibt. Hier ein (konstruiertes) Extrembeispiel, um die möglichen Meldungen zu demonstrieren:

Insofern: Ran und die eigenen Daten checken. Wenn etwas gefunden wird, tiefer in die echten Daten sehen und bei positivem (also in diesem Fall eigentlich negativem) Ergebnis entsprechend handeln, denn die Daten sind datenschutzkonform erhoben worden und müssen folgerichtig gelöscht werden. Dazu ist eine Korrektur an der Quelle (ggf. im dataLayer), in GA4 per Filter und / oder mt den oben angesprochenen Vorlagen für den Tag Manager fällig. Ein paar Hinweise zum Vorgehen bei gefundenen Problemen finden sich direkt auf der Seite unter dem Check.

Viel "Spaß" damit! Und wie immer: Wer Vorschläge oder Feedback hierzu hat, sendet mir bitte einfach eine Mail.