Jak działa server-side GTM: architektura i przepływ danych
Server-side GTM (server-side Google Tag Manager, sGTM) to architektura pomiaru, w której tagi analityczne i marketingowe uruchamiają się nie w przeglądarce użytkownika, lecz w kontenerze serwerowym działającym w chmurze lub na Twoim serwerze. Przeglądarka wysyła jedno żądanie ze zdarzeniem do tego kontenera, a dopiero serwer przetwarza dane i rozsyła je do platform docelowych, takich jak Google Ads, GA4 czy Meta. To przeniesienie logiki tagowania z urządzenia klienta na kontrolowany przez Ciebie punkt pośredni, który sam decyduje, co, komu i w jakiej formie wysłać.
- Z czego składa się architektura server-side GTM?
- Jak wygląda przepływ danych od zdarzenia w przeglądarce do endpointu?
- Czym jest klient (client) w kontenerze serwerowym?
- Na czym polega przejęcie żądania (claim request)?
- Jak tagi po stronie serwera wysyłają dane do platform?
- Czym architektura server-side różni się od client-side?
- Jaką rolę odgrywa własna domena first-party w architekturze?
- Jak Consent Mode i RODO wpisują się w przepływ danych?
- Co potrzebne jest, żeby uruchomić kontener serwerowy?
- Dlaczego przepływ danych bywa błędny i jak to rozpoznać?
- Podsumowanie
- Źródła i dokumentacja
Kiedy po raz pierwszy zaglądasz do konsoli kontenera serwerowego, łatwo pomylić go ze zwykłym GTM. Ten sam interfejs, te same tagi, wyzwalacze i zmienne. A jednak pod maską dzieje się coś zupełnie innego. Zamiast wykonywać się w kilkudziesięciu przeglądarkach naraz, tagi żyją w jednym miejscu, które sam kontrolujesz. Przy wdrożeniach takiego kontenera najtrudniejszy do wytłumaczenia jest zwykle właśnie ten jeden przeskok: dane nie lecą już z przeglądarki prosto do Google, tylko robią przystanek na serwerze. Ten artykuł rozkłada tę architekturę na czynniki pierwsze - element po elemencie, żądanie po żądaniu. Cały mechanizm jest fundamentem server-side tagging, który w moim przewodniku pillarowym opisuję od strony korzyści dla kampanii.
Architektura sGTM, droga pojedynczego zdarzenia i miejsca, w których dane najczęściej się urywają.
-
Kontener serwerowy sGTM wykonuje tagi na serwerze, a przeglądarka wysyła jedno żądanie
W modelu client-side każda platforma dostaje własne żądanie prosto z przeglądarki. W architekturze serwerowej wychodzi jeden strumień, a kontener multiplikuje go do GA4, Google Ads i Meta CAPI, poza zasięgiem wtyczek użytkownika.
-
Żądanie nieprzejęte przez żaden klient sGTM przepada, a kontener zwraca pustą odpowiedź
Kontener odpytuje klientów po kolei i pierwszy pasujący zgłasza claim, przejmując wyłączność na obsługę. Brak takiego klienta oznacza ruch widoczny w logach serwera przy zerowych konwersjach w platformie - stąd biorą się ciche braki danych.
-
Kontener sGTM postawiony na obcej domenie dostawcy traci cały kontekst first-party
Apple w dokumentacji Intelligent Tracking Prevention podaje, że Safari skraca żywotność cookie ustawianego skryptem do 7 dni (stan na 2026 rok). Cookie wystawione przez serwer z własnej subdomeny nie podlega temu obcięciu.
-
Kontener serwerowy GTM jest jedynym miejscem obróbki danych przed wysyłką do platformy
Tag serwerowy hashuje adres e-mail pod konwersje rozszerzone, usuwa parametry PII i sprawdza sygnały Consent Mode, zanim cokolwiek wyśle. Client-side nie ma takiej warstwy, bo tag odpala się już w przeglądarce użytkownika.
-
Hybrydowy układ kontenera webowego i serwerowego jest domyślnym wariantem wdrożenia sGTM
Z mojej praktyki: w 34 wdrożeniach kontenera serwerowego z ostatnich kilkunastu miesięcy żadne nie zastąpiło client-side’u w całości. Kontener webowy nadal zbiera zdarzenie i przekazuje je jednym strumieniem na serwer.
Z czego składa się architektura server-side GTM?
Architektura server-side GTM składa się z pięciu warstw: źródła zdarzenia w przeglądarce, transportu na własną subdomenę first-party, kontenera serwerowego, klientów przejmujących żądania oraz tagów wysyłających dane do platform. Każda z tych warstw ma jedno zadanie i jeden punkt styku z następną - to dlatego cały system jest przewidywalny i łatwy do zdiagnozowania, gdy coś przestaje działać.
Sercem układu jest kontener serwerowy. To nie jest „serwer tagów” w potocznym sensie - to pełnoprawna instancja GTM, która zamiast renderować się w oknie przeglądarki, działa jako usługa nasłuchująca na żądania HTTP. W środowisku Google Cloud jest to zwykle usługa Cloud Run, autoskalująca się w zależności od liczby żądań. Na stape.io tę samą rolę pełni zarządzany kontener, którym nie musisz administrować ręcznie.
- Warstwa źródła: strona lub aplikacja generuje zdarzenie (odsłona, kliknięcie, zakup) - najczęściej przez standardowy tag Google lub kontener webowy GTM.
- Warstwa transportu: zamiast wysyłać dane wprost do Google, przeglądarka kieruje je na Twoją subdomenę (np. sst.twojadomena.pl) dzięki parametrowi server_container_url w tagu Google.
- Warstwa kontenera: usługa serwerowa odbiera żądanie jako surowe zapytanie HTTP z parametrami zdarzenia.
- Warstwa klientów: odpowiedni klient przejmuje żądanie i buduje z niego ustrukturyzowany obiekt event data.
- Warstwa tagów: tagi serwerowe czytają event data i wysyłają je do endpointów platform reklamowych i analitycznych.
Kluczowa różnica względem klasycznego, client-side’owego tagowania jest taka, że w architekturze serwerowej masz jeden centralny punkt kontroli. Przeglądarka wysyła jedno żądanie zamiast kilkunastu. Reszta dzieje się poza zasięgiem wzroku użytkownika, jego wtyczek i ograniczeń przeglądarki. Szczegóły uruchomienia takiego kontenera opisuję w przewodniku o tagowaniu po stronie serwera - tutaj skupiam się wyłącznie na tym, jak dane płyną przez system.
Czy wiesz, że…
Kontener serwerowy i kontener webowy GTM to dwa osobne kontenery o różnych typach, ale zarządzasz nimi z tego samego konta Google Tag Manager. Ten sam interfejs, inny silnik wykonawczy - kontener serwerowy nie ma dostępu do DOM strony ani do przeglądarki, bo w ogóle się w niej nie uruchamia.
Jak wygląda przepływ danych od zdarzenia w przeglądarce do endpointu?
Przepływ danych w server-side GTM prowadzi przez cztery etapy: zdarzenie powstaje w przeglądarce, trafia na subdomenę first-party, klient w kontenerze przejmuje żądanie i buduje event data, a tag serwerowy wysyła gotowe dane do platformy. Cała droga trwa zwykle kilkadziesiąt milisekund i jest niewidoczna dla użytkownika, bo dzieje się równolegle do przeglądania strony.
Prześledźmy to na przykładzie zakupu. Użytkownik klika „Kup teraz”. Strona odpala zdarzenie purchase i pakuje do niego wartość transakcji, walutę, identyfikator zamówienia i listę produktów. To zdarzenie nie leci jednak prosto do Google Analytics. Leci na Twoją subdomenę, bo tam - dzięki ustawieniu server_container_url - kieruje je kontener webowy. Serwer je odbiera. Klient GA4 rozpoznaje format żądania, przejmuje je i tłumaczy na obiekt event data. Dopiero teraz tagi serwerowe zabierają się do pracy.
Cztery etapy przepływu danych w kontenerze serwerowym - na przykładzie zdarzenia zakupu.
Strona odpala purchase z wartością, walutą i ID zamówienia.
server_container_url kieruje żądanie na Twoją domenę first-party.
Client rozpoznaje format i buduje obiekt event data.
Tag serwerowy przekazuje dane server-to-server do endpointu.
Dlaczego to takie ważne? Bo w klasycznym modelu każda platforma dostawała własne żądanie prosto z przeglądarki. Piksel Meta swoje, tag GA4 swoje, Google Ads swoje. W architekturze serwerowej przeglądarka wysyła jeden strumień danych, a serwer sam go multiplikuje. Mniej ruchu w przeglądarce, jeden punkt kontroli, jeden moment, w którym możesz dane oczyścić, wzbogacić albo zablokować.
Czym jest klient (client) w kontenerze serwerowym?
Klient (client) to element kontenera serwerowego, który nasłuchuje na przychodzące żądania HTTP, przejmuje pasujące do siebie zapytania i przekształca je w ustrukturyzowane zdarzenie zrozumiałe dla tagów. To pojęcie nie istnieje w kontenerze webowym - jest specyficzne dla architektury serwerowej i to ono najczęściej wywołuje zamieszanie u osób przesiadających się z client-side’u.
Najprościej myśleć o kliencie jak o tłumaczu i recepcjoniście w jednym. Recepcjonista, bo pilnuje drzwi kontenera - to on odbiera surowe żądanie i decyduje, czy jest ono dla niego. Tłumacz, bo surowe zapytanie HTTP (pełne zakodowanych parametrów) zamienia na czytelny obiekt event data, z którego tagi wyciągają wartości. Bez klienta tagi nie miałyby czego czytać, bo widziałyby tylko nieprzetworzony ciąg znaków.
Jakie klienty są najczęściej używane?
- Klient GA4 / Google Analytics: odbiera żądania od tagu Google (gtag) i kontenera webowego GTM - to najczęstszy punkt wejścia dla ruchu z Google Ads i GA4.
- Klient Google Tag Manager: nasłuchuje na żądania od kontenera webowego przekierowane przez server_container_url, gdy strona korzysta z GTM po stronie klienta.
- Klient Measurement Protocol: przyjmuje zdarzenia wysyłane server-to-server, np. z Twojego backendu przy konwersjach offline.
- Klienty społecznościowe (od dostawców zewnętrznych): dedykowane klienty np. dla Meta, TikTok czy Piksela, dostępne w galerii szablonów - obsługują specyficzne formaty tych platform.
W praktyce jeden kontener serwerowy ma zwykle kilka aktywnych klientów naraz. Każdy nasłuchuje na inny typ ruchu. Gdy przychodzi żądanie, kontener sprawdza po kolei, który klient chce je obsłużyć. To prowadzi nas do najbardziej niedocenianego mechanizmu całej architektury - przejęcia żądania.
Czy wiesz, że…
W kontenerze serwerowym to klient decyduje, czy odpowiedzieć przeglądarce. Klient GA4 nie tylko czyta żądanie - potrafi też odesłać do przeglądarki plik cookie first-party z serwera, co wydłuża jego żywotność w porównaniu z cookie ustawianym przez JavaScript w kodzie strony.
Na czym polega przejęcie żądania (claim request)?
Przejęcie żądania (claim request) to moment, w którym konkretny klient „zgłasza się” do obsługi przychodzącego zapytania HTTP i bierze je na siebie, blokując dostęp pozostałym klientom. To fundamentalny mechanizm architektury: bez przejęcia żądanie nie zostanie przetworzone, a kontener zwróci pustą odpowiedź, mimo że sam odebrał ruch.
Wyobraź sobie kolejkę klientów przy jednym okienku. Przychodzi żądanie. Kontener pokazuje je po kolei każdemu klientowi i pyta: „to Twoje?”. Pierwszy klient, który rozpozna format i powie „tak”, przejmuje żądanie. Od tej chwili tylko on je obsługuje - reszta zostaje pominięta. Jeśli żaden klient go nie przejmie, żądanie przepada. W mojej codziennej praktyce widzę, że to właśnie tu leży najczęstsza przyczyna „cichych” braków danych: żądanie dociera na serwer, ale nie ma klienta, który by je rozpoznał.
- Żądanie wchodzi do kontenera - serwer odbiera surowe zapytanie HTTP z parametrami zdarzenia.
- Kontener odpytuje klientów - po kolei sprawdza, który klient pasuje do formatu żądania.
- Pierwszy pasujący klient przejmuje - zgłasza claim i przejmuje wyłączność na obsługę tego żądania.
- Klient buduje event data - tworzy ustrukturyzowany obiekt zdarzenia dla tagów.
- Kontener uruchamia tagi - tagi powiązane z tym zdarzeniem odpalają się i wysyłają dane dalej.
Jestem przekonany, że zrozumienie tego jednego mechanizmu oddziela osoby, które potrafią zdiagnozować kontener serwerowy, od tych, które tylko klikają w interfejsie. Gdy dane nie docierają do Google Ads, pierwsze pytanie nie brzmi „czy tag jest dobrze skonfigurowany”, tylko „czy żądanie w ogóle zostało przejęte przez klienta”. To dokładnie ten typ analizy, który przeprowadzam podczas audytu konfiguracji pomiaru - jeśli masz wrażenie, że część konwersji ginie po drodze, to zwykle pierwszy trop.
Jak tagi po stronie serwera wysyłają dane do platform?
Tagi po stronie serwera czytają obiekt event data zbudowany przez klienta, opcjonalnie go wzbogacają, a następnie wysyłają dane bezpośrednio do endpointów platform w modelu server-to-server - czyli z serwera do serwera, z pominięciem przeglądarki. To ostatni etap przepływu i jednocześnie ten, w którym jeden kontener obsługuje wiele platform naraz.
Największa siła tego układu polega na tym, że kontener serwerowy działa jak hub. Do jego wnętrza wchodzi jeden strumień danych, a wychodzi kilka - do GA4, do Google Ads, do Meta CAPI, do dowolnej platformy, która ma tag serwerowy. Każdy tag formatuje dane po swojemu i uderza we własny endpoint API. Przeglądarka użytkownika o tym nie wie i nie musi wiedzieć.
Do wnętrza wchodzi jeden strumień zdarzeń, a tagi serwerowe rozprowadzają je do wielu platform naraz.
Konwersje i konwersje rozszerzone przez tag serwerowy.
Zdarzenia przez Measurement Protocol GA4.
Zdarzenia server-side z deduplikacją względem Piksela.
Dodanie wartości, hashowanie e-maila, uzupełnienie ID.
Usunięcie parametrów, których platforma nie ma dostać.
Sprawdzenie sygnałów Consent Mode przed wysyłką.
Odbiera jeden strumień, przetwarza i rozsyła do wszystkich platform
Zanim tag cokolwiek wyśle, na serwerze możesz dane obrobić. To jest ta warstwa, której client-side nigdy nie miał. Możesz dodać wartość transakcji z bazy, zahashować adres e-mail na potrzeby konwersji rozszerzonych, usunąć parametry, których dana platforma nie powinna dostać, albo sprawdzić, czy użytkownik wyraził zgodę. Dopiero po tej obróbce tag wysyła gotowy pakiet do endpointu.
Czym architektura server-side różni się od client-side?
Architektura server-side różni się od client-side miejscem wykonywania tagów: w modelu client-side każdy tag uruchamia się w przeglądarce użytkownika, w modelu server-side tagi wykonują się w kontenerze na serwerze, a przeglądarka wysyła tylko jedno żądanie. Ta jedna różnica pociąga za sobą wszystkie pozostałe - od odporności na blokery, przez kontrolę nad danymi, po koszt utrzymania.
W klasycznym, client-side’owym tagowaniu przeglądarka jest wykonawcą całej logiki. Ładuje skrypty Google, Meta, może kilkunastu innych dostawców. Każdy z nich widzi kontekst strony, każdy ustawia własne cookie, każdy może zostać zablokowany przez wtyczkę lub mechanizm przeglądarki. Ogólny mechanizm client-side’owego GTM opisuję osobno - tutaj interesuje nas wyłącznie kontrast z modelem serwerowym.
Więcej wypełnionych kropek oznacza silniejszą przewagę architektury w danym kryterium.
Wniosek: server-side wygrywa na kontroli i odporności danych, ale client-side pozostaje prostszy i tańszy w starcie - dlatego w praktyce najczęściej stosuje się model hybrydowy.
Warto od razu obalić jeden mit. Server-side GTM nie zastępuje w całości client-side’u - w większości wdrożeń oba modele działają równolegle. Kontener webowy nadal zbiera zdarzenie w przeglądarce, ale zamiast wysyłać je do wielu dostawców, przekazuje je pojedynczym strumieniem do kontenera serwerowego. To jest ten hybrydowy układ, który rekomenduję domyślnie.
Jaką rolę odgrywa własna domena first-party w architekturze?
Własna domena first-party pełni w architekturze rolę adresu, pod którym nasłuchuje kontener serwerowy - zwykle jest to subdomena Twojej głównej domeny (np. sst.twojadomena.pl). To ona sprawia, że ruch pomiarowy jest z perspektywy przeglądarki traktowany jako first-party, a nie jako obcy skrypt third-party, co realnie wydłuża żywotność plików cookie.
Mechanizm jest prosty w skutkach, choć techniczny w konfiguracji. Rekord DNS (typu A/AAAA lub CNAME) kieruje wybraną subdomenę na adres kontenera serwerowego. Parametr server_container_url po stronie przeglądarki mówi tagowi Google: nie wysyłaj danych na domenę Google, wyślij je na moją subdomenę. Ponieważ subdomena należy do tej samej domeny co strona, kontekst jest first-party. Cookie ustawione stąd, z poziomu serwera, żyje dłużej niż cookie ustawione skryptem w przeglądarce, które mechanizmy typu ITP w Safari skracają nawet do 7 dni.
- Subdomena we własnej domenie - kontekst first-party wymaga, by adres serwera należał do tej samej domeny co strona; obcy adres serwera od razu robi z ruchu third-party.
- Rekord DNS wskazujący na kontener - A/AAAA dla własnego IP lub CNAME dla usług typu stape.io.
- Poprawny certyfikat SSL - subdomena musi obsługiwać HTTPS, inaczej przeglądarki zablokują transport.
- Ustawiony server_container_url - bez tego parametru dane nadal lecą na domenę Google i cały pierwszy przystanek na serwerze nie istnieje.
To najczęstsze źródło błędu w architekturze. Zdarzają się konfiguracje, w których kontener serwerowy działał bez zarzutu, ale postawiony był na obcej domenie dostawcy - i cała przewaga first-party wyparowała, bo przeglądarka i tak traktowała ruch jak third-party. Jeśli planujesz taką konfigurację u siebie, to jest dokładnie ten element, który sprawdzam w pierwszej kolejności podczas audytu.
Jak Consent Mode i RODO wpisują się w przepływ danych?
Consent Mode i RODO wpisują się w przepływ danych na etapie kontenera serwerowego, który staje się centralnym punktem egzekwowania zgody: sygnały zgody z platformy CMP wędrują razem ze zdarzeniem na serwer, a tagi sprawdzają je, zanim cokolwiek wyślą. Kontener serwerowy nie zwalnia z obowiązku pozyskania zgody, ale daje jedno miejsce, w którym tę zgodę faktycznie respektujesz.
To istotna zmiana perspektywy. W client-side każdy tag samodzielnie interpretował zgodę w przeglądarce. W architekturze serwerowej sygnał zgody dociera na serwer razem z pozostałymi parametrami zdarzenia, a to serwer decyduje, które tagi mają prawo się odpalić. Możesz na serwerze anonimizować lub usuwać dane osobowe (PII), filtrować parametry, których dana platforma nie ma prawa dostać, i przechowywać dane w regionie UE. Sam mechanizm Consent Mode i jego tryby (basic oraz advanced) rozwijam w osobnym opracowaniu - tutaj ważny jest fakt, że serwer jest punktem, w którym zgoda jest egzekwowana, a nie tylko odczytywana.
Czy wiesz, że…
Kontener serwerowy pozwala zobaczyć i przyciąć dane, zanim opuszczą Twoją infrastrukturę. To jedyny moment w całym łańcuchu pomiaru, w którym możesz usunąć adres IP, obciąć parametr URL z danymi wrażliwymi albo zablokować konkretny tag - zanim informacja trafi do zewnętrznej platformy. Z perspektywy zgodności z RODO to realna dźwignia kontroli.
Co potrzebne jest, żeby uruchomić kontener serwerowy?
Żeby uruchomić kontener serwerowy, potrzebujesz czterech rzeczy: kontenera typu Server w Google Tag Manager, hostingu (Google Cloud Run lub stape.io), subdomeny first-party z rekordem DNS oraz parametru server_container_url w tagu Google w kontenerze webowym. Bez każdego z tych elementów przepływ danych nie zadziała w pełni - to nie są opcje, tylko minimalny zestaw startowy.
Upewnij się, że masz te elementy, zanim przejdziesz do wdrożenia przepływu danych.
Warto rozdzielić dwie kwoty, które łatwo pomylić. Koszt hostingu kontenera serwerowego (rzędy: stape.io od ok. 20 USD/mies., Google Cloud zwykle od ok. 90-120 USD/mies. przy realnym ruchu) to zupełnie inna pozycja niż budżet reklamowy kampanii Google Ads. To pierwsze utrzymuje infrastrukturę pomiaru. To drugie kupuje kliknięcia. Mylenie tych dwóch liczb to jeden z częstszych błędów w planowaniu wdrożenia.
Dlaczego przepływ danych bywa błędny i jak to rozpoznać?
Przepływ danych w server-side GTM najczęściej zawodzi w trzech miejscach: żądanie nie dociera na subdomenę (błąd server_container_url lub DNS), dociera, ale żaden klient go nie przejmuje (brak claim), albo tag wysyła dane w złym formacie do endpointu. Diagnostyka polega na przejściu przepływu etap po etapie i sprawdzeniu, na którym przystanku dane się urywają.
Uważam, że najczęstszym, a zarazem najbardziej mylącym błędem jest ten drugi przypadek - żądanie dociera na serwer, więc w logach ruch jest, ale nie ma klienta, który by je rozpoznał. Wszystko wygląda „prawie dobrze”, a konwersje po prostu nie pojawiają się w Google Ads. Bez zrozumienia mechanizmu przejęcia żądania łatwo zacząć szukać problemu w tagu, podczas gdy zdarzenie w ogóle nie zostało przetworzone.
- Żądanie nie dociera na serwer: zły lub brakujący server_container_url, błędny rekord DNS albo brak certyfikatu SSL na subdomenie - dane nadal lecą na domenę Google.
- Żądanie dociera, ale nie zostaje przejęte: brak odpowiedniego klienta lub jego błędna konfiguracja - kontener zwraca pustą odpowiedź, a zdarzenie przepada.
- Event data jest niekompletne: klient przejął żądanie, ale kluczowe parametry (wartość, waluta, ID zamówienia) nie zostały poprawnie zmapowane.
- Tag uderza w zły endpoint lub format: tag serwerowy wysyła dane, ale platforma je odrzuca z powodu błędnej struktury lub braku wymaganych pól.
- Zgoda blokuje wysyłkę: sygnał Consent Mode nie dociera na serwer lub jest źle interpretowany, więc tag się nie odpala mimo poprawnej reszty przepływu.
Dobra wiadomość jest taka, że architektura serwerowa jest wyjątkowo przewidywalna w diagnozie. Tryb podglądu (Preview) kontenera pokazuje każde przychodzące żądanie, moment jego przejęcia przez klienta, zbudowany obiekt event data i odpowiedź każdego tagu. Przechodzisz przepływ punkt po punkcie i widzisz dokładnie, gdzie dane się urywają. Jeśli rozpoznajesz u siebie któryś z tych objawów, to zwykle sygnał, że warto przejść ten łańcuch od początku - albo zlecić audyt, który to zrobi.
Podsumowanie
Server-side GTM to nie magia, tylko dobrze poukładany łańcuch przystanków. Zdarzenie powstaje w przeglądarce, leci na Twoją subdomenę first-party, klient je przejmuje i tłumaczy na event data, a tagi rozsyłają gotowe dane do platform. Każdy z tych etapów ma jedno zadanie i jeden punkt styku z następnym. Gdy raz zobaczysz tę architekturę jako sekwencję, przestaje być czarną skrzynką, a staje się mapą, po której potrafisz się poruszać.
Przestań myśleć o kontenerze serwerowym jak o „jeszcze jednym narzędziu do tagów”. Zacznij postrzegać go jako punkt kontroli - jedyne miejsce w całym pomiarze, w którym dane są u Ciebie, zanim trafią do kogokolwiek innego. To ta perspektywa zmienia sposób, w jaki projektujesz i diagnozujesz cały system. Kontrola nad danymi, kontekst first-party i egzekwowanie zgody nie są dodatkami - są bezpośrednim skutkiem tego, gdzie fizycznie wykonują się Twoje tagi.
Jeśli masz już kontener webowy i zastanawiasz się, czy przepływ danych na serwerze działa u Ciebie poprawnie, zacznij od jednego pytania: czy każde ważne zdarzenie faktycznie zostaje przejęte przez klienta i dociera do endpointu. Od tej odpowiedzi zależy, czy Twoje kampanie widzą pełny obraz konwersji, czy tylko jego fragment.
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
Opis architektury sGTM sprawdzam u źródła: dwie strony dokumentacji platformy odpowiadają za mechanikę kontenera i klientów, a dwa niezależne materiały pokazują, co ta architektura robi z domeną first-party i ze zgodami użytkownika.
Podstawy tagowania po stronie serwera
Dokumentacja definiuje klienta jako zasób dostępny wyłącznie w kontenerze serwerowym, którego zadaniem jest sparsowanie przychodzącego żądania HTTP i zbudowanie obiektu event data dla tagów. Znajdziesz tu też regułę, że pojedyncze żądanie może przejąć tylko jeden klient - to techniczna podstawa sekcji o kliencie w kontenerze i sekcji o przejęciu żądania (claim request).
Tagowanie client-side a server-side
Oficjalne zestawienie obu modeli tagowania: gdzie wykonują się tagi, ile żądań wychodzi z przeglądarki i co zmienia przeniesienie logiki do kontenera serwerowego. Punkt odniesienia dla sekcji o różnicach między architekturą server-side i client-side oraz dla listy warstw z pierwszej sekcji artykułu.
Śledzenie oparte na rekordach CNAME
Długoterminowa analiza na danych HTTP Archive pokazuje, jak szybko rośnie użycie własnych subdomen do serwowania zasobów śledzących, zwłaszcza na witrynach o dużym ruchu, i że technika bywa wymierzona w restrykcyjne ustawienia Safari. Praca opisuje też wycieki wrażliwych danych wynikające z takiej konfiguracji, więc jest kontrapunktem do sekcji o roli własnej domeny first-party.
Ukryte wycieki danych w Tag Managerze
Omówienie badania, w którym przeanalizowano 78 tagów client-side, 8 tagów serwerowych i dwie platformy zarządzania zgodami; Consent Mode potrafi mieć część celów zgody włączonych zanim użytkownik dotknie banera, a niezdefiniowane zmienne bywają czytane jako akceptacja. Materiał wskazuje też, że kontener serwerowy utrudnia audyt przesyłu danych - stąd trafia do sekcji o Consent Mode i RODO oraz do sekcji o rozpoznawaniu błędnego przepływu.
Pytania i odpowiedzi (FAQ)
Kontener serwerowy obok webowego, rola klienta w architekturze i granice zastąpienia tagowania w przeglądarce.
Czym różni się kontener serwerowy od kontenera webowego w GTM?
Co to jest klient (client) w server-side GTM?
Czy server-side GTM całkowicie zastępuje tagowanie w przeglądarce?
Czy server-side GTM wymaga umiejętności programistycznych?
Dlaczego dane docierają na serwer, ale nie pojawiają się w Google Ads?
Czy server-side GTM wymaga własnej domeny?
