Śledzenie po stronie serwera GA4 przez warstwę przekierowań

Tagowanie GA4 po stronie klienta przez gtag.js lub GTM to punkt bazowy atrybucji, do którego domyślnie sięga większość zespołów. Działa dobrze w idealnych warunkach: użytkownik Chrome na komputerze stacjonarnym, szybkie połączenie, brak blokady reklam, sesja Safari, która nie uruchomiła 24-godzinnego limitu cookie ustawianego przez skrypt ITP. Idealne warunki obejmują może 65–75% ruchu z UE w 2026 roku.

Reszta - użytkownicy uBlock Origin, wbudowane blokowanie Brave, Intelligent Tracking Prevention Safari na iOS, rosnąca kohorta blokad na poziomie sieci jak NextDNS i Pi-hole - wysyła zdarzenia, które albo gubią się zanim dotrą do www.google-analytics.com, albo docierają bez użytecznego identyfikatora klienta, bo cookie _ga zostało wyczyszczone. Typowa luka w przypadku odbiorców z przewagą UE to 25–35% zdarzeń konwersji. Dla niektórych branż - fintech, narzędzia do prywatności, narzędzia deweloperskie - jest wyższa, bo demografia użytkowników koreluje z adopcją blokad reklam.

GA4 Measurement Protocol to ścieżka po stronie serwera, która omija to wszystko. Twój serwer komunikuje się bezpośrednio z endpointem zbierania danych Google. Stan przeglądarki jest nieistotny. Ten post omawia dokładną konfigurację: poświadczenia, kształt ładunku, zszywanie client_id, walidację i wzorzec deduplikacji dla zespołów uruchamiających gtag obok ścieżki po stronie serwera.

Podstawowa architektura przekazywania konwersji - dlaczego serwer wygrywa i jak działa fan-out do wielu platform - jest omówiona w przeglądzie śledzenia konwersji po stronie serwera. Wersja tego poradnika dla Meta CAPI znajduje się w przekazywaniu konwersji do Meta CAPI; wzorzec konfiguracji ma ten sam kształt, tutaj specyficzne dla GA4 parametry.

TL;DR

• GA4 gtag.js traci 25–35% zdarzeń konwersji na typowym ruchu z UE przez blokady reklam (uBlock, Brave) i ITP (limity czasu życia cookie Safari); Measurement Protocol omija to wszystko, ponieważ żądanie pochodzi z Twojego serwera.
• Potrzebujesz dwóch poświadczeń: Measurement ID (G-XXXXXXXX) ze strumienia danych i sekretu API wygenerowanego w Admin → Data Streams → Measurement Protocol API secrets. Tych samych dwóch rzeczy wymaga integracja GA4 w Elido, która przekazuje zdarzenia kliknięć (nie zakupy) i konfiguruje się w około dwie minuty.
• client_id to pole, które łączy zdarzenie po stronie serwera z sesją GA4. Elido nie nadaje ID kliknięcia ani nie ustawia cookie przy przekierowaniu i nie przekazuje jeszcze zakupów do GA4, więc client_id przechwytujesz na własnej stronie i wysyłasz zdarzenie Measurement Protocol z własnego serwera.
• Walidacja zajmuje około dziesięciu minut: GA4 DebugView pokazuje zdarzenia Measurement Protocol pojawiające się w ciągu około dziesięciu sekund; standardowe raporty uzupełniają się przez 24–48 godzin.

Dwa potrzebne poświadczenia

GA4 Measurement Protocol wymaga dwóch informacji, obu z konsoli administratora GA4.

Measurement ID. Identyfikator strumienia danych, w formacie G-XXXXXXXX. Znajdź go w Admin → Data Streams → Twój strumień web → panel szczegółów strumienia. To ten sam ID, który podajesz do gtag('config', 'G-XXXXXXXX') w swojej konfiguracji po stronie klienta - nie jest to sekret; pojawia się w źródle Twojej strony.

