Tutorial: Odczyt żądania GA4 collect parametr po parametrze

Żądanie GA4 Collect pokazuje dane, które przeglądarka próbuje wysłać do punktu zbierania. Adres, treść żądania i nagłówki tworzą całość. Treść zawiera dane poza adresem URL, a nagłówki przekazują dodatkowe informacje o żądaniu, np. typ zawartości. Jedno żądanie może zawierać kilka zdarzeń, a końcowy raport zależy również od przetwarzania, konfiguracji i innych źródeł. Stała lista sześćdziesięciu parametrów nie opisuje każdego żądania.

Poniższe skróty służą do diagnozowania transportu przeglądarkowego tagu Google. Nie stanowią stabilnego publicznego API do tworzenia własnych żądań. Udokumentowane pola zdarzeń gtag i Measurement Protocol są osobnymi interfejsami. Kodowanie wewnętrzne może się zmieniać; bieżąca implementacja tagu Google została sprawdzona 24 października 2026 r.

Całe żądanie zamiast samego adresu

Rejestracja w DevTools zaczyna się przed akcją testową; Preserve log zachowuje wpisy po nawigacji. Filtr collect jest przydatnym początkiem, ale może objąć inne usługi i pominąć własną ścieżkę zbierania. Adres docelowy, metoda, inicjator, czas, dane i odpowiedź określają rzeczywistą drogę.

Parametry mogą wystąpić w query, treści POST lub obu miejscach. Żądania zbiorcze mogą współdzielić parametry adresu między kilkoma wierszami zdarzeń. Małe GET i duże POST nie są uniwersalną regułą. Paczka zakodowana wierszami wymaga analizy wspólnego kontekstu oraz rekordów; dowolne linie nieznanej treści nie są automatycznie zdarzeniami.

Poniższy sztuczny przykład ma podziały linii dla czytelności i nie jest rzeczywistym żądaniem. Identyfikatory są zastępcze. Zakup zawiera identyfikator transakcji, wartość, walutę i produkt; przykład służy do odczytu, a nie ręcznego ponownego wysyłania zakupu.

https://www.google-analytics.com/g/collect
  ?v=2&tid=G-EXAMPLE&cid=1234567890.1737041234
  &sid=1737041234&sct=4&dl=https%3A%2F%2Fshop.example%2Fcheckout
  &dt=Checkout&en=purchase&ep.transaction_id=ORDER-EXAMPLE-42
  &epn.value=129.9&cu=EUR
  &pr1=idSKU-42~nmChair~pr64.95~qt2

Cel i kontekst sesji

Nie każde żądanie zawiera każde pole. Identyfikator pomiaru oznacza strumień danych internetowych w usłudze. Identyfikator klienta opisuje instancję przeglądarki, a nie zweryfikowaną osobę; zgoda na zapis, konfiguracja i pomiar między domenami wpływają na pochodzenie oraz trwałość wartości.

Automatyczne identyfikatory sesji GA4 wykorzystują sekundy od 1 stycznia 1970 r., godziny 00:00 UTC, czyli początku epoki Unix. Sam identyfikator sesji nie jest globalnie unikalny; wartości ustawione ręcznie lub dostarczone przez serwer wymagają osobnej oceny. Luka w wewnętrznym liczniku nie dowodzi utraty pakietu: początek rejestracji, filtry, grupowanie i kilka miejsc docelowych mogą zmieniać widoczną kolejność. Brak żądania może też wynikać z błędu skryptu, CSP, innego endpointu albo niedopasowanego wyzwalacza. Panel sieci, konsola i Tag Assistant dostarczają uzupełniających dowodów.

Kontekst strony i dane wrażliwe

dl, dr i dt zwykle przenoszą adres strony, odsyłacz i tytuł. Domyślne wartości pochodzą z dokumentu przeglądarki, ale konfiguracja i redakcja danych mogą zmieniać wynik. Brak odsyłacza nie dowodzi wejścia bezpośredniego: polityka przeglądarki lub ochrona prywatności może go usunąć. W aplikacji jednostronicowej treść zmienia się bez pełnego ponownego wczytania dokumentu. Moment zdarzenia i jawnie podany tytuł muszą odpowiadać właściwej stronie.

ul i sr opisują język oraz rozdzielczość ekranu. Angielski interfejs i 800×600 pikseli nie dowodzą automatyzacji. Te wartości nie sprawdzają tożsamości i nie są wiarygodnym klasyfikatorem botów.

