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

Przypadkowy wyciek danych osobowych (PII) w parametrach zapytań HTTP stanowi jedno z najbardziej krytycznych ryzyk prawnych i technicznych w analityce cyfrowej. Gdy formularze przesyłają dane metodą GET lub systemy automatyzacji marketingu dołączają niezaszyfrowane adresy e-mail, numery telefonów czy numery PESEL do adresów URL, tagi działające po stronie klienta przekazują te informacje bezpośrednio do zewnętrznych platform. Nowoczesne architektury analityczne minimalizują to ryzyko, wykorzystując Server-Side Google Tag Manager (ssGTM) jako pośredniczący firewall prywatności, który automatycznie czyści wrażliwe ciągi znaków przed wysłaniem ładunku danych do Google Analytics 4 lub Meta Conversions API.

1. Dlaczego wyciek PII w adresach URL stanowi krytyczne ryzyko regulacyjne

Przekazywanie danych osobowych do podmiotów trzecich bez wcześniejszego kryptograficznego haszowania narusza rygorystyczne przepisy o ochronie prywatności (takie jak RODO/GDPR) oraz regulaminy głównych platform reklamowych. Warunki korzystania z Google Analytics 4 zabraniają niezaszyfrowanych ciągów PII także w standardowych wymiarach, takich jak page_location, bądź w parametrach niestandardowych, a już zebrane wartości usuwa dopiero wniosek o usunięcie danych w usłudze. Tradycyjne metody maskowania po stronie klienta (w przeglądarce) są często zawodne z powodu blokowania skryptów lub braku kontroli nad dynamicznie generowanymi adresami.

2. Server-Side GTM jako pośredniczący firewall prywatności

W architekturze tagowania po stronie serwera zapytania analityczne generowane w przeglądarce trafią najpierw na własny serwer tagowania (First-Party Endpoint). Ponieważ żądanie HTTP jest kontrolowane w izolowanym środowisku serwerowym przed jakąkolwiek wysyłką do zewnętrznych dostawców, możliwa jest pełna inspekcja, transformacja i redagowanie modelu danych zdarzenia:

• Rozdzielenie odbioru od wysyłki: Przeglądarka internetowa komunikuje się wyłącznie z kontenerem ssGTM. Zewnętrzne systemy reklamowe nie otrzymują bezpośredniego dostępu do przeglądarki użytkownika końcowego.
• Scentralizowana filtracja: Jedna reguła czyszcząca zdefiniowana w kontenerze serwerowym zabezpiecza wszystkie tagi wychodzące jednocześnie, zapobiegając wyciekom do wielu platform reklamowych na raz.

3. Tworzenie zmiennych Sandboxed JavaScript do detekcji PII

Wdrożenie automatycznego silnika czyszczącego w ssGTM wymaga napisania dedykowanej zmiennej Sandboxed JavaScript, która analizuje ciągi URL i zamienia pasujące wyrażenia regularne na bezpieczne symbole zastępcze. Logika wyrażeń regularnych musi być zgodna z ograniczeniami interfejsu Sandboxed JavaScript API:

• Redagowanie adresów e-mail: Wzorzec RegEx identyfikuje standardowe struktury adresów ([a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+) i zastępuje wykryty ciąg statyczną wartością [REDACTED_EMAIL].
• Maskowanie numerów telefonów: Ciągi cyfr o długości od 9 do 15 znaków, często poprzedzone prefiksem kraju (np. +48) lub separatorami, są wykrywane i usuwane z parametrów URL, co zapobiega transmisji danych kontaktowych.
• Filtrowanie numerów PESEL: Specjalistyczne reguły RegEx identyfikują 11-cyfrowe ciągi numeryczne zgodne ze strukturą daty urodzenia lub sumami kontrolnymi PESEL, zastępując je symbolem [REDACTED_PESEL].

4. Stosowanie redagowania danych w tagach GA4 oraz Meta Conversions API

Po skonfigurowaniu zmiennej czyszczącej należy mapować ją na kluczowe parametry adresów URL wewnątrz kontenera serwerowego. W przypadku tagów Google Analytics 4 nadpisanie parametrów page_location, page_referrer oraz niestandardowych parametrów URL oczyszczonym ciągiem gwarantuje, że niezaszyfrowane PII nigdy nie opuści infrastruktury serwerowej. Tagi Meta Conversions API mogą bezpiecznie operować na zredagowanych adresach URL, podczas gdy właściwa identyfikacja użytkowników realizowana jest wyłącznie poprzez prawidłowo za-haszowane algorytmem SHA-256 parametry User Data.

5. Reguła jako transformacja

Zmienna czyści dane; transformacja decyduje, dokąd trafia oczyszczona wartość. W kontenerze serwerowym transformacje działają po tym, jak klient utworzy obiekt danych zdarzenia, a przed odczytaniem go przez tagi. Spośród trzech typów, Allow parameters, Augment event i Exclude parameters, to Augment event zmienia wartość istniejącego parametru zdarzenia. Bez dodatkowych ustawień transformacja obejmuje wszystkie tagi, więc również tag dodany później otrzymuje oczyszczoną wartość bez własnego przypisania.

Konfiguracja składa się z trzech części:

1. Niestandardowy szablon zmiennej w Sandboxed JavaScript odczytuje jeden parametr z danych zdarzenia i zwraca go oczyszczonego. Nazwa parametru pochodzi z pola tekstowego szablonu, dzięki czemu ten sam szablon obsługuje każde pole.
2. Z szablonu powstaje osobna zmienna dla każdego pola, na przykład dla page_location, page_referrer i search_term.
3. Transformacja typu Augment event ustawia każdy z tych parametrów na jego zmienną. Affected Tags i Matching Conditions pozostają przy ustawieniach domyślnych, obejmujących wszystkie tagi i wszystkie zdarzenia.

Skrócona wersja szablonu:

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

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

// parametry zapytania, które nie mogą opuścić serwera, bez rozróżniania wielkości liter
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]');
}

// adresy w innych miejscach wartości, także z @ zakodowanym procentowo
const mail = createRegex('[a-zA-Z0-9_.+-]+(@|%40)[a-zA-Z0-9-]+\\.[a-zA-Z0-9.-]+', 'gi');
return out.replace(mail, '[REDACTED_EMAIL]');

createRegex wymaga obrazu serwera w wersji 2.0.0 lub nowszej i zwraca null tam, gdzie RE2 jest niedostępne; wersja obrazu należy więc do listy kontrolnej przed opublikowaniem kontenera. Wzorzec numeru telefonu z sekcji 3 został celowo pominięty: każdy ciąg od 9 do 15 cyfr trafia także w numery zamówień, znaczniki czasu w sekundach lub milisekundach i długie identyfikatory produktów. Zastosowany do adresu URL zastępuje numer zamówienia w ścieżce; zastosowany do wszystkich pól zdarzenia może nadpisać transaction_id. Wzorce cyfrowe należą więc wyłącznie do pól z dowolnym tekstem, takich jak wyszukiwane frazy, a pola o znanym znaczeniu pozostają wyłączone.

Przed publikacją trzy żądania testowe pokazują, czy reguła działa: jedno z ?email=test@example.com, jedno z zakodowanym procentowo test%40example.com i jedno z nazwą parametru zapisaną jako Email=. W podglądzie przychodzące żądanie nadal pokazuje surowe wartości, co jest oczekiwane; wychodzące żądania tagów GA4 i Meta muszą zawierać symbole zastępcze. Zdarzenie testowe z prawdziwymi numerami zamówień obok pokazuje, czy nadpisane zostało coś, co powinno pozostać.