Nie każde zdarzenie GA4 musi iść przez serwer. Jak rozdzielić ruch w sGTM
Serwerowy Google Tag Manager (server-side GTM, w skrócie sGTM) stał się popularnym sposobem na porządkowanie danych marketingowych. Zdarzenia z przeglądarki trafiają najpierw na Twój serwer, a dopiero stamtąd do Google Analytics, Meta, LinkedIn czy innych narzędzi. Ma to jedną wadę, o której łatwo zapomnieć przy wdrożeniu: każde zapytanie kosztuje. Dlatego warto wiedzieć, że nie wszystkie zdarzenia GA4 muszą przechodzić przez serwer.
Po co dzielić zdarzenia
Na ten pomysł zwrócił uwagę Simo Ahava, jeden z najbardziej znanych specjalistów od GTM. Wskazuje kilka powodów, by tylko część strumienia GA4 kierować do sGTM, a resztę wysyłać bezpośrednio do Google:
- Mniejsze obciążenie serwera - przez sGTM idą tylko zdarzenia ważne dla biznesu.
- Odporność na awarie - można też zrobić odwrotnie i wysyłać kluczowe zdarzenia prosto do Google, żeby ewentualna awaria sGTM nie zepsuła najważniejszych danych.
- Niższe koszty - w większości konfiguracji płacisz za każde zapytanie i odpowiedź generowaną przez serwer (w rozliczeniach widać to jako ruch wychodzący, tzw. egress). Zdarzenia liczne, ale mało istotne, mogą generować spory rachunek.
Jak działa przekierowanie: server_container_url
O tym, dokąd trafia zdarzenie GA4, decyduje parametr server_container_url. Standardowo ustawia się go w konfiguracji tagu Google (Google Tag) tak, by wskazywał na adres Twojego kontenera serwerowego. Wtedy wszystkie zdarzenia dla tego samego identyfikatora pomiaru, także te zbierane automatycznie, płyną przez sGTM.
Ahava radzi dodatkowo wpisać ten sam parametr w zmiennej ustawień zdarzeń (Event Settings Variable) jako zabezpieczenie. Jeśli tag zdarzenia odpali się przed tagiem Google albo jakiś konflikt na stronie zresetuje ustawienia, zdarzenie i tak trafi do serwera.
Wyjątek: jeśli chcesz, by przez serwer szło tylko kilka wybranych zdarzeń, nie dodawaj server_container_url do tagu Google w ogóle i ustaw go tylko w tych tagach, które mają iść przez sGTM.
Jak wyłączyć serwer dla jednego tagu
Sposób jest prosty. W ustawieniach konkretnego tagu zdarzenia dodaj parametr server_container_url i zostaw jego wartość pustą. Parametr ustawiony bezpośrednio w tagu ma pierwszeństwo przed zmienną ustawień zdarzeń i przed konfiguracją tagu Google, więc to zdarzenie pójdzie prosto do Google.
Są dwa praktyczne zastrzeżenia:
- Pusty tekst albo null, nigdy undefined. Dla GTM wartość undefined oznacza „zignoruj to pole”, więc tag zachowa się tak, jakby nic nie zmieniono, i wyśle dane na serwer.
- Udokumentuj to. Puste pole wygląda jak błąd i ktoś z zespołu może je „naprawić”. Lepiej użyć zmiennej (np. własnej zmiennej JavaScript albo szablonu zmiennej), która zwraca pusty tekst i ma nazwę jasno mówiącą, o co chodzi.
Uwaga na identyfikator użytkownika
Drugi ważny szczegół dotyczy tożsamości użytkownika. Jeśli część zdarzeń idzie do GA4 z przeglądarki, a część przez sGTM, klient GA4 w kontenerze serwerowym musi korzystać z trybu JavaScript Managed. W trybie Server Managed zdarzenia z serwera i z przeglądarki dostaną różne identyfikatory w plikach cookie i GA4 potraktuje je jak dwóch różnych użytkowników. Raporty ścieżek i konwersji przestaną mieć sens.
Przeniesienie tagów na serwer nie zwalnia z obowiązku zgody. Jeśli zdarzenie dotyczy analityki lub reklamy, użytkownik musi najpierw wyrazić zgodę, a stan zgody z Google Consent Mode v2 musi dotrzeć do serwera razem ze zdarzeniem i być tam respektowany.
Server-side a zgody: o czym nie zapomnieć
Wokół sGTM narosło nieporozumienie, że skoro dane idą przez „własny” serwer, to zgoda przestaje być potrzebna. Tak nie jest. Prawo komunikacji elektronicznej i RODO dotyczą celu, w jakim zbierasz dane, a nie drogi, którą płyną. Analityka i reklama nadal wymagają zgody, niezależnie od tego, czy tag działa w przeglądarce, czy na serwerze.
Przy dzieleniu ruchu warto pilnować kilku rzeczy:
- Baner i Consent Mode działają w przeglądarce dla obu ścieżek. Zarówno zdarzenia wysyłane prosto do Google, jak i te kierowane do sGTM, muszą powstawać dopiero zgodnie ze stanem zgody.
- Stan zgody dociera na serwer. Zapytania GA4 przekazują informację o zgodzie. Sprawdź w podglądzie sGTM, czy ją widać, i nie przekazuj dalej danych do narzędzi reklamowych, gdy użytkownik odmówił.
- Tagi serwerowe innych dostawców. Przekazując zdarzenia do Meta czy LinkedIn z serwera, ustaw warunki oparte na stanie zgody, żeby odmowa w banerze oznaczała realny brak przekazania.
- Testuj obie ścieżki osobno. Po odmowie zgody sprawdź, co wysyła przeglądarka, a co serwer.
Podział ruchu ma tu nawet pewną zaletę: łatwiej zobaczyć, które zdarzenia są naprawdę potrzebne. Jeśli przy przeglądzie okaże się, że część z nich nie służy żadnej decyzji biznesowej, być może nie trzeba ich zbierać wcale. Mniej danych to niższy rachunek i mniej rzeczy do opisania w polityce prywatności.
Krótko: kiedy to się opłaca
Dzielenie zdarzeń ma sens, gdy masz dużo zdarzeń o małym znaczeniu, np. przewijanie czy widoczność elementów, a rachunek za sGTM rośnie. Pamiętaj jednak, że to niestandardowa konfiguracja, która wymaga dokumentacji, trybu JavaScript Managed i starannego testowania zgód. Zanim zaczniesz optymalizować koszty, upewnij się, że podstawy działają: baner blokuje narzędzia do czasu zgody, a Consent Mode v2 przekazuje prawidłowy stan. Możesz to szybko sprawdzić w darmowym narzędziu Skaner zgody.
Źródło: Simo Ahava
server-side GTMGA4Google Tag ManagerGoogle Consent Modekoszty sGTM