#ga4 #googleanalytics
Czym jest Measurement Protocol i kiedy warto go stosować w GA4?
Spis treści
- Do czego służy Measurement Protocol?
- Zalety Measurement Protocol
- Wady Measurement Protocol
- Dobre praktyki
- Podsumowanie
Do czego służy Measurement Protocol?
Measurement Protocol (MP) to metoda przesyłania danych do Google Analytics 4. Pozwala ona na zbieranie danych z dowolnego źródła podłączonego do Internetu, niezależnie od tego, czy jest to strona internetowa, aplikacja mobilna, CRM czy automat sprzedający kawę.
Większość danych w GA4 pochodzi z front endu, czyli kodów umieszczonych na stronie i widocznych dla każdego użytkownika, podobnie jak HTML strony. Kiedy użytkownik dokonuje zakupu na stronie, generowane jest zdarzenie purchase, które następnie wysyła dane zakupionych produktów do GA4 (za pośrednictwem Google Tag Managera lub bezpośrednio). Dane te oglądamy później w raportach GA4.
Czasem jednak ta metoda nie daje możliwości wysłania danych wszystkich zakupów (lub innych konwersji) do GA4. Przykłady to:
- Strony leadowe, na których użytkownicy pozostawiają swoje dane kontaktowe, wypełniając formularze, ale sam zakup ma miejsce później, np. po kontakcie mailowym albo telefonicznym.
- Strony, na których można dokonać płatności tylko w przypadku części produktów. Pozostałe produkty wymagają podpisania umowy albo innego kontaktu, przez co zakup nie jest finalizowany online.
- Strony, na których użytkownicy kupują subskrypcje, które są regularnie odnawiane. Klienci płacą za pierwszy miesiąc w trakcie trwania sesji w Google Analytics, a kolejne płatności są pobierane automatycznie z ich karty. Domyślnie GA4 jest w stanie zanotować tylko zakup za pierwszy miesiąc.
- Nieco inny przypadek to strony, na których można dokonać zakupu, ale użytkownicy nie wracają na thank you page lub pojawiają się błędne lub anulowane zakupy, przez co występują znaczne rozbieżności danych z CRM-u i z GA4.
W każdym z tych przypadków oprócz domyślnego wysyłania danych online (frontendowych) można wysłać dodatkowe dane (backendowe), w tym dane offline. Możemy pobrać z CRM-u dane klienta płacącego co miesiąc subskrypcję i wysłać je do GA4. Wymaga to użycia Measurement Protocol, który jest metodą procesowania danych z narzędzia wyjściowego (np. z CRM-u) do narzędzia docelowego (GA4). Jest to więc API, czyli sposób na to, żeby dwa narzędzia się „skomunikowały”, ponieważ nie mają domyślnej integracji (takiej w jaką są wyposażone na przykład Google Ads i GA4). Wymaga to zaangażowania programisty, który wdroży Measurement Protocol, oraz testowania przesyłanych danych w GA4.
Przesyłanie danych do GA bez MP
Schemat przesyłania danych do Analytics bez MP (tylko dane frontendowe):
Przesyłanie danych do GA z MP
Uproszczony schemat przesyłania danych do Analytics przez MP (dane frontendowe + backendowe):
Zalety Measurement Protocol
Precyzyjne dane
Measurement Protocol pozwala na bardzo precyzyjne przesyłanie danych do GA4. Spójrzmy na przykład. Użytkownicy potwierdzają na stronie zakup, po czym mogą:
- od razu wykonać płatność,
- nie wykonać płatności,
- wykonać płatność po jakimś czasie.
Dodatkowo zamówienie może mieć różny status realizacji, np.
- w trakcie realizacji,
- wysłane do klienta,
- wstrzymane,
- anulowane przez klienta.
Śledzenie frontendowe (czyli w oparciu o kody wywoływane w źródle witryny) daje możliwość odnotowania zakupu po wybranej akcji użytkownika online, np. po kliknięciu w przycisk „Zapłać”, czyli zanim doszło do płatności. W efekcie do Analytics trafiają dane nieopłaconych zakupów. Używając MP i korzystając z danych z CRM-u można dokładnie wybrać, które zamówienia mają być przesłane do GA4, np. tylko transakcje opłacone, przez co śledzenie może stać się bardziej precyzyjne.
Dane offline
Measurement Protocol pozwala na przesyłanie danych offline, które domyślnie nie są śledzone w Google Analytics.
Śledzenie pełnej ścieżki użytkownika
Analytics umożliwia śledzenie kliknięć w adresy e-mail i numery telefonu oraz kopiowanie takich danych przez użytkownika. Pozwala na śledzenie wypełniania formularzy. Nie daje jednak możliwości przekazania informacji, co dzieje się później. Czy po wysłaniu wiadomości użytkownik dostał odpowiedź przez e-mail lub telefonicznie i doszło do podpisania umowy? Analytics nie ma dostępu do takich danych, ponieważ te akcje użytkownika odbywają się poza witryną. Przesłanie takich danych wymaga połączenia danych frontendowych (akcji użytkownika na stronie) z danymi backendowymi (CRM, baza danych) i wysłania ich do Analytics używając Measurement Protocol.
Konwersje po kontaktach mailowych i telefonicznych
Dane na temat tych akcji wykonywane poza stroną można uzupełnić, używając MP. W tym wypadku może jednak brakować informacji o źródle ruchu przypisanym do konwersji. Wynika to z braku informacji o sesji, do której można przypisać konwersję. Na szczęście istnieje możliwość dopisania tych informacji ręcznie.
Dane odnawialnych płatności, subskrypcji i pakietów
Konwersje tego typu często mają miejsce poza witryną, więc nie są śledzone przez Analytics. Wyjątkiem są witryny, które do zakupu pakietu wymagają wykonania akcji na stronie, na przykład wypełnienia formularza dla zalogowanych użytkowników i potwierdzenia zakupu. Jeśli dane subskrypcji i pakietów znajdują się poza witryną, można przesłać je przez MP.
Dane zwrotów produktów
Zwroty produktów często odbywają się mailowo, więc trudno uzupełnić te dane w Analytcis. Measurement Protocol może przyjść tutaj z pomocą.
Bardziej precyzyjne śledzenie LTV
Długoterminowa wartość klienta (LTV, lifetime value) to kwota, jaką dany klient wyda na produkty lub usługi przez cały okres korzystania z usług firmy. Wskaźnik ten pomaga rozróżnić klientów powracających i kupujących regularnie od tych, którzy dokonują zakupów sporadycznie.
W kontekście optymalizacji kampanii reklamowych jest to ważna informacja. Na pozyskanie klientów o wysokim LTV warto wydać więcej budżetu reklamowego lub ustalić wyższe docelowe koszty konwersji (tCPA), ponieważ zwróci się to, ale w dłuższej perspektywie. Jeśli witryna oferuje odnawialne pakiety czy subskrypcje, LTV będzie rosło z każdym miesiącem. Jego mierzenie jest utrudnione, gdy odnowienia pakietów odbywają się poza witryną. Measurement Protocol może pomóc uzupełnić dane tak, by dokładniej mierzyć LTV i ułatwić analizę danych oraz optymalizację kampanii marketingowych.
Wady Measurement Protocol
Nie ma róży bez kolców i MP nie jest wyjątkiem. Rozwiązanie nie należy do łatwych w implementacji i wiąże się z kilkoma wyzwaniami.
- Połączenie danych frontendowych i backendowych oznacza, że musimy nawiązać współpracę z programistą, który specjalizuje się w obu tych dziedzinach.
- Wdrożenie po stronie programisty jest bardziej czasochłonne niż klasyczna implementacja kodów frontendowych. Może to oznaczać wyższe koszty wdrożenia.
- W chwili publikacji tego artykułu, to jest na zimę 2023, GA4 jest wciąż rozwijającym się produktem Google, który zyskuje kolejne funkcje i ulepszenia. Pełna dokumentacja GA4 nie jest jeszcze dostępna i wiele rzeczy może ulec zmianie, w tym Measurement Protocol, a GA4 stopniowo zyskuje na wygodzie użytkowania.
- Zdarzenia przesyłane przez MP domyślnie wiążą się z wartościami (not set) w części raportów.
- Przesyłania zdarzeń przez MP z opóźnieniem 72 godzin w stosunku do czasu sesji użytkownika oznacza, że GA4 nie będzie móc połączyć zdarzenia z sesją, co może powodować wartości (not set) w raportach, np. w Sesja – źródło/medium.
Łączenie danych frontendowych z Measurement Protocol
Łączenie danych frontendowych z Measurement Protocol wymaga pobrania identyfikatora użytkownika z pliku cookie (client_id) oraz ID sesji (session_id) i połączenie ich przez MP.
W przypadku braku tych wartości GA4 nie jest w stanie połączyć danych frontendowych. Oznacza to, że zdarzenie, np. zakup, nie będzie połączone z sesją zainicjowaną przez użytkownika. W efekcie pojawiają się (not sety) w raportach dotyczących sesji, np. Sesja – źródło/medium.
Ten sam problem pojawia się, kiedy dane zdarzeń są przesyłane po 72 godzinach od czasu trwania sesji – GA4 stworzy wtedy nową sesję, do której przypisze akcję, a więc nie uda się przypisać zdarzenia do pierwotnego źródła ruchu.
Jeśli przesyłamy dane po 72 godzinach, możemy ręcznie uzupełnić informacje o źródle/medium sesji, pobierając je z wyjściowego narzędzia, np. CRM-u. W praktyce jednak takich danych może nam zabraknąć – CRM zwykle ich nie zbiera.
Precyzyjny plan śledzenia
Prawidłowe działania MP wymaga precyzyjnego ustalenia, które zdarzenia mają być wysyłane. Czy ma to być każda opłacona transakcja, czy dopiero zrealizowane zamówienia? Czy anulowane zamówienia mają być rejestrowane jako zakupy i zwroty, czy wykluczone ze śledzenia? Im bardziej skomplikowany schemat działania transakcji tym więcej tematów do uwzględnienia. Moment wysłania zamówienia i moment jego opłacenia mogą się znacznie różnić, a przekroczenie 72 godzin od czasu sesji użytkownika komplikuje wdrożenie.
Dane technologii, lokalizacji i stron
Zdarzenia przesyłane przez MP nie dostarczają informacji o technologii, lokalizacji i stronach zdarzeń. Oznacza to, że przy zdarzeniach frontendowych zobaczymy dane przeglądarki, rozdzielczości ekranu, kraju, miasta, języka czy ścieżki strony, a przy zdarzeniach z MP pojawią się (not sety). W przypadku kategorii urządzenia zdarzenia z MP często są w całości przypisane do desktopu.
Brak dodatkowych konfiguracji
Porządne wdrożenie GA4 to mocna podstawa do dalszych konfiguracji. Kody frontendowe GA4 są powszechnie używane do wdrażania również innych narzędzi, takich jak zdarzenia Facebooka, Binga, Google Ads czy remarketing w Google Ads. W przypadku zdarzeń przesyłanych przez MP nie ma możliwości użycia tego kodu do wdrożenia np. konwersji z tagiem Google Ads czy tagiem Facebooka – to wymaga kodów frontendowych i Google Tag Managera. Można jednak bez żadnego problemu wysłać zdarzenia GA4 do Google Ads, korzystając z integracji tych narzędzi.
Na podstawie zdarzeń z MP nie można konfigurować dodatkowych zdarzeń w GA4, co bywa przydatną funkcją tego narzędzia.
Dobre praktyki
- Wdrożenie MP warto zaplanować na więcej czasu po stronie programisty niż wdrożenie kodów frontendowych. Przed rozpoczęciem projektu warto skonsultować temat z programistą, pokazując jakiego typu kody mają zostać wdrożone.
- Sprawne wdrożenie wymaga współpracy programisty i specjalisty Google Analytics, ponieważ testowanie funkcji nie jest możliwe do wykonania w pojedynkę.
- Podczas wdrażania MP dla e-commerce warto precyzyjnie ustalić, jakie transakcje mają być przesyłane do GA4.
- Wdrażając śledzenie zakupów przez Measurement Protocol warto dodatkowo wdrożyć standardowy kod e-commerce, żeby mieć na czym oprzeć konfigurację konwersji w narzędziach inne niż GA4, np. Google Ads, Facebook, Bing.
Podsumowanie
Measurement Protocol to potężne narzędzie, które może być wykorzystywane do zbierania bardzo precyzyjnych danych z różnych narzędzi, np. wybranych typów transakcji z CRM-u. Funkcja pozwala też uzupełnić raporty GA o dane, których nie można zebrać domyślnie, np. konwersje offline po kontaktach telefonicznych z klientami czy zakupy subskrypcyjne. Jest to odpowiedź na bolączkę wielu marketerów i przedsiębiorców, którzy chcieliby, żeby Google Analytics pokazywał dokładniejsze dane.
Z drugiej strony, Measurement Protocol jest trudniejszy i bardziej czasochłonny do wdrożenia. Korzystanie z niego może wiązać się z lukami w danych GA4, szczególnie w sytuacji, kiedy wysyłamy dane z opóźnieniem.