Debug GA4 Measurement Protocol: dlaczego 2xx niczego nie dowodzi

GA4 Measurement Protocol zwraca status 2xx dla niemal wszystkiego, co do niego wyślesz: poprawnego zdarzenia, zdarzenia z literówką, zdarzenia bez client_id, wymyślonego secret. Dlatego kod statusu jest bezużyteczny przy debugowaniu. Aby debugować wywołania GA4 Measurement Protocol, wyślij to samo body do serwera walidacji pod /debug/mp/collect, przeczytaj zwrócone validationMessages, popraw wskazane elementy i dopiero wtedy potwierdź dotarcie zdarzenia w DebugView albo Realtime.

Ten ostatni krok jest ważniejszy, niż wiele osób zakłada. Dlaczego? Serwer walidacji nie sprawdza Twojego API secret, więc payload może przejść walidację, dostać 204 z prawdziwego endpointu i nadal nigdy nie trafić do Twojej usługi. Widziałam zespół, który stracił na tym tydzień, zanim komukolwiek przyszło do głowy, żeby ponownie skopiować secret.

Jeśli łączysz zdarzenia server-side do śledzenia kampanii, główny przewodnik o śledzeniu UTM od początku do końca pokazuje, co powinno znaleźć się w linku, zanim dojdziesz do tego etapu. Ten post dotyczy chwili, w której wysyłasz zdarzenie, a nic się nie pojawia.

Dlaczego Measurement Protocol odpowiada 2xx na wszystko

Dokumentacja protokołu Google mówi to wprost: endpoint zwraca kod statusu 2xx, jeśli żądanie HTTP zostało odebrane, i nie zwraca błędu, gdy payload jest źle zbudowany albo dane nie są przetworzone. Zbieranie działa w modelu "wyślij i zapomnij". Twój serwer nigdy nie czeka na przetwarzanie.

Sprawdziliśmy to sami. POST do /mp/collect z body {"garbage":true}, fałszywym measurement ID i wymyślonym secret wrócił jako HTTP 204 z pustym body. Tak samo jak idealne zdarzenie.

Logika ponawiania oparta na kodach statusu łapie awarie sieci. Nic więcej. Nie powie Ci, że GA4 odrzuciło Twoje zdarzenia. Do tego potrzebujesz drugiego endpointu.

Jak używać serwera walidacji pod /debug/mp/collect

Serwer walidacji measurement protocol znajduje się na tym samym hoście. Ten sam ciąg zapytania, ta sama treść żądania:

curl -s -X POST \
  "https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"events":[{"name":"session_start","params":{"firebase_x":1}}]}'

Odpowiada 200 z treścią JSON zamiast pustej odpowiedzi. Ten testowy payload ma trzy problemy, a serwer raportuje pierwszy, na który trafia:

{
  "validationMessages": [
    {
      "fieldPath": "client_id",
      "description": "Measurement requires a client_id.",
      "validationCode": "VALUE_REQUIRED"
    }
  ]
}

Dodaj client_id, a przejdzie dalej do NAME_RESERVED dla session_start; zmień nazwę zdarzenia, a następny będzie prefiks firebase_. Każdy komunikat ma fieldPath, opis dla człowieka i kod. Kody udokumentowane przez Google obejmują VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES i NAME_DUPLICATED.

Pusta tablica, "validationMessages": [ ], oznacza, że struktura jest w porządku. Nic wysłane do /debug/mp/collect nie jest zapisywane. Używaj go intensywnie podczas prac programistycznych, ile chcesz; pamiętaj tylko, że wywołanie debug nigdy nie dowodzi, że dane dotarły.

Czego serwer walidacji nie sprawdza

Większość tutoriali pomija tę część. Strona Google o walidowaniu zdarzeń mówi wprost, że serwer walidacji nie weryfikuje api_secret. W naszym teście z 22 września 2026 nie sprawdzał też measurement ID: G-FAKE123 z sekretem nonsense zwrócił pustą tablicę validationMessages.

Błędny secret przechodzi. Tak samo unieważniony, taki z innego strumienia danych albo literówka w G-. Measurement protocol api_secret to najczęstsza przyczyna, jaką widzę przy "poprawnym payloadzie bez danych", a potwierdzić go możesz tylko wtedy, gdy zobaczysz, że zdarzenie dotarło.

