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

Das unbeabsichtigte Durchsickern personenbezogener Daten (PII) über HTTP-Query-Parameter stellt eines der kritischsten regulatorischen und technischen Risiken in der modernen Webanalyse dar. Wenn Formulare Daten über GET-Anfragen übertragen oder Marketing-Automation-Tools unverschlüsselte E-Mail-Adressen, Telefonnummern oder nationale Identifikationsnummern an URL-Parameter anhängen, übermitteln clientseitige Tags diese PII direkt an externe Endpunkte. Moderne Analyse-Architekturen minimieren dieses Risiko durch den Einsatz des Server-Side Google Tag Manager (ssGTM) als vorgeschaltete Datenschutz-Firewall, die sensible Zeichenketten bereinigt, bevor ausgehende Datenpakete an Google Analytics 4 oder die Meta Conversions API gesendet werden.

1. Warum PII-Lecks in URLs ein kritisches Compliance-Risiko darstellen

Die unverschlüsselte Übertragung personenbezogener Daten an Drittanbieter verstößt sowohl gegen strengste Datenschutzverordnungen (wie die DSGVO) als auch gegen die verbindlichen Nutzungsbedingungen großer Werbeplattformen. Die Nutzungsbedingungen von Google Analytics 4 untersagen unverschlüsselte PII auch in Standard-Dimensionen wie page_location oder benutzerdefinierten Parametern, und bereits erfasste Werte lassen sich nur über einen Löschauftrag in der Property entfernen. Rein clientseitige Filtermaßnahmen sind dabei oft anfällig für Fehler, da Skripte blockiert werden können oder dynamisch angehängte Query-Parameter übersehen werden.

2. Der Server-Side GTM als vorgeschaltete Datenschutz-Firewall

In einer serverseitigen Tagging-Architektur enden eingehende Analyse-Anfragen des Browsers auf einem firmeneigenen Tagging-Server. Da der eingehende HTTP-Request in der sicheren Serverumgebung verarbeitet wird, bevor eine Kommunikation mit Drittanbietern stattfindet, kann das gesamte Event-Datenmodell innerhalb einer vertrauenswürdigen Zone analysiert, transformiert und bereinigt werden:

• Entkopplung von Datenerfassung und Versand: Der Browser kommuniziert ausschließlich mit dem ssGTM-Container. Drittanbieter treten niemals in direkten Kontakt mit dem Client.
• Zentrale Filterung: Eine im Server-Container definierte Filterregel schützt alle ausgehenden Tags gleichzeitig und verhindert versehentliche Datenlecks über sämtliche Marketingkanäle hinweg.

3. Entwicklung von Sandboxed-JavaScript-Variablen zur PII-Erkennung

Für die automatische URL-Bereinigung im ssGTM erstellst du eine benutzerdefinierte Sandboxed-JavaScript-Variable. Sie prüft URL-Zeichenketten mit regulären Ausdrücken (RegEx) und ersetzt passende Textstellen durch sichere Platzhalter. Die Ausdrücke müssen dabei den Beschränkungen der Sandboxed-JavaScript-API entsprechen:

