GA4 Measurement Protocol: Serwerowa integracja konwersji offline z CRM

GA4 Measurement Protocol uzupełnia pomiar internetowy o zdarzenia serwerowe, na przykład zakup potwierdzony później w CRM. Pozwala zarejestrować sprzedaż także wtedy, gdy w chwili finalizacji nie powstaje zdarzenie w przeglądarce. Nie oznacza to automatycznego ani bezbłędnego przypisania przychodu do pierwotnej kampanii.

Rzetelna integracja rozdziela trzy pytania: która instancja przeglądarki lub znane konto odpowiada zdarzeniu, kiedy zakup rzeczywiście nastąpił oraz jaką analizę ma wspierać zdarzenie. Przetworzenie danych, atrybucja sesji i eksport reklamowy mają różne wymagania.

1. Zachowanie identyfikatorów bez wymyślania powiązań

• client_id: W strumieniu internetowym identyfikuje instancję przeglądarki. Połączenie z istniejącymi zdarzeniami wymaga rzeczywiście przechwyconej wartości. Podobnie sformatowany identyfikator wymyślony z numeru CRM nie tworzy takiego powiązania. Identyfikator jest pseudonimowy, a nie automatycznie anonimowy.
• session_id: Dodatni liczbowy parametr zdarzenia identyfikuje konkretną sesję. Google tag udostępnia wartość przez gtag('get', 'G-XXXXXXXXXX', 'session_id', callback), a identyfikator przeglądarki przez analogiczne wywołanie z client_id. Parsowanie pozycji wewnętrznych pól ciasteczka nie jest potrzebne. Proces pobierania musi obsługiwać wartości brakujące lub jeszcze niedostępne.
• user_id: Opcjonalny, spójny identyfikator konta może łączyć znaną aktywność po zalogowaniu. Dowolny numer leada nie staje się automatycznie identyfikatorem osoby na różnych urządzeniach. Adresy e-mail, numery telefonów i inne bezpośrednio identyfikujące dane nie powinny trafiać do tych zwykłych pól identyfikatorów ani zdarzeń.

Identyfikatory są pobierane wyłącznie w dozwolonym kontekście pomiarowym i przechowywane dla określonego celu. Brak wartości oznacza lukę w danych, a nie powód do stworzenia fikcyjnej tożsamości. Strumienie aplikacji używają innych pól, w szczególności firebase_app_id i app_instance_id; przykład dotyczy wyłącznie strumienia internetowego.

2. Czas zakupu a okno sesji

Przykład: lead powstaje w poniedziałek, a zakup następuje w piątek. Szybkie zgłoszenie w piątek nie jest zakupem wysłanym cztery dni za późno. Zakupu nie należy jednak datować na poniedziałek tylko po to, aby dopasować starą sesję. Prawidłowe zdarzenie zakupu może znajdować się poza oknem atrybucji pierwotnej sesji.

Google rozróżnia także sposób walidacji. Przy RELAXED lub braku ustawienia dokumentacja przewiduje przesunięcie czasu zdarzeń starszych niż 72 godziny na 72 godziny przed odebraniem. Przy ENFORCE_RECOMMENDATIONS takie zdarzenia są odrzucane. Test debug na dokładnej granicy sekundowej nie dowodzi więc powszechnego odrzucania produkcyjnego ani gwarantowanej tolerancji. Kolejka wysyłkowa powinna zachowywać zapas czasu i jawnie obsługiwać przeterminowane rekordy zamiast zmieniać moment zakupu.

Ogólna dokumentacja wysyłania podaje dodatkowo 48 godzin dla zdarzeń przeznaczonych do wspólnego przetwarzania ze zdarzeniami klienckimi. Dla atrybutów sesji obowiązuje bardziej szczegółowy warunek 24 godzin. Różnych zastosowań nie należy łączyć w jedno uniwersalne okno atrybucji.

3. Ładunek zakupu bez fikcyjnej sesji

Poniższe żądanie HTTPS przedstawia zakup wysyłany bezpośrednio w chwili rzeczywistego wystąpienia. Pominięcie timestamp_micros oznacza użycie czasu żądania przez GA4. Opóźniona wysyłka wymaga rzeczywistego czasu zdarzenia jako liczbowego znacznika Unix w mikrosekundach. Stałe daty skopiowane z przykładu nie nadają się do tego celu. Przykładowy identyfikator, numer transakcji i dane dostępowe wymagają zastąpienia prawdziwymi wartościami dopuszczonymi do użycia.

POST /mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=SERVER_SIDE_SECRET HTTP/1.1
Host: www.google-analytics.com
Content-Type: application/json

{
  "client_id": "1234567890.1700000000",
  "consent": {
    "ad_user_data": "DENIED",
    "ad_personalization": "DENIED"
  },
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "CRM_INV_EXAMPLE_001",
        "value": 1499.0,
        "currency": "EUR",
        "items": [
          {
            "item_id": "SKU_ENTERPRISE_PLAN",
            "item_name": "Enterprise Service License",
            "price": 1499.0,
            "quantity": 1
          }
        ]
      }
    }
  ]
}

Stare session_id i wymyślony czas zaangażowania zostały celowo pominięte. Właściwe analizy sesji i czasu rzeczywistego zależą od poprawnej sesji oraz rzeczywiście zmierzonego engagement_time_msec; arbitralne 100 milisekund tworzyłoby fikcyjny pomiar. Przykład nie gwarantuje zatem pełnej widoczności w Realtime ani metrykach sesji.

transaction_id musi być unikalne dla zamówienia, niepuste i pozbawione danych bezpośrednio identyfikujących klienta. Ponowienie tego samego zamówienia zachowuje to samo ID. GA4 może ograniczać w ten sposób duplikaty zakupów w strumieniach internetowych; własny dziennik wysyłki i zabezpieczenie przed równoległym podwójnym wysłaniem nadal są potrzebne. Kwota i waluta muszą odpowiadać przyjętej definicji zakupu. Tutaj wartość odpowiada jednej pozycji za 1499 EUR bez doliczonych kosztów dostawy i podatku.

api_secret pozostaje wyłącznie na serwerze i nie powinno pojawiać się w kodzie przeglądarki ani pełnych logach URL żądania. Alternatywny host region1.google-analytics.com umożliwia zbieranie danych w UE; sama nazwa hosta nie określa wszystkich miejsc dalszego przetwarzania.

4. Kontrola uprawnienia i wycofania zgody przed wysyłką

Przesyłanie serwerowe nie zastępuje podstawy prawnej ani nie omija decyzji o zgodzie. Dowód stanu podczas zbierania danych jest istotny. Przy przetwarzaniu opartym na zgodzie przed wysyłką trzeba także uwzględnić późniejsze wycofanie; wcześniejsze dodatnie pole nie stanowi trwałego zezwolenia. Cel, retencja i brak dowodów wymagają jasnych reguł.

Przykładowe pola consent ustawiają reklamowe wykorzystanie danych i reklamę spersonalizowaną na DENIED. Nie zastępuje to oceny dopuszczalności samego przesłania do Analytics. non_personalized_ads jest przestarzałe; aktualny interfejs używa consent.ad_personalization. Bez jawnych pól zgody GA4 może wykorzystać ustawienia powiązanych interakcji online. Kontrolowany proces CRM wymaga ustalonej polityki tego zachowania.

5. Walidacja a rzeczywiste przetwarzanie

/debug/mp/collect sprawdza ładunek i zwraca validationMessages; wysłane tam zdarzenia nie pojawiają się w raportach. Podczas tworzenia integracji Google zaleca ENFORCE_RECOMMENDATIONS. Pusta lista błędów nie dowodzi poprawności danych dostępowych ani przetworzenia we właściwej usłudze. Produkcyjna odpowiedź 2xx potwierdza odbiór HTTP, a nie zaksięgowanie przychodu lub przypisanie kampanii.

Przydatna weryfikacja obejmuje testy ładunku ze sztucznymi danymi, kontrolowany test w oddzielnej usłudze oraz późniejsze uzgodnienie liczby transakcji i kwot. Dziennik wysyłki rozróżnia co najmniej przygotowanie, transport i uzgodnienie. Błędy połączenia, niepewny stan doręczenia i przeterminowane zdarzenia wymagają osobnej obsługi; nieskończone ślepe ponowienia nie potwierdzają sukcesu.