Czym to jest i co trzeba przygotować

Najkrócej: to sposób wysłania do GA4 tego samego rodzaju zdarzenia, jakie normalnie wysyła tag na stronie, tylko żądaniem z serwera.

Konsekwencja tej definicji jest ważniejsza od samej definicji. Tag w przeglądarce robi dwie rzeczy: buduje zdarzenie i dokleja do niego kontekst, o który nikt go nie prosi — urządzenie, język, adres strony, źródło wizyty, identyfikator sesji. Measurement Protocol robi tylko pierwszą rzecz. Kontekst musisz dostarczyć sam albo pogodzić się z jego brakiem.

Google formułuje to zresztą wprost w dokumentacji: protokół ma uzupełniać zbieranie danych po stronie klienta, a nie je zastępować. Traktuję to jako ostrzeżenie napisane przed moimi błędami, a nie jako korporacyjne zastrzeżenie prawne.

Nazwa „rozszerzony protokół” bywa myląca, więc rozwiewam: to nie nowy produkt ani wersja premium, tylko ten sam interfejs w wariancie dla GA4, z inną strukturą danych niż protokół znany z Universal Analytics.

Do pierwszego zdarzenia potrzebujesz czterech rzeczy:

• Identyfikatora pomiaru strumienia danych — tego samego, którego używa tag na stronie.

• Klucza API generowanego w ustawieniach tego strumienia. To sekret: nie umieszcza się go w kodzie strony ani w publicznym repozytorium, bo każdy, kto go ma, może zapisywać dane do Twojej usługi.

• Systemu, który zna prawdę o zamówieniu — aplikacji, systemu sprzedaży, warstwy integracyjnej. Nie kolejnego pośrednika w łańcuchu.

• Decyzji, co jest zdarzeniem i jak się nazywa. Nazw w GA4 nie da się potem sensownie zmienić, więc ustala się je raz.

Jeśli w firmie działa środowisko testowe, zrób dla niego osobny strumień i osobny klucz. Wysyłanie danych testowych do usługi produkcyjnej to najprostszy sposób, żeby zaśmiecić sobie historię na stałe — GA4 nie pozwala usuwać pojedynczych zdarzeń.

Trzy zastosowania, w których to się opłaca

Nie wdrażam tego domyślnie, tylko gdy występuje jedna z trzech sytuacji.

Pierwsza: konwersja potwierdzana poza sesją. Leady przechodzące weryfikację, zamówienia z płatnością odroczoną, rezerwacje domykane telefonicznie. Tag w przeglądarce zliczy tu zapytanie, a nie sprzedaż — i to jest liczba, na której nie da się prowadzić kampanii.

Druga: korekta wartości. Sklep z anulacjami i zwrotami raportuje przychód wyższy od faktycznego, a zdarzenie korygujące z serwera zbliża dane do rzeczywistości.

Trzecia: zdarzenia z systemów bez interfejsu — powiadomienia od operatora płatności, zmiany statusu w magazynie, odnowienia abonamentu. Przeglądarki tam nie ma, więc innej drogi też nie ma.

Czego bym tym nie robił? Nie zbierałbym w ten sposób zwykłego ruchu ani nie obchodził blokad. Do przeniesienia pomiaru na własny serwer służy inne narzędzie — kontener serwerowy w Menedżerze tagów, który kontekst przeglądarki zachowuje, bo dostaje go od tagu na stronie.

Identyfikatory: tu przegrywa większość wdrożeń

Każde zdarzenie wysłane protokołem musi nieść identyfikator klienta. GA4 używa go, żeby przypisać zdarzenie do właściwego użytkownika i — jeśli to możliwe — do trwającej sesji.

Jeśli podasz identyfikator wygenerowany na serwerze, czyli losowy lub oparty na numerze zamówienia, GA4 potraktuje to jako nowego, nieznanego użytkownika. Zdarzenie się zapisze, ale zawiśnie w powietrzu: bez powiązania z wizytą i bez informacji o pochodzeniu ruchu.

Rozwiązanie jest jedno i trzeba je zaplanować przed wdrożeniem, nie po. Identyfikator trzeba przechwycić w przeglądarce, gdy użytkownik jest na stronie, i zapisać razem z zamówieniem — najczęściej odczytując wartość z pliku cookie GA4 i przekazując ją w formularzu albo dopisując do zamówienia jako dodatkowe pole. Serwer wysyła potem zdarzenie z tą samą wartością, choćby trzy dni później.

Przy aplikacjach z logowaniem warto dołożyć drugi identyfikator — własny numer użytkownika, ten sam, który przekazuje tag na stronie. Ratuje sytuacje, w których cookie zniknęło, i pozwala zszywać dane między urządzeniami.

Osobno trzeba pomyśleć o sesji. Zdarzenie z serwera nie wie, do której sesji należy, więc może otworzyć nową i sztucznie podbić licznik. Da się temu zaradzić, przekazując również identyfikator sesji przechwycony na stronie — tą samą drogą co identyfikator klienta.

Ograniczenia, o których lepiej wiedzieć zawczasu

Każde z nich potrafi zaskoczyć po wdrożeniu, kiedy naprawa jest już droga.

• Brak atrybucji dla zdarzeń bez kontekstu. Zdarzenie, którego nie da się powiązać z wcześniejszą wizytą, wyląduje bez źródła i medium. To nie wada protokołu, a konsekwencja tego, że serwer nie wie, skąd przyszedł użytkownik.

• Wąskie okno datowania wstecz. Zdarzeniu można nadać własny czas, ale nie dowolnie stary — limit liczony jest w godzinach, nie w dniach, i wypada go sprawdzić w dokumentacji przed wdrożeniem. Zdarzenia poza oknem są odrzucane bez żadnego komunikatu.

• Limity na paczkę: liczba zdarzeń w jednym żądaniu, liczba parametrów, długość nazw. Przekroczenie oznacza odrzucenie całej wysyłki, nie jej części.

• Zero automatycznego kontekstu. Urządzenia, przeglądarki, lokalizacji i tytułu strony nie będzie albo będzie tyle, ile sam dołożysz.

• Cisza nie jest potwierdzeniem. Zwykły punkt zbierania danych przyjmuje żądanie i odpowiada pomyślnie także wtedy, gdy zdarzenie jest bezsensowne.

Do tego rzecz oczywista, o której łatwo zapomnieć w euforii wdrożenia: danych z GA4 nie da się usunąć wybiórczo. Błędna integracja zostawia trwały ślad w historii usługi.

Jak testować, żeby nie zaśmiecić danych

Kolejność, której nie skracam nawet przy prostym zdarzeniu.

Zaczynam od punktu walidacyjnego — Google udostępnia osobny adres, który zamiast zapisywać zdarzenie zwraca listę zastrzeżeń: nieznany parametr, zła nazwa, brak wymaganego pola. To jedyne miejsce, w którym dostaniesz wprost informację o błędzie.

Potem wysyłam zdarzenia z włączonym trybem debugowania i oglądam je w widoku debugowania w GA4. Sprawdzam wtedy przede wszystkim jedno: czy zdarzenie dokleiło się do właściwego użytkownika, czy utworzyło nowego.

Na końcu przechodzę na dane produkcyjne i przez kilka dni porównuję je z systemem klienta — nie co do złotówki, bo różnice zawsze będą, ale co do rzędu wielkości i dziennej liczby zdarzeń wobec liczby zamówień.

Zabezpieczenie przed duplikatami warto omówić z programistą przed pierwszym testem. Jeśli integracja ponawia nieudane żądania, musi wiedzieć, że dane zamówienie zostało już wysłane. Inaczej pierwsza awaria sieci podwoi konwersje w raporcie.

Zgody i dane osobowe: granica, której nie przekraczam

Protokół nie pyta o zgodę i to jego najniebezpieczniejsza cecha.

Tag na stronie działa w ramach mechanizmu zgód i przy braku zgody na analitykę ogranicza zbieranie. Żądanie z serwera nie ma o tym pojęcia — wyśle wszystko, co mu każesz. Odpowiedzialność za sprawdzenie zgody przenosi się na Twój system i musi być tam zapisana świadomie: status zgody trzeba przechowywać razem z zamówieniem albo przekazywać w zdarzeniu.

Druga granica dotyczy treści. Do GA4 nie wolno wysyłać danych identyfikujących osobę — adresów e-mail, numerów telefonu, nazwisk, adresów zamieszkania. Nie chodzi tylko o przepisy: jest to wprost zabronione w warunkach korzystania z usługi i grozi jej wyłączeniem. Identyfikator użytkownika ma być numerem lub skrótem, nie adresem e-mail w czystej postaci.

Jeśli celem jest przekazanie danych z systemu obsługi klienta do Google Ads, to nie ta droga. Do konwersji domykanych offline służą mechanizmy w samym Google Ads — import z identyfikatorem kliknięcia oraz konwersje rozszerzone dla leadów, zaprojektowane pod dane kontaktowe i przetwarzające je w postaci zaszyfrowanej.

Kiedy odpuścić i zrobić to inaczej

Trzy sytuacje, w których odradzam wdrożenie, choć technicznie by zadziałało.

Gdy problemem jest atrybucja, a nie brak zdarzenia. Zdarzenie z serwera nie odzyska informacji o źródle, jeśli nikt jej wcześniej nie zapisał. To się naprawia na stronie.

Gdy nie ma kto tego utrzymać. Integracja nie jest jednorazowym ustawieniem — będzie wymagać uwagi przy każdej przebudowie sklepu i zmianie w systemie zamówień. Wdrożenie, którego nikt nie pilnuje, przestaje działać cicho i zwykle w najgorszym momencie.

Gdy wystarczy prostsze narzędzie. Zanim sięgnę po protokół, sprawdzam, czy tego samego nie da się zrobić zwykłym zdarzeniem na stronie podziękowania, importem konwersji do Google Ads albo raportem w systemie klienta. Najlepsze wdrożenie pomiaru to takie, którego nie trzeba było robić.