• Filterung von E-Mail-Adressen: Ein regulärer Ausdruck erkennt typische E-Mail-Strukturen ([a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+) und ersetzt diese durch einen statischen Text wie [REDACTED_EMAIL].
• Maskierung von Telefonnummern: Nummernfolgen von 9 bis 15 Ziffern, häufig eingeleitet durch Ländervorwahlen (z. B. +49 oder +48), werden identifiziert und aus den Parametern gelöscht, um die unvollständige oder vollständige Übertragung von Rufnummern zu verhindern.
• Sperrung nationaler Identifikationsnummern (z. B. PESEL): Für mitteleuropäische Anwendungen erfassen spezifische RegEx-Regeln 11-stellige Ziffernfolgen nach gängigen Prüfsummen- oder Geburtsdatumsschemata und ersetzen diese durch [REDACTED_PESEL].

4. Implementierung der Bereinigung für GA4- und Meta-Conversions-API-Tags

Sobald die Filter-Variable definiert ist, muss sie den zentralen URL-Parametern im Server-Container zugewiesen werden. Bei Google-Analytics-4-Tags wird sichergestellt, dass keine unverschlüsselten Daten den Server verlassen, indem die Parameter page_location, page_referrer sowie alle benutzerdefinierten URL-Parameter mit dem bereinigten Variablenwert überschrieben werden. Ebenso können Tags der Meta Conversions API vollständig anonymisierte URLs verarbeiten, während die reine Nutzeridentifikation ausschließlich über korrekt SHA-256-gehashte Datensätze erfolgt.

5. Die Regel als Transformation einrichten

Die Variable bereinigt; eine Transformation entscheidet, wo der bereinigte Wert ankommt. Im Server-Container laufen Transformationen, nachdem der Client das Ereignisdatenobjekt erzeugt hat, und bevor die Tags es lesen. Von den drei Typen Allow parameters, Augment event und Exclude parameters ist Augment event derjenige, der den Wert eines vorhandenen Ereignisparameters ändert. Ohne weitere Einstellungen gilt eine Transformation für alle Tags, sodass auch ein später angelegtes Tag den bereinigten Wert ohne eigene Zuweisung erhält.

Die Einrichtung besteht aus drei Teilen:

1. Eine benutzerdefinierte Variablenvorlage in Sandboxed JavaScript liest einen Parameter aus den Ereignisdaten und gibt ihn bereinigt zurück. Der Parametername kommt aus einem Textfeld der Vorlage, damit dieselbe Vorlage für jedes Feld dient.
2. Aus der Vorlage entsteht je Feld eine eigene Variable, etwa für page_location, page_referrer und search_term.
3. Eine Transformation vom Typ Augment event setzt jeden dieser Parameter auf seine Variable. Affected Tags und Matching Conditions bleiben auf der Voreinstellung, die alle Tags und alle Ereignisse umfasst.

Eine verkürzte Fassung der Vorlage:

const getEventData = require('getEventData');
const createRegex = require('createRegex');
const getType = require('getType');

const value = getEventData(data.parameter);
if (getType(value) !== 'string') {
  return value;
}

// Query-Parameter, die den Server nicht verlassen dürfen, ohne Unterscheidung von Groß- und Kleinschreibung
const params = ['email', 'e-mail', 'user_email', 'phone', 'token', 'reset_key'];
let out = value;
for (let i = 0; i < params.length; i++) {
  const re = createRegex('\\b' + params[i] + '=[^&#]*', 'gi');
  out = out.replace(re, params[i] + '=[REDACTED_PARAM]');
}

// Adressen an anderer Stelle im Wert, auch mit prozentkodiertem @
const mail = createRegex('[a-zA-Z0-9_.+-]+(@|%40)[a-zA-Z0-9-]+\\.[a-zA-Z0-9.-]+', 'gi');
return out.replace(mail, '[REDACTED_EMAIL]');

createRegex setzt das Server-Image 2.0.0 oder neuer voraus und gibt null zurück, wo RE2 nicht verfügbar ist; die Image-Version gehört deshalb vor dem Veröffentlichen des Containers auf die Prüfliste. Das Telefonmuster aus Abschnitt 3 fehlt mit Absicht: Jede Folge von 9 bis 15 Ziffern trifft auch Bestellnummern, Zeitstempel in Sekunden oder Millisekunden und lange Produkt-IDs. Auf eine URL angewandt, ersetzt es eine Bestellnummer im Pfad; auf alle Felder eines Ereignisses angewandt, kann es eine transaction_id überschreiben. Ziffernmuster gehören deshalb nur auf Freitextfelder wie Suchbegriffe, Felder mit bekannter Bedeutung bleiben ausgenommen.

Vor dem Veröffentlichen zeigen drei Testanfragen, ob die Regel hält: eine mit ?email=test@example.com, eine mit dem prozentkodierten test%40example.com und eine mit dem Parameternamen in der Schreibung Email=. In der Vorschau zeigt die eingehende Anfrage weiterhin die Rohwerte, das ist erwartet; die ausgehenden Anfragen der GA4- und Meta-Tags müssen die Platzhalter tragen. Ein Testereignis mit echten Bestellnummern daneben zeigt, ob etwas überschrieben wurde, das hätte bleiben sollen.