Server-side tagging w praktyce: przenosimy Google Tag Manager na własny serwer

Jak działa server-side tagging w Google Tag Manager

W server-side taggingu pojawia się dodatkowe ogniwo: serwer tagowania między przeglądarką a dostawcami. Kontener internetowy wysyła do niego żądania, a kontener serwerowy decyduje, co z nimi zrobić.

Przeglądarka (kontener internetowy GTM, tag Google)
   |  żądanie GA4 na https://twojsklep.pl/metrics/g/collect
   v
Serwer tagowania (kontener serwerowy GTM)
   |-- Klient GA4: zamienia żądanie na dane zdarzenia
   |-- Transformacje: dopuszczają, usuwają lub uzupełniają parametry
   |-- Tagi: GA4, Google Ads, Meta Conversions API, inne

Kontener serwerowy ma trzy elementy, których nie znasz z kontenera internetowego. Klient odbiera żądanie HTTP i zamienia je na dane zdarzenia – wbudowany klient GA4 rozumie żądania tagu Google. Transformacje pozwalają przed uruchomieniem tagów dopuścić tylko wybrane parametry, usunąć niepotrzebne albo dopisać nowe. Tagi działają jak w zwykłym kontenerze, ale wysyłają dane z serwera, a nie z przeglądarki. Ogólny opis narzędzia znajdziesz na stronie Google Tag Manager.

Co przygotować przed migracją

Zanim uruchomisz pierwszy serwer, podejmij kilka decyzji, które trudno zmienić później. Najważniejsze to hosting, region i domena.

Porównanie Cloud Run, dostawców zarządzanych i własnych serwerów pod kątem kosztów omawiamy w tekście o hostingu server-side GTM. Jeśli zależy Ci wyłącznie na tym, żeby tagi Google działały w domenie sklepu, a nie potrzebujesz przetwarzania danych na serwerze, sprawdź prostsze rozwiązanie – porównanie Google Tag Gateway i server-side GTM.

Krok 1 i 2: kontener serwerowy i serwer tagowania w Cloud Run

Najpierw tworzysz w GTM kontener typu „Serwer”, potem uruchamiasz dwie usługi Cloud Run: serwer podglądu i właściwy serwer tagowania. Obie korzystają z tego samego obrazu Google.

W GTM utwórz nowy kontener i wybierz platformę „Serwer”. Kreator zaproponuje automatyczne lub ręczne udostępnienie serwera. Automatyczne tworzy usługę Cloud Run w regionie us-central1 i według dokumentacji Google służy do testów; zmiana regionu wymaga później utworzenia nowej usługi i usunięcia starej. Do produkcji wybierz ręczne udostępnianie i skopiuj ciąg konfiguracji kontenera. Następnie w Cloud Shell uruchom dwa polecenia: pierwsze tworzy serwer podglądu (wystarczy mu jedna instancja), drugie – produkcyjny serwer tagowania.

gcloud run deploy server-side-tagging-preview \
  --region europe-central2 \
  --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --min-instances 0 --max-instances 1 --timeout 60 \
  --allow-unauthenticated --no-cpu-throttling \
  --update-env-vars RUN_AS_PREVIEW_SERVER=true,CONTAINER_CONFIG="TWOJ_CIAG_KONFIGURACJI"

gcloud run deploy server-side-tagging \
  --region europe-central2 \
  --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --min-instances 2 --max-instances 10 --timeout 60 \
  --allow-unauthenticated --no-cpu-throttling \
  --update-env-vars PREVIEW_SERVER_URL="https://ADRES-SERWERA-PODGLADU",CONTAINER_CONFIG="TWOJ_CIAG_KONFIGURACJI"

Każda instancja ma 1 vCPU i 0,5 GB pamięci. Google podaje, że autoskalowanie od 2 do 10 instancji obsłuży ok. 35–350 żądań na sekundę, a koszt jednej instancji szacuje na ok. 45–50 USD miesięcznie. Minimalny rachunek to więc liczba stałych instancji pomnożona przez tę kwotę, plus ruch wychodzący, load balancer i logi. Te ostatnie potrafią zaskoczyć: przy ponad milionie żądań miesięcznie logowanie każdego z nich generuje zauważalne koszty. Jeśli nie potrzebujesz logów żądań, dodaj do filtra domyślnego ujścia w Cloud Logging wykluczenie NOT LOG_ID("run.googleapis.com/requests") i ustaw alert budżetowy w Cloud Billing.

Krok 3: własna domena i dlaczego subdomena nie zawsze wystarcza

Serwer tagowania musi odpowiadać w domenie sklepu, bo tylko wtedy ustawiane przez niego ciasteczka są ciasteczkami własnymi. Masz dwie możliwości: subdomenę albo ścieżkę w głównej domenie.

Subdomena, np. sgtm.twojsklep.pl, to najprostsza opcja: dodajesz rekord DNS i mapujesz go na usługę Cloud Run lub na globalny load balancer aplikacji. Mapowanie domen bezpośrednio w Cloud Run ma ograniczenia zależne od regionu, dlatego Google często wskazuje load balancer jako lepszy wybór, mimo dodatkowego kosztu.

Ścieżka w tej samej domenie, np. twojsklep.pl/metrics/, wymaga skierowania ruchu z tej ścieżki do serwera tagowania przez load balancer lub CDN, z której korzysta sklep. Daje jednak ważną przewagę w Safari. Od wersji 16.4 przeglądarka skraca do 7 dni czas życia ciasteczek ustawianych przez serwer, którego adres IP znacząco różni się od adresu głównej witryny – a subdomena wskazująca na infrastrukturę Google zwykle ma inny adres niż sklep. O tym, jak Safari ogranicza też identyfikatory kliknięć, piszemy w tekście o Safari 26 i parametrach gclid oraz fbclid. Jeśli sklep działa za Cloudflare, ten sam mechanizm kierowania ścieżki wykorzystuje Google Tag Gateway na Cloudflare.

