Tutorial: Anonimizacja IP Server-Side: GA4, Adobe Launch i Jentis

Spis treści
Skrócenie IP po stronie serwera zmienia adres dostępny dla kolejnych usług. Krótsza wartość nie zapewnia anonimowości zdarzenia: identyfikatory, adresy URL i inne pola nadal mogą umożliwiać powiązanie z osobą. Podstawą jest określenie zakresu wysyłanych danych, wdrożenie reguły i kontrola rzeczywistych żądań.
1. sGTM: reguła wyjściowa przed konfiguracją tagu
Google dokumentuje ip_override jako wspólne pole danych zdarzenia dla IPv4 lub IPv6. Dane zdarzenia musi najpierw przygotować klient kontenera. Istnienie i znaczenie dodatkowego pola ip zależy od klienta. Nieudokumentowana wartość zastępcza może ominąć zamierzoną regułę.
W kontenerze serwerowym należy utworzyć szablon zmiennej z uprawnieniem odczytu ip_override. Poniższy przykład akceptuje wyłącznie prawidłowy zapis IPv4 z czterema dziesiętnymi oktetami i zeruje czwarty oktet. Odrzuca IPv6, brakujące wartości i błędne dane. To przykład dla IPv4, a nie pełne wdrożenie dla ruchu IPv4/IPv6.
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';
Po zapisaniu szablonu należy utworzyć zmienną i przypisać wynik do nadpisania ip_override w tagu GA4. Osobny warunek wyzwalacza musi blokować wysyłkę w tym przykładzie, gdy zmienna nie zwraca wartości. Sam wynik undefined nie dowodzi pominięcia pierwotnego adresu; konieczna jest kontrola wartości zastępczych w szablonie tagu. Obsługa IPv6 w produkcji wymaga sprawdzonego parsera adresów i określonej reguły prefiksu.
Transformacje mogą również zmieniać lub wykluczać parametry zdarzeń dla wybranych tagów. Znaczenie ma wybór tagów i kolejność transformacji. Zmiana danych zdarzenia nie usuwa przychodzącego żądania HTTP ani logów infrastruktury.

2. Adobe: osobne ustawienia maskowania i geolokalizacji
W Datastreams → Advanced Options → IP Obfuscation opcja Partial zeruje ostatni oktet IPv4 lub ostatnie 80 bitów IPv6, a Full cały adres. Geo Lookup działa wcześniej i wymaga osobnego ograniczenia. Kolejne usługi mogą reagować inaczej; pełne maskowanie wpływa np. na filtry IP w Adobe Analytics. To ustawienie strumienia, nie przełącznik „Mask IP Address” usługi Analytics.
3. Jentis: funkcje przekształcania a tryb działania
Jentis dokumentuje funkcje IPv4 losowo zastępujące jedną, dwie, trzy lub wszystkie części adresu. Ogólna pseudonimizacja tekstu może tworzyć nieprawidłowe adresy IP. Nie oznacza to uniwersalnej reguły „ostatni oktet na zero”. Funkcja, typ wejścia i odbiorca wymagają sprawdzenia.
Essential Mode jest odrębnym trybem z ustawieniami zależnymi od dostawcy, tagu i zgody. Jentis opisuje zastępowanie IP adresem serwera w komunikacji z podmiotami trzecimi w tym trybie. Rozstrzyga konkretna konfiguracja.
4. Raporty lokalizacji: pomiar skutków
Według Google GA4 określa lokalizację podczas zbierania danych, po czym odrzuca IP przed zapisaniem w logach. Wcześniejsze skrócenie zmienia dane wejściowe. Dokładność miasta i kraju zależy od zakresu adresów, bazy geolokalizacji oraz ścieżki zbierania. Usunięcie oktetu nie oznacza gwarantowanego wzrostu „(not set)” ani gwarancji poprawnego kraju.
W GA4 Measurement Protocol pole user_location przekazuje jawną lokalizację i ma pierwszeństwo przed ip_override. To osobny interfejs; nie wynika z tego obsługa przez każdy tag sGTM. Lokalizacja ustalona lokalnie także jest informacją przekazywaną odbiorcy i wymaga określonego zakresu.
5. Osobna walidacja Conversions API
Poprawna składnia adresu nie dowodzi zgodności z wymaganym przez reklamowe API adresem urządzenia. Meta używa user_data.client_ip_address; LinkedIn używa typowanych wpisów w user.userIds, a dokumentowane typy IP obecnie akceptują tylko IPv4. Mapowanie pól nie potwierdza obsługi dowolnie skróconych wartości. Zależnie od pól obowiązkowych reguła prywatności może wymagać pominięcia identyfikatora lub zablokowania wysyłki.
6. Weryfikacja przed publikacją
- Testy powinny obejmować zwykłe IPv4, skrócone i pełne IPv6, brak danych, błędne wartości oraz listy adresów z nagłówków proxy. Błąd nie może po cichu przywracać pełnego adresu.
- Podgląd serwera powinien obejmować wszystkich odbiorców, wychodzące payloady i istotne nagłówki, również po zmianie zgody i dla wszystkich wariantów tagów.
- Raporty lokalizacji należy porównać z udokumentowanym punktem odniesienia. Brakujące miasta i przesunięcia wymagają pomiaru, nie założenia stałej straty.
- Osobnej kontroli wymagają piksele przeglądarki i logi dostępu; zmiana tagu serwerowego nie obejmuje tych ścieżek.
Pytania i odpowiedzi
Dlaczego pierwsze trzy grupy IPv6 rozdzielone dwukropkiem nie wystarczą?
Skrócony zapis może pomijać grupy w różnych miejscach. Dla 2001::1:2:3:4:5:6 prefiks /48 to 2001:0:1::. Podział na :: i zachowanie lewej części błędnie daje 2001::. Przed zastosowaniem reguły bitowej parser musi rozwinąć i zweryfikować adres.
Czy haszowanie wystarczy?
Haszowanie i skracanie to różne operacje. Deterministyczny skrót IPv4 bez soli ma małą przestrzeń kandydatów: 232 adresów. Sam skrót nie zapewnia anonimowości. Wymaganego przez API haszowania nie można też zastąpić dowolną regułą maskowania.
Źródła
- Server-side tagging overview
- Regulation (EU) 2016/679 (GDPR)
- Meta Conversions API: Customer Information Parameters
- LinkedIn Conversions API Schema
- sGTM: Common event data
- sGTM: APIs
- sGTM: Transformations
- Adobe: Datastream configuration
- Jentis: Anonymization and pseudonymization functions
- Jentis: Essential Mode
- GA4: Regional data collection
- GA4 Measurement Protocol
- EDPB: FAQ