Klient (client) w sGTM (ang. client) to komponent kontenera serwerowego Google Tag Managera, który odbiera przychodzące żądania HTTP (np. z biblioteki gtag.js dla GA4 albo z Measurement Protocol), rozpoznaje ich format i przekształca je w ujednolicone zdarzenia, na których mogą pracować tagi serwerowe. Dla marketera to „bramka wejściowa” całego server-side taggingu: bez poprawnie działającego klienta żaden tag w kontenerze serwerowym nie otrzyma danych, więc konwersje i zdarzenia po prostu nie zostaną wysłane do platform reklamowych i analitycznych.
Jak działa klient w kontenerze serwerowym?
Kontener serwerowy działa jako aplikacja na własnym serwerze (np. w Google Cloud) i wystawia adres, na który przeglądarka użytkownika kieruje żądania zamiast bezpośrednio do Google. Klient jest pierwszym elementem, który te żądania „widzi”. Jego praca przebiega w kilku krokach:
- Odebranie żądania – klient sprawdza, czy przychodzące zapytanie pasuje do jego warunków (np. ścieżka
/g/collectdla GA4). - Przejęcie żądania (claim) – tylko jeden klient może obsłużyć dane żądanie; decyduje o tym kolejność (priorytet) w konfiguracji.
- Parsowanie danych – parametry z URL, ciała żądania i nagłówków zamieniane są na obiekt zdarzenia z ustandaryzowanymi nazwami pól (np.
event_name,client_id,page_location). - Uruchomienie kontenera – zdarzenie trafia do reguł i tagów serwerowych, które mogą z niego korzystać przez zmienne „Event Data”.
- Odpowiedź do przeglądarki – klient może ustawić nagłówki odpowiedzi, w tym pliki cookie w domenie witryny (first-party cookie), co jest jedną z kluczowych zalet architektury serwerowej.
Warto podkreślić różnicę względem kontenera webowego: w klasycznym Google Tag Managerze źródłem danych jest warstwa danych w przeglądarce, a w kontenerze serwerowym rolę tę pełni właśnie klient.
Jakie typy klientów są dostępne?
Google udostępnia kilka gotowych klientów, a społeczność publikuje własne szablony w galerii. Najczęściej wykorzystywane to:
| Klient | Co odbiera | Typowe zastosowanie |
|---|---|---|
| Google Analytics: GA4 | Żądania gtag.js kierowane do GA4 | Podstawa większości wdrożeń, zasila tagi GA4, Google Ads, Meta i inne |
| Measurement Protocol | Żądania wysyłane bezpośrednio z backendu sklepu lub CRM | Zdarzenia offline, potwierdzenia płatności, zwroty |
| Google Tag Manager: Web Container | Żądania o skrypt kontenera webowego | Serwowanie gtm.js z własnej domeny (mniejsza podatność na blokady) |
| Szablony niestandardowe | Dowolny format zdefiniowany w kodzie szablonu | Integracje z systemami spoza ekosystemu Google |
Szczegółowy opis mechanizmu przejmowania żądań znajduje się w dokumentacji Google dla programistów.
Kiedy warto budować własnego klienta, a kiedy nie?
- Warto, gdy dane przychodzą z systemu, który nie wysyła ich w formacie GA4 ani Measurement Protocol (np. własny endpoint z aplikacji mobilnej).
- Warto, gdy potrzebujesz pełnej kontroli nad tym, jakie pola trafiają do zdarzenia, np. ze względów prywatności.
- Nie warto, jeśli wdrożenie opiera się wyłącznie na GA4 – wbudowany klient obsłuży wszystko, a własny kod to dodatkowe ryzyko błędów.
- Nie warto duplikować klientów o tych samych warunkach – żądanie i tak przejmie tylko jeden z nich, a debugowanie stanie się trudniejsze.
Najczęstsze błędy w konfiguracji klienta
- Brak ustawienia
server_container_urlpo stronie tagu webowego – żądania nigdy nie docierają do klienta. - Zły priorytet klientów, przez który generyczny klient przejmuje żądania przeznaczone dla GA4.
- Wyłączona opcja ustawiania cookies w domenie witryny, co niweczy korzyść z first-party cookie.
- Ignorowanie podglądu (Preview) w kontenerze serwerowym – to jedyne miejsce, gdzie widać, czy klient poprawnie przejął i sparsował żądanie.
Klient w praktyce ICBM
We wdrożeniach server-side taggingu zaczynamy od audytu tego, jakie źródła danych mają zasilać kontener serwerowy. Zwykle wystarczają dwa klienci: GA4 dla ruchu z przeglądarki oraz Measurement Protocol dla zdarzeń z systemu sklepowego. Dopiero gdy pojawiają się nietypowe integracje, przygotowujemy własny szablon i dokładnie testujemy go w trybie podglądu, zanim tagi zaczną wysyłać dane do Google Ads czy Meta. Dbamy też o to, by klient ustawiał pliki cookie w domenie klienta, co realnie wydłuża żywotność identyfikatorów użytkowników.
Najczęściej zadawane pytania
Czym różni się klient od tagu w kontenerze serwerowym?
Klient odbiera dane przychodzące i tworzy z nich zdarzenie, natomiast tag wysyła dane wychodzące do platformy docelowej (np. GA4, Google Ads). Klient stoi na początku przepływu, tag – na jego końcu.
Czy w jednym kontenerze serwerowym może działać wielu klientów?
Tak, i jest to typowa sytuacja. Każde przychodzące żądanie przejmuje jednak tylko jeden klient – ten, który jako pierwszy (według priorytetu) uzna je za pasujące do swoich warunków.
Czy klient GA4 obsłuży też dane dla Meta czy Google Ads?
Tak. Klient GA4 tworzy uniwersalny obiekt zdarzenia, z którego mogą korzystać wszystkie tagi serwerowe, nie tylko tag GA4. Wystarczy odpowiednio zmapować pola w tagach docelowych.
