Tutorial: Server-Side IP-Anonymisierung: GA4, Adobe Launch und Jentis

Eine serverseitige IP-Kürzung verändert die Adresse, die nachgelagerte Dienste erhalten. Ein kürzerer Wert macht ein Ereignis nicht automatisch anonym: Kennungen, URLs und weitere Felder können weiterhin einen Personenbezug ermöglichen. Entscheidend ist eine klare Regel für die ausgehenden Daten und die Prüfung der tatsächlich versendeten Anfragen.

1. sGTM: erst das Ergebnis festlegen, dann das Tag konfigurieren

Google dokumentiert ip_override als gemeinsames Event-Datenfeld für IPv4 oder IPv6. Zunächst muss ein Client die Event-Daten bereitstellen. Ob ein zusätzliches Feld ip existiert und welche Bedeutung dahintersteht, hängt vom Client ab. Ein unbelegter Rückfall kann die gewünschte Regel umgehen.

Im Server-Container ein Variablen-Template mit Leseberechtigung für ip_override erstellen. Das folgende Beispiel akzeptiert ausschließlich gültige IPv4-Schreibweise mit vier dezimalen Oktetten und setzt das vierte Oktett auf null. IPv6, fehlende Werte und ungültige Eingaben werden verworfen. Das Beispiel deckt nur IPv4 ab und ist keine vollständige Lösung für gemischten IPv4-/IPv6-Verkehr.

const getEventData = require('getEventData');
const createRegex = require('createRegex');
const testRegex = require('testRegex');
const makeNumber = require('makeNumber');
const ip = getEventData('ip_override');
const digits = createRegex('^(0|[1-9][0-9]{0,2})$');
if (typeof ip !== 'string' || !digits) return undefined;
const parts = ip.split('.');
if (parts.length !== 4) return undefined;
for (let i = 0; i < 4; i++) {
  if (!testRegex(digits, parts[i]) || makeNumber(parts[i]) > 255) {
    return undefined;
  }
}
return parts.slice(0, 3).join('.') + '.0';

Das Template speichern, daraus eine Variable erstellen und das Ergebnis im GA4-Tag als Überschreibung für ip_override verwenden. Eine zusätzliche Triggerbedingung muss den Versand dieses Beispiels sperren, sobald die Variable keinen Wert liefert. Ein undefinierter Wert beweist allein kein Weglassen der Originaladresse; Rückfälle im Tag-Template müssen geprüft werden. Für IPv6 braucht ein produktiver Aufbau einen geprüften Adressparser und eine festgelegte Präfixregel.

Alternativ können Transformationen Event-Parameter für ausgewählte Tags ändern oder ausschließen. Tag-Auswahl und Reihenfolge sind relevant. Eine Änderung der Event-Daten entfernt weder die eingehende HTTP-Anfrage noch Infrastrukturprotokolle.

2. Adobe: IP-Verschleierung und Standortableitung getrennt einstellen

Unter Datastreams → Advanced Options → IP Obfuscation setzt Partial das letzte IPv4-Oktett beziehungsweise die letzten 80 IPv6-Bits auf null; Full setzt die ganze Adresse auf null. Geo Lookup läuft vorher und benötigt eigene Grenzen. Nachgelagerte Dienste reagieren unterschiedlich; vollständige Verschleierung beeinflusst etwa Adobe-Analytics-IP-Filter. Die Einstellung gehört zum Datastream, nicht zu einem Analytics-Dienstschalter „IP-Adresse maskieren“.

3. Jentis: Transformationsfunktion und Betriebsmodus unterscheiden

Jentis dokumentiert spezielle IPv4-Funktionen, die einen, zwei, drei oder alle Adressabschnitte zufällig ersetzen. Allgemeine Zeichenketten-Pseudonymisierung kann ungültige IP-Schreibweisen erzeugen. Daraus folgt keine allgemeine Regel „letztes Oktett auf null“. Funktion, Eingabetyp und Zielsystem benötigen eine eigene Prüfung.

Essential Mode ist ein gesonderter Betriebsmodus mit unterschiedlichen Einstellungen nach Anbieter, Tag und Einwilligung. Jentis beschreibt dafür die Server-IP als Ersatz bei der Kommunikation mit Dritten. Maßgeblich bleibt die konkrete Konfiguration.

4. Standortberichte: Auswirkungen messen

Google beschreibt die Standortableitung in GA4 während der Erfassung und das anschließende Verwerfen der IP vor der Protokollierung. Eine vorgelagerte Kürzung verändert die Eingabe. Die Genauigkeit von Stadt und Land hängt von Adressbereich, Geodatenbank und Erfassungsweg ab. Aus einem entfernten Oktett folgen weder ein garantierter Anstieg von „(not set)“ noch verlässlich richtige Länderangaben.

Beim GA4 Measurement Protocol setzt user_location explizite Standortangaben und hat Vorrang vor ip_override. Das ist eine eigene Schnittstelle; Unterstützung in jedem sGTM-Tag darf daraus nicht abgeleitet werden. Auch lokal ermittelte Standortangaben sind Daten, die beim Empfänger ankommen und einen festgelegten Umfang benötigen.

5. Conversions APIs gesondert prüfen

Eine syntaktisch gültige Adresse ist nicht automatisch ein zulässiger Ersatz für die von einer Werbe-API erwartete Geräte-IP. Meta verwendet user_data.client_ip_address; LinkedIn verwendet typisierte Einträge in user.userIds, deren dokumentierte IP-Typen derzeit nur IPv4 annehmen. Die Feldzuordnung belegt keine Unterstützung beliebiger gekürzter Werte. Je nach Pflichtfeldern kann eine Datenschutzregel das Weglassen der Kennung oder das Unterbinden des Versands erfordern.

6. Prüfung vor der Veröffentlichung

1. Normale IPv4, komprimierte und ausgeschriebene IPv6, fehlende Werte, ungültige Eingaben und Proxy-Headerlisten testen. Kein Fehlerpfad darf unbemerkt die Rohadresse wieder einsetzen.
2. Im Server-Preview sämtliche Ziele, ausgehenden Payloads und relevanten Header prüfen. Einwilligungsänderungen und alle Tag-Varianten einschließen.
3. Standortberichte mit einer dokumentierten Ausgangslage vergleichen. Fehlende Orte und Verschiebungen messen, statt feste Verlustquoten anzunehmen.
4. Separate Browserpixel und Zugriffsprotokolle kontrollieren; die Änderung eines Server-Tags erfasst diese Wege nicht.