Tutorial: Odczyt żądania GA4 collect parametr po parametrze
Spis treści
Trafienie GA4 to jedno żądanie HTTP, a wszystko, czego usługa kiedykolwiek dowie się o tej chwili, stoi w jego ciągu zapytania. Sześćdziesiąt parametrów, wszystkie skrócone do dwóch albo trzech znaków, żaden objaśniony w interfejsie.
Umiejętność ich odczytania opłaca się z jednego powodu: to jedyne miejsce, w którym widać, co przeglądarka naprawdę wysłała. Każdy raport, każdy podgląd i każdy wskaźnik zgody leży za tym żądaniem – a wartość, której tu brakuje, nigdy nie została wysłana.
Znalezienie żądania
Żądanie idzie pod /g/collect, wprost do Google albo do kontenera serwerowego, jeśli taki działa. W panelu sieci przeglądarki filtr na collect skraca listę dokładnie do tych trafień.
https://www.google-analytics.com/g/collect
?v=2&tid=G-AB12CD34>m=45je55h0v9182736&_p=1737041234567
&cid=1234567890.1737041234&ul=de-de&sr=2560x1440&_s=2
&sid=1737041234&sct=4&seg=1&dl=https%3A%2F%2Fshop.example%2Fkasse
&dt=Kasse&dr=https%3A%2F%2Fwww.google.com%2F&en=purchase
&ep.payment_type=card&epn.value=129.9&cu=EUR&_et=4312
&pr1=idSKU-42~nmStuhl~caMoebel~pr64.95~qt2&gcs=G111Dwie praktyczne uwagi o tym, gdzie się chowa. Małe trafienia jadą jako GET i parametry stoją wtedy w adresie; większe przechodzą na POST, a wtedy adres niesie tylko część, a reszta siedzi w ciele żądania. I kilka zdarzeń da się spakować w jeden POST, po jednym na linię – ciało z trzema liniami to trzy trafienia, a nie jedno.
Żądanie, które w ogóle się nie pojawia, samo jest wynikiem, a przyczyny bywają trzy: brak zgody i tag się wstrzymuje, blokada reklam usunęła skrypt albo tag nigdy nie zadziałał. Te trzy rozdziela debuger tagów, a nie ten widok.
Parametry, które oznaczają
Pierwsza grupa odpowiada, kto wysyła i do której usługi. Te parametry stoją na każdym trafieniu i rzadko się zmieniają.
| Parametr | Znaczenie |
|---|---|
| v=2 | Wersja protokołu – 2 to GA4, 1 było Universal Analytics |
| tid | Identyfikator pomiaru usługi docelowej |
| cid | Identyfikator klienta, wartość z ciasteczka _ga bez przedrostka |
| sid | Identyfikator sesji – sekunda epoki, w której sesja się zaczęła |
| sct | Liczba sesji tego klienta |
| seg | 1, gdy sesja liczy się jako angażująca, wcześniej 0 |
| _p | Liczba losowa na każde wczytanie strony, wiąże trafienia jednej strony |
| _s | Licznik w obrębie wczytania strony – pierwsze trafienie to 1 |
Dwa z nich są pożyteczniejsze, niż wyglądają. Identyfikator sesji jest znacznikiem czasu i mówi dokładnie, kiedy sesja się zaczęła – sesja startująca wciąż od nowa widać tutaj wcześniej niż w jakimkolwiek raporcie. A _s uwidacznia luki: strona, której trafienia skaczą z 1 na 3, po drodze jedno zgubiła.
Parametry, które opisują stronę
Druga grupa to kontekst i tam powstaje najwięcej błędnych wartości, bo te parametry tag może nadpisać.
dl to adres strony i przychodzi zakodowany procentowo; z niego powstaje ścieżka strony i każdy parametr zapytania, który GA4 później wykazuje. dr to odsyłacz i przy wejściu bezpośrednim pozostaje pusty. dt to tytuł dokumentu, wzięty w chwili zadziałania – dlatego aplikacja jednostronicowa działająca przed zmianą tytułu melduje tytuł poprzedniej strony.
ul to język przeglądarki, a sr rozdzielczość ekranu. Oba pochodzą z przeglądarki i są dwoma polami najczęściej zdradzającymi odwiedzającego automatycznego: rozdzielczość 800×600 wraz z angielskim ustawieniem języka w niemieckim sklepie to wzorzec, a nie osoba.
Jedno warto sprawdzać tutaj, a nie w raporcie: czy dl niesie parametry, które w analityce nie mają czego szukać. Wszystko za znakiem zapytania trafia do wymiaru strony, a formularz wpisujący adres pocztowy do adresu URL wysyła go najpierw tutaj.
Zdarzenie i jego parametry
Trzecia grupa to to, co faktycznie się stało, i trzyma się prostej zasady nazewniczej.
en=purchase nazwa zdarzenia
ep.payment_type=card parametr zdarzenia, tekst
epn.value=129.9 parametr zdarzenia, liczba
up.plan=premium właściwość użytkownika, tekst
upn.credits=40 właściwość użytkownika, liczba
_et=4312 czas zaangażowania w milisekundach od ostatniego trafienia
cu=EUR walutaRóżnica między ep. a epn. kosztuje najwięcej czasu, gdy jest postawiona źle. Liczba wysłana jako tekst ląduje w wymiarze tekstowym, nie daje się sumować i nie da się jej później zamienić w miarę – a nic nie zgłasza błędu, bo parametr tekstowy o zawartości 129.9 jest całkowicie poprawny.
Czas zaangażowania jest naliczany na trafienie, a nie na sesję: każde żądanie niesie milisekundy od poprzedniego. Strona wysyłająca tu stale 0 nie jest oglądana – albo coś zeruje licznik.
Dane e-commerce w jednym polu
Artykuły nie dostają po własnym parametrze. Pakowane są w pr1, pr2 i dalej, po jednym polu na artykuł, z dwuliterowymi kodami i tyldą jako rozdzielnikiem.
pr1=idSKU-42~nmStuhl~caMoebel~pr64.95~qt2~brNordholz~vaEiche| Kod | Pole GA4 | Kod | Pole GA4 |
|---|---|---|---|
| id | item_id | pr | price |
| nm | item_name | qt | quantity |
| br | item_brand | ds | discount |
| ca | item_category | cp | coupon |
| c2 … c5 | item_category2 … 5 | ln | item_list_name |
| va | item_variant | lp | index |
Trzy rzeczy stają się sprawdzalne, gdy tylko to jest czytelne. Czy każdy artykuł niesie id – artykuł bez niego zostaje po cichu odrzucony. Czy pr jest czystą liczbą: cena przychodząca jako 64,95 z przecinkiem albo ze znakiem waluty nie jest liczbą, a przychód pozostaje pusty. Oraz czy suma ceny razy ilość zgadza się z epn.value, bo oba wysyłane są niezależnie od siebie, a rozbieżność między nimi nie jest widoczna w żadnym raporcie.
Liczba artykułów ma górną granicę, którą łatwo osiągnąć. Żądanie ma ograniczenie długości, a koszyk z dwustoma pozycjami je przekracza – GA4 przechodzi wtedy na POST, a powyżej tego skraca. Zakup, którego lista artykułów jest w raportach krótsza niż w sklepie, to niemal zawsze właśnie to.
Pola zgody
Ostatnia grupa jest krótka i rozstrzyga więcej niż cała reszta razem.
gcs=G111 ad_storage udzielone, analytics_storage udzielone
gcs=G100 oba odmówione
gcs=G101 ad_storage odmówione, analytics_storage udzielone
gcd=13t3t3t3t5 ustawienia domyślne sprzed decyzjiDwie cyfry za G1 to pamięć reklamowa i pamięć analityczna w tej kolejności, 1 dla udzielonej i 0 dla odmówionej. Trafienie z G100 jest pingiem bez ciasteczka: liczy się do modelowania, ale nie zapisuje identyfikatora, a identyfikator klienta w nim powstaje na każde żądanie od nowa, zamiast być przechowywany.
Polem do zestawienia jest gcd, zapisujące, jak brzmiały ustawienia domyślne. Kontener, którego ustawienia domyślne przychodzą jako udzielone, choć baner nie został jeszcze rozstrzygnięty, to błędna konfiguracja ujawniająca się wyłącznie tutaj – raporty wyglądają zwyczajnie, bo dane przecież napływają.
Ostatnie sprawdzenie trwa dziesięć sekund i kończy całą klasę sporów: przeładować stronę z odmówioną zgodą i poszukać żądania. Jeśli wychodzi trafienie z gcs=G100, tryb zgody działa zgodnie z zamysłem. Jeśli nie wychodzi nic, tag jest blokowany w całości – to inny układ z innymi raportami, a warto wiedzieć, który z nich zachodzi.
Powiązane artykuły
