Czy server-side tagging jest zgodny z RODO? Minimalizacja danych w praktyce

Server-side tagging w kontekście RODO to model zbierania i przesyłania danych, w którym zdarzenia z przeglądarki trafiają najpierw do kontenera serwerowego (server-side Google Tag Manager, sGTM) pod kontrolą administratora danych, a dopiero stamtąd - po odfiltrowaniu i pseudonimizacji - są przekazywane do platform zewnętrznych. Sam server-side tagging nie jest ani automatycznie zgodny, ani automatycznie niezgodny z RODO: to narzędzie techniczne, które daje administratorowi realną kontrolę nad tym, jakie dane osobowe opuszczają serwer, ale nie zwalnia go z obowiązku posiadania podstawy prawnej ani z obowiązku pozyskania zgody użytkownika.

Pytanie o RODO pojawia się jako jedno z pierwszych, gdy tylko pada temat przeniesienia tagów na serwer. I słusznie. Częsty błąd to sytuacja, w której firma traktuje server-side tagging jak prawną tarczę, która sama z siebie „załatwia RODO”. To nieporozumienie potrafi kosztować więcej niż samo wdrożenie. Serwer daje kontrolę nad danymi. Kontrola to jednak nie to samo co zgodność.

Skrót artykułu

Co warto wiedzieć

Wnioski, które decydują o tym, czy tagowanie po stronie serwera realnie ogranicza dane osobowe.

• Kontener serwerowy nie ma prawa wysłać danych bez zgody na cel marketingowy

  Przeniesienie tagów na serwer zmienia trasę danych, nie podstawę prawną. Sygnał zgody dociera do kontenera przez Consent Mode v2 i to on decyduje, czy tag Google Ads albo Meta w ogóle się odpali.

• Zasada minimalizacji z artykułu 5 RODO ogranicza zakres danych opuszczających kontener serwerowy

  Rozporządzenie 2016/679, stosowane od 25 maja 2018 roku, w art. 5 ust. 1 lit. c nakazuje przetwarzać dane adekwatne i ograniczone do celu (stan na 2026 rok). W sGTM egzekwuje to reguła tagu, a nie deklaracja w polityce prywatności.

• Filtrowanie w kontenerze sGTM zbiło liczbę parametrów z danymi osobowymi z 14 do 3

  Przykład ilustracyjny (liczby poglądowe): kontener wysyła czternaście pól mogących identyfikować osobę; po wdrożeniu reguł filtrowania w sGTM zostają trzy. Sygnał konwersji przetrwał to cięcie, kartoteka użytkownika nie, a platforma dostała dokładnie tyle, ile potrzebuje.

• Jawny adres e-mail w parametrze URL jest najczęstszym wyciekiem danych z kontenera serwerowego

  Adres e-mail w query stringu trafia do logów serwera, cache i systemów pośredniczących, więc jeden przeoczony parametr mnoży kopie danych. Do dopasowania konwersji wystarczy skrót SHA-256 policzony po stronie serwera.

• Hosting kontenera sGTM dokłada kolejnego procesora danych do listy obowiązków administratora

  Właściciel strony pozostaje administratorem i odpowiada za cel oraz zakres przetwarzania. Google i dostawca infrastruktury działają na jego zlecenie, więc każdy z nich potrzebuje osobnej umowy powierzenia i deklaracji regionu przetwarzania.

• Kontener w regionie UE zawęża ekspozycję danych, ale nie zatrzymuje ich w Europie

  Wybór regionu europejskiego, na przykład europe-central2, decyduje o tym, gdzie dane są przetwarzane po drodze. Platforma reklamowa, która odbiera zdarzenie, może je dalej przetwarzać globalnie i tego kontener nie zmienia.

Czy server-side tagging jest zgodny z RODO?

Server-side tagging jest zgodny z RODO wtedy i tylko wtedy, gdy administrator poprawnie skonfiguruje podstawę prawną, zgodę oraz zakres danych opuszczających kontener serwerowy. Sama technologia jest neutralna - zgodność albo niezgodność rodzi się w konfiguracji, nie w architekturze.