Druga luka to tryb walidacji. Domyślnie serwer działa w trybie RELAXED i w tym trybie przepuścił dwie rzeczy zakazane przez limity samego Google: zdarzenie z 26 parametrami oraz wartość parametru o długości 120 znaków. Dodaj "validation_behavior": "ENFORCE_RECOMMENDATIONS" do treści wywołania debug, a oba przypadki się wyłożą, z EXCEEDED_MAX_ENTITIES i VALUE_TOO_LONG. Zawsze walidowałabym w trybie rygorystycznym, nawet jeśli produkcja zostaje w trybie relaxed. To różnica między sprawdzarką a pieczątką.

Jak zobaczyć zdarzenia serwerowe w GA4 DebugView i Realtime

Gdy payload przejdzie walidację, wyślij go do prawdziwego endpointu i sprawdź, czy dotrze. Dwa widoki działają dla zdarzeń serwerowych, a standardowe raporty nie są jednym z nich, bo mogą być opóźnione o 24 do 48 godzin.

DebugView wymaga włączenia dla każdego zdarzenia. Przewodnik weryfikacji Google prosi o "debug_mode": 1 (albo true) w parametrach zdarzenia oraz dodatnie engagement_time_msec. Pojawiają się tylko zdarzenia z tą flagą, więc paczka, w której jedno zdarzenie jej nie ma, wygląda na półpustą. Otwórz sekcję Administracja, potem DebugView, i daj mu minutę.

Realtime nie wymaga niczego dodatkowego. Przewiń do karty "Event count by Event name" i poszukaj swojego zdarzenia. Google zaznacza, że session_id i engagement_time_msec mają znaczenie dla widoczności aktywności użytkownika w Realtime, więc jeśli zdarzenie przechodzi walidację, ale Realtime pozostaje puste, najpierw sprawdź te dwa pola.

Jeszcze jedno zastrzeżenie z tego samego przewodnika: według niego w strumieniach internetowych poprawne zdarzenie używa client_id, którego gtag.js już użył. Syntetyczne identyfikatory nadal są zliczane, każdy jako osobny użytkownik, ale nigdy nie łączą się z sesją w przeglądarce, a w raporcie opartym na sesjach widać to jako długi ogon użytkowników z jednym zdarzeniem, którego nie umiesz wyjaśnić, dopóki nie wiesz, skąd się wziął. Więcej o tym w następnej sekcji. Jeśli brakuje danych kampanii, a nie zdarzeń, parametry UTM niewidoczne w GA4 przeprowadza przez stronę DebugView tego problemu.

Typowe błędy payloadu i odpowiedzi walidatora

Większość zepsutych zdarzeń wpada w kilka schematów. Oto one wraz z tym, co zwrócił serwer walidacji, gdy wysłaliśmy każde z nich 22 września 2026:

Dwa wiersze wymagają komentarza. Prefiks ga_ jest zarezerwowany według dokumentacji, a mimo to walidator zaakceptował ga_session_id w obu trybach, gdy go próbowaliśmy, więc nie traktuj pustej tablicy jako zgody. Limit 100 znaków dla wartości bardzo często łapie pełne docelowe adresy URL: strona docelowa z pięcioma tagami UTM często jest dłuższa.

Samo client_id jest subtelne. Dowolny ciąg znaków przechodzi walidację relaxed, ale tryb rygorystyczny odrzucił zarówno c1, jak i elido-12-4711 z komunikatem "It should be in . format". Jeśli Twoje zdarzenia muszą sklejać się z sesjami w przeglądarce, wysyłaj prawdziwą wartość _ga; przewodnik po śledzeniu server-side w GA4 wyjaśnia to sklejanie szczegółowo.

Jak używają tego GA4 Forwarder i Test connection w Elido

Elido przekazuje kliknięcia krótkich linków do GA4 po stronie serwera. Wklejasz Measurement ID i Measurement Protocol API secret do karty GA4 w Integracjach, a od tego momentu każde kliknięcie w tym obszarze roboczym staje się jednym zdarzeniem link_click:

{
  "client_id": "elido-12-4711",
  "events": [
    {
      "name": "link_click",
      "params": {
        "workspace_id": 12,
        "link_id": 4711,
        "slug": "spring-26",
        "country": "DE",
        "device": "mobile",
        "destination": "https://shop.example/spring?utm_source=newsletter",
        "engagement_time_msec": 100
      }
    }
  ]
}

client_id ma postać elido-<workspace>-<link>, więc każde kliknięcie jednego linku czyta się jako ten sam użytkownik GA4 i żadne nie łączy się z sesją przeglądarki. To uczciwy kompromis, gdy robisz to bez ciasteczka: sumy oraz podziały według slug, kraju i urządzenia działają; liczby użytkowników i lejki sesji nie. Kraj i urządzenie są zwykłymi parametrami zdarzenia. Najpierw zarejestruj je jako wymiary niestandardowe. A destination powyżej 100 znaków wpada w limit z tabeli wyżej, więc raportuj po slug albo link_id zamiast po nim.

Przycisk Test connection działa w kolejności zalecanej w tym artykule:

Najpierw wysyła syntetyczne link_click, oznaczone elido_test: true, do /debug/mp/collect. Jeśli validationMessages nie jest puste, test kończy się błędem i pokazuje opisy Google dosłownie. Jeśli tablica jest pusta, to samo zdarzenie idzie naprawdę do /mp/collect. Pod przyciskiem widzisz odpowiedź dostawcy (status HTTP, endpoint debug z Twoim measurement ID, ale nigdy z sekretem, oraz body Google) plus notatkę, że Measurement Protocol nie weryfikuje API secret.

Zielony wynik oznacza więc "poprawne i Google je odebrał". Nie "Twoja usługa je ma". Zdarzenie testowe zawiera debug_mode: 1 i elido_test: true, więc pojawia się w DebugView jako link_click; w Realtime też je zobaczysz. Jeśli chcesz zdarzenia kliknięć w GA4 bez taga na każdej stronie docelowej, utwórz obszar roboczy i najpierw skieruj kartę GA4 do usługi testowej.

Kolejność debugowania GA4 Measurement Protocol, która działa

Gdy zdarzenia GA4 się nie pojawiają, przejdź przez te kroki i zatrzymaj się na pierwszej awarii:

1. Wyślij body do /debug/mp/collect z validation_behavior ustawionym na ENFORCE_RECOMMENDATIONS. Popraw każdy komunikat.
2. Skopiuj API secret ponownie z sekcji Administracja, Strumienie danych, Twój strumień internetowy, Measurement Protocol API secrets. Sprawdź, czy pochodzi z tego samego strumienia co identyfikator G-.
3. Wyślij jedno zdarzenie do /mp/collect z debug_mode: 1 i obserwuj DebugView przez dwie minuty.
4. Usuń flagę i sprawdź Realtime, potem daj standardowym raportom dzień lub dwa.

Krok 2 to miejsce, w którym kończy się większość mojego debugowania. Strona rozwiązywania problemów Google zaczyna od tych samych trzech pytań: właściwy secret, nadal ważny, skopiowany dokładnie. Gdy liczby w końcu płyną, ale nadal nie zgadzają się z liczbą kliknięć linków, kliknięcia krótkich linków kontra sesje GA4 wyjaśnia różnicę, a śledzenie konwersji po stronie serwera omawia zdarzenia konwersji, które zwykle idą następne. Ten sam nawyk "najpierw waliduj, potem weryfikuj" dotyczy innych miejsc docelowych na stronie śledzenia konwersji.

Powiązane na blogu

• Śledzenie GA4 server-side przez redirecty - dane dostępowe, kształt payloadu i sklejanie client_id.
• Mixpanel kontra GA4 dla analityki linków - które narzędzie powinno przechowywać dane kliknięć.
• Śledzenie kliknięć linków w Mixpanel - ten sam forwarder skierowany do Mixpanel, z jego własną osobliwością 200-za-wszystko.
• Parametry UTM niewidoczne w GA4 - wersja tego problemu debugowania dotycząca danych kampanii.
• Śledzenie konwersji po stronie serwera - GA4, Meta CAPI i TikTok obok siebie.