Serwerowe redagowanie PII: Jak zbudować firewall prywatności w ssGTM

Adresy e-mail, numery telefonów i tokeny dostępu mogą przypadkowo trafić do analityki przez adresy URL, tytuły stron lub pola formularzy. Server-side Google Tag Manager (ssGTM) dodaje punkt filtrowania przed wysyłką przez skonfigurowane tagi. Ogranicza to ryzyko, ale nie zapewnia automatycznie anonimowości ani zgodności z prawem.

1. Ograniczenie zbierania u źródła

Dane osobowe nie powinny trafiać do adresów URL używanych w analityce. Google Analytics zabrania PII w zwykłych polach URL i zdarzeń. Zahaszowany e-mail nie zmienia parametru niestandardowego w dozwolony kanał danych klienta. Specjalne funkcje danych przekazanych przez użytkowników mają osobne pola, konfigurację i warunki.

Haszowanie, szyfrowanie i anonimizacja pełnią różne funkcje. Hash służący do dopasowania klienta nadal może stanowić dane osobowe. RODO nie wymaga ogólnie haszowania każdego dozwolonego przekazania danych. Nadal potrzebne są zgodność przetwarzania z prawem, minimalizacja i odpowiednie zabezpieczenia.

POST usuwa wartości formularza z adresu URL, ale nadal przesyła treść żądania. HTTPS, ograniczone logowanie i kontrola zbierania danych analitycznych pozostają konieczne. Filtr ssGTM nie usuwa wstecz informacji z historii przeglądarki, proxy ani systemów dostawców. Incydent wymaga zatrzymania zbierania i oceny możliwości usunięcia danych w każdym dotkniętym systemie.

2. Zakres działania filtra

Klient ssGTM przekształca żądanie w dane zdarzenia. Transformacje zmieniają, dopuszczają lub wykluczają parametry przed odczytem przez wybrane tagi. Affected Tags i Matching Conditions określają zakres. Ustawienia domyślne obejmują wszystkie tagi i zdarzenia, ale późniejsze zmiany mogą ograniczyć działanie.

Transformacja nie przepisuje całego żądania HTTP. Szablon z odpowiednimi uprawnieniami może odczytać nagłówki lub oryginalną treść żądania z innego źródła. Piksele w przeglądarce, logi serwera, kod klienta i inne integracje wychodzące wymagają osobnej kontroli. Różne transformacje i mapowania tagów mogą też tworzyć różne ładunki wyjściowe.

3. Zatwierdzone pola i znane ścieżki

Wyrażenie regularne rozpoznaje wzorzec, a nie znaczenie danych. Wzorzec e-mail może przeoczyć zakodowany lub nietypowy adres. Ciąg 9–15 cyfr pasuje również do numerów zamówień i znaczników czasu. Jedenaście cyfr nie potwierdza poprawnego numeru PESEL. Nawet poprawna suma kontrolna nie dowodzi dopuszczalności przekazania.

Mniejszy model danych ułatwia kontrolę: bez dowolnych tekstów formularzy, tylko zatwierdzone parametry i stałe ścieżki stron bez identyfikatorów. Poniższa zmienna przykładowa akceptuje trzy dokładne adresy i usuwa cały query string oraz fragment. Nieznane ścieżki i wartości inne niż tekst zwracają undefined. Domena i ścieżki przykładowe wymagają zastąpienia sprawdzonymi wartościami danej witryny.

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;

Szablon wymaga pola tekstowego parameter i uprawnienia read_event_data ograniczonego do odpowiedniego pola URL. Wynik zawsze pochodzi ze stałej listy. Zakodowane nazwy parametrów i wielokrotnie zakodowane wartości zapytania nie przechodzą do wyniku. Metoda usuwa także parametry kampanii i celowo ma wąski zakres; nie jest uniwersalnym detektorem PII.

4. Zastosowanie bez powrotu do surowych wartości

1. Osobne zmienne sprawdzają page_location i inne zatwierdzone pola URL. Ta sama lista nie pasuje do dowolnych zewnętrznych referrerów. Nieznany referrer musi zostać pominięty lub obsłużony według osobnej sprawdzonej reguły.
2. Transformacja Augment event przekazuje zaakceptowane adresy kanoniczne do wskazanych tagów. Niepotrzebne pola tekstowe są wykluczane. Lista dozwolonych parametrów musi uwzględniać pola techniczne wymagane przez wybrane tagi.
3. Odrzucona wartość musi jawnie blokować odpowiedni tag albo prowadzić do jawnego wykluczenia pola. Samo undefined nie dowodzi usunięcia: tag może użyć surowego URL lub innego źródła zastępczego.
4. Kolejność transformacji, tagi objęte regułą, warunki i uprawnienia szablonu wymagają kontroli. Późniejsza transformacja nie może przywracać wartości surowej.

GA4 i Meta wymagają osobnego sprawdzenia wysyłki. Nie wszystkie pola danych klienta Meta korzystają z SHA-256: dopasowanie e-mail i telefonu różni się od obsługi IP klienta, user-agenta czy identyfikatorów przeglądarki. Oczyszczony URL nie zezwala automatycznie na te pola i nie anonimizuje całego zdarzenia.

5. Test żądania wychodzącego

Syntetyczne dane testowe powinny obejmować wielkie litery, kodowane nazwy parametrów, %40, wielokrotne kodowanie, fragmenty, powtarzające się klucze, błędne typy danych, nieznane ścieżki i tokeny. Z https://www.example.com/products?email=test%40example.com powinno powstać wyłącznie https://www.example.com/products. Nieznana ścieżka musi zostać odrzucona.

Logikę zmiennej można sprawdzić osobno. Publikacja wymaga dodatkowo podglądu ssGTM i kontroli rzeczywistego ładunku dla każdego odbiorcy. Podgląd wejściowy nadal zawiera oryginalne żądanie. Retencja logów i dostęp do logów wymagają więc osobnych zasad.