Sekret API. To poświadczenie autoryzujące zapisy po stronie serwera do endpointu zbierania danych. Przejdź do Admin → Data Streams → Twój strumień web → Measurement Protocol API secrets → Create. Sekret to krótki alfanumeryczny ciąg. Traktuj go jak klucz konta usługi: przechowuj jako sekret workspace'u, rotuj go wraz z innymi poświadczeniami usług, nie commituj do kodu źródłowego.

W Elido wklejasz je w Workspace Settings w sekcji Integrations → GA4. Test connection wysyła następnie zdarzenie testowe do serwera walidacji GA4 i, jeśli ładunek przejdzie, wysyła je do GA4 z ustawionym debug_mode. Ta kontrola obejmuje ładunek, nie poświadczenia: serwer walidacji akceptuje dowolny sekret API, a nawet Measurement ID, który nie należy do żadnej usługi, więc pomyślne przejście nie dowodzi poprawności pary. Potwierdź zdarzenie testowe w DebugView lub Realtime, zanim zaczniesz na nim polegać.

Kształt zdarzenia

Dokumentacja GA4 Measurement Protocol (dostęp 2026-05-12) określa format żądania. Endpoint to:

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=<secret>

Treść zawiera client_id, opcjonalne user_id i tablicę events. Oto ładunek dla zdarzenia zakupu:

{
  "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "user_id": "user-shop-12847",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "ord_98231",
        "value": 89.5,
        "currency": "EUR",
        "engagement_time_msec": 1,
        "items": [
          {
            "item_id": "sku-spring-jeans-32-blue",
            "item_name": "Spring Jeans 32 Blue",
            "quantity": 1,
            "price": 89.5
          }
        ]
      }
    }
  ]
}

Kilka rzeczy w tym ładunku, które łatwo zepsuć:

event_name musi być w lowercase snake_case. Dokumentacja zdarzeń GA4 (dostęp 2026-05-12) zawiera listę zalecanych nazw zdarzeń: purchase, sign_up, generate_lead, add_to_cart. Wysłanie Purchase (z wielkiej litery P) stworzy oddzielne zdarzenie o nazwie Purchase w raportach GA4 zamiast łączenia się z Twoimi zdarzeniami purchase z gtag. Platforma Cię nie ostrzega; zdarzenie po prostu ląduje jako dziwnie nazwane zdarzenie niestandardowe.

engagement_time_msec musi być obecne i ustawione na dodatnią liczbę całkowitą. Bez tego GA4 liczy zdarzenie, ale nie przypisuje zaangażowania sesji, a niektóre modele atrybucji wykluczają zdarzenia bez czasu zaangażowania. Ustawienie 1 wystarczy do spełnienia tego wymogu.

event_params jest ograniczone do 25 parametrów na zdarzenie. Measurement Protocol odrzuci ładunki przekraczające ten limit. Odrzucenie jest domyślnie ciche - żądanie zwraca 204 bez treści niezależnie od tego, czy zdarzenie zostało zaakceptowane. Używaj debugowego endpointu z validation_behavior ustawionym na ENFORCE_RECOMMENDATIONS (opisanego w sekcji walidacji), aby wychwytywać przepełnienia; tryb domyślny przepuszcza 26. parametr.

user_id jest opcjonalne, ale wartościowe. Jeśli masz trwały identyfikator użytkownika po stronie serwera - ID klienta w tabeli zamówień, ID subskrybenta w CRM - wyślij go. GA4 używa go do atrybucji między urządzeniami i poprawia dopasowanie między zdarzeniami po stronie serwera i klienta.

Zszywanie client_id: dlaczego ma znaczenie i jak obsługuje to Elido

client_id to pole, którego GA4 używa do powiązania zdarzenia po stronie serwera z sesją przeglądarki. Gdy gtag.js uruchamia się na stronie, odczytuje cookie _ga i używa jego UUID jako client_id dla wszystkich zdarzeń, które wysyła. Jeśli Twoje zdarzenie po stronie serwera zawiera ten sam client_id, GA4 może zszyć te zdarzenia w tę samą podróż użytkownika i sesję.

Wyzwaniem jest przeniesienie tego UUID na stronę serwera. Cookie _ga to first-party cookie na Twojej domenie, więc Twój serwer może je odczytać w momencie realizacji zamówienia i dołączyć do ładunku konwersji. Ale to działa tylko wtedy, gdy przeglądarka użytkownika ma ustawione _ga, co jest dokładnie populacją, którą tracisz przez ITP i blokady reklam.

Elido jeszcze tego nie rozwiązuje na poziomie przekierowania: nie ustawia cookie ani nie dopisuje ID kliknięcia do docelowego URL i nie przekazuje konwersji do GA4. ID kliknięcia w przekierowaniu jest w naszym backlogu, nie jest wdrożone. Do tego czasu zszywanie budujesz sam, na własnej stronie. Przepływ:

Twoja strona docelowa lub menedżer tagów odczytuje wartość _ga, jeśli istnieje, albo generuje własny first-party UUID, jeśli nie istnieje, i zapisuje ją w niestandardowych atrybutach zamówienia. W momencie konwersji Twój webhook zamówienia niesie tę wartość. Twój serwer buduje ładunek Measurement Protocol z client_id ustawionym na nią i wysyła go do GA4.

Zapisanie identyfikatora w zamówieniu w momencie wizyty jest bardziej niezawodne niż odczytywanie _ga przy realizacji zamówienia, ponieważ nawet jeśli ITP wyczyści cookie w ciągu 24 godzin, atrybut zamówienia pozostaje w Twojej bazie danych niezależnie od tego.

Przewodnik GA4 dotyczący wysyłania zdarzeń (dostęp 2026-05-12) opisuje, jak client_id działa na ścieżkach klienta i serwera.

Przekazywanie Elido: właściwe polecenie curl

Elido nie składa ani nie przekazuje tego ładunku dla zakupów; robi to Twój własny serwer, gdy dociera webhook zamówienia. Wywołanie, które wykonuje, a które możesz też uruchomić ręcznie, żeby przetestować stronę GA4 tego połączenia, wygląda tak:

curl -X POST \
  "https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "user_id": "user-shop-12847",
    "events": [
      {
        "name": "purchase",
        "params": {
          "transaction_id": "ord_98231",
          "value": 89.50,
          "currency": "EUR",
          "engagement_time_msec": 1
        }
      }
    ]
  }'

GA4 zwraca 204 zarówno dla prawidłowych, jak i nieprawidłowych zdarzeń. Nie możesz odróżnić zniekształconego zdarzenia od pomyślnego ingestionu wyłącznie po kodzie statusu HTTP. Aby sprawdzić, czy zdarzenie jest poprawnie sformułowane, używaj debugowego endpointu podczas rozwoju:

POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET

Debugowy endpoint zwraca treść JSON zawierającą listę błędów walidacji dla każdego zdarzenia. Zdarzenie z błędną nazwą parametru, ładunek przekraczający 25 parametrów lub zniekształcony client_id pojawi się tutaj. Niektóre z tych problemów pojawiają się dopiero, gdy w treści żądania debugowego ustawisz validation_behavior na ENFORCE_RECOMMENDATIONS, a sekret API nigdy nie jest sprawdzany; przewodnik debugowania Measurement Protocol omawia, co walidator wykrywa, a czego nie.

Podczas używania Elido Test connection uruchamia tę kontrolę za Ciebie i wyświetla wszelkie validationMessages jako błąd. Czysty wynik nadal nic nie mówi o sekrecie API, dlatego kolejnym krokiem jest DebugView.

Walidacja: DebugView

GA4 DebugView to najszybsza pętla informacji zwrotnych podczas konfiguracji. Aby aktywować go dla zdarzeń po stronie serwera, dodaj "debug_mode": 1 do obiektu params zdarzenia. Zdarzenia z tą flagą pojawiają się w DebugView w ciągu około dziesięciu sekund; nie wliczają się do danych raportów produkcyjnych.

W DebugView (GA4 Admin → DebugView) każde zdarzenie pokazuje swoją nazwę, parametry, które niosło, i czy jakieś parametry zostały odrzucone. Widok grupuje zdarzenia według client_id, więc możesz śledzić pełną sesję od kliknięcia do konwersji.

Co zweryfikować przed usunięciem debug_mode:

• Nazwa zdarzenia pojawia się dokładnie tak, jak oczekiwano w strumieniu zdarzeń DebugView (purchase, a nie Purchase ani ecommerce_purchase).
• Parametr transaction_id jest widoczny i pasuje do formatu Twojego ID zamówienia.
• client_id to ciąg w formacie UUID - nie pusty, nie zastępczy ciąg "unknown".
• currency to prawidłowy kod ISO 4217 (EUR, nie eur, nie Euro).

Standardowe raporty GA4 potrzebują 24–48 godzin, aby odzwierciedlić dane konwersji po stronie serwera. Nie oceniaj dokładności raportów w pierwszym dniu. DebugView potwierdza kształt zdarzenia; raporty potwierdzają atrybucję i sumy.

Typowe błędy

Brakujące client_id. Zdarzenia bez client_id są cicho odrzucane przez Measurement Protocol. To najczęstszy pojedynczy scenariusz awarii. Porzucenie jest niewidoczne - żądanie zwraca 204, DebugView nic nie pokazuje, konwersja nigdy się nie pojawia. Sprawdź, że pole client_id jest zawsze wypełnione przed wysłaniem żądania. W powyższej konfiguracji brakujące client_id oznacza, że identyfikator nie został zapisany w zamówieniu w momencie konwersji - sprawdź tag na stronie docelowej lub handler webhooka.

Błędny format nazwy zdarzenia. Purchase tworzy niestandardowe zdarzenie o nazwie Purchase obok istniejących zdarzeń purchase z gtag. Łączna liczba zakupów w raportach GA4 dzieli się na dwie nazwy zdarzeń. Rozwiązaniem jest wymuszenie lowercase snake_case dla wszystkich nazw zdarzeń wysyłanych do endpointu Measurement Protocol. Dokumentacja zdarzeń GA4 (podlinkowana powyżej) zawiera kanoniczne nazwy dla zdarzeń e-commerce.

Przekroczenie 25 event_params. Measurement Protocol cicho odrzuca ładunki z więcej niż 25 parametrami na zdarzenie. Zespoły przekazujące pełne metadane zamówienia (wszystkie pozycje, wszystkie niestandardowe atrybuty) często trafiają na ten limit, nie zdając sobie z tego sprawy. Używaj debugowego endpointu w trybie ENFORCE_RECOMMENDATIONS do wychwytywania przepełnień podczas rozwoju. Na produkcji usuwaj nieistotne parametry i trzymaj ładunki zdarzeń zwięźle.

Waluta pobrana z konfiguracji strony, a nie z zamówienia. Jeśli konfiguracja gtag domyślnie ustawia USD, ale Twoje zamówienia są w EUR, zdarzenie po stronie serwera i zdarzenie po stronie klienta niosą różne wartości waluty. GA4 rejestruje je pod tą samą nazwą zdarzenia, ale nie może agregować wartości. Pobieraj walutę z rekordu zamówienia w backendzie, a nie z konfiguracji gtag na poziomie strony.

Deduplikacja z gtag po stronie klienta

Jeśli uruchamiasz gtag.js po stronie klienta i Measurement Protocol po stronie serwera jednocześnie, potrzebujesz deduplikacji. GA4 deduplikuje zdarzenia używając client_id w połączeniu z oknem czasowym. Mechanizm jest mniej wyraźny niż pole event_id Meta CAPI, ale praktyczne podejście jest takie samo: nies spójny transaction_id w zdarzeniach zakupu na obu ścieżkach.

Dla zdarzeń zakupu ustaw transaction_id na ID zamówienia. Twój gtag po stronie przeglądarki wysyła purchase z transaction_id: "ord_98231" gdy ładuje się strona potwierdzenia; zdarzenie Measurement Protocol po stronie serwera niesie ten sam transaction_id: "ord_98231". GA4 deduplikuje w tym samym oknie sesji. Jeśli ta sama kombinacja client_id + transaction_id dotrze dwa razy w oknie deduplikacji, drugie jest ignorowane.

Dla zdarzeń upstream - generate_lead, sign_up, add_to_cart - nie ma ID zamówienia do użycia. Identyfikator odwiedzającego, który sam wygenerowałeś, działa tutaj: ustaw event_id na UUID zapisany na Twojej stronie. Zarówno piksel po stronie przeglądarki, jak i wywołanie po stronie serwera odwołują się do tej samej wartości. To ta sama dyscyplina opisana w poradniku śledzenia UTM end-to-end, który omawia szerszą konfigurację tagowania kampanii, która przenosi identyfikatory przez cały lejek.

Okno deduplikacji w GA4 nie jest publicznie udokumentowane z precyzją, jaką Meta publikuje dla CAPI. W praktyce zdarzenia z pasującym client_id + transaction_id docierające w tym samym oknie sesji są deduplikowane. Uruchamianie obu ścieżek jednocześnie to bezpieczniejsza konfiguracja - zapewnia pokrycie fallback dla odbiorców z ciężkimi blokadami reklam, dając jednocześnie algorytmowi czystszy sygnał ze ścieżki serwera.

Miejsce tego rozwiązania w pipeline atrybucji

Measurement Protocol zamyka lukę sygnału GA4 w ten sam sposób, w jaki CAPI zamyka lukę sygnału Meta. Mechanizmy są różne - GA4 używa client_id i transaction_id, gdzie Meta używa event_id i kluczy dopasowania - ale architektura jest identyczna: zdarzenie po stronie serwera, które nie zależy od stanu przeglądarki.

Dla pełnego obrazu, do których platform przekazywać i jak działa fan-out w skali, przegląd śledzenia konwersji po stronie serwera omawia GA4, Meta CAPI i TikTok Events obok siebie. Dla kampanii, gdzie tagowanie UTM jest poprzedzającym krokiem, śledzenie kampanii UTM end-to-end to wymagana lektura.

Powierzchnia produktu dla tej konfiguracji: funkcje śledzenia konwersji dokumentują to, co działa dziś: zakupy ze Stripe i Shopify powiązane z linkiem przez elido_link_id. Przekazywanie zakupów do GA4, Meta lub TikTok nie jest jeszcze dostępne. Rozwiązania dla marketerów pokazuje, jak pipeline konwersji pasuje do przepływu pracy kampanii obok szablonów UTM i inteligentnego routingu linków.

Sama konfiguracja - poświadczenia w konfiguracji Twojego serwera, krok menedżera tagów zapisujący identyfikator na stronie docelowej, instalacja webhooka zamówień - zajmuje pół dnia dla większości zespołów. Krok walidacji DebugView dodaje kolejne trzydzieści minut. Wynikiem są dane konwersji GA4 odzwierciedlające to, co Twoje kampanie naprawdę generują, a nie 65–75% z nich, które przeżyje ścieżkę po stronie przeglądarki.

---

Źródła

• Google Analytics 4: Measurement Protocol overview. developers.google.com/analytics/devguides/collection/protocol/ga4 (dostęp 2026-05-12)
• GA4 Measurement Protocol: Event reference. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (dostęp 2026-05-12)
• GA4 Measurement Protocol: Sending events. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (dostęp 2026-05-12)