Ś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. Oba wklejasz w ustawieniach workspace'u Elido w mniej niż dwie minuty.
• client_id to pole, które łączy zdarzenie po stronie serwera z sesją GA4; Elido ustawia first-party cookie UUID przy przekierowaniu krótkiego linku i dołącza go do każdego przekazywanego zdarzenia konwersji, więc nie musisz odczytywać cookie _ga z przeglądarki.
• 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. Po zapisaniu Elido waliduje parę względem debugowego endpointu GA4 i potwierdza łączność. Walidacja jest natychmiastowa; błąd 4xx na tym etapie oznacza, że Measurement ID lub sekret API jest niepoprawny.

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 (opisanego w sekcji walidacji), aby wychwytywać przepełnienia.

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 rozwiązuje to na poziomie warstwy przekierowań. Gdy użytkownik klika krótki link, handler edge Elido generuje UUID i ustawia go jako first-party cookie _elido_cid w odpowiedzi przekierowania - zanim użytkownik dotrze do Twojej strony. UUID jest też dołączany do docelowego URL jako ?elido_click=<uuid> (konfigurowalne per workspace). Przepływ:

Twoja strona docelowa lub menedżer tagów odczytuje elido_click z URL i zapisuje go w niestandardowych atrybutach zamówienia. W momencie konwersji Twój webhook zamówienia niesie UUID. Elido go wyszukuje, buduje ładunek Measurement Protocol z client_id ustawionym na ten UUID i przekazuje do GA4.

Jest to bardziej niezawodne niż odczytywanie _ga z przeglądarki, ponieważ UUID jest przechwytywany w momencie kliknięcia, zanim sesja przeglądarki użytkownika określi, czy cookies są akceptowane. Nawet jeśli ITP wyczyści cookie _ga w ciągu 24 godzin, cookie _elido_cid Elido pozostaje jako first-party cookie pod Twoją domeną krótkiego linku - a 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#

Gdy POST /v1/conversions dociera z click_id, Elido składa ładunek Measurement Protocol i przekazuje go. Aby wywołać endpoint bezpośrednio - omijając Elido i testując stronę GA4 MP instalacji - polecenie curl 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 faktycznie dotarło, 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.

Podczas używania Elido ta sama widoczność walidacji jest dostępna przez GET /v1/conversions/{id} - rekord konwersji pokazuje status przekazania GA4 i wszelkie odpowiedzi błędów z debugowego endpointu w trybie testowym.

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 konfiguracji Elido brakujące client_id oznacza, że parametr elido_click 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 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. ID kliknięcia działa tutaj: ustaw event_id na UUID z elido_click. Zarówno piksel po stronie przeglądarki, jak i przekazanie 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 sprawia, że ten ID jest dostępny w całym lejku.

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.

Interfejs produktu dla tej konfiguracji: funkcje śledzenia konwersji dokumentuje pełne API /v1/conversions, w tym fan-out do wielu platform, zdarzenia zwrotów i semantykę ponownych prób. 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 ustawieniach workspace'u, krok menedżera tagów dla elido_click 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)