{"id":17211,"date":"2026-10-10T18:10:00","date_gmt":"2026-10-10T16:10:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=17211"},"modified":"2026-10-09T22:44:51","modified_gmt":"2026-10-09T20:44:51","slug":"ladunki-measurement-protocol-w-ga4-kazde-pole-kazdy-limit-i-dlaczego","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/ladunki-measurement-protocol-w-ga4-kazde-pole-kazdy-limit-i-dlaczego\/","title":{"rendered":"\u0141adunki Measurement Protocol w GA4: ka\u017cde pole, ka\u017cdy limit i dlaczego endpoint odpowiada 204 na uszkodzony JSON"},"content":{"rendered":"

\u017b\u0105danie Measurement Protocol to pojedynczy POST po HTTPS: ci\u0105g zapytania z dwoma danymi dost\u0119powymi i tre\u015b\u0107 JSON ze zdarzeniami. T\u0105 drog\u0105 do us\u0142ugi GA4 trafiaj\u0105 dane, kt\u00f3re nie pochodz\u0105 z przegl\u0105darki \u2014 konwersje offline z CRM, p\u0142atno\u015b\u0107 potwierdzona webhookiem, backend aplikacji, nadrobienie trafie\u0144 po\u0142kni\u0119tych przez blokad\u0119 reklam.<\/p>\n

To zarazem jedyna droga dostarczania danych w ca\u0142ej uk\u0142adance, kt\u00f3ra nigdy nie m\u00f3wi, czy si\u0119 powiod\u0142a.<\/p>\n

\n\"Po
Z czego sk\u0142ada si\u0119 \u0142adunek i co odpowiada endpoint produkcyjny, gdy jego cz\u0119\u015bci s\u0105 b\u0142\u0119dne.<\/figcaption><\/figure>\n

Co odpowiada endpoint<\/h2>\n

Dziewi\u0119\u0107 \u017c\u0105da\u0144 trafi\u0142o 9 wrze\u015bnia 2026 na https:\/\/www.google-analytics.com\/mp\/collect<\/code>, ka\u017cde z wymy\u015blonym identyfikatorem pomiaru, aby nigdzie nic nie zosta\u0142o zapisane. Siedem z nich by\u0142o celowo uszkodzonych.<\/p>\n

Osiem z dziewi\u0119ciu wr\u00f3ci\u0142o jako 204 No Content<\/strong>, w oko\u0142o 100 milisekundach i z pust\u0105 tre\u015bci\u0105. Nie tylko to poprawne: tak\u017ce zdarzenie o nazwie zaczynaj\u0105cej si\u0119 od podkre\u015blenia, puste events<\/code>, \u0142adunek z wymy\u015blonym polem na najwy\u017cszym poziomie, \u017c\u0105danie bez client_id<\/code> oraz tre\u015b\u0107, kt\u00f3ra wcale nie by\u0142a JSON-em. \u017b\u0105danie ca\u0142kiem bez ci\u0105gu zapytania<\/strong> \u2014 bez identyfikatora pomiaru, bez sekretu API \u2014 r\u00f3wnie\u017c wr\u00f3ci\u0142o z kodem 204.<\/p>\n

Dok\u0142adnie dwie rzeczy wywo\u0142a\u0142y b\u0142\u0105d HTTP i \u017cadna z nich nie jest ocen\u0105 \u0142adunku. Tre\u015b\u0107 o rozmiarze 140 kB zosta\u0142a odrzucona kodem 413<\/strong> i stron\u0105 b\u0142\u0119du HTML z warstwy wej\u015bciowej, poniewa\u017c przekroczy\u0142a udokumentowany limit 130 kB, zanim cokolwiek zosta\u0142o odczytane. Metoda GET<\/code> zosta\u0142a odrzucona kodem 405<\/strong>.<\/p>\n

Europejski endpoint region1.google-analytics.com<\/code> zachowuje si\u0119 tak samo. Po pi\u0119\u0107 przebieg\u00f3w na host: mediana czasu obiegu z tego samego serwera wynios\u0142a w obu przypadkach 90 milisekund.<\/p>\n

Kod odpowiedzi potwierdza wi\u0119c tylko, \u017ce \u017c\u0105danie dotar\u0142o. Nie m\u00f3wi, czy zdarzenie zosta\u0142o zrozumiane i zapisane ani czy pomini\u0119to kt\u00f3ry\u015b parametr. Przy wysy\u0142ce tych problem\u00f3w nie wida\u0107; ujawniaj\u0105 si\u0119 dopiero kilka godzin p\u00f3\u017aniej jako brakuj\u0105ce dane w raporcie.<\/p>\n

Gdzie naprawd\u0119 nale\u017cy \u0142adunek<\/h2>\n

Dwie cz\u0119\u015bci, a pomylenie ich jest \u0142atwe.<\/p>\n

Ci\u0105g zapytania<\/strong> niesie dane dost\u0119powe: measurement_id<\/code> dla strumienia sieciowego (albo firebase_app_id<\/code> dla strumienia aplikacji) oraz api_secret<\/code>, zak\u0142adany osobno dla ka\u017cdego strumienia w administracji GA4. \u017badne z nich nie nale\u017cy do JSON-a. Tam staj\u0105 si\u0119 nieznanymi polami, a nieznane pole nie jest pomijane \u2014 czyni ca\u0142y \u0142adunek nieczytelnym.<\/p>\n

Tre\u015b\u0107<\/strong> to obiekt JSON ze sta\u0142ym zestawem dozwolonych kluczy:<\/p>\n

{\n  \"client_id\": \"1234567890.1700000000\",\n  \"user_id\": \"crm-88213\",\n  \"timestamp_micros\": 1788000000000000,\n  \"consent\": { \"ad_user_data\": \"GRANTED\", \"ad_personalization\": \"DENIED\" },\n  \"user_properties\": { \"poziom_klienta\": { \"value\": \"gold\" } },\n  \"events\": [\n    {\n      \"name\": \"purchase\",\n      \"params\": {\n        \"transaction_id\": \"T-8891\",\n        \"currency\": \"EUR\",\n        \"value\": 20,\n        \"session_id\": \"1700000000\",\n        \"engagement_time_msec\": 100,\n        \"items\": [\n          { \"item_id\": \"A-1\", \"item_name\": \"Koszula\", \"price\": 10, \"quantity\": 2 }\n        ]\n      }\n    }\n  ]\n}<\/code><\/pre>\n
Poza tym dokumentacja dopuszcza user_data<\/code>, user_location<\/code>, ip_override<\/code>, device<\/code>, user_agent<\/code>, non_personalized_ads<\/code> i validation_behavior<\/code>. To jest pe\u0142na lista. Wszystko inne \u2014 klucz event<\/code> przeniesiony razem z obiektu dataLayer, otoczka ecommerce<\/code>, notatka dla kole\u017canki z zespo\u0142u \u2014 kosztuje ca\u0142e \u017c\u0105danie.<\/p>\n
Pola identyfikacyjne<\/h2>\n
client_id<\/code> jest w strumieniu sieciowym obowi\u0105zkowe i to jedno pole decyduje, czy zdarzenie do\u0142\u0105czy do istniej\u0105cego u\u017cytkownika, czy wymy\u015bli nowego. Zalecana posta\u0107 to dwie dodatnie liczby po\u0142\u0105czone kropk\u0105 \u2014 dok\u0142adnie to, co wydaje gtag('get')<\/code> i co zwraca wbudowana zmienna Analytics Client ID w Google Tag Managerze. Pe\u0142na warto\u015b\u0107 ciasteczka _ga<\/code>, czyli GA1.1.1234567890.1700000000<\/code>, te\u017c jest przyjmowana; obie liczby siedz\u0105 w \u015brodku.<\/p>\n
Warto\u015b\u0107 wymy\u015blona na serwerze r\u00f3wnie\u017c zostanie przyj\u0119ta i to jest kosztowna pomy\u0142ka. \u015awie\u017cy identyfikator przy ka\u017cdym \u017c\u0105daniu tworzy za ka\u017cdym razem nowego u\u017cytkownika i now\u0105 sesj\u0119 \u2014 us\u0142uga wygl\u0105da na ruchliw\u0105, a sk\u0142ada si\u0119 wy\u0142\u0105cznie z sesji po jednym zdarzeniu.<\/p>\n
Strumienie aplikacji u\u017cywaj\u0105 zamiast tego app_instance_id<\/code>: 32 znaki szesnastkowe z SDK Firebase, a nie client_id pod inn\u0105 nazw\u0105. Wys\u0142anie obu nie szkodzi i nie pomaga; pole nale\u017c\u0105ce do drugiego rodzaju strumienia zostaje pomini\u0119te.<\/p>\n
user_id<\/code> jest opcjonalne, ma najwy\u017cej 256 znak\u00f3w i musi by\u0107 ci\u0105giem znak\u00f3w. To klucz \u0142\u0105cz\u0105cy, nie osoba: adres e-mail albo numer telefonu w tym polu to dana osobowa, czego warunki korzystania z Google Analytics zabraniaj\u0105 i co wystarczy jako pow\u00f3d usuni\u0119cia us\u0142ugi. To samo dotyczy ka\u017cdego parametru zdarzenia i ka\u017cdej w\u0142a\u015bciwo\u015bci u\u017cytkownika.<\/p>\n
Dwa parametry, od kt\u00f3rych zale\u017cy zgodno\u015b\u0107 raport\u00f3w<\/h2>\n
Zdarzenie bez session_id<\/code> nie nale\u017cy do \u017cadnej sesji. Nadal zostaje zapisane i policzone, ale sesje, sesje anga\u017cuj\u0105ce i wymiary o zakresie sesji si\u0119 nie zgadzaj\u0105, a w widoku czasu rzeczywistego zdarzenia mo\u017ce zabrakn\u0105\u0107 zupe\u0142nie.<\/p>\n
Zdarzenie bez engagement_time_msec<\/code> nie wnosi nic do \u015bredniego czasu zaanga\u017cowania, kt\u00f3ry dla ruchu dostarczonego t\u0105 drog\u0105 pokazuje wtedy zero.<\/p>\n
\u017badne z nich nie jest obowi\u0105zkowe, \u017cadne nie wywo\u0142uje nigdzie ostrze\u017cenia i oba s\u0105 zwyk\u0142\u0105 odpowiedzi\u0105 na \u201ezdarzenia docieraj\u0105, ale raport si\u0119 nie zgadza”. session_id<\/code> musi by\u0107 dodatni\u0105 liczb\u0105 ca\u0142kowit\u0105 \u2014 w typowym przypadku znacznikiem czasu \u2014 i mo\u017ce zosta\u0107 wys\u0142ane jako liczba albo jako ci\u0105g cyfr. Litery w \u015brodku s\u0105 odrzucane.<\/p>\n
Zdarzenie i jego nazwa<\/h2>\n
Zdarzenie to obiekt z dok\u0142adnie dwoma dozwolonymi kluczami: name<\/code> i params<\/code>. Znacznik czasu postawiony obok nich jako trzeci klucz psuje \u0142adunek; znacznik dla pojedynczego zdarzenia nale\u017cy do params<\/code> jako timestamp_micros<\/code>.<\/p>\n
Nazwy musz\u0105 zaczyna\u0107 si\u0119 od litery i mog\u0105 zawiera\u0107 wy\u0142\u0105cznie litery, cyfry i podkre\u015blenia. My\u015blniki, kropki i spacje s\u0105 odrzucane wprost. Nazwy rozr\u00f3\u017cniaj\u0105 wielko\u015b\u0107 liter<\/strong> i to jest przypadek najcichszy: Purchase<\/code> zostanie przyj\u0119te, zostanie zapisane i jest innym zdarzeniem ni\u017c purchase<\/code> \u2014 w raportach e-commerce nie pojawi si\u0119 nigdy, bo te s\u0105 podpi\u0119te pod nazw\u0119 pisan\u0105 ma\u0142ymi literami.<\/p>\n
Trzydzie\u015bci jeden nazw Google zachowuje dla siebie, w\u015br\u00f3d nich session_start<\/code>, first_visit<\/code>, user_engagement<\/code>, app_remove<\/code> i error<\/code>. Trzy kolejne \u2014 screen_view<\/code>, ad_impression<\/code> i in_app_purchase<\/code> \u2014 istniej\u0105, ale s\u0105 dozwolone tylko w strumieniach aplikacji. W strumieniu sieciowym po prostu nie zostan\u0105 zebrane i nikt nigdzie o tym nie wspomina.<\/p>\n
Parametry i obowi\u0105zuj\u0105ce je limity<\/h2>\n
Wszystkie limity protoko\u0142u w jednym miejscu:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Co<\/th>\nLimit<\/th>\n<\/tr>\n
Tre\u015b\u0107 JSON<\/td>\nponi\u017cej 130 kB<\/td>\n<\/tr>\n
Zdarzenia na \u017c\u0105danie<\/td>\n25<\/td>\n<\/tr>\n
Nazwa zdarzenia<\/td>\n40 znak\u00f3w<\/td>\n<\/tr>\n
Parametry na zdarzenie<\/td>\n25<\/td>\n<\/tr>\n
Nazwa parametru<\/td>\n40 znak\u00f3w<\/td>\n<\/tr>\n
Warto\u015b\u0107 parametru<\/td>\n100 znak\u00f3w, 500 w us\u0142udze Analytics 360<\/td>\n<\/tr>\n
W\u0142a\u015bciwo\u015bci u\u017cytkownika na \u017c\u0105danie<\/td>\n25<\/td>\n<\/tr>\n
Nazwa w\u0142a\u015bciwo\u015bci u\u017cytkownika<\/td>\n24 znaki<\/td>\n<\/tr>\n
Warto\u015b\u0107 w\u0142a\u015bciwo\u015bci u\u017cytkownika<\/td>\n36 znak\u00f3w<\/td>\n<\/tr>\n
user_id<\/code><\/td>\n256 znak\u00f3w<\/td>\n<\/tr>\n
Pozycje na zdarzenie<\/td>\n200<\/td>\n<\/tr>\n
W\u0142asne parametry na pozycj\u0119<\/td>\n10<\/td>\n<\/tr>\n
Datowanie wstecz<\/td>\n72 godziny<\/td>\n<\/tr>\n<\/table>\n
Nazwy parametr\u00f3w nie mog\u0105 zaczyna\u0107 si\u0119 od _<\/code>, firebase_<\/code>, ga_<\/code>, google_<\/code> ani gtag.<\/code>, a firebase_conversion<\/code> jest zastrze\u017cone wprost. Nazwy w\u0142a\u015bciwo\u015bci u\u017cytkownika podlegaj\u0105 tym samym regu\u0142om przedrostk\u00f3w plus pi\u0119ciu nazwom zastrze\u017conym, spo\u015br\u00f3d kt\u00f3rych po user_id<\/code> si\u0119ga si\u0119 przez pomy\u0142k\u0119 najcz\u0119\u015bciej \u2014 identyfikator u\u017cytkownika nale\u017cy na najwy\u017cszy poziom, a nie do user_properties<\/code>.<\/p>\n
Tablic\u0105 mo\u017ce by\u0107 wy\u0142\u0105cznie items<\/code>. Ka\u017cdy inny parametr przyjmuje pojedyncz\u0105 warto\u015b\u0107; obiekt zagnie\u017cd\u017cony odpada, a w raporcie parametr pojawia si\u0119 jako brakuj\u0105cy, nie jako b\u0142\u0119dny.<\/p>\n
Gdzie oba maksima wchodz\u0105 sobie w drog\u0119<\/h2>\n
Dwadzie\u015bcia pi\u0119\u0107 zdarze\u0144 na \u017c\u0105danie i dwie\u015bcie pozycji na zdarzenie s\u0105 udokumentowane oba, a razem si\u0119 nie mieszcz\u0105. Zmierzone na wygenerowanych \u0142adunkach z realistycznymi polami pozycji \u2014 identyfikator, nazwa, marka, kategoria, wariant, cena, ilo\u015b\u0107:<\/p>\n