Serverseitige PII-Bereinigung: Aufbau einer Datenschutz-Firewall im ssGTM

E-Mail-Adressen, Telefonnummern und Zugangstoken können über URLs, Seitentitel oder Formularfelder versehentlich in Analysesysteme gelangen. Der serverseitige Google Tag Manager (ssGTM) bietet einen zusätzlichen Filterpunkt vor dem Versand durch konfigurierte Tags. Dadurch sinkt das Risiko; automatisch anonym oder rechtmäßig wird die Datenerhebung nicht.

1. Die Erfassung an der Quelle begrenzen

Personenbezogene Angaben gehören nicht in Analyse-URLs. Google Analytics untersagt PII in gewöhnlichen URL- und Ereignisfeldern. Auch eine gehashte E-Mail-Adresse macht einen benutzerdefinierten Parameter nicht zu einem zulässigen Kundendatenkanal. Spezielle Funktionen für nutzerbereitgestellte Daten haben eigene Felder, Einstellungen und Richtlinien.

Hashing, Verschlüsselung und Anonymisierung erfüllen unterschiedliche Aufgaben. Ein Hash zum Kundenabgleich kann weiterhin personenbezogen sein. Die DSGVO verlangt nicht pauschal das Hashing jeder zulässigen Übermittlung. Rechtmäßige Verarbeitung, Datenminimierung und angemessene Sicherheit bleiben erforderlich.

POST hält Formularwerte aus der URL heraus, überträgt aber weiterhin einen Anfrageinhalt. HTTPS, begrenzte Protokollierung und eine kontrollierte Analyseerfassung bleiben nötig. Ein ssGTM-Filter entfernt keine bereits gespeicherten Daten aus Browserverlauf, Proxys oder Anbietersystemen. Bei einem Vorfall sind die Erfassung zu stoppen und Löschmöglichkeiten in allen betroffenen Systemen zu prüfen.

2. Den Wirkungsbereich festlegen

Der ssGTM-Client wandelt eine Anfrage in Ereignisdaten um. Transformationen ändern, erlauben oder entfernen Ereignisparameter vor dem Zugriff ausgewählter Tags. Affected Tags und Matching Conditions bestimmen den Umfang. Die Voreinstellungen umfassen alle Tags und Ereignisse; spätere Änderungen können den Bereich einschränken.

Die Transformation schreibt nicht die gesamte HTTP-Anfrage um. Eine Vorlage mit passenden Rechten kann Header oder den ursprünglichen Anfrageinhalt aus einer anderen Datenquelle lesen. Browser-Pixel, Serverprotokolle, Client-Code und weitere ausgehende Integrationen benötigen deshalb eigene Prüfungen. Unterschiedliche Transformationen und Tag-Zuweisungen können außerdem unterschiedliche Nutzlasten erzeugen.

3. Freigegebene Felder und bekannte Routen bevorzugen

Ein regulärer Ausdruck erkennt ein Muster, nicht die Bedeutung der Daten. Ein E-Mail-Muster kann kodierte oder ungewöhnliche Adressen übersehen. Eine Folge von 9 bis 15 Ziffern kann auch eine Bestellnummer oder ein Zeitstempel sein. Elf Ziffern belegen keine gültige PESEL-Nummer. Selbst eine Prüfsummenprüfung wäre kein Nachweis für eine zulässige Weitergabe.

Ein kleineres Datenmodell erleichtert die Kontrolle: keine beliebigen Formulartexte, nur freigegebene Parameter und feste Seitenrouten ohne Kennungen. Die folgende Beispielvariable akzeptiert drei genaue URLs und entfernt sämtliche Query-Parameter und Fragmente. Unbekannte Routen und andere Datentypen ergeben undefined. Beispieldomain und Routen müssen durch geprüfte Werte der jeweiligen Website ersetzt werden.

const getEventData = require('getEventData');
const getType = require('getType');
const value = getEventData(data.parameter);
if (getType(value) !== 'string') return undefined;
const base = value.split('#')[0].split('?')[0];
const allowed = [
  'https://www.example.com/',
  'https://www.example.com/products',
  'https://www.example.com/checkout/complete'
];
for (let i = 0; i < allowed.length; i++) {
  if (base === allowed[i]) return allowed[i];
}
return undefined;

Die Vorlage benötigt das Textfeld parameter und die auf das jeweilige URL-Feld begrenzte Berechtigung read_event_data. Der Rückgabewert stammt immer aus der festen Liste. Kodierte Parameternamen und mehrfach kodierte Query-Werte gelangen dadurch nicht in die Ausgabe. Das Verfahren entfernt auch Kampagnenparameter und ist bewusst eng begrenzt, kein allgemeiner PII-Detektor.

4. Ohne Rückfall auf Rohwerte anwenden

1. Eigene Variablen prüfen page_location und weitere freigegebene URL-Felder. Für beliebige externe Referrer passt dieselbe Liste nicht. Ein unbekannter Referrer muss entfallen oder einer eigenen geprüften Regel folgen.
2. Eine Augment-event-Transformation übergibt akzeptierte kanonische URLs an die vorgesehenen Tags. Unnötige Freitextfelder werden ausgeschlossen. Eine Parameter-Freigabeliste muss erforderliche technische Felder der ausgewählten Tags berücksichtigen.
3. Ein abgewiesener Wert muss das betroffene Tag ausdrücklich blockieren oder zum ausdrücklichen Ausschluss des Felds führen. undefined allein belegt keine Entfernung: Ein Tag kann auf eine rohe URL oder eine andere Quelle zurückfallen.
4. Reihenfolge, betroffene Tags, Bedingungen und Vorlagenrechte müssen zusammenpassen. Eine spätere Transformation darf den Rohwert nicht wiederherstellen.

GA4 und Meta benötigen getrennte Ausgangsprüfungen. Bei Meta verwenden nicht alle Kundendatenfelder SHA-256: Für E-Mail- und Telefonabgleich gelten andere Regeln als für Client-IP, User-Agent und Browserkennungen. Eine bereinigte URL erlaubt diese Felder nicht automatisch und anonymisiert nicht das gesamte Ereignis.

5. Die ausgehende Anfrage prüfen

Synthetische Testdaten sollten Großschreibung, kodierte Parameternamen, %40, mehrfache Kodierung, Fragmente, wiederholte Schlüssel, ungültige Datentypen, unbekannte Pfade und Token-URLs abdecken. Aus https://www.example.com/products?email=test%40example.com darf nur https://www.example.com/products entstehen. Ein unbekannter Pfad muss an der Freigabeliste scheitern.

Die Variablenlogik lässt sich separat testen. Vor der Veröffentlichung sind zusätzlich ssGTM-Vorschau und tatsächliche Nutzlast jedes Ziels zu prüfen. Die eingehende Vorschau enthält weiterhin die ursprüngliche Anfrage. Aufbewahrung und Zugriff auf Protokolle brauchen deshalb eigene Regeln.