To rozróżnienie jest kluczowe, bo w branży krąży skrót myślowy „server-side = prywatnie = legalnie”. Uważam, że to jeden z groźniejszych mitów pomiarowych ostatnich lat. Serwer faktycznie odcina przeglądarkę od bezpośredniego kontaktu z dziesiątkami skryptów third-party i daje Ci jeden punkt, w którym możesz zdecydować, co wysłać dalej. Ale ten sam serwer, źle ustawiony, potrafi wysłać do platformy reklamowej pełny adres e-mail w parametrze URL równie ochoczo jak najgorszy piksel client-side.

W praktyce zgodność z RODO w server-side tagging opiera się na czterech filarach, które sprawdzam w każdym audycie:

• Podstawa prawna i zgoda: zanim jakikolwiek tag odpali, musi istnieć ważna zgoda dla danego celu - inaczej serwer nie ma prawa przetwarzać danych marketingowych.
• Minimalizacja zakresu: do platform trafia tylko to, co niezbędne do pomiaru konwersji, nie cały strumień zdarzeń z pełnym kontekstem osobowym.
• Kontrola nad transferem: administrator wie i decyduje, dokąd i w jakiej formie wychodzą dane z kontenera.
• Rozliczalność: konfigurację da się udokumentować i wykazać przed organem nadzorczym, co RODO nazywa zasadą rozliczalności.

Territory: ten artykuł dotyczy warstwy RODO w architekturze server-side. Mechanikę samej zgody i tryby działania sygnału opisuję osobno - tutaj traktuję Consent Mode v2 jako element, który trzeba wpiąć, a nie jako temat do rozwinięcia od zera.

Dlaczego kontener serwerowy ułatwia zgodność z RODO?

Kontener serwerowy ułatwia zgodność z RODO, bo przenosi decyzję o wysłaniu danych z przeglądarki użytkownika na serwer administratora - czyli w miejsce, które administrator w pełni kontroluje. W modelu client-side każdy skrypt third-party czyta dane bezpośrednio i wysyła je do swojego dostawcy, zanim właściciel strony zdąży cokolwiek odfiltrować.

Na tym polega fundamentalna różnica client-side kontra server-side w kontekście prywatności. Przy client-side tagowaniu Twoja strona jest tablicą ogłoszeń: każdy piksel widzi dataLayer, cookie i nagłówki, po czym raportuje do siebie. Przy tagowaniu po stronie serwera masz bramkę. Wszystko przechodzi przez jeden kontener, a Ty ustawiasz reguły, kto dostaje co i w jakiej postaci.

Ta kontrola przekłada się na konkretne możliwości techniczne, których model przeglądarkowy po prostu nie daje:

• Usuwanie parametrów przed wysyłką: możesz wyciąć z żądania e-mail, telefon czy identyfikatory, zanim opuszczą serwer.
• Haszowanie danych po stronie serwera: dane niezbędne do dopasowania (np. dla konwersji rozszerzonych) hashujesz na serwerze, więc do platformy trafia skrót, nie wartość jawna.
• Ograniczenie liczby odbiorców: jeden serwer obsługuje wiele platform, ale to Ty decydujesz, do których i z jakim zestawem danych.
• Skrócenie lub anonimizacja IP: adres IP możesz obciąć lub w ogóle nie przekazywać dalej.

Przykład ilustracyjny (liczby poglądowe): po wdrożeniu reguł filtrowania liczba odrębnych parametrów zawierających dane mogące identyfikować osobę, które opuszczają kontener, spada z 14 do 3. To nie jest kosmetyka. To różnica między „wysyłamy wszystko, co się da” a „wysyłamy to, co niezbędne”.

Na czym polega minimalizacja danych w kontenerze serwerowym?