Zdekodowany adres wymaga kontroli wrażliwych ścieżek, wartości query i innych niezamierzonych danych. Treść query nie staje się automatycznie wymiarem niestandardowym; ścieżka strony i pełny adres są różnymi wymiarami. Redakcja danych może usuwać wybrane wartości przed wysłaniem, ale działa w określonym zakresie i bez gwarancji wykrycia wszystkiego. Poprawny adres nie ocenia pozostałych parametrów ani nagłówków.

Wartości zdarzeń i zaangażowanie

en zwykle określa zdarzenie. Ogólne pola ep./epn. rozróżniają tekst i liczby w sprawdzonym transporcie. up./upn. pełnią podobną funkcję dla właściwości użytkownika; pola predefiniowane mogą mieć własne kody, na przykład cu dla waluty. Jeżeli szablon normalizuje wartość wejściową, ostateczne żądanie pozostaje właściwą kontrolą.

Prefiks transportu nie tworzy automatycznie wymiaru ani wskaźnika raportowego. Raportowanie własnych danych wymaga odpowiedniej definicji, a Google może interpretować tekst przypominający liczbę jako liczbę. Wartości liczbowe powinny odpowiadać schematowi zdarzenia już u źródła. Samo Number nie wystarcza do walidacji: pusty tekst staje się zerem, przecinek dziesiętny daje NaN, a Infinity nie jest poprawną skończoną kwotą.

_et zwykle oznacza milisekundy zaangażowania. Zaangażowanie mierzy czas skupienia na stronie lub działania aplikacji na pierwszym planie, a nie sam odstęp między żądaniami HTTP. Wartość może trafić do późniejszego zdarzenia albo zostać pominięta przy braku nowego czasu zaangażowania. Zero lub brak pola nie dowodzą nieobecności człowieka.

Produkty i sumy zakupu

W sprawdzonym formacie przeglądarkowym pr1, pr2 i dalsze pola mogą zawierać po jednym spakowanym produkcie. Poniższe zestawienie popularnych kodów pomaga w odczycie, ale nie jest kompletną specyfikacją parsera. Separatory, kodowanie i własne parametry produktów wymagają ostrożności.

Udokumentowany produkt wymaga item_id lub item_name; zalecane są oba pola. Sam brak id nie oznacza odrzucenia. Wartość zakupu jest sumą ceny razy ilość, bez wysyłki i podatku, z odpowiednią walutą. W przykładzie 64,95 × 2 daje 129,90. Identyfikatory transakcji muszą konsekwentnie oznaczać rzeczywiste zakupy, aby umożliwić zapobieganie duplikatom.

Udokumentowana tablica items dopuszcza do 200 elementów. Dokładnie 200 produktów nie dowodzi przepełnienia transportu, a skrócona lista w raporcie nie ma jednej automatycznej przyczyny. Konstrukcja danych, limity zdarzeń, przetwarzanie i zakres raportu wymagają porównania. Przychód zdarzenia i przychód produktu mają różne zakresy; rozbieżności można badać także w odpowiednich raportach lub eksportach.

Sygnały zgody i ich granice

gcs przenosi stany pamięci reklamowej i analitycznej. Typowe wartości to G111 dla obu udzielonych, G100 dla obu odmówionych, G101 tylko dla pamięci analitycznej i G110 tylko dla reklamowej. Obejmują dwa sygnały, a nie całe wdrożenie zgód. gcd zawiera bardziej szczegółowe informacje i jest wysyłane również bez aktywnego trybu zgody; nie opisuje jedynie ustawień domyślnych.

Tag Assistant ułatwia sprawdzenie ustawień domyślnych, aktualizacji i czterech istotnych sygnałów Google: ad_storage, analytics_storage, ad_user_data oraz ad_personalization. Zgłoszone stany wymagają porównania z kolejnością, faktycznym działaniem tagów, zapisem i wyborem w banerze, również po późniejszym wycofaniu zgody.

Zaawansowany tryb zgody może wysyłać pomiary bez cookies przy odmowie pamięci analitycznej; podstawowy blokuje tagi Google do wymaganej zgody. Samo żądanie G100 nie dowodzi poprawnej inicjalizacji, braku wszystkich identyfikatorów ani kwalifikacji do modelowania. Sygnały bez cookies mogą zawierać losową wartość na wczytanie strony; nowy identyfikator klienta dla każdego żądania nie jest bezpiecznym założeniem ogólnym. Sam brak widocznego żądania nie wyjaśnia przyczyny blokady.

