Tutorial: Personenbezogene Daten in GA4-Seitenpfaden finden und entfernen

Eine E-Mail-Adresse im URL-Pfad, ein Suchbegriff mit Telefonnummer oder ein personenbezogener Bestellverweis kann zusammen mit einem Ereignis an GA4 gelangen. Der Befund betrifft zwei getrennte Aufgaben: weitere Übertragungen verhindern und bereits gespeicherte Daten behandeln. Eine Änderung am Tag bereinigt keinen historischen Bericht.

Der folgende Ablauf beginnt mit einer Bestandsaufnahme, begrenzt anschließend die Erfassung und behandelt zuletzt die Löschmöglichkeiten. Kein einzelner Bericht und kein regulärer Ausdruck kann die Abwesenheit personenbezogener Daten beweisen.

1. Betroffene Werte und Übertragungswege bestimmen

E-Mail-Adressen und persönliche Telefonnummern sind offensichtliche Fälle. Auch eine Bestellnummer oder ein Passwort-Reset-Token kann mit verfügbaren Zusatzinformationen einer Person zugeordnet werden. Ein Token ist außerdem ein Geheimnis. Die Bezeichnung „pseudonym“ oder eine Hashfunktion beseitigt den Personenbezug nicht automatisch. PII steht für „personally identifiable information“, also Angaben zur Identifizierung einer Person. Googles PII-Regeln und der datenschutzrechtliche Begriff personenbezogener Daten sind nicht deckungsgleich.

Für die Untersuchung sind vollständige Seitenadresse, Pfad, Query-Parameter, Referrer, Seitentitel, Suchbegriffe und benutzerdefinierte Ereignisparameter relevant. Die GA4-Standardbelegung von page_location schließt das URL-Fragment nach # aus. JavaScript oder eine abweichende Implementierung kann Fragmente trotzdem ausdrücklich übertragen. Ein Fragment ist daher kein sicherer Ablageort für Geheimnisse.

Ein Befundprotokoll benötigt Quelle, Parameter, Zeitraum, betroffene Datenziele und einen bereinigten Beispielwert. Vollständige Tokens oder Adressen gehören nicht in Tickets, frei zugängliche Tabellen oder öffentliche Online-Prüfer. Bei kompromittierten Zugangs- oder Reset-Tokens gehört außerdem die Ungültigmachung zum Vorfall; eine spätere Berichtslöschung reicht dafür nicht.

2. Vorhandene Berichte gezielt abfragen

Die Data API liefert Berichtsdaten, keinen vollständigen Rohdatenbestand. pageLocation enthält die Seitenadresse einschließlich Host und Query, pagePathPlusQueryString Pfad und Query. pagePath allein lässt Query-Parameter aus. Ergänzende Abfragen mit pageReferrer und searchTerm erfassen andere mögliche Fundstellen. Benutzerdefinierte Parameter erscheinen nicht allein durch die Übertragung als abfragbare benutzerdefinierte Dimension.

Dieses Beispiel gehört in den JSON-Body eines authentifizierten POST-Aufrufs an https://analyticsdata.googleapis.com/v1beta/properties/PROPERTY_ID:runReport. Erforderlich sind die passende numerische Property-ID, Lesezugriff und etwa der OAuth-Bereich analytics.readonly. Der feste Zeitraum ist ein Beispiel und muss zum untersuchten Vorfall passen.

{
  "dateRanges": [
    {
      "startDate": "2026-10-01",
      "endDate": "2026-10-07"
    }
  ],
  "dimensions": [
    {
      "name": "pageLocation"
    }
  ],
  "metrics": [
    {
      "name": "eventCount"
    }
  ],
  "orderBys": [
    {
      "dimension": {
        "dimensionName": "pageLocation",
        "orderType": "ALPHANUMERIC"
      }
    }
  ],
  "limit": "10000",
  "offset": "0",
  "returnPropertyQuota": true
}

