{"id":437,"date":"2026-09-02T17:00:00","date_gmt":"2026-09-02T15:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=437"},"modified":"2026-08-13T14:27:57","modified_gmt":"2026-08-13T12:27:57","slug":"server-side-pii-redaction-privacy-firewall-ssgtm-pl","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-marketing-pl\/server-side-pii-redaction-privacy-firewall-ssgtm-pl\/","title":{"rendered":"Serwerowe redagowanie PII: Jak zbudowa\u0107 firewall prywatno\u015bci w ssGTM"},"content":{"rendered":"\r\n
Przypadkowy wyciek danych osobowych (PII) w parametrach zapyta\u0144 HTTP stanowi jedno z najbardziej krytycznych ryzyk prawnych i technicznych w analityce cyfrowej. Gdy formularze przesy\u0142aj\u0105 dane metod\u0105 GET lub systemy automatyzacji marketingu do\u0142\u0105czaj\u0105 niezaszyfrowane adresy e-mail, numery telefon\u00f3w czy numery PESEL do adres\u00f3w URL, tagi dzia\u0142aj\u0105ce po stronie klienta przekazuj\u0105 te informacje bezpo\u015brednio do zewn\u0119trznych platform. Nowoczesne architektury analityczne minimalizuj\u0105 to ryzyko, wykorzystuj\u0105c Server-Side Google Tag Manager (ssGTM) jako po\u015brednicz\u0105cy firewall prywatno\u015bci, kt\u00f3ry automatycznie czy\u015bci wra\u017cliwe ci\u0105gi znak\u00f3w przed wys\u0142aniem \u0142adunku danych do Google Analytics 4 lub Meta Conversions API.<\/p>\r\n\r\n\r\n\r\n
1. Dlaczego wyciek PII w adresach URL stanowi krytyczne ryzyko regulacyjne<\/h2>\r\n\r\n\r\n\r\n
Przekazywanie danych osobowych do podmiot\u00f3w trzecich bez wcze\u015bniejszego kryptograficznego haszowania narusza rygorystyczne przepisy o ochronie prywatno\u015bci (takie jak RODO\/GDPR) oraz regulaminy g\u0142\u00f3wnych platform reklamowych. Google Analytics 4 natychmiast usuwa dane z us\u0142ug lub trwale blokuje zbieranie statystyk, je\u017celi wykryty zostanie niezaszyfrowany ci\u0105g PII w standardowych wymiarach, takich jak page_location<\/code>, b\u0105d\u017a w parametrach niestandardowych. Tradycyjne metody maskowania po stronie klienta (w przegl\u0105darce) s\u0105 cz\u0119sto zawodne z powodu blokowania skrypt\u00f3w lub braku kontroli nad dynamicznie generowanymi adresami.<\/p>\r\n\r\n\r\n\r\n\n\nKontener jest w\u0105skim gard\u0142em: surowe zdarzenie przychodzi raz, regu\u0142y redaguj\u0105ce dzia\u0142aj\u0105 raz, a ka\u017cdy cel poni\u017cej otrzymuje ten sam oczyszczony \u0142adunek \u2014 zamiast osobnej regu\u0142y na tag.<\/figcaption>\n<\/figure>\n\n
2. Server-Side GTM jako po\u015brednicz\u0105cy firewall prywatno\u015bci<\/h2>\r\n\r\n\r\n\r\n
W architekturze tagowania po stronie serwera zapytania analityczne generowane w przegl\u0105darce trafi\u0105 najpierw na w\u0142asny serwer tagowania (First-Party Endpoint). Poniewa\u017c \u017c\u0105danie HTTP jest kontrolowane w izolowanym \u015brodowisku serwerowym przed jak\u0105kolwiek wysy\u0142k\u0105 do zewn\u0119trznych dostawc\u00f3w, mo\u017cliwa jest pe\u0142na inspekcja, transformacja i redagowanie modelu danych zdarzenia:<\/p>\r\n\r\n\r\n\r\n
\r\n
Rozdzielenie odbioru od wysy\u0142ki:<\/strong> Przegl\u0105darka internetowa komunikuje si\u0119 wy\u0142\u0105cznie z kontenerem ssGTM. Zewn\u0119trzne systemy reklamowe nie otrzymuj\u0105 bezpo\u015bredniego dost\u0119pu do przegl\u0105darki u\u017cytkownika ko\u0144cowego.<\/li>\r\n
Scentralizowana filtracja:<\/strong> Jedna regu\u0142a czyszcz\u0105ca zdefiniowana w kontenerze serwerowym zabezpiecza wszystkie tagi wychodz\u0105ce jednocze\u015bnie, zapobiegaj\u0105c wyciekom do wielu platform reklamowych na raz.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
3. Tworzenie zmiennych Sandboxed JavaScript do detekcji PII<\/h2>\r\n\r\n\r\n\r\n
Wdro\u017cenie automatycznego silnika czyszcz\u0105cego w ssGTM wymaga napisania dedykowanej zmiennej Sandboxed JavaScript, kt\u00f3ra analizuje ci\u0105gi URL i zamienia pasuj\u0105ce wyra\u017cenia regularne na bezpieczne symbole zast\u0119pcze. Logika wyra\u017ce\u0144 regularnych musi by\u0107 zgodna z ograniczeniami interfejsu Sandboxed JavaScript API:<\/p>\r\n\r\n\r\n\r\n
\r\n
Redagowanie adres\u00f3w e-mail:<\/strong> Wzorzec RegEx identyfikuje standardowe struktury adres\u00f3w ([a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+<\/code>) i zast\u0119puje wykryty ci\u0105g statyczn\u0105 warto\u015bci\u0105 [REDACTED_EMAIL]<\/code>.<\/li>\r\n
Maskowanie numer\u00f3w telefon\u00f3w:<\/strong> Ci\u0105gi cyfr o d\u0142ugo\u015bci od 9 do 15 znak\u00f3w, cz\u0119sto poprzedzone prefiksem kraju (np. +48<\/code>) lub separatorami, s\u0105 wykrywane i usuwane z parametr\u00f3w URL, co zapobiega transmisji danych kontaktowych.<\/li>\r\n
Filtrowanie numer\u00f3w PESEL:<\/strong> Specjalistyczne regu\u0142y RegEx identyfikuj\u0105 11-cyfrowe ci\u0105gi numeryczne zgodne ze struktur\u0105 daty urodzenia lub sumami kontrolnymi PESEL, zast\u0119puj\u0105c je symbolem [REDACTED_PESEL]<\/code>.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
4. Stosowanie redagowania danych w tagach GA4 oraz Meta Conversions API<\/h2>\r\n\r\n\r\n\r\n
Po skonfigurowaniu zmiennej czyszcz\u0105cej nale\u017cy mapowa\u0107 j\u0105 na kluczowe parametry adres\u00f3w URL wewn\u0105trz kontenera serwerowego. W przypadku tag\u00f3w Google Analytics 4 nadpisanie parametr\u00f3w page_location<\/code>, page_referrer<\/code> oraz niestandardowych parametr\u00f3w URL oczyszczonym ci\u0105giem gwarantuje, \u017ce niezaszyfrowane PII nigdy nie opu\u015bci infrastruktury serwerowej. Tagi Meta Conversions API mog\u0105 bezpiecznie operowa\u0107 na zredagowanych adresach URL, podczas gdy w\u0142a\u015bciwa identyfikacja u\u017cytkownik\u00f3w realizowana jest wy\u0142\u0105cznie poprzez prawid\u0142owo za-haszowane algorytmem SHA-256 parametry User Data.<\/p>\r\n\n\n
![\"Dwa](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/ssgtm-serwerowe-redagowanie-pii-pl.png\")
\n