Minimalizacja danych w kontenerze serwerowym polega na tym, że do każdej platformy przekazujesz wyłącznie dane niezbędne do realizacji jej celu - i ani jednego parametru więcej. To techniczne wdrożenie zasady minimalizacji z art. 5 RODO wewnątrz reguł tagu server-side.

W praktyce oznacza to trzy operacje, które konfiguruję na poziomie tagów i zmiennych w sGTM: filtrowanie (usunięcie zbędnych parametrów), pseudonimizację (haszowanie tego, co potrzebne do dopasowania) oraz redukcję precyzji (np. skrócenie IP, ogólniejsza geolokalizacja). Cel jest jeden: platforma dostaje sygnał konwersji, nie kartotekę osoby.

Najczęstszy błąd to myślenie zerojedynkowe - „zbieramy wszystko” albo „nie zbieramy nic”. Jedno i drugie szkodzi. Zbyt szeroki zakres to ryzyko prawne i brak podstawy. Zbyt agresywne cięcie potrafi zabić atrybucję i optymalizację kampanii, przez co pomiar staje się bezużyteczny. Sztuką jest środek: minimum, które jest jednocześnie zgodne i użyteczne.

MINIMALIZACJA DANYCH

Ile danych naprawdę potrzebujesz na serwerze?

RODO i skuteczność pomiaru spotykają się pośrodku. Zbyt szeroki zakres to ryzyko prawne, zbyt wąski - martwa atrybucja. Zgodny jest środek.

Zbieram wszystkoPełne PII

Cały ruch, jawny e-mail, pełne IP i dokładna geolokalizacja - brak podstawy prawnej i realne ryzyko.

Zakres optymalnyDane zhaszowane

Sygnał konwersji, zhaszowane dane dopasowania, skrócone IP - zgodnie i wystarczająco do optymalizacji.

Za mało do pomiaruZero sygnału

Tak agresywne cięcie, że atrybucja i Smart Bidding przestają działać - pomiar traci sens.

Rekomendacja: Zacznij od pytania „czego platforma naprawdę potrzebuje do policzenia konwersji”, a nie „co da się wysłać”. Haszuj dane dopasowania na serwerze, skracaj IP i wycinaj parametry, których nikt nie wykorzystuje.

To dokładnie ten moment analizy, który przechodzę podczas audytu pomiaru - mapuję, który parametr do czego służy, i wszystko, co nie ma odbiorcy ani celu, znika z żądania.

Które dane osobowe filtrować po stronie serwera?

Po stronie serwera filtruj przede wszystkim dane, które bezpośrednio identyfikują osobę i nie są potrzebne platformie w postaci jawnej: adres e-mail, numer telefonu, pełny adres IP oraz precyzyjną lokalizację. Dane potrzebne do dopasowania konwersji przekazuj wyłącznie w formie zhaszowanej.

Kolejność ma znaczenie, bo nie każdy wyciek waży tyle samo. Jawny e-mail w parametrze URL to najcięższy przypadek - trafia do logów, cache i systemów pośredniczących. Właśnie parametry w query stringu bywają najczęściej przeoczanym źródłem danych osobowych wyciekających z kontenera.

FILTROWANIE PARAMETRÓW

Top 5 danych do odfiltrowania na serwerze

Ranking według tego, jak często dany wyciek się zdarza i jak poważne jest ryzyko przy przekazaniu w postaci jawnej.

1

- Jawny adres e-mail

Nigdy nie wysyłaj w postaci czytelnej. Do dopasowania konwersji przekaż wyłącznie skrót SHA-256 wyliczony na serwerze.

2

- Pełny adres IP

Skróć lub anonimizuj. Pełne IP to dana osobowa i rzadko jest potrzebne platformie w całości.

3

- Numer telefonu

Ten sam reżim co e-mail: hasz zamiast wartości jawnej, nigdy w query stringu.

4

- Precyzyjna geolokalizacja

Dokładne współrzędne rzadko są potrzebne. Ogranicz do poziomu miasta lub regionu.

5

- Identyfikatory w URL

