![\"Eine](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/pii-im-bestand-de.png\")
Was in einem Seitenpfad personenbezogen ist<\/h2>\n
Die offensichtlichen F\u00e4lle sind Mailadressen und Telefonnummern. Die weniger offensichtlichen bereiten mehr \u00c4rger, denn sie werden gar nicht als personenbezogen erkannt.<\/p>\n
Eine Bestellnummer ist personenbezogen, sobald sie sich in einem anderen System zu einer Person aufl\u00f6sen l\u00e4sst – und das l\u00e4sst sie sich meistens. Ein Token zum Zur\u00fccksetzen eines Passworts ist nicht personenbezogen, aber ein Geheimnis, und ein Geheimnis in einem Analysebericht steht jedem offen, der die Property lesen darf. Ein Suchbegriff ist personenbezogen, sobald Leute den eigenen Namen oder die eigene Adresse in das Suchfeld tippen – in einem Shop mit Bestellsuche t\u00e4glich.<\/p>\n
Allen gemeinsam ist der Weg \u00fcber die Adresse, und die Adresse erreicht GA4 vollst\u00e4ndig. Alles hinter dem Fragezeichen wird Teil der Seitendimension, und das Fragment hinter der Raute ist der einzige Teil, der den Browser nie verl\u00e4sst.<\/p>\n
Die Seitenpfade aus der Property holen<\/h2>\n
Die Data API liefert dieselben Dimensionen wie die Berichte, ohne deren Zeilengrenzen. Eine Anfrage \u00fcber einen langen Zeitraum bringt alles zur\u00fcck, was je erfasst wurde.<\/p>\n
curl -X POST \\\n \"https:\/\/analyticsdata.googleapis.com\/v1beta\/properties\/123456789:runReport\" \\\n -H \"Authorization: Bearer $TOKEN\" \\\n -H \"Content-Type: application\/json\" \\\n -d '{\n \"dateRanges\": [{ \"startDate\": \"395daysAgo\", \"endDate\": \"today\" }],\n \"dimensions\": [{ \"name\": \"pagePathPlusQueryString\" }],\n \"metrics\": [{ \"name\": \"screenPageViews\" }],\n \"limit\": 100000,\n \"orderBys\": [{ \"metric\": { \"metricName\": \"screenPageViews\" }, \"desc\": true }]\n }'<\/code><\/pre>\nDrei Einzelheiten entscheiden, ob das Ergebnis vollst\u00e4ndig ist. Die Dimension muss die mit der Abfragezeichenfolge sein – pagePath<\/code> allein schneidet genau den Teil ab, in dem die Daten \u00fcblicherweise stecken. Der Zeitraum sollte so weit zur\u00fcckreichen, wie die Property Daten vorh\u00e4lt, denn ein vor einem halben Jahr behobenes Leck steckt weiterhin in den gespeicherten Zeilen. Und eine Property mit vielen Pfaden braucht Seitenaufteilung: Die Antwort tr\u00e4gt eine Zeilenzahl, und alles jenseits der Grenze verlangt eine zweite Anfrage mit Versatz.<\/p>\nEin Wort zum Kontingent. Die API rechnet Marken je Property und Tag ab, und eine Abfrage \u00fcber vierhundert Tage mit hunderttausend Zeilen ist nicht umsonst. Sie einmal im Quartal zu fahren, ist sinnvoll; sie beim Entwickeln in einer Schleife zu fahren, verbraucht das Tageskontingent an einem Nachmittag.<\/p>\n
Die Muster, nach denen sich zu suchen lohnt<\/h2>\n
Sechs Muster decken fast jede Fundstelle ab, und sie geh\u00f6ren auf die rohe und auf die dekodierte Form des Pfads angewandt – denn eine Adresse kommt ebenso oft als %40<\/code> an wie als @<\/code>.<\/p>\nimport re, urllib.parse\n\nMUSTER = {\n \"mail\": re.compile(r\"[\\w.+-]+@[\\w-]+\\.[\\w.]{2,}\"),\n \"mail_kod\": re.compile(r\"[\\w.+-]+%40[\\w-]+\"),\n \"telefon\": re.compile(r\"(?:\\+|00)\\d{7,15}|\\b0\\d{8,13}\\b\"),\n \"schluessel\": re.compile(r\"[?&](?:token|hash|auth|key|sig|pwd|password)=\", re.I),\n \"namensfeld\": re.compile(r\"[?&](?:name|vorname|nachname|first|last|user)=\", re.I),\n \"suche\": re.compile(r\"[?&](?:q|s|search|query)=\", re.I),\n}\n\ndef pruefe(pfad):\n formen = {pfad, urllib.parse.unquote(pfad)}\n return {name for name, m in MUSTER.items() if any(m.search(f) for f in formen)}<\/code><\/pre>\nDie letzten beiden verlangen einen zweiten Blick, bevor etwas gemeldet wird. Ein Parameter namens name<\/code> tr\u00e4gt oft einen Produktnamen und keine Person, und ein Suchparameter ist nur dann ein Problem, wenn Leute Personenbezogenes hineinschreiben – das kl\u00e4rt das Lesen von zwanzig echten Werten, nicht der Parametername.<\/p>\nDas Telefonmuster erzeugt die meisten Fehltreffer von allen: Bestellnummern, Artikelnummern und Daten der Form 20260920 passen allesamt auf eine lange Ziffernfolge. Es auf die Parameter einzugrenzen, in denen es auftritt, statt auf den ganzen Pfad, beseitigt das gr\u00f6sstenteils.<\/p>\n
Am Stream schw\u00e4rzen statt im Tag<\/h2>\n
Liegen die Fundstellen vor, wird das Leck an der fr\u00fchesten beherrschbaren Stelle geschlossen. GA4 bietet das am Datenstream selbst an, und es gilt f\u00fcr alles, was der Stream empf\u00e4ngt, unabh\u00e4ngig davon, welches Tag gesendet hat.<\/p>\n
Die Einstellung sitzt in der Verwaltung beim Web-Datenstream in den Tag-Einstellungen unter Daten schw\u00e4rzen<\/strong>. Sie besteht aus zwei Teilen: einem automatischen Entfernen von allem, was wie eine Mailadresse aussieht, und einer Liste von Parameternamen, deren Werte vor dem Speichern ersetzt werden.<\/p>\ntoken, hash, auth, key, sig, pwd, password,\nemail, mail, e-mail, user, username,\nphone, tel, mobile,\nname, firstname, lastname<\/code><\/pre>\nDiese Liste geh\u00f6rt an dieselbe Stelle wie die Ergebnisse des Suchlaufs und sollte nachgezogen werden, sobald der Lauf einen neuen Parameter findet. Das Schw\u00e4rzen arbeitet exakt: Ein Parameter, der auf einer Seite anders geschrieben ist – e_mail<\/code> statt email<\/code> -, geht unber\u00fchrt hindurch.<\/p>\nZwei Bemerkungen zur Einordnung gegen\u00fcber den anderen Wegen. page_location<\/code> im Tag-Manager zu \u00fcberschreiben funktioniert auch und greift fr\u00fcher, aber nur f\u00fcr die Treffer dieses einen Tags; ein zweites Tag oder ein fest im Theme stehender gtag-Aufruf umgeht es. Das Bereinigen in einem Servercontainer ist der st\u00e4rkste Weg und der einzige, der auch die Weitergabe an Werbeplattformen sch\u00fctzt – eine eigene Arbeit mit eigenem Artikel. Die Stream-Einstellung ist die, die zehn Minuten kostet und alles abdeckt.<\/p>\nDer bereits gespeicherte Bestand<\/h2>\n
Das Schw\u00e4rzen gilt f\u00fcr Treffer von jetzt an. Es \u00e4ndert nichts an den Zeilen, die bereits in der Property liegen – und genau die z\u00e4hlen f\u00fcr eine datenschutzrechtliche Frage.<\/p>\n
Was sie entfernt, ist ein L\u00f6schauftrag, in der Verwaltung auf Ebene der Property. Der einschl\u00e4gige Typ l\u00f6scht ausgew\u00e4hlte Parameter \u00fcber alle Ereignisse hinweg, und die Seitenadresse ist einer dieser Parameter.<\/p>\n
Drei Eigenschaften dieses Verfahrens lohnen sich vor dem Ausl\u00f6sen zu kennen. Es hat eine Wartezeit von einigen Tagen, in der es sich zur\u00fccknehmen l\u00e4sst – das ist Absicht und n\u00fctzlich. Einmal angelaufen, dauert die vollst\u00e4ndige Anwendung bis zu etwa zwei Monaten. Und es ist unumkehrbar: Die Seitendimension dieses Zeitraums ist danach fort, auch f\u00fcr die unbedenklichen Pfade, wenn der Auftrag den ganzen Parameter umfasste.<\/p>\n
Was der Auftrag nicht anfasst, ist der BigQuery-Export. Daten, die vor der L\u00f6schung exportiert wurden, liegen in einem Datensatz, \u00fcber den die Property keine Verf\u00fcgung mehr hat, und dort sind sie eigens zu entfernen – eine DELETE<\/code>-Anweisung oder eine neu gebaute Tabelle, f\u00fcr denselben Zeitraum.<\/p>\nUPDATE `projekt.analytics_123456789.events_*`\nSET event_params = ARRAY(\n SELECT AS STRUCT\n p.key,\n IF(p.key = 'page_location',\n STRUCT(REGEXP_REPLACE(p.value.string_value,\n r'([?&](?:email|token|phone)=)[^&]*', r'\\1[entfernt]')\n AS string_value, p.value.int_value,\n p.value.float_value, p.value.double_value),\n p.value) AS value\n FROM UNNEST(event_params) AS p)\nWHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260920';<\/code><\/pre>\nWas der Suchlauf nicht sieht<\/h2>\n
Drei Orte tragen dieselbe Art von Daten und tauchen in diesem Bericht nicht auf.<\/p>\n
Der erste sind Ereignisparameter ausserhalb der Seitenadresse. Eine Formularmessung, die den eingegebenen Wert als Parameter sendet, legt ihn in eine benutzerdefinierte Dimension, und der obige Lauf schaut dort nie hin. Dieselbe Data-API-Abfrage mit der benutzerdefinierten Dimension anstelle des Seitenpfads findet ihn, und diese Abfrage lohnt sich f\u00fcr jede angemeldete Dimension einmal.<\/p>\n
Der zweite ist das Feld f\u00fcr die Nutzerkennung. Eine Property, die eine Nutzerkennung empfangen soll und stattdessen eine Mailadresse bekommt, ist ein Lehrbuchverstoss und in Berichten unsichtbar, weil das Feld in den meisten davon gar nicht erscheint. Die Pr\u00fcfung ist dieselbe wie \u00fcberall: die echten Werte ansehen, nicht den Feldnamen.<\/p>\n
Der dritte ist alles, was das Haus schon verlassen hat. Gingen die Treffer auch an eine Werbeplattform, \u00e4ndert das Schw\u00e4rzen in GA4 nichts an der Kopie, die dort ankam – und diese Plattform hat ihren eigenen L\u00f6schweg. Die Liste der Empf\u00e4nger lohnt sich vor dem ersten L\u00f6schauftrag aufzuschreiben, denn der Auftrag selbst erzeugt sie nicht.<\/p>\n