Odbiór i przetwarzanie serwerowe

HTTP 204 oznacza odpowiedź bez treści. Nie jest walidacją schematu każdego zdarzenia ani gwarancją raportowania. DebugView wymaga trybu debugowania i może pomijać zdarzenia przy ochronie prywatności po stronie klienta lub odmowie zgody na analityczne cookies. Widok czasu rzeczywistego i raporty przetworzone odpowiadają na inne pytania; nie są kompletnymi rejestrami surowych żądań.

Przy tagowaniu serwerowym przeglądarka zwykle pokazuje tylko drogę do kontenera serwerowego. Podgląd kontenera przedstawia żądanie wejściowe, obsługującego klienta, dane zdarzenia, uruchomione tagi i żądania wyjściowe. Te zapisy ujawniają dodane, usunięte lub zmienione pola. Same dane przeglądarki nie dowodzą, co odebrał i później przetworzył końcowy punkt zbierania.

Czy brak parametru oznacza, że GA4 nigdy nie pozna wartości?

Brak pola dowodzi wyłącznie nieobecności w danej części zapisu. Treść żądania, nagłówki, inne żądania, wzbogacenie serwerowe i późniejsze przetwarzanie są osobnymi źródłami.

Czy Collect jest Measurement Protocol?

Opisany transport przeglądarkowy i udokumentowany JSON Measurement Protocol mają różne formaty oraz procedury walidacji. Query przeglądarki nie jest treścią JSON Measurement Protocol.

Kontrola w praktyce: porównanie wielu żądań Collect

Analizator parametrów GA4 może teraz badać kilka przeglądarkowych żądań Collect razem. Każdy wiersz zawiera jeden adres lub ciąg query/body zakodowany jak parametry URL. Jeżeli parametry należą do wspólnego adresu żądania POST, osobne pole wspólnych parametrów pokazuje ten kontekst w każdym wierszu.

Przegląd przedstawia nazwy zdarzeń, identyfikatory pomiaru i powtarzające się klucze. Porównanie pokazuje tylko różnice: brak klucza różni się od klucza z pustą wartością. Różne typy zdarzeń naturalnie zawierają różne parametry, więc sama różnica nie dowodzi błędu pomiaru. Powtórzone klucze zachowują pierwotną kolejność. Narzędzie nie twierdzi, które wystąpienie wykorzystuje odbiorca.

Wartości są dekodowane raz i wyświetlane jako tekst, również gdy przypominają HTML. Opcjonalny plik CSV zawiera zdekodowane wartości i nie jest anonimizowany. Analizator pomaga więc sprawdzić nieoczekiwany adres strony lub parametr, ale nie jest kompletnym detektorem danych osobowych. Brak widocznego problemu nie dowodzi, że wdrożenie nie zawiera takich danych.

Wklejone żądania nie są odtwarzane ani wysyłane. Narzędzie opisuje wejście, a nie przyjęcie danych przez Google. Rzeczywisty pomiar można w odpowiednich przypadkach sprawdzić w Google DebugView. Dekodowanie query opiera się na regułach kodowania formularzowego URL; spakowane segmenty produktów są interpretowane heurystycznie. Dla JSON Measurement Protocol przeznaczony jest osobny walidator.

Źródła

• Google Analytics: zalecane zdarzenia i pola zakupu
• Google Tag Platform: omówienie trybu zgody
• Google Analytics: zaangażowanie użytkowników
• Google Analytics: dokumentacja konfiguracji
• Google Analytics: niestandardowe wymiary i dane
• Google Analytics: usuwanie danych wrażliwych
• Chrome DevTools: funkcje panelu sieciowego
• Google Analytics: monitorowanie zdarzeń w DebugView
• Google Tag Manager: podgląd i diagnoza kontenerów serwerowych
• Google Tag Platform: kontrola trybu zgody w Tag Assistant
• Google Analytics: sesje w Analytics
• Google Analytics: pomiar handlu elektronicznego
• Tag Google: dostarczana implementacja JavaScript, sprawdzona 24 października 2026
• IETF RFC 9110: 204 – odpowiedź bez treści
• MDN: JavaScript Number
• Google Analytics: walidacja zdarzeń Measurement Protocol