ID zamówienia z danymi klienta, tokeny sesji, imię i nazwisko w parametrach - wytnij przed wysyłką.

Zwróć uwagę, że filtrowanie nie oznacza rezygnacji z dopasowania. Dla mechanizmu tagowania po stronie serwera kluczowe jest to, że dane wrażliwe haszujesz zanim opuszczą serwer - platforma dostaje skrót, który potrafi dopasować, ale którego nie odczyta jako wartości jawnej.

Kto jest administratorem, a kto podmiotem przetwarzającym?

W typowym wdrożeniu server-side tagging administratorem danych jest właściciel strony lub sklepu, który decyduje o celach i sposobach przetwarzania. Dostawcy - Google, dostawca hostingu kontenera serwerowego - działają jako podmioty przetwarzające, wykonujące operacje na zlecenie administratora.

Ta klasyfikacja nie jest formalnością. Wyznacza, kto odpowiada za co i jakie umowy muszą istnieć. Jako administrator odpowiadasz za podstawę prawną, zakres i informowanie użytkowników. Jako że korzystasz z podmiotów przetwarzających, potrzebujesz z każdym z nich umowy powierzenia przetwarzania danych (DPA).

W kontekście kontenera serwerowego dochodzi jeden niuans, który łatwo przeoczyć: hosting. Gdy stawiasz kontener na własnej infrastrukturze albo u zewnętrznego dostawcy, ten dostawca też jest podmiotem przetwarzającym - i też wymaga umowy powierzenia oraz weryfikacji, gdzie fizycznie leżą dane.

• Administrator (właściciel strony): ustala cele, podstawę prawną, zakres danych; odpowiada wobec organu nadzorczego i użytkownika.
• Podmiot przetwarzający (Google): przetwarza dane na potrzeby usług reklamowych i analitycznych w ramach warunków i DPA.
• Podmiot przetwarzający (hosting kontenera): udostępnia infrastrukturę serwerową; wymaga osobnej umowy powierzenia i deklaracji regionu przetwarzania.
• Użytkownik (podmiot danych): ma prawo do informacji, sprzeciwu, dostępu i usunięcia - a serwer musi te prawa realnie umożliwiać.

Region serwera w UE a transfer danych poza EOG

Region, w którym fizycznie działa kontener serwerowy, ma bezpośrednie znaczenie dla RODO, bo decyduje o tym, czy dane osobowe są przetwarzane w Europejskim Obszarze Gospodarczym, czy transferowane poza niego. Wybór regionu UE upraszcza kwestię transferu i ogranicza ryzyko związane z przekazywaniem danych do państw trzecich.

W praktyce oznacza to konkretną decyzję konfiguracyjną. Jeśli hostujesz kontener na Google Cloud, wybierasz region europejski (np. europe-central2 czy europe-west). Jeśli korzystasz z zewnętrznego dostawcy, upewniasz się, że oferuje przetwarzanie w UE - dobre platformy hostingu sGTM mają taką opcję wprost. Rekomenduję traktować region UE jako ustawienie domyślne, a nie opcję do rozważenia.

Trzeba jednak rozróżnić dwie rzeczy. Region serwera decyduje o tym, gdzie dane są przetwarzane po drodze. Nie zmienia jednak faktu, że finalny odbiorca - platforma reklamowa - może przetwarzać dane globalnie. To interpretacja, którą podkreślam w każdym audycie: własny kontener w UE zawęża ekspozycję, ale nie sprawia, że dane przekazane do Google nigdy nie opuszczą Europy.

Czy server-side tagging zwalnia z obowiązku zgody?

Nie - server-side tagging nie zwalnia z obowiązku zgody. Przeniesienie tagów na serwer zmienia miejsce przetwarzania, ale nie tworzy nowej podstawy prawnej. Jeśli cel wymaga zgody (marketing, analityka reklamowa), serwer nadal nie ma prawa przekazywać danych, dopóki użytkownik jej nie wyrazi.