eventCount zählt Ereignisse; Seitenaufrufe wären für eine getrennte Suchbegriffsabfrage unpassend. Weitere Seiten entstehen durch offset gleich der bisher gelesenen Zeilenzahl, bis die gemeldete rowCount erreicht ist. Alphabetische Sortierung und ein fester Zeitraum erleichtern den seitenweisen Abruf, verhindern aber keine Änderungen durch nachgelieferte Daten. Die API erlaubt höchstens 250.000 Zeilen pro Anfrage; Quoten gelten weiterhin.

Zur Antwortprüfung gehören dataLossFromOtherRow, samplingMetadatas, dataTruncationReasons und subjectToThresholding. Der letzte Wert bedeutet, dass Schwellenwerte gelten; tatsächlich fehlende Zeilen folgen daraus nicht zwingend. Weitere Seiten stellen weder zusammengefasste Werte aus „(other)“ noch abgeschnittene oder nicht mehr verfügbare Daten wieder her. Auch unauffällige Metadaten ergeben keinen vollständigen Datenschutznachweis.

3. Hinweise erkennen, anschließend fachlich bewerten

Prozentkodierung stellt Zeichen in einer URL durch Codes dar: %40 steht beispielsweise für @. Die Dekodierung wandelt solche Codes wieder in Zeichen um. Das Python-Beispiel untersucht den Originaltext und bis zu zwei zusätzliche Prozentdekodierungen. Die Query-Auswertung berücksichtigt wiederholte und leere Parameter sowie kodierte Schlüsselnamen. Eine Fragmentprüfung liefert lediglich einen Hinweis auf den Eingabetext, keinen Beleg für eine tatsächliche GA4-Übertragung.

import re
from urllib.parse import parse_qsl, unquote, urlsplit

EMAIL = re.compile(r"[A-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[A-Z0-9-]+(?:\.[A-Z0-9-]+)+", re.I)
FIELDS = {
    "secret_field": {"token", "hash", "auth", "key", "sig", "pwd", "password"},
    "name_field": {"name", "vorname", "nachname", "firstname", "lastname", "user"},
    "phone_field": {"phone", "tel", "mobile", "telephone"},
    "search_field": {"q", "s", "search", "query"},
}


def scan_url(text):
    if not isinstance(text, str):
        raise TypeError("text must be a string")
    if len(text) > 16384:
        return {"input_too_long"}
    flags = set()
    if re.search(r"%(?![0-9a-fA-F]{2})", text):
        flags.add("invalid_percent_encoding")
    forms = [text]
    for _ in range(2):
        decoded = unquote(forms[-1])
        if decoded == forms[-1]:
            break
        forms.append(decoded)
    if unquote(forms[-1]) != forms[-1]:
        flags.add("further_encoding")
    for form in forms:
        if EMAIL.search(form):
            flags.add("email_like")
        try:
            parts = urlsplit(form)
            if parts.username is not None or parts.password is not None:
                flags.add("url_credentials")
            # Fragment query syntax is inspected too, without claiming collection.
            queries = [parts.query, parts.fragment.partition("?")[2] or parts.fragment]
            for query in queries:
                for key, value in parse_qsl(query, keep_blank_values=True, max_num_fields=1000):
                    for label, names in FIELDS.items():
                        if key.casefold() in names:
                            flags.add(label)
                    if EMAIL.search(value):
                        flags.add("email_like")
        except ValueError:
            flags.add("url_parse_error")
    return flags

Die Funktion liefert Kategorien statt Rohwerte. email_like bezeichnet ein E-Mail-ähnliches Muster, secret_field einen verdächtigen Schlüsselnamen. phone_field bestätigt weder eine gültige Telefonnummer noch einen Personenbezug. Auch ein Produktsuchwort oder name=product kann einen Prüfhinweis erzeugen. Die Zahl 20260920 wird nicht pauschal als Telefonnummer eingestuft.

