{"id":356,"date":"2026-07-15T23:13:35","date_gmt":"2026-07-15T21:13:35","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=356"},"modified":"2026-10-24T01:19:14","modified_gmt":"2026-10-23T23:19:14","slug":"tutorial-server-side-ip-anonymisierung-ga4-adobe-launch-und-jentis","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/tutorials-de\/tutorial-server-side-ip-anonymisierung-ga4-adobe-launch-und-jentis\/","title":{"rendered":"Tutorial: Server-Side IP-Anonymisierung: GA4, Adobe Launch und Jentis"},"content":{"rendered":"

Eine serverseitige IP-K\u00fcrzung ver\u00e4ndert die Adresse, die nachgelagerte Dienste erhalten. Ein k\u00fcrzerer Wert macht ein Ereignis nicht automatisch anonym: Kennungen, URLs und weitere Felder k\u00f6nnen weiterhin einen Personenbezug erm\u00f6glichen. Entscheidend ist eine klare Regel f\u00fcr die ausgehenden Daten und die Pr\u00fcfung der tats\u00e4chlich versendeten Anfragen.<\/p>\n

1. sGTM: erst das Ergebnis festlegen, dann das Tag konfigurieren<\/h2>\n

Google dokumentiert ip_override<\/code> als gemeinsames Event-Datenfeld f\u00fcr IPv4 oder IPv6. Zun\u00e4chst muss ein Client die Event-Daten bereitstellen. Ob ein zus\u00e4tzliches Feld ip<\/code> existiert und welche Bedeutung dahintersteht, h\u00e4ngt vom Client ab. Ein unbelegter R\u00fcckfall kann die gew\u00fcnschte Regel umgehen.<\/p>\n

Im Server-Container ein Variablen-Template mit Leseberechtigung f\u00fcr ip_override<\/code> erstellen. Das folgende Beispiel akzeptiert ausschlie\u00dflich g\u00fcltige IPv4-Schreibweise mit vier dezimalen Oktetten und setzt das vierte Oktett auf null. IPv6, fehlende Werte und ung\u00fcltige Eingaben werden verworfen. Das Beispiel deckt nur IPv4 ab und ist keine vollst\u00e4ndige L\u00f6sung f\u00fcr gemischten IPv4-\/IPv6-Verkehr.<\/p>\n

const getEventData = require('getEventData');\nconst createRegex = require('createRegex');\nconst testRegex = require('testRegex');\nconst makeNumber = require('makeNumber');\nconst ip = getEventData('ip_override');\nconst digits = createRegex('^(0|[1-9][0-9]{0,2})$');\nif (typeof ip !== 'string' || !digits) return undefined;\nconst parts = ip.split('.');\nif (parts.length !== 4) return undefined;\nfor (let i = 0; i < 4; i++) {\n  if (!testRegex(digits, parts[i]) || makeNumber(parts[i]) > 255) {\n    return undefined;\n  }\n}\nreturn parts.slice(0, 3).join('.') + '.0';<\/code><\/pre>\n
Das Template speichern, daraus eine Variable erstellen und das Ergebnis im GA4-Tag als \u00dcberschreibung f\u00fcr ip_override<\/code> verwenden. Eine zus\u00e4tzliche Triggerbedingung muss den Versand dieses Beispiels sperren, sobald die Variable keinen Wert liefert. Ein undefinierter Wert beweist allein kein Weglassen der Originaladresse; R\u00fcckf\u00e4lle im Tag-Template m\u00fcssen gepr\u00fcft werden. F\u00fcr IPv6 braucht ein produktiver Aufbau einen gepr\u00fcften Adressparser und eine festgelegte Pr\u00e4fixregel.<\/p>\n
Alternativ k\u00f6nnen Transformationen Event-Parameter f\u00fcr ausgew\u00e4hlte Tags \u00e4ndern oder ausschlie\u00dfen. Tag-Auswahl und Reihenfolge sind relevant. Eine \u00c4nderung der Event-Daten entfernt weder die eingehende HTTP-Anfrage noch Infrastrukturprotokolle.<\/p>\n
\"Unterschiedliche
Unterschiedliche Verarbeitungsschritte ben\u00f6tigen eigene Regeln und Pr\u00fcfungen.<\/figcaption><\/figure>\n
2. Adobe: IP-Verschleierung und Standortableitung getrennt einstellen<\/h2>\n
Unter Datastreams \u2192 Advanced Options \u2192 IP Obfuscation<\/strong> setzt Partial<\/em> das letzte IPv4-Oktett beziehungsweise die letzten 80 IPv6-Bits auf null; Full<\/em> setzt die ganze Adresse auf null. Geo Lookup l\u00e4uft vorher und ben\u00f6tigt eigene Grenzen. Nachgelagerte Dienste reagieren unterschiedlich; vollst\u00e4ndige Verschleierung beeinflusst etwa Adobe-Analytics-IP-Filter. Die Einstellung geh\u00f6rt zum Datastream, nicht zu einem Analytics-Dienstschalter \u201eIP-Adresse maskieren\u201c.<\/p>\n
3. Jentis: Transformationsfunktion und Betriebsmodus unterscheiden<\/h2>\n
Jentis dokumentiert spezielle IPv4-Funktionen, die einen, zwei, drei oder alle Adressabschnitte zuf\u00e4llig ersetzen. Allgemeine Zeichenketten-Pseudonymisierung kann ung\u00fcltige IP-Schreibweisen erzeugen. Daraus folgt keine allgemeine Regel \u201eletztes Oktett auf null\u201c. Funktion, Eingabetyp und Zielsystem ben\u00f6tigen eine eigene Pr\u00fcfung.<\/p>\n
Essential Mode ist ein gesonderter Betriebsmodus mit unterschiedlichen Einstellungen nach Anbieter, Tag und Einwilligung. Jentis beschreibt daf\u00fcr die Server-IP als Ersatz bei der Kommunikation mit Dritten. Ma\u00dfgeblich bleibt die konkrete Konfiguration.<\/p>\n
4. Standortberichte: Auswirkungen messen<\/h2>\n
Google beschreibt die Standortableitung in GA4 w\u00e4hrend der Erfassung und das anschlie\u00dfende Verwerfen der IP vor der Protokollierung. Eine vorgelagerte K\u00fcrzung ver\u00e4ndert die Eingabe. Die Genauigkeit von Stadt und Land h\u00e4ngt von Adressbereich, Geodatenbank und Erfassungsweg ab. Aus einem entfernten Oktett folgen weder ein garantierter Anstieg von \u201e(not set)\u201c noch verl\u00e4sslich richtige L\u00e4nderangaben.<\/p>\n
Beim GA4 Measurement Protocol setzt user_location<\/code> explizite Standortangaben und hat Vorrang vor ip_override<\/code>. Das ist eine eigene Schnittstelle; Unterst\u00fctzung in jedem sGTM-Tag darf daraus nicht abgeleitet werden. Auch lokal ermittelte Standortangaben sind Daten, die beim Empf\u00e4nger ankommen und einen festgelegten Umfang ben\u00f6tigen.<\/p>\n
5. Conversions APIs gesondert pr\u00fcfen<\/h2>\n
Eine syntaktisch g\u00fcltige Adresse ist nicht automatisch ein zul\u00e4ssiger Ersatz f\u00fcr die von einer Werbe-API erwartete Ger\u00e4te-IP. Meta verwendet user_data.client_ip_address<\/code>; LinkedIn verwendet typisierte Eintr\u00e4ge in user.userIds<\/code>, deren dokumentierte IP-Typen derzeit nur IPv4 annehmen. Die Feldzuordnung belegt keine Unterst\u00fctzung beliebiger gek\u00fcrzter Werte. Je nach Pflichtfeldern kann eine Datenschutzregel das Weglassen der Kennung oder das Unterbinden des Versands erfordern.<\/p>\n
6. Pr\u00fcfung vor der Ver\u00f6ffentlichung<\/h2>\n
    \n
  1. Normale IPv4, komprimierte und ausgeschriebene IPv6, fehlende Werte, ung\u00fcltige Eingaben und Proxy-Headerlisten testen. Kein Fehlerpfad darf unbemerkt die Rohadresse wieder einsetzen.<\/li>\n
  2. Im Server-Preview s\u00e4mtliche Ziele, ausgehenden Payloads und relevanten Header pr\u00fcfen. Einwilligungs\u00e4nderungen und alle Tag-Varianten einschlie\u00dfen.<\/li>\n
  3. Standortberichte mit einer dokumentierten Ausgangslage vergleichen. Fehlende Orte und Verschiebungen messen, statt feste Verlustquoten anzunehmen.<\/li>\n
  4. Separate Browserpixel und Zugriffsprotokolle kontrollieren; die \u00c4nderung eines Server-Tags erfasst diese Wege nicht.<\/li>\n<\/ol>\n
    \n
    Fragen und Antworten<\/h2>\n
    Warum reichen die ersten drei durch Doppelpunkte getrennten IPv6-Gruppen nicht?<\/h3>\n
    Die Kurzschreibweise kann Gruppen an unterschiedlichen Positionen auslassen. F\u00fcr 2001::1:2:3:4:5:6<\/code> lautet ein \/48-Pr\u00e4fix 2001:0:1::<\/code>. Eine Trennung an ::<\/code> mit \u00dcbernahme des linken Teils ergibt f\u00e4lschlich 2001::<\/code>. Vor einer bitweisen Regel muss ein Parser die Adresse vollst\u00e4ndig aufl\u00f6sen und validieren.<\/p>\n
    Reicht Hashen aus?<\/h3>\n
    Hashen und K\u00fcrzen sind unterschiedliche Operationen. Ein deterministischer IPv4-Hash ohne Salt hat einen kleinen Kandidatenraum von 232<\/sup> Adressen; Hashen allein belegt keine Anonymit\u00e4t. Auch ein von der API vorgeschriebenes Hashverfahren l\u00e4sst sich nicht durch eine beliebige Maskierung ersetzen.<\/p>\n<\/div>\n
    \n
    Quellen<\/h2>\n