Strona główna / GA4 debugger

Debugger GA4, który pokazuje żądanie

GA4 ma DebugView. Pokazuje, co Google Analytics odebrało, dla usługi, do której masz dostęp, przy włączonym trybie debug. Błędy mieszkają wcześniej.

DebugView to raport. Renderuje zdarzenia po tym, jak GA4 je przyjęło i przetworzyło, dla usługi, do której masz dostęp, i tylko gdy sesja jest oznaczona do debugowania. To czyni go właściwym narzędziem do jednego pytania — czy GA4 to przyjęło — i niewłaściwym do pytania, które ludzie mają zwykle: co przeglądarka faktycznie wysłała.

Tag Master czyta /g/collect wprost. Każdy parametr, w kolejności wysyłki, na dowolnej stronie, bez trybu debug i bez dostępu do usługi.

Czego DebugView nie pokaże

• Żądania, zanim GA4 go dotknęło. Parametry przekraczające limit, wymiary niestandardowe, których nigdy nie zarejestrowano, ucięte wartości — GA4 odrzuca je po cichu, a DebugView pokazuje to, co przetrwało. Nie pokazuje tego, co wysłano i odrzucono.
• Niczego bez trybu debug. DebugView wymaga oznaczonej sesji, czyli rozszerzenia, podglądu GTM albo debug_mode: true. To oznaczenie zmienia zachowanie strony i nie tak mierzony jest Twój prawdziwy ruch.
• Usług, których nie posiadasz. Żadnej konkurencji, żadnego klienta przed umową, żadnego szybkiego rzutu oka na stronę, którą masz przejąć.
• Wszystkiego innego na stronie. Błąd wyglądający na GA4 to często problem Meta albo TikToka w tych samych spodniach — wspólny klucz w dataLayer, jedna bramka zgody uderzająca w oba.

Co widzisz zamiast tego

Zdekodowane trafienie: nazwa zdarzenia, parametry rozbite na postać tekstową i liczbową, identyfikatory klienta i sesji, adres strony i referrer w wysłanej postaci, jadący z nimi sygnał zgody oraz numer sekwencji mówiący, czy trafienie było pierwsze w swojej partii.

Pozycje ecommerce, rozpakowane

GA4 pakuje tablicę pozycji w skompresowaną formę pozycyjną — pr1, pr2, każda to ciąg dwuliterowych kluczy. Technicznie da się to czytać i nikt tego nie czyta. Panel rozpakowuje każdą pozycję z powrotem na pola, więc brakujące ID produktu albo ilość zero widać od razu, zamiast dekodować ręcznie.

Tu właśnie zwykle siedzą problemy raportowania ecommerce: nie tag, który się nie uruchomił, ale tag uruchomiony z tablicą pozycji złożoną z dataLayer opóźnionego o jedną stronę. Dłuższe porównanie z DebugView przechodzi przez to, do czego służy każde z nich.

Zgoda przy każdym trafieniu

W Consent Mode odrzucone trafienie i tak wychodzi; wychodzi oznaczone. Różnica między „brak trafienia" a „trafienie, które powiedziało Google, żeby nie używać go do reklam" jest w DebugView niewidoczna i rozstrzygająca, gdy ktoś pyta, czemu spadły konwersje. Każde żądanie niesie swój stan zgody, czytany obok sekwencji default-potem-update, a nie osobno.

Gdzie DebugView nadal wygrywa

We wszystkim, co GA4 zrobiło po odebraniu trafienia. Czy zdarzenie przypisano do właściwej sesji, czy właściwość użytkownika się utrzymała, czy odbiorcy się dopasowali, czy GA4 przyjęło zarejestrowany wymiar niestandardowy — to wszystko dzieje się po stronie Google i żadne rozszerzenie tego nie zobaczy. Najpierw wyślij trafienie, potem potwierdź, że doleciało. Dwie połowy, dwa narzędzia.

Pytania

Czy mogę debugować GA4 bez DebugView?

Tak, we wszystkim do momentu, w którym GA4 odbierze trafienie. Odczyt żądania /g/collect pokazuje nazwę zdarzenia, parametry, identyfikatory i sygnał zgody w postaci wysłanej przez przeglądarkę, bez trybu debug i bez dostępu do usługi.

Czy potrzebuję debug_mode albo rozszerzenia GA Debugger?

Nie. One istnieją po to, by oznaczyć sesję, żeby DebugView ją wyświetlił. Czytanie sieci nie wymaga żadnego z nich, co zarazem znaczy, że strona zachowuje się dokładnie tak jak dla prawdziwego ruchu.

Czy dekoduje pozycje ecommerce?

Tak. GA4 wysyła pozycje w skompresowanej formie pozycyjnej, a panel rozpakowuje każdą z powrotem na pola, więc brakujące ID produktu albo zerową ilość widać bez ręcznego dekodowania.

Czy pokazuje stan Consent Mode dla każdego trafienia?

Tak. Każde żądanie niesie swój sygnał zgody, pokazany obok sekwencji default-potem-update — tak odróżnia się trafienie odrzucone od takiego, które nigdy nie nastąpiło.

Czy zastępuje DebugView?

Nie i nie taki jest zamiar. DebugView to jedyny wgląd w to, co GA4 zrobiło po odebraniu trafienia: przypisanie sesji, właściwości użytkownika, odbiorcy. To pokazuje, co wysłała przeglądarka. Większość debugowania potrzebuje obu, w tej kolejności.

Poradniki

Dłuższa forma, o częściach, które sprawiają kłopot.

• Debugowanie GA4, gdy DebugView nic nie pokazuje — Dlaczego strumień debugowania jest pusty, co naprawdę zawiera żądanie /g/collect i jak sprawdzić GA4 na produkcji bez włączania trybu debugowania.
• Debugowanie Consent Mode V2: gcs, gcd i naruszenia, których nikt nie łapie — Czytaj parametry zgód wprost z żądań, odróżnij domyślną wartość od aktualizacji i znajdź platformy, które wysyłają dane niezależnie od banera.
• Jak debugować server-side GTM — Dlaczego żądania przepuszczone przez własną domenę znikają z większości narzędzi, cztery sygnały zdradzające sGTM i jak podłączyć podgląd kontenera serwerowego.
• Gdy GA4 twierdzi, że ruch przyszedł skądinąd — Parametry kampanii giną między kliknięciem a żądaniem częściej, niż ktokolwiek sprawdza. Sześć miejsc, w których znikają, i jak odczytać żądanie ze złym źródłem.
• Google Tag Gateway: sprawdzenie, czy naprawdę działa — Tag Gateway serwuje skrypty Google z Twojej domeny. Co zmienia się w żądaniu, czym różni się od server-side GTM i jak po cichu działa połowicznie.
• Test Events dla TikToka, Snapa, UET i pięciu platform — DebugView i Tag Assistant zna każdy. Każda inna platforma ma to samo, włączane plikiem cookie, którego prawie nikt nie dokumentuje — oto pełna lista.

Pozostałe dwie: GTM debugger, inspektor dataLayer