Grenzen sind unbekannte Parameternamen, personenbezogene Pfadnummern, Unicode-Sonderfälle, tiefer verschachtelte Kodierung und verschlüsselte Inhalte. Dekodierte Trennzeichen können zusätzliche Fehlalarme erzeugen. input_too_long, url_parse_error oder further_encoding erfordern eine gesonderte Untersuchung. Ein leeres Ergebnisset bedeutet ausschließlich: keine Erkennung durch diese begrenzten Regeln. Stichproben helfen bei der Bewertung, ersetzen aber keine Prüfung aller relevanten Quellen.

4. Weitere Übertragungen an der Quelle verhindern

Eine URL ohne sensible Werte schützt mehr als die nachgelagerte Korrektur eines Analysefelds. Wo personenbezogene Formulareingaben erforderlich sind, vermeidet POST die übliche Übernahme der Formularfelder in die Query. POST verhindert jedoch weder Tracking von Formulardaten noch Protokolle des Anfrageinhalts, problematische Weiterleitungen oder eine spätere URL mit denselben Werten.

Eine geeignete Erfassung verwendet erlaubte, fachlich benötigte Felder und bereinigt Seitenadresse, Referrer, Titel und freie Eingaben vor dem Versand. Server-seitiges Tagging kann zusätzliche Kontrollen vor der Weiterleitung anbieten. Bereits an andere Ziele gesendete Browser-Requests und direkte Übertragungen am Server-Container vorbei bleiben davon unberührt.

Die GA4-Datenentfernung eines Web-Datenstreams ergänzt diese Maßnahmen. E-Mail-Erkennung erfolgt nach bestem Bemühen; die Werte angegebener Query-Schlüssel werden in den dokumentierten URL-Parametern durch einen Platzhalter ersetzt, darunter page_location und page_referrer. Die Verarbeitung findet clientseitig statt. Measurement Protocol, Datenimport und HTTP-Header sind davon nicht abgedeckt. Die Einstellung bereinigt keine historischen Werte.

Für einen kontrollierten Test eignen sich ausschließlich erfundene Werte wie test@example.invalid. Entscheidend ist der tatsächlich ausgehende Request nach allen Tag-Regeln: Erstaufruf, Navigation, interne Suche, Formularabschluss und sämtliche Versandwege. Ein korrektes Vorschaufenster allein belegt noch keine korrekte produktive Übertragung.

5. Historische GA4-Daten: Löschtyp und Ausnahmen beachten

Unter Verwaltung stehen Datenlöschungsanfragen für unterstützte Parameter und Zeiträume zur Verfügung. Der Zeitraum folgt der Zeitzone der Property. Für automatisch erfasste Parameter verlangt die Dokumentation den umfassenden Typ „Alle Parameter in allen Ereignissen löschen“; die scheinbar gezielte Auswahl von page_location ist kein allgemeiner Ersatz. Eine zusätzliche Registrierung als benutzerdefinierte Dimension umgeht diese Einschränkung nicht.

Wichtige Grenze: search_term steht ausdrücklich auf Googles Liste nicht löschbarer Parameter für diesen Mechanismus. Weitere dokumentierte Ausnahmen gelten ebenfalls. Ein Vorfall mit Suchbegriffen darf deshalb nicht als erledigt gelten, nur weil eine Löschanfrage für andere Parameter abgeschlossen wurde. Der konkrete Fall benötigt eine geeignete zusätzliche Klärung und gegebenenfalls den Google-Support.

Der Mechanismus betrifft Textwerte, nicht numerische Parameterwerte, und erhält Ereigniszählungen. Die unterstützten Werte werden durch einen Löschvermerk ersetzt; beim umfassenden Typ kann auch der Ereignisname betroffen sein. Für User-ID-bezogene Löschung existiert ein gesonderter Weg. Datenlöschung ist daher weder gleichbedeutend mit dem Entfernen ganzer Ereignisse noch mit dem Löschen aller personenbezogenen Daten eines Falls.

Eine Anfrage kann sieben Tage lang widerrufen werden. Die Verarbeitung kann insgesamt sieben bis 63 Tage dauern; Daten müssen älter als zwölf Tage sein. Ein optionaler Enthält-Filter vergleicht Text ohne Beachtung der Groß-/Kleinschreibung. Vorschau und vorübergehendes Ausblenden belegen noch keinen abgeschlossenen Löschlauf. Umfang, Status und Berichtsauswirkungen müssen dokumentiert werden.

6. BigQuery und weitere Kopien separat behandeln

Eine GA4-Löschanfrage ersetzt keine Bereinigung bereits exportierter Daten. Der folgende Bestandstest zählt Parametervorkommen und Datentypen in genau einer Tabelle, ohne die Werte auszugeben. Projekt, Dataset, Datum und Schlüssel benötigen einen Abgleich mit dem tatsächlichen Befund.

-- Review one closed daily table; no modification is performed.
DECLARE target_keys ARRAY<STRING> DEFAULT
  ['page_location', 'page_referrer', 'search_term'];

SELECT
  p.key,
  COUNT(*) AS parameter_occurrences,
  COUNTIF(p.value.string_value IS NOT NULL) AS text_values,
  COUNTIF(p.value.int_value IS NOT NULL
       OR p.value.float_value IS NOT NULL
       OR p.value.double_value IS NOT NULL) AS numeric_values
FROM `project_id.analytics_123456789.events_20261001`,
UNNEST(event_params) AS p
WHERE p.key IN UNNEST(target_keys)
GROUP BY p.key
ORDER BY p.key;

Falls die vollständige Entfernung dieser drei Parameter fachlich beschlossen ist, zeigt das nächste Muster die begrenzte Umsetzung. Mit apply_change = FALSE läuft nur eine Abfrage der betroffenen Ereignisse. Die Umschaltung auf TRUE entfernt sämtliche Einträge der ausgewählten Schlüssel aus dieser Tabelle, einschließlich unauffälliger Werte. Das ist eine destruktive Änderung am aktuellen Tabellenstand, keine präzise Maskierung einzelner E-Mail-Adressen.

-- Example for a confirmed full removal of selected parameter values.
-- Project, dataset, table and key list require case-specific review.
DECLARE apply_change BOOL DEFAULT FALSE;
DECLARE target_keys ARRAY<STRING> DEFAULT
  ['page_location', 'page_referrer', 'search_term'];

SELECT COUNT(*) AS affected_events
FROM `project_id.analytics_123456789.events_20261001`
WHERE EXISTS (
  SELECT 1 FROM UNNEST(event_params) AS p
  WHERE p.key IN UNNEST(target_keys)
);

IF apply_change THEN
  UPDATE `project_id.analytics_123456789.events_20261001`
  SET event_params = ARRAY(
    SELECT AS STRUCT p.*
    FROM UNNEST(event_params) AS p WITH OFFSET AS position
    WHERE p.key IS NULL OR p.key NOT IN UNNEST(target_keys)
    ORDER BY position
  )
  WHERE EXISTS (
    SELECT 1 FROM UNNEST(event_params) AS p
    WHERE p.key IN UNNEST(target_keys)
  );
END IF;

Andere Parametereinträge, einschließlich möglicher NULL-Schlüssel, bleiben samt Reihenfolge erhalten. Die Zielschlüsselliste darf keine NULL-Werte enthalten. Andere Tabellen, user_properties, Nutzerkennungen, weitere Ereignisfelder und nachgelagerte Exporte bleiben unverändert. Vor einer Änderung sind das Ziel, Berechtigungen, erwartete Anzahl und Auswirkungen in einer isolierten Testtabelle zu prüfen; danach folgt die erneute Bestandsabfrage. Laufende oder verspätete Exporte können Daten wieder ergänzen und benötigen eine gesonderte Kontrolle.

