Jak debugować server-side GTM

Tagowanie po stronie serwera przeniosło najciekawszą część układanki poza przeglądarkę. Dobrze wpływa to na wydajność i kontrolę nad danymi, a utrudnia życie każdemu, kto próbuje to debugować: żądania, które kiedyś czytałeś w zakładce sieci, idą teraz do domeny należącej do Ciebie, w formie, której większość narzędzi nie rozpoznaje.

Dlaczego większość debuggerów milczy

Prawie każdy inspektor tagów rozpoznaje ruch po nazwie hosta. Ma listę — google-analytics.com, facebook.com, bat.bing.com — a resztę ignoruje. W chwili, gdy klient GA4 wysyła dane na sst.twojastrona.pl zamiast na google-analytics.com, host przestaje pasować i żądanie zostaje odrzucone, zanim ktokolwiek na nie spojrzy.

Rozwiązaniem jest dopasowanie najpierw po ścieżce, a host traktowanie jako sygnał pomocniczy. Żądanie do /g/collect?v=2&tid=G-XXXX jest żądaniem GA4 niezależnie od tego, czy trafia na serwery Google, czy na subdomenę Twojego sklepu. Tag Master klasyfikuje właśnie tak, dlatego przepuszczony ruch nadal się pojawia, zdekodowany i oznaczony jako server-side.

Cztery sygnały, że strona korzysta z sGTM

Rzadko istnieje jeden rozstrzygający dowód — punktuj poszlaki:

1. Ścieżki zbierania na hoście first-party. /g/collect, /mp/collect lub /gtm.js?id=GTM-XXXXXX serwowane z subdomeny samej strony, a nie z googletagmanager.com. Ta sama domena rejestrowalna co strona to najmocniejsza wersja tego sygnału.
2. Ciasteczko FPID z flagą HttpOnly. JavaScript nie może ustawić ciasteczka HttpOnly, więc tak zapisany FPID pochodzi z serwera. Zwykle widać też towarzyszące mu FPLC. To niemal rozstrzygające.
3. Zadeklarowany endpoint w konfiguracji tagu. Poszukaj server_container_url albo transport_url w konfiguracji gtag na stronie — konfiguracja sama mówi, dokąd wysyła dane.
4. Cisza tam, gdzie spodziewasz się ruchu. Jeśli ze strony wychodzą żądania o kształcie GA4, ale nic nie idzie do google-analytics.com, ruch jest najpierw przekazywany gdzie indziej.

Podłączenie sesji podglądu serwera

Wykrycie mówi, że sGTM istnieje. Żeby zobaczyć, co kontener serwerowy faktycznie robi z żądaniem, potrzebna jest sesja podglądu, a ta opiera się na nagłówku: X-Gtm-Server-Preview.

Otwórz kontener serwerowy w GTM, kliknij Preview i skopiuj token. W Tag Masterze przejdź do zakładki GTM, wklej token i domenę endpointu w polu podglądu sGTM i włącz przełącznik. Od tej chwili żądania z Twojej przeglądarki do tej domeny niosą nagłówek i pojawiają się w sesji podglądu razem z tagami, które uruchamiają. Po skończonej pracy wyłącz przełącznik — reguła znika natychmiast.

Co sprawdzić, gdy już widzisz ruch

• Czy klient przejmuje żądanie? Nieprzejęte żądanie oznacza, że klient GA4 nie jest skonfigurowany na ścieżkę używaną przez przeglądarkę.
• Czy sygnały zgód przeżywają przeskok? Parametry gcs i gcd powinny dotrzeć do kontenera serwerowego, a nie zgubić się po drodze.
• Czy nazwa zdarzenia jest nienaruszona? Zmiana nazwy w locie to częsta przyczyna sytuacji „zdarzenie się odpala, ale raport jest pusty”.
• Które platformy są przekazywane? Zdarzenie Meta lub TikTok z event_id i bez odpowiadającego mu piksela w przeglądarce zwykle znaczy, że wysyła je serwer — sprawdź duplikaty po drugiej stronie.

Krótka lista kontrolna

1. Przeładuj stronę z otwartym panelem, żeby złapać pierwsze żądanie.
2. Poszukaj plakietki server-side przy żądaniach GA4 — to potwierdza, że klasyfikacja po ścieżce znalazła Twój endpoint.
3. Sprawdź na liście ciasteczek, czy jest FPID z HttpOnly.
4. Wklej token podglądu, żeby podłączyć sesję serwerową.
5. Porównaj zdarzenia z przeglądarki z tym, co raportuje serwer; różnica to miejsce, w którym tracisz dane.

Jak to zrobić w panelu →

Reszta tej grupy: GA4, server-side i atrybucja

• Debugowanie GA4, gdy DebugView nic nie pokazuje
• GA4 liczy wszystko dwa razy
• Google Tag Gateway: sprawdzenie, czy naprawdę działa
• Gdy GA4 twierdzi, że ruch przyszedł skądinąd
• E-mail, który wyszedł otwartym tekstem

Cała grupa GA4, server-side i atrybucja