To najczęstsze i najgroźniejsze nieporozumienie, jakie spotykam. Logika bywa taka: „skoro dane idą przez nasz serwer, a nie bezpośrednio do Google, to zbieramy je my, więc nie potrzebujemy zgody na piksele”. Jestem przekonany, że to błędne rozumowanie - i potencjalnie kosztowne. Cel przetwarzania nie znika dlatego, że zmieniłeś trasę danych. Jeśli ostatecznie zasilasz nimi kampanie reklamowe, potrzebujesz zgody na ten cel.

Rolę technicznego nośnika sygnału zgody między stroną a kontenerem pełni Consent Mode. To on przekazuje do serwera informację, czy użytkownik zgodził się na dany cel, i na tej podstawie tag decyduje, czy w ogóle zadziałać. Nie rozwijam tu jego mechaniki - architekturę zgody, tryby basic i advanced oraz modelowanie konwersji opisuję szczegółowo w tekście o Consent Mode v2. W kontekście RODO wystarczy zapamiętać jedną zasadę:

• Brak zgody = brak wysyłki: serwer respektuje sygnał zgody i nie przekazuje danych do platform, jeśli użytkownik nie wyraził zgody na dany cel.
• Zgoda przed zdarzeniem: sygnał musi dotrzeć do kontenera zanim tag się odpali, nie po fakcie.
• Serwer jako egzekutor, nie źródło zgody: zgodę zbiera CMP na stronie, a kontener serwerowy jedynie ją egzekwuje na poziomie transferu.

Najczęstsze błędy RODO w konfiguracji sGTM

Najczęstsze błędy RODO w konfiguracji server-side GTM to przekazywanie danych mimo braku zgody, wysyłanie parametrów z danymi osobowymi w postaci jawnej oraz błędne założenie, że sam serwer załatwia zgodność. Wszystkie trzy wynikają z tego samego źródła - mylenia kontroli z legalnością.

Przy przeglądzie kontenera serwerowego warto zacząć od krótkiej listy obszarów sprawdzanych w pierwszej kolejności. Poniższa ocena pokazuje, jak zwykle wypada świeże, „domyślne” wdrożenie, zanim ktokolwiek dotknie reguł filtrowania i zgody.

RODO READINESS

Ocena typowej, domyślnej konfiguracji sGTM

Skala A-F według tego, jak obszar wygląda w świeżym wdrożeniu, zanim wprowadzisz reguły minimalizacji i egzekwowania zgody.

A

Potencjał kontroli nad danymi

Architektura daje pełną możliwość decydowania, co opuszcza serwer - to najmocniejsza strona modelu.

B

Region i hosting w UE

Łatwe do ustawienia poprawnie, ale w domyślnych wdrożeniach region bywa dobrany przypadkowo.

C

Minimalizacja parametrów

Domyślnie tag przekazuje sporo nadmiarowych danych - wymaga świadomej konfiguracji reguł.

F

Powiązanie ze zgodą użytkownika

Najczęściej pomijane lub błędnie wdrożone - serwer wysyła dane niezależnie od decyzji użytkownika.

Jeśli rozpoznajesz u siebie ocenę F w powiązaniu ze zgodą, to nie wyjątek - to reguła w kontenerach, które trafiają do mnie na audyt. Dobra wiadomość jest taka, że każdy z tych obszarów da się podnieść do oceny bezpiecznej, jeśli podejdzie się do konfiguracji świadomie, a nie „z pudełka”.

Server-side tagging a RODO - mocne i słabe strony

Server-side tagging daje w kontekście RODO realną przewagę kontroli, ale przenosi też odpowiedzialność za dane na administratora. To bilans: zyskujesz narzędzie do egzekwowania minimalizacji, a w zamian bierzesz na siebie decyzję o każdym parametrze, który opuszcza serwer.

Poniższa analiza porządkuje ten bilans w cztery pola, które pomagają ocenić, czy i jak model pasuje do Twojej sytuacji. Traktuję ją jako punkt wyjścia do rozmowy, nie jako wyrok - u różnych organizacji te same czynniki ważą inaczej.

ANALIZA SWOT

Server-side tagging w świetle RODO

Cztery pola pokazujące, gdzie model pomaga w zgodności, a gdzie tworzy nowe obowiązki i ryzyka.

SMocne strony

• +Pełna kontrola nad tym, co opuszcza serwer.
• +Filtrowanie i haszowanie PII w jednym punkcie.
• +Mniej skryptów third-party w przeglądarce.

WSłabe strony

• −Odpowiedzialność za każdy tag spada na administratora.
• −Łatwo przeoczyć parametr wyciekający dane.
• −Wymaga kompetencji technicznych i regularnego audytu.

OSzanse

• ↗Trwalszy pomiar first-party bez third-party cookies.
• ↗Audytowalność i łatwiejsza rozliczalność.
• ↗Budowanie zaufania jako przewaga rynkowa.

TZagrożenia

• ⚠Złudne poczucie zgodności bez pozyskanej zgody.
• ⚠Transfer danych poza EOG przy złym wyborze regionu.
• ⚠Wyciek przez własne, źle skonfigurowane tagi.

Jeśli rozpoznajesz w tych zagrożeniach swoją sytuację - a szczególnie w pierwszym punkcie - to dokładnie ten wzorzec, który weryfikuję na początku każdego audytu pomiaru. Kontrola bez zgody nie jest zgodnością, tylko dobrze udokumentowanym ryzykiem.

Podsumowanie

Przestań traktować server-side tagging jak prawną tarczę. Zacznij postrzegać go jako narzędzie kontroli, które działa tak dobrze, jak dobrze je skonfigurujesz. Serwer daje Ci coś, czego model client-side dać nie może - jeden punkt, w którym decydujesz, jakie dane osobowe opuszczają Twoją infrastrukturę i w jakiej formie. To ogromna wartość dla zgodności z RODO, pod jednym warunkiem: że tę kontrolę faktycznie wykorzystasz.

Zgodność rodzi się z trzech decyzji, nie z samego przeniesienia tagów na serwer. Po pierwsze - zbieraj zgodę i respektuj ją na poziomie transferu. Po drugie - minimalizuj, czyli filtruj i haszuj dane, których platforma nie potrzebuje w postaci jawnej. Po trzecie - kontroluj region i umowy powierzenia, żeby wiedzieć, gdzie i przez kogo dane są przetwarzane. Kontener serwerowy ułatwia każdą z tych rzeczy, ale żadnej nie robi za Ciebie.

Moja rekomendacja po latach audytów jest prosta: potraktuj wdrożenie server-side jako okazję do uporządkowania pomiaru pod kątem prywatności, a nie do zamiecenia tematu pod dywan. Jeśli chcesz sprawdzić, jakie dane naprawdę wychodzą dziś z Twojego kontenera, zacznij od zmapowania każdego parametru i jego celu - to pierwszy krok, który i tak wykonuję na starcie każdego audytu pomiaru.

Na czym opieram te wnioski

Źródła i dokumentacja

Cztery źródła, które stoją za tezami tego tekstu: dokumentacja transformacji w kontenerze serwerowym, pomiar wycieku danych ze sklepów internetowych, wskazówki o rolach administratora i procesora oraz wykładnia tego, kiedy dochodzi do transferu danych poza EOG.

developers.google.com

Transformacje parametrów w kontenerze serwerowym

Dokumentacja opisuje trzy typy transformacji w sGTM: Allow Parameters przepuszcza wyłącznie jawnie wskazane parametry, Exclude Parameters usuwa wybrane pola, a Augment Event zmienia lub dodaje wartości, przy czym regułę można nałożyć na wszystkie tagi, na typ tagu albo na pojedynczy tag. Techniczna podstawa sekcji o tym, na czym polega minimalizacja danych w kontenerze serwerowym.

Google for Developers Otwórz

arxiv.org

Wyciek danych klientów w sklepach internetowych

Półautomatyczny pomiar popularnych sklepów internetowych wykazał, że blisko 30 procent z nich ujawnia dane osobowe podmiotom trzecim, a minimalna interakcja użytkownika wystarcza do zbudowania profilu i powiązania go z kontem w serwisie społecznościowym. Dowód pod sekcję o tym, które dane osobowe filtrować po stronie serwera.

arXiv Otwórz

deloitte.com

Cookies i technologie śledzące pod RODO

Deloitte wskazuje, że organizacja ma zbadać rolę każdego podmiotu trzeciego korzystającego z cookies i podobnych technologii, aby ustalić współadministrowanie lub inną relację przetwarzania, i zawrzeć z nim właściwą umowę powierzenia. Punkt odniesienia dla sekcji o tym, kto jest administratorem, a kto podmiotem przetwarzającym.

Deloitte Otwórz

deloitte.com

Kiedy przekazanie danych jest transferem

Opracowanie rozkłada wytyczne Europejskiej Rady Ochrony Danych na trzy przesłanki, które muszą wystąpić łącznie, żeby mówić o przekazaniu danych poza EOG, i przypomina o mechanizmach z rozdziału V RODO, w tym standardowych klauzulach umownych. Podstawa prawna sekcji o regionie serwera w UE i transferze danych poza EOG.

Deloitte Otwórz

Najczęściej zadawane pytania

Pytania i odpowiedzi (FAQ)

Zgodność tagowania serwerowego z RODO, obowiązek zgody i dane do filtrowania w kontenerze.

01Czy potrzebna jest umowa powierzenia z dostawcą hostingu kontenera?

Tak - dostawca przetwarza dane w Twoim imieniu, więc jest podmiotem przetwarzającym. Potrzebna jest umowa powierzenia i informacja o nim w rejestrze czynności. Dotyczy to zarówno hostowanych rozwiązań, jak i chmury publicznej, w której stawiasz kontener samodzielnie.

02Czy muszę zbierać zgodę, skoro tagi działają na serwerze?

Tak. Przeniesienie tagów na serwer nie tworzy nowej podstawy prawnej. Jeśli cel wymaga zgody, na przykład marketing i analityka reklamowa, serwer nie ma prawa przekazywać danych bez niej. Sygnał zgody przekazuje do kontenera Consent Mode, a serwer go jedynie egzekwuje.

03Czy adres IP użytkownika trzeba anonimizować na serwerze?

Adres IP jest daną osobową, więc jego przekazywanie wymaga podstawy prawnej. Kontener serwerowy pozwala obciąć lub zastąpić IP, zanim dane opuszczą Twoją infrastrukturę - i to jedna z jego realnych przewag. Część narzędzi robi to domyślnie, ale warto to zweryfikować, a nie zakładać.

04Czy hosting kontenera serwerowego w USA łamie RODO?

Nie automatycznie, ale komplikuje sprawę i podnosi ryzyko związane z transferem danych poza EOG. Dlatego rekomenduję hosting kontenera w regionie UE jako ustawienie domyślne. Region serwera decyduje o tym, gdzie dane są przetwarzane po drodze, choć nie zmienia zasad przetwarzania po stronie finalnej platformy.

05Czy mały sklep naprawdę potrzebuje filtrowania danych na serwerze?

Tak, bo RODO nie zależy od wielkości sklepu, tylko od tego, czy przetwarzasz dane osobowe. Nawet mały sklep wysyła e-maile i adresy IP. Dobra wiadomość: reguły filtrowania w kontenerze serwerowym ustawia się raz, a potem działają dla całego ruchu, niezależnie od skali.

06Kto odpowiada za naruszenie RODO przy server-side tagging?

Jako właściciel strony jesteś zwykle administratorem danych i to Ty odpowiadasz za cel, zakres i podstawę prawną. Google i dostawca hostingu działają jako podmioty przetwarzające na Twoje zlecenie. Dlatego potrzebujesz z każdym z nich umowy powierzenia i musisz kontrolować, co dokładnie wysyłasz.

---