BigQuery hält frühere Versionen über Time Travel vor, standardmäßig sieben Tage und konfigurierbar zwischen zwei und sieben Tagen. Danach folgt eine siebentägige Fail-safe-Phase. Diese Daten sind nicht unmittelbar abfragbar; eine Wiederherstellung erfordert den dokumentierten Supportprozess. Snapshots, Kopien, Downloads und andere Systeme haben eigene Lebenszyklen. Eine leere aktuelle Abfrage beweist deshalb keine sofortige physische Löschung sämtlicher Kopien.

7. Collect-Requests ohne erneuten Versand vergleichen

Der GA4 Parameter Analyser zerlegt vollständige Collect-URLs oder Query-kodierte Request-Zeilen. Gemeinsame Parameter einer POST-URL können im getrennten Eingabefeld stehen. Mehrere Zeilen ermöglichen den Vergleich von Ereignisnamen, Mess-IDs, wiederholten Schlüsseln und fehlenden gegenüber leeren Werten.

Die Analysefunktion dekodiert Prozentkodierung einmal, ersetzt Pluszeichen entsprechend der Formularkodierung und stellt Ergebnisse als Text dar. Die Funktion sendet die eingefügten Requests nicht erneut ab. Measurement-Protocol-JSON ist ein anderes Format; zusammengesetzte Produktwerte werden nur heuristisch zerlegt. CSV-Ausgabe ist keine Anonymisierung. Für die Untersuchung bleiben bereinigte oder frei erfundene Beispiele angemessen; eine Parameteransicht ist weder ein GA4-Empfangsnachweis noch eine vollständige PII-Prüfung.

Häufige Fragen

Reicht das Entfernen eines Query-Parameters?

Nur für genau diese Fundstelle. Pfad, Referrer, Titel, Suche, andere Parameter und weitere Versandwege können denselben Wert enthalten. Die Änderung wirkt außerdem nur auf künftige Übertragungen.

Verhindert die Referrer-Policy jede Weitergabe?

Bei strict-origin-when-cross-origin bleibt innerhalb derselben Origin die URL als Referrer möglich; beim Wechsel der Origin wird normalerweise nur die Origin übermittelt, beim HTTPS-zu-HTTP-Wechsel kein Referrer. Origin bedeutet Protokoll, Host und Port, nicht bloß dieselbe Website. Abweichende Policies und ausdrücklich gesetzte Analyseparameter benötigen eine eigene Prüfung.

Ist eine maskierte Adresse automatisch anonym?

Eine Maskierung kann den Informationsgehalt reduzieren. Verbleibende Kennungen, Zusatzinformationen und der Zweck der Verarbeitung bestimmen weiterhin den möglichen Personenbezug. Ein ersetzter Query-Wert ist kein allgemeiner Anonymitätsnachweis.

Wann ist der Vorfall technisch bearbeitet?

Wenn die betroffenen Quellen erfasst, künftige Übertragungen kontrolliert, die verfügbaren Löschwege abgeschlossen und verbleibende Kopien oder technische Grenzen dokumentiert sind. Eine Regex ohne Treffer oder ein einzelner bereinigter Bericht erfüllt diese Bedingungen nicht allein.

Quellen und technische Dokumentation

• GA4: Daten vor dem Versand entfernen
• GA4: Datenlöschungsanfragen
• Data API: runReport
• Data API: ResponseMetaData
• Data API: Dimensionen und Messwerte
• GA4: Seitenaufrufe
• BigQuery: Time Travel
• DSGVO: Artikel 4
• EuGH: C-604/22
• Google Analytics: PII
• Python: urllib.parse
• BigQuery: DML
• Chrome: Referrer-Policy
• GA4 Parameter Analyser: JavaScript
• GA4: Datenerfassung
• GA4: DebugView
• WHATWG: URL-Kodierung von Formulardaten