Po skonfigurowaniu domeny przejdź w kontenerze serwerowym do sekcji Administracja, otwórz ustawienia kontenera i dodaj adres serwera. Jeśli mapujesz kilka domen, ścieżka po nazwie domeny musi być w każdej z nich identyczna.

Krok 4: skierowanie tagu Google na serwer

Kontener internetowy musi wiedzieć, że dane GA4 ma wysyłać na Twój serwer zamiast bezpośrednio do Google. Służy do tego parametr konfiguracji tagu Google.

Kontener internetowy -> Tag Google (G-XXXXXXX)
Ustawienia konfiguracji:
  server_container_url = https://twojsklep.pl/metrics
Reguła: Inicjowanie – wszystkie strony

Od czerwca 2025 roku klient kontenera internetowego w serwerze tagowania może też serwować skrypty Google, np. gtm.js i gtag.js. Wtedy w fragmencie GTM na stronie zmieniasz adres skryptu na adres Twojego serwera i również sam plik kontenera ładuje się z domeny sklepu.

W kliencie GA4 w kontenerze serwerowym wybierasz sposób zarządzania identyfikatorem klienta: przez JavaScript albo przez serwer. Tryb serwerowy ustawia identyfikator w ciasteczku z flagą HttpOnly, niedostępnym dla skryptów na stronie. Przy zmianie trybu włącz migrację istniejących identyfikatorów, żeby powracający użytkownicy nie zostali policzeni jako nowi.

Krok 5: tagi w kontenerze serwerowym i kolejność migracji

Migruj tagi pojedynczo i po każdym etapie porównuj dane. Kolejność od GA4 do platform innych firm pozwala najpierw ustabilizować źródło, z którego korzystają pozostałe tagi.

1. GA4. Dodaj w kontenerze serwerowym tag GA4 uruchamiany dla zdarzeń z klienta GA4. Najpierw przetestuj całość na osobnej usłudze GA4 lub w środowisku testowym, żeby nie zdublować danych produkcyjnych.
2. Google Ads. Dodaj tag łączący konwersje oraz tag śledzenia konwersji uruchamiany zdarzeniem purchase. Jeśli korzystasz z rozszerzonych konwersji, dane klienta przejdą razem ze zdarzeniem – konfigurację po stronie kontenera internetowego opisujemy w poradniku o Enhanced Conversions przez GTM.
3. Meta. Tag Conversions API uruchamiasz z szablonu, a piksel w przeglądarce zostawiasz z tym samym identyfikatorem zdarzenia. Pełną konfigurację zawiera tekst o Meta Conversions API przez server-side GTM, a zasady łączenia obu źródeł – o deduplikacji zdarzeń Pixel i Conversions API.
4. Pozostałe platformy. Przenoś je dopiero po ustabilizowaniu trzech pierwszych etapów.
5. Transformacje. Usuń parametry, których dostawca nie potrzebuje, zanim dane opuszczą Twój serwer.
6. Wyłączenie duplikatów. Po potwierdzeniu, że tag serwerowy działa, usuń jego odpowiednik z kontenera internetowego.

Gdy migracja jest zakończona, serwer staje się miejscem, w którym możesz dopisywać do konwersji marżę czy status klienta z CRM – opisujemy to w artykule o wzbogacaniu zdarzeń po stronie serwera.

Testy, zgody i monitoring po uruchomieniu

Kontener serwerowy ma własny tryb podglądu, w którym widzisz przychodzące żądania, dane zdarzenia i żądania wychodzące do dostawców razem z kodami odpowiedzi. To podstawowe narzędzie do testów.

Najpierw uruchom podgląd kontenera serwerowego, potem podgląd kontenera internetowego i przejdź przez ścieżkę zakupu. Dla każdego zdarzenia sprawdź, czy klient GA4 je odebrał, które tagi się uruchomiły i czy dostawcy odpowiedzieli kodem 200 lub 204.

Przeniesienie tagów na serwer nie zmienia obowiązków dotyczących zgód. Stan Consent Mode jest przekazywany w żądaniach tagu Google i tagi Google w kontenerze serwerowym go uwzględniają. Dla tagów innych firm musisz samodzielnie dodać warunki uruchamiania zależne od stanu zgody; sposób jego odczytu zależy od klienta i szablonu. Listę kontrolną zgód znajdziesz w checkliście Consent Mode v2. Przetwarzanie danych na własnym serwerze nie zmienia też wymogów RODO, a w sprawach dotyczących podstaw prawnych warto skonsultować się z prawnikiem.

Po uruchomieniu obserwuj metryki usługi Cloud Run: liczbę żądań, czas odpowiedzi i odsetek błędów 5xx. Ustaw alerty w Cloud Monitoring, a po stronie danych – powiadomienia o spadku liczby zdarzeń, opisane w tekście o monitoringu tagów na produkcji. Przez pierwsze tygodnie porównuj liczbę konwersji w GA4, Google Ads i Meta z danymi sklepu; jeśli rozjazd się zmienia, przyczyn szukaj według listy z artykułu o rozbieżnościach konwersji. Serwer tagowania to też element szerszej strategii danych first-party, a kolejne poradniki znajdziesz w podtemacie server-side tagging.