Bezpieczeństwo danych w server-side GTM: kontrola i filtrowanie parametrów
Bezpieczeństwo danych w server-side GTM to zestaw praktyk i mechanizmów, które kontrolują, jakie dane wchodzą do kontenera serwerowego, jak są w nim przetwarzane i co ostatecznie opuszcza serwer w drodze do Google Ads, GA4 czy Meta. W modelu tagowania po stronie serwera to administrator - a nie przeglądarka użytkownika - decyduje, które parametry (w tym dane osobowe, czyli PII) zostają odfiltrowane, zanonimizowane lub zahaszowane przed wysyłką. Bezpieczeństwo obejmuje trzy warstwy: kontrolę danych wychodzących z serwera, uprawnienia do samego kontenera oraz zabezpieczenie infrastruktury hostingu.
- Na czym polega bezpieczeństwo danych w server-side GTM?
- Dlaczego kontener serwerowy daje większą kontrolę niż tagowanie client-side?
- Jak filtrować parametry i dane PII, zanim opuszczą serwer?
- Jakie dane najczęściej wyciekają przez własne tagi?
- Jak zarządzać uprawnieniami do kontenera serwerowego?
- Jak Consent Mode wpływa na to, co serwer może wysłać?
- Czego server-side tagging NIE zabezpiecza?
- Dobre praktyki bezpieczeństwa w sGTM: od czego zacząć
- Podsumowanie
- Źródła i dokumentacja
Kiedy pierwszy raz otwierasz podgląd żądania w kontenerze serwerowym, widzisz coś, czego przeglądarka klienta nigdy Ci nie pokaże: pełną listę parametrów, które Twoja strona wysyła w świat. Adresy e-mail. Numery telefonów w parametrach URL. Identyfikatory zamówień powiązane z danymi klienta. Przez lata audytowania konfiguracji pomiaru pod kampanie Google Ads nauczyłem się jednej rzeczy - większość wycieków danych nie bierze się ze złośliwych ataków, tylko z tagów, które ktoś kiedyś wkleił i o których wszyscy zapomnieli. Kontener serwerowy to jedyne miejsce, w którym możesz ten strumień zobaczyć i realnie nim sterować.
Wnioski, które decydują o tym, jakie dane realnie opuszczają Twój kontener serwerowy.
-
Kontener serwerowy sGTM jest jedynym miejscem, w którym widzisz każdy parametr przed wysyłką
W modelu client-side tag odpala się w przeglądarce i wysyła dane bezpośrednio do platformy, poza Twoją kontrolą. Kontener serwerowy przechwytuje to żądanie, pokazuje pełny payload w trybie Preview i pozwala zmienić lub wyciąć dowolne pole.
-
Surowy adres e-mail potrafi wyciekać do GA4 przez zapomniane tagi w kontenerze serwerowym
Przykład ilustracyjny (liczby poglądowe): wśród 13 kontenerów serwerowych cztery przekazują pełny adres e-mail w parametrze zdarzenia, a jeden numer telefonu w adresie URL. Żaden z właścicieli o tym nie wie - winne były zapomniane tagi.
-
Allowlista parametrów chroni lepiej niż lista zakazanych pól w tagu serwerowym
Przy liście zakazanych pól każdy nowo dodany parametr domyślnie opuszcza serwer i nikt tego nie zauważa. Allowlista odwraca domyślną odpowiedź: tag wysyła wyłącznie pola wpisane jawnie, a wszystko inne zostaje w kontenerze.
-
Haszowanie SHA-256 na serwerze trzyma surowy e-mail poza kodem przeglądarki
Skrypt haszujący w przeglądarce ma surową wartość w zasięgu każdego, kto otworzy narzędzia deweloperskie. Ta sama operacja w kontenerze serwerowym odbywa się w zamkniętym środowisku, więc do Google Ads trafia wyłącznie skrót potrzebny do dopasowania konwersji.
-
Google wymaga Consent Mode v2 od marca 2024 dla ruchu z EOG
Zgodnie z dokumentacją Google sygnał zgody dociera do kontenera serwerowego razem ze zdarzeniem i decyduje, czy tag wyśle pełne dane, dane ograniczone, czy tylko sygnał modelowany. Filtrowanie parametrów działa dopiero po tym warunku (stan na 2026 rok).
-
Piksele client-side działające obok kontenera wysyłają dane całkowicie poza jego kontrolą
Przeniesienie części tagów na serwer nie czyści reszty stosu pomiarowego. Stary piksel wciąż osadzony w szablonie strony nadal wysyła surowe dane bezpośrednio do platformy, a kontener serwerowy nawet o tym żądaniu nie wie.
Na czym polega bezpieczeństwo danych w server-side GTM?
Bezpieczeństwo danych w server-side GTM polega na kontrolowaniu trzech rzeczy naraz: co wchodzi do kontenera serwerowego, kto ma do niego dostęp i co z niego wychodzi. To nie jest pojedyncze ustawienie, tylko warstwa architektury, w której serwer działa jak filtr między Twoją stroną a platformami zewnętrznymi. W server-side tagging przeglądarka wysyła zdarzenie do Twojego kontenera, a dopiero kontener - według reguł, które ustawiasz - decyduje, jakie dane trafią do Google Ads, GA4 czy Meta.
Różnica względem klasycznego GTM jest fundamentalna. W modelu client-side każdy tag odpala się w przeglądarce użytkownika i wysyła dane bezpośrednio do zewnętrznego serwera - Ty tego strumienia nie widzisz i nie modyfikujesz. W modelu server-side ten sam strumień przechodzi przez punkt, który kontrolujesz w całości. To przenosi bezpieczeństwo z poziomu „mam nadzieję, że tag wysyła tylko to, co trzeba” na poziom „widzę dokładnie każdy parametr i mogę go zatrzymać”. Kontrola nad pojedynczym parametrem jest zresztą kryterium, którym coraz częściej ocenia się narzędzia marketingowe: liczy się nie to, ile danych zbierają, tylko ile z nich wypuszczają dalej.
Bezpieczeństwo w tym kontekście ma trzy filary, które warto rozdzielić, bo każdy chroni przed czym innym:
- Kontrola danych wychodzących - filtrowanie i haszowanie parametrów, żeby PII nie opuściło serwera w surowej postaci.
- Kontrola dostępu - uprawnienia do kontenera i do konsoli hostingu, żeby nikt niepowołany nie dodał tagu wysyłającego dane w nieznane miejsce.
- Kontrola infrastruktury - region przetwarzania (UE), szyfrowanie transportu (HTTPS/SSL na własnej subdomenie first-party), izolacja środowiska.
Uważam, że to właśnie pierwszy filar jest najbardziej niedoceniany. Firmy inwestują w certyfikaty SSL i skomplikowane hasła, a jednocześnie ich kontener przepuszcza do trzech platform pełny adres e-mail klienta w niezaszyfrowanym parametrze zdarzenia. Takie wycieki wychodzą dopiero przy przeglądzie parametrów, dlatego analityka internetowa obejmuje dziś także kontrolę tego, co wysyłasz, a nie tylko tego, co zbierasz.
Czy wiesz, że…
Polityki Google Ads i Google Analytics zakazują przesyłania surowych danych osobowych do tych usług. Naruszenie tej zasady może skutkować zawieszeniem konta reklamowego - a kontener serwerowy to jedyne miejsce, w którym możesz taki parametr wyciąć, zanim opuści Twoją infrastrukturę.
Dlaczego kontener serwerowy daje większą kontrolę niż tagowanie client-side?
Kontener serwerowy daje większą kontrolę, ponieważ przenosi punkt decyzyjny z przeglądarki użytkownika - której nie kontrolujesz - na serwer, który należy do Ciebie. W tagowaniu client-side każdy skrypt widzi cały kontekst strony: ciasteczka, dataLayer, adres URL z parametrami, dane w formularzach. W server-side tag widzi tylko to, co świadomie mu przekażesz w żądaniu do kontenera.
To odwrócenie logiki. Przez lata pracy z kontami Google Ads wielokrotnie obserwowałem sytuację, w której piksel jednej platformy „podbierał” dane przeznaczone dla innej - bo w przeglądarce wszystkie skrypty siedzą w tym samym środowisku i mają dostęp do tego samego dataLayer. Nazywam to kradnięciem pikseli. Na serwerze to znika, bo każdy tag dostaje wyłącznie ten wycinek danych, który mu przypiszesz.
Warto zestawić, co realnie zyskujesz w zakresie kontroli nad danymi, przechodząc z modelu przeglądarkowego na serwerowy:
Które mechanizmy bezpieczeństwa danych masz realnie do dyspozycji w każdym modelu. ✓ pełna kontrola, ~ ograniczona, ✗ brak.
To dokładnie sytuacja, którą sprawdzam podczas audytu pomiaru - jeśli chcesz zobaczyć, ile parametrów Twoja strona wysyła dziś bez Twojej wiedzy, zacznij od podglądu żądań w trybie Preview kontenera. Jestem przekonany, że dla większości sklepów będzie to niespodzianka.
Jak filtrować parametry i dane PII, zanim opuszczą serwer?
Parametry filtruje się na serwerze przez modyfikację danych zdarzenia w tagu lub w zmiennej, zanim tag wyśle żądanie do platformy docelowej. W praktyce oznacza to trzy operacje: usunięcie pola, którego nie chcesz przekazywać (np. pełny e-mail), zamianę wartości na jej skrót kryptograficzny (haszowanie SHA-256 dla dopasowań) albo skrócenie danych do postaci nieidentyfikującej (np. tylko domena zamiast pełnego adresu). To rdzeń minimalizacji danych w modelu serwerowym.
Kolejność ma znaczenie. Filtr zawsze zakładasz na wylocie - między danymi, które dotarły do kontenera, a momentem, w którym tag je wysyła. Rekomenduję podejście, w którym każdy tag ma jawnie zdefiniowaną listę parametrów dozwolonych (allowlist), a nie listę zabronionych. Allowlist jest bezpieczniejsza, bo nowy, przypadkowo dodany parametr domyślnie nie wychodzi, zamiast domyślnie wychodzić.
Typowy payload żądania e-commerce, który trafia do kontenera serwerowego, składa się z bardzo różnych typów danych - i tylko część z nich powinna kiedykolwiek opuścić serwer w surowej formie:
Orientacyjny rozkład typów pól w żądaniu zdarzenia purchase ze sklepu, na przykładzie typowej konfiguracji. Proporcje ilustracyjne - klucz jest w tym, że warstwa PII wymaga świadomej decyzji o filtrowaniu.
Praktyczne reguły filtrowania, które stosuję w pracy z moimi klientami przy konfiguracji kontenera serwerowego:
- Usuwaj pełny URL z tokenami - linki do potwierdzenia zamówienia czy resetu hasła często zawierają dane, które w parametrze
page_locationlądują w GA4. Skracaj URL do ścieżki bez query stringa albo czyść wrażliwe parametry. - Haszuj dane do dopasowań (SHA-256) - jeśli przekazujesz e-mail dla konwersji rozszerzonych, zahaszuj go w kontenerze, a nie w przeglądarce. Surowy adres nigdy nie powinien opuścić serwera.
- Blokuj parametry PII po stronie tagu GA4 - Google Analytics odrzuca zdarzenia z wykrytym PII, ale lepiej odfiltrować je samodzielnie, niż liczyć na automat.
- Maskuj adres IP - w kontenerze możesz przekazywać IP w formie zredukowanej lub w ogóle go nie wysyłać do platform, które go nie potrzebują.
- Waliduj każdy nowy tag - przed publikacją sprawdź w trybie Preview, jaki payload realnie wychodzi. Nowy tag to nowy potencjalny kanał wycieku.
Czy wiesz, że…
Haszowanie danych po stronie serwera jest bezpieczniejsze niż w przeglądarce, bo surowa wartość nigdy nie trafia do kodu widocznego dla użytkownika. W tagowaniu client-side skrypt haszujący e-mail siedzi w przeglądarce, gdzie każdy może go podejrzeć - na serwerze operacja odbywa się w zamkniętym środowisku, które kontrolujesz.
Jakie dane najczęściej wyciekają przez własne tagi?
Najczęstsze wycieki nie pochodzą z zewnątrz - powodują je tagi, które sam wdrożyłeś. Kontener serwerowy zwiększa kontrolę, ale też koncentruje odpowiedzialność: jeśli źle skonfigurujesz tag, wyślesz dane sprawnie i skutecznie w niewłaściwe miejsce. W praktyce powtarza się kilka wzorców wycieku, i prawie zawsze są to błędy konfiguracji, nie luki w oprogramowaniu.
W przykładzie ilustracyjnym (liczby poglądowe) na 13 kontenerach serwerowych 4 wysyłają do GA4 pełny adres e-mail w parametrze zdarzenia, a w jednym przypadku numer telefonu klienta przechodzi w parametrze URL do trzech platform naraz. Żaden z tych właścicieli nie wie, że to się dzieje - dane po prostu „przeciekają” przez tag, który ktoś skonfigurował dawno temu.
W przykładzie (liczby poglądowe) w blisko jednej trzeciej kontenerów jakiś parametr z danymi osobowymi opuszcza serwer w surowej postaci. Zwykle nie jest to działanie celowe - to zapomniane tagi i skopiowane szablony. Dlatego regularny podgląd payloadu to nie luksus, tylko higiena.
Katalog danych, które najczęściej wyciekają przez błędnie skonfigurowane tagi:
- Adres e-mail w surowej postaci - najczęstszy przypadek, zwykle w parametrze zdarzenia purchase lub w formularzu kontaktowym.
- Numer telefonu w parametrze URL - trafia do
page_location, gdy formularz przekazuje dane w query stringu. - Pełny URL z tokenem sesji - linki potwierdzające, które w parametrze strony niosą dane umożliwiające przejęcie sesji.
- Dane z pól formularza - imię, nazwisko, adres, przypadkowo wpięte do dataLayer i przekazane dalej.
- Wewnętrzne identyfikatory klienta - ID z CRM, które połączone z innym źródłem pozwala zdeanonimizować użytkownika.
Jeśli rozpoznajesz któryś z tych wzorców w swoich kampaniach, to znak, że warto zajrzeć do kontenera, zanim zrobi to ktoś inny. To pierwszy element, który sprawdzam w audycie pomiaru.
Żeby uporządkować, na czym skupić uwagę w pierwszej kolejności, warto rozłożyć ryzyka na dwie osi - prawdopodobieństwo wystąpienia i wpływ na firmę, gdy się zmaterializują:
Oś pionowa - jak często dane ryzyko realnie się materializuje. Oś pozioma - jak dotkliwe są skutki. Zaczynaj od pola prawego górnego.
Jak zarządzać uprawnieniami do kontenera serwerowego?
Uprawnieniami zarządzasz na dwóch poziomach: dostępu do samego kontenera GTM oraz dostępu do konsoli hostingu, na której serwer działa. Zasada jest jedna - najmniejszy potrzebny zakres. Osoba, która ma tylko publikować tagi, nie potrzebuje uprawnień administratora do konta Google Cloud, a zewnętrzny specjalista nie powinien mieć trwałego dostępu do produkcji po zakończeniu wdrożenia.
W kontenerze serwerowym GTM masz te same role co w wersji przeglądarkowej: odczyt, edycja, zatwierdzanie, publikacja. To za mało doceniana warstwa. Wielokrotnie widziałem konta, gdzie pięć osób miało prawo publikacji, choć realnie wdrażała jedna. Każde konto z prawem publikacji to potencjalny wektor - jeśli ktoś przejmie takie konto, może dodać tag wysyłający dane, gdzie zechce.
Praktyki, które porządkują dostęp do kontenera:
- Rozdziel edycję od publikacji - większość osób powinna móc przygotować zmianę, ale publikować niech może wąskie grono.
- Używaj kont imiennych, nie współdzielonych - wspólny login uniemożliwia ustalenie, kto dodał podejrzany tag.
- Rewiduj dostęp cyklicznie - po każdym zakończonym projekcie odbieraj uprawnienia współpracownikom zewnętrznym.
- Ogranicz uprawnienia do hostingu - dostęp do konsoli Google Cloud czy panelu stape.io to osobna, mocniejsza warstwa niż sam GTM.
- Włącz uwierzytelnianie dwuskładnikowe - na kontach Google powiązanych z kontenerem i hostingiem, bez wyjątków.
Czy wiesz, że…
Kontener serwerowy hostowany w regionie UE pomaga spełnić wymóg przetwarzania danych na terenie Europy, ale region hostingu to nie to samo co region odbiorcy danych. Jeśli tag wysyła dane do platformy przetwarzającej je poza UE, sama europejska lokalizacja serwera problemu transferu nie rozwiązuje.
Jak Consent Mode wpływa na to, co serwer może wysłać?
Consent Mode decyduje o tym, czy serwer w ogóle ma prawo przekazać dane pomiarowe dalej - działa jako warunek wstępny, zanim jakikolwiek filtr parametrów wejdzie do gry. Sygnał zgody z platformy CMP trafia do kontenera serwerowego razem ze zdarzeniem, a tag odczytuje ten sygnał i na jego podstawie ustala, czy wysłać pełne dane, dane ograniczone, czy tylko sygnał modelowany.
To ważne rozróżnienie, które często się myli. Filtrowanie parametrów odpowiada na pytanie „jakie dane wolno wysłać”, a Consent Mode na pytanie „czy w ogóle wolno je wysłać”. Bezpieczna architektura potrzebuje obu warstw naraz - zgody użytkownika i minimalizacji danych. Sam mechanizm zgody, jego tryby basic i advanced oraz modelowanie konwersji opisuję szczegółowo w osobnym materiale o Consent Mode v2 - tutaj zależy mi tylko na tym, żeby pokazać, gdzie ta warstwa spina się z bezpieczeństwem serwera.
W kontenerze serwerowym możesz uzależnić działanie tagu od sygnału zgody na kilka sposobów:
- Warunek na wyzwalaczu - tag odpala się tylko, gdy zdarzenie niesie zgodę na dany cel (analityka, reklama).
- Redukcja danych bez zgody - przy braku zgody wysyłasz jedynie bezcookie’owy sygnał modelowany, bez identyfikatorów.
- Serwer jako punkt egzekwowania - kontener staje się miejscem, w którym reguła zgody jest wymuszana centralnie, a nie rozproszona po dziesiątkach tagów w przeglądarce.
Czego server-side tagging NIE zabezpiecza?
Server-side tagging nie zabezpiecza tego, co dzieje się w przeglądarce przed dotarciem danych do kontenera - i to jest granica, której nie wolno pomijać. Jeśli Twoja strona ładuje piksele bezpośrednio w przeglądarce obok kontenera serwerowego, te piksele nadal wysyłają dane po staremu, a serwer nie ma nad nimi żadnej kontroli. Przeniesienie części tagów na serwer nie czyści automatycznie reszty stosu.
Kiedyś sądziłem, że samo wdrożenie kontenera serwerowego „domyka” temat bezpieczeństwa danych. Zmieniłem zdanie, gdy zobaczyłem konfigurację, w której serwer był wzorowo skonfigurowany, a równolegle w przeglądarce działały trzy stare piksele wysyłające surowe dane. Serwer robił swoje, a wyciek i tak następował obok niego. To była moja hipoteza, którą dane szybko zweryfikowały.
Obszary, których model serwerowy sam z siebie nie rozwiązuje:
- Zgoda użytkownika - server-side tagging nie zwalnia z obowiązku pozyskania zgody; o to dba warstwa CMP i Consent Mode.
- Piksele client-side działające obok - jeśli nie usuniesz starych tagów z przeglądarki, nadal wysyłają dane poza kontrolą serwera.
- Bezpieczeństwo samej strony - podatności front-endu, wstrzyknięcia skryptów czy przejęte wtyczki to osobny temat, niezależny od kontenera.
- Decyzje o zakresie danych - serwer daje narzędzie, ale to Ty ustawiasz, co filtrować; źle skonfigurowany filtr nie chroni niczego.
Dlatego jestem przekonany, że o server-side tagging trzeba myśleć jak o mocnym narzędziu, a nie gotowym rozwiązaniu. Sam kontener niczego nie gwarantuje - gwarantuje to sposób, w jaki go skonfigurujesz i utrzymasz.
Dobre praktyki bezpieczeństwa w sGTM: od czego zacząć
Bezpieczeństwo kontenera serwerowego zaczyna się od jednej czynności: regularnego podglądu tego, co realnie z niego wychodzi. Zanim wdrożysz zaawansowane reguły, otwórz tryb Preview i zobacz payload żądań dla kluczowych zdarzeń - konwersji, dodania do koszyka, wysłania formularza. Dopiero wtedy wiesz, co filtrować.
Kolejność wdrażania, którą rekomenduję w pracy z moimi klientami Google Ads, gdy porządkujemy bezpieczeństwo pomiaru:
- Audyt payloadu - przejrzyj żądania w Preview i wypisz każdy parametr niosący dane osobowe.
- Filtrowanie i haszowanie - odfiltruj surowe PII, zahaszuj dane potrzebne do dopasowań konwersji.
- Allowlista parametrów - zdefiniuj jawnie, co każdy tag może wysłać, i domyślnie blokuj resztę.
- Porządek uprawnień - ogranicz prawo publikacji, włącz uwierzytelnianie dwuskładnikowe, usuń martwe konta.
- Region i transport - upewnij się, że hosting działa w UE, a transport idzie po HTTPS na własnej subdomenie first-party.
- Cykliczny przegląd - wpisz przegląd tagów i uprawnień w stały rytm, nie rób go raz przy wdrożeniu.
To dokładnie ten zestaw czynności, który przechodzę podczas audytu konfiguracji pomiaru. Jeśli nie masz pewności, co dziś wysyła Twój kontener, warto zacząć od zewnętrznego spojrzenia - jedna sesja podglądu żądań potrafi ujawnić więcej niż miesiąc domysłów.
Podsumowanie
Server-side tagging przenosi bezpieczeństwo danych z obszaru nadziei do obszaru kontroli. W modelu client-side zdajesz się na to, że każdy tag zachowa się poprawnie. W modelu serwerowym widzisz każdy parametr i decydujesz o jego losie - to jakościowa zmiana, ale też przeniesienie odpowiedzialności na Twoją stronę. Kontener serwerowy jest bramą celną: skuteczną tylko wtedy, gdy ktoś realnie kontroluje, co przez nią przechodzi.
Przestań traktować kontener serwerowy jak samą infrastrukturę techniczną. Zacznij postrzegać go jako punkt egzekwowania trzech reguł naraz - minimalizacji danych, kontroli dostępu i zgodności zgody. Trzy warstwy: filtrowanie parametrów na wylocie, uporządkowane uprawnienia i przetwarzanie w UE. Jeśli poukładasz te trzy elementy, kontener przestaje być ryzykiem, a staje się Twoją najmocniejszą linią obrony nad danymi pod kampanie Google Ads.
Zacznij od najprostszego kroku, który nic nie kosztuje: otwórz tryb Preview i zobacz, co Twój kontener wysyła w tej chwili. Reszta to już kwestia świadomych decyzji, a nie przypadku.
Czy ten artykuł był dla Ciebie pomocny?
Oceń go w skali od 1 do 5. Dzięki temu wiem, które tematy rozwijać.
Brak ocen. Twoja będzie pierwsza.
Źródła i dokumentacja
Bezpieczeństwo kontenera serwerowego to trzy osobne warstwy: polityka platformy wobec danych osobowych, role w narzędziu i sygnał zgody. Poniżej dokumentacja i badanie pomiarowe, na których opieram konkretne zalecenia z tego artykułu.
Dane osobowe w adresach URL
Oficjalna polityka Google wobec PII trafiającego do tagów: formularze wysyłane metodą GET, adresy e-mail w parametrach kampanii i w ścieżkach stron, a w konsekwencji wyłączenie segmentów danych do czasu naprawy. Podstawa sekcji o filtrowaniu parametrów, zanim opuszczą serwer, i katalogu danych, których nigdy nie wypuszczasz w surowej postaci.
Konfiguracja tagów a zbieranie danych z formularzy
Pomiar na 40 150 witrynach: tag Google jest obecny na 72,6 procent stron, ale skonfigurowany do zbierania danych z formularzy na 11,6 procent, podczas gdy u Meta jest to 28,2 procent obecności i aż 62,3 procent takiej konfiguracji. Twarde tło dla sekcji o tym, jakie dane najczęściej wyciekają przez własne tagi, i dla ostrzeżenia, że haszowanie nie jest samo w sobie ochroną prywatności.
Zarządzanie użytkownikami i uprawnieniami w GTM
Dokumentacja rozpisuje dwa poziomy uprawnień konta oraz pięć poziomów dostępu do kontenera: brak dostępu, odczyt, edycja, zatwierdzanie i publikacja, wraz z zaleceniem utrzymania co najmniej dwóch administratorów. Punkt odniesienia dla sekcji o zarządzaniu uprawnieniami, zwłaszcza dla rady, by rozdzielić edycję od publikacji.
Nowe sterowanie transmisją danych w Google Ads
Relacja ze stycznia 2026 o funkcji Data Transmission Control, która nakłada się na Advanced Consent Mode i pozwala osobno ograniczyć dane reklamowe, analitykę behawioralną i dane diagnostyczne, a przy braku zgody na ad_storage wybrać między wysyłką z wyciętymi identyfikatorami a całkowitą blokadą. Rozwinięcie sekcji o wpływie Consent Mode na to, co serwer może wysłać.
Pytania i odpowiedzi (FAQ)
Bezpieczeństwo danych w kontenerze serwerowym: filtrowanie parametrów i wystarczalność lokalizacji w Unii Europejskiej.
Czy logi kontenera serwerowego zawierają dane osobowe?
Na czym polega filtrowanie parametrów w kontenerze serwerowym?
Czy kontener serwerowy w UE wystarczy do zgodności z RODO?
Mam mały sklep - czy bezpieczeństwo sGTM w ogóle mnie dotyczy?
Czym różni się kontrola danych na serwerze od zgody użytkownika?
Jak sprawdzić, czy kontener serwerowy wysyła zbędne dane?
