Blog

Google Analytics 4. Wszystko o nowym narzędziu GA4

Rafał Piszczatowski
| 24 października 2021
| Google Analytics 4, Google Tag Manager

Google Analytics 4 – przyszłość analityki?

Google Analytics 4 została uruchomiana w 2020 roku. Wstępnie nosiła nazwę „App+Web”, a finalnie otrzymała przydomek GA4. Najważniejszym założeniem i różnicą między jego poprzednikiem jest jednakowa struktura danych dla stron WWW i aplikacji mobilnych. Z całą pewnością jest to potrzebny krok w świecie, gdzie aplikacje i strony internetowe mocno się od siebie uzależniają, a klienci ze względu na wygodę korzystają z dwóch opcji. Jest to też odpowiedź na trend rosnącej roli aplikacji w biznesie i sposobu na lojalizację klienta.

GA4 vs Google Analytics Universal - różnice i podobieństwa

Sposób zbierania danych

Google Analytytics Universal stawiał na ruch ze stron WWW, dlatego przyzwyczailiśmy się jako użytkownicy, tego narzędzia do takich parametrów jak sesja, unikalny użytkownik, odsłona, transakcje. W GA4 wszystko to będzie rejestrowane jako zdarzenia. Same zdarzenia też są czymś innym niż w starszej wersji. W Universal byliśmy przyzwyczajeni do tego, że zdarzenie mają zawsze 3 parametry Kategoria, Działanie i Etykieta. W GA4 każde działanie jest zdarzeniem. Nie ma zatem odróżnienia między rodzajami działań. Wyświetlenie strony kiedyś oznaczało Odsłonę. W GA4 jest to po prostu zdarzenie o nazwie page_view.

Odsłona
Zdarzenie
Transakcja
Czas działań użytkownika
Wyświetlenie ekranu

Zdarzenie
Zdarzenie
Zdarzenie
Zdarzenie
Zdarzenie

źródło: https://support.google.com/analytics/answer/9964640

Sesje

W Universal sesja mogła zawierać wiele odsłon, różnych zdarzeń, transkacji e-commerce. W przypadku GA4 sesja rozpoczyna się zdarzeniem sessios_start, a czas trwania określa pierwsze i ostatnie zdarzenie w tej sesji. Poza inną wartością czasu trwania sesji nastawmy się również na mniejszą liczbę sesji w GA4. Będzie tak, ponieważ nowe źródło kampanii (np. nadpisanie wizyty nowym utm) podczas trwającej sesji nie spowoduje otwarcia nowej sesji.

User ID

Funkcja ta pozostaje niezmienna i ma na celu anonimową identyfikacja tego samego klienta, który wchodzi z różnych przeglądarek czy urządzeń (np. na podstawie logowania użytkownika na stronie). Dużą zaletą User ID w przypadku GA4 będzie możliwość analizy ścieżki klienta, nie tylko na stronie WWW wchodząc z desktopu czy mobile, ale także analiza zachowania użytkownika, który korzysta z aplikacji i WWW. Tworząc usługę, która łączy streaming danych ze wszystkich źródeł i implementując funkcję User ID możemy bardzo mocno wzbogacić nasze dane i zrozumieć zachowanie klienta w różnych środowiskach. Konieczne z perspektywy wdrożenia będzie przesyłanie tego samego identyfikatora użytkownika w aplikacji, jak i na stronie WWW.

Bounce rate idzie w zapomnienie

Jeśli jednym z Twoim KPI, które co miesiąc przedstawiasz w raporcie jest bounce rate to będziesz musiał zaaktualizować swoją prezentację. GA4 nie będzie miało takiego parametru jak współczynnik odrzuceń. Nowa wersja GA zamienia ten parametr na współczynnik zaangażowania. Wydaje mi się, że jest to dobry kierunek. Być może pozwoli to analitykom unikać odpowiedzi, że dobry współczynnik odrzuceń to… to zależy.

Zalety Google Analytics 4

APP + WWW w jednym miejscu

Zaletą nowej wersji Google Analytics jest łączenie danych z aplikacji mobilnych i stron WWW. To szczególnie istotne dla większych firm, które działają w biznesie w dwóch obszarach jednocześnie. Obecnie analiza danych pochodzących z portalu i aplikacji jest mocno utrudniona ze względu na zupełnie inna strukturę danych i sposobu ich liczenia. Google Analytics 4 stawia na eventy, a więc decyduje się na rozwiązanie, które jest obecnie stosowane w Firebase. Oznacza to, że GA4 pozwoli na połączenie w całości 3 światów: iOS, Android, a także danych pochodzących z WWW, dzięki przejściu na zbieranie danych za pomocą eventów.

BigQuery dostępne dla wszystkich

Inna zmianą w porównaniu do Google Analytics Universal jest możliwość korzystania z BigQuery. Obecnie w przypadku Universal było to możliwe tylko dla posiadaczy wersji premium. GA4 zakłada, że połączenie usługi z BigQuery będzie darmowe. Mając dostęp do surowych danych można je wykorzystać, aby nie mieć próbkowania danych przy większych zbiorach. Dostęp do BigQuery to również możliwość bezpośredniego połączenia do surówki danych przez dostępne konektory w narzędziach wizualizacyjnych, takich jak DataStudio czy PowerBI.

Dokładniejszy remarketing

Wyobraź sobie, że masz użytkownika, który dodał Twój produkt koszyka w aplikacji, ale nie sfinalizował zakupu. Taki event możesz odłożyć w usłudze, która łączy WWW+APP. To oznacza, że lista remarketingowa będzie możliwa do stworzenia, a więc użytkownik, który wykonał pewną czynność w aplikacji będzie brany pod uwagę przy kampaniach remarketingowych np. na desktopie.

Różne modele atrybucji łatwiej dostępne

W GA4 stworzone przez nas raporty możemy analizować w różnych modelach atrybucyjnych. W przypadku Universal byliśmy przyzwyczajani zazwyczaj do modelu last-click. Wynikało to z tego, że modele atrybucyjne były oddzielna zakładką i ciężko je było jednoznaczanie nałożyć na tworzone przez nas niestandardowe raporty. W GA4 te podejście się zmienia i model atrybucji jest do wyboru na poziomie różnych raportów, co jest na pewno dużym plusem przy analizie faktycznych źródeł zakupu. Warto też w tym miejscu pamiętać o połączeniu app i web. Obecnie analiza działań promocyjnych danej aplikacji na stronie WWW jest dość ciężkie. Wyobraźmy sobie, że wrzucamy post na Linkedin, prowadzący na naszą stronę WWW, która oferuję sprzedaż na stronie lub zainstalowanie aplikacji i tam dokonanie zakupu w innym kanale (aplikacja). Połączenie danych, aby przypisać faktyczne źródło jest zwyczajnie bardzo ciężkie. Nadal sam Firebase nie jest dokładnym narzędziem do przypisywania samego źródła ruchu i przychodzą mu z pomocą takie narzędzia, jak np. Appsflyer. W teorii GA4 wydaje się ciekawe pod kątem analizy faktycznego źródła zakupu w aplikacji (w omawianym przykładzie wejście z postu na LinkedIn).

Wady Google Analytics 4

Nowa struktura danych

GA4 bardzo mocno przypomina Firebase. Dla części użytkowników będzie to plus, ponieważ są już przyzwyczajeni do danej struktury danych i sposobu ich analizowania. Dla większości jednak użytkowników, którzy korzystają tylko z Google Analytics Universal i analizują ruch na stronie WWW przejście na GA4 to będzie jak przejście na zupełnie nowe analityczne narzędzie.

Zainstalowałem Google Analytics czy jakieś inne narzędzie?

Sama struktura danych jest zupełnie inna, bo bazuje na eventach, ale interfejs narzędzia oraz informacje w nim zawarte diametralnie się różnią. Na grupach sympatyków Analyticsa często można napotkać na wpisy, które polegają na problemie zauważenia, że są w nowym narzędziu.

„Chodzi o zakładkę "Pozyskiwanie". Na jednej stronie mam tam dostęp do sekcji Całych ruch -> kanały a na drugiej nie mam. Co zrobić, żeby uzyskać dostęp do tych danych? Potrzebuję wiedzieć ile jest sesji (nie użytkowników) oraz z jakiego źródła (organic, direct, social itd)”

Google stara się wymuszać uruchamiania GA4 przy tworzeniu nowych usług. O ile jest to na pewno dobry kierunek, czyli próba połączenia danych z aplikacji + WWW, tak dla odbiorcy, który korzysta z analityki raz na jakiś czas i potrzebuję danych tylko dla swojej strony będzie to zwyczajnie ciężkie do przetrawienia, aby zrozumieć nowe narzędzie.

Nowy interfejs narzędzia

Google Universal w samej obsłudze był dość prostym narzędziem. Podstawowa analiza ruchu, źródeł, konwersji na portalu była dość zrozumiała i zazwyczaj logiczna. GA4 w odbiorze jest trudniejszym narzędziem, szczególnie dla osób, które korzystają z analityki raz na jakiś czas i są przyzwyczajeni już do widoku danych w Universal. Przejście na GA4 może okazać się ciężkie. Jeśli, ktoś posiada tylko stronę WWW i ma ograniczone wymagania, co do danych to takie przejście też nie będzie uzasadnione, oprócz argumentu, że Google przestanie wspierać starszą wersje.

Brak gotowych raportów

W rzucając podstawowy skrypt Google Analytics na naszą stronę i po zebraniu danych otrzymujemy sporą liczbę gotowych raportów w Universal. Łatwo jest tam sprawdzić informację o ciasteczkach, typ urządzenia, informację o źródłach ruchu, głównych stronach. W GA4 bez wyklikania i przygotowania raportów będzie się nam poruszało zdecydowanie ciężej. Podejrzewam, że jest to jedna z rzeczy, która będzie upraszczana i przy kolejnych aktualizacjach ten podpunkt zostanie przeze mnie skasowany (a przynajmniej mam taką nadzieję!), tak obecnie niestety poruszanie się po GA4 będzie wymagało nieco pracy od nas, aby otrzymać podstawowe raporty, które mogą nas interesować i do których byliśmy przyzwyczajeni w Universal. Chociaż spotkałem się z głosami, że to właśnie GA4 upraszcza ten interfejs i to Universal wydaje się być nieco za bardzo skomplikowany przez mnogość informacji, które nie są potrzebne, aby były od razu dostępne w panelu. Kwestia pewnie samego przyzwyczajenia i subiektywnej oceny.

Wdrożenie GA4 na stronie WWW

Warto wdrożyć GA4 szybciej niż później. Nowa struktura danych nie pozwala na migrację danych historycznych, zatem im szybciej założymy nowe konto tym więcej będziemy mieli danych historycznych. Dane w GA4 będą nieco się różniły pod względem wolumenów w porównaniu do jego starszej wersji. Na przykład liczba sesji będzie nieco mniejsza ze względu na inny model zliczania.

Dla firm, które mają tylko stronę WWW ciężko będzie doszukiwać się sensu tej migracji. To będzie jak przejście na kompletnie nowe narzędzie, przynajmniej pod kątem interfejsu. Nie zaszkodzi jednak przygotować nawet podstawową implementację (np. zbieranie samego ruchu) aby w momencie, gdy Google wycofa poprzednią wersję nie mieć kompletnie nowego narzędzia, w którym nie mamy żadnych danych historycznych.

Poniżej instrukcja implementacji GA4 dla posiadaczy konta Google Analytics Universal, którzy korzystają z Google Tag Managera.

Stwórz nową usługę w Google Analytics

Przejść do zakładki Administracja, a następnie w Usługa wybierz: Asystent konfiguracji usługi Google Analytics 4.

Po kliknięciu we Wprowadzenie i akceptacji utworzenia nowej usługi dostaniemy jej nowy Identyfikator oraz utworzy się nam dodatkowa usługa na obecnym koncie. To nie jest zatem migracja obecnego konta, a jedynie utworzenie kolejnej usługi. W praktyce, więc zamierzamy zbierać dane na dwóch usługach – na obecnym Google Analytics Universal i nowy streaming danych w GA4.

Po wyborze Zobacz swoją usługę Google Analytics4 zostaniemy przeniesieni do nowej usługi.

Kliknij w tym miejscu w Instalacja tagu, a następnie w utworzony strumień danych. Dostaniesz w nim szczegóły o swoim koncie. W tym miejscu potrzebujemy skopiować identyfikator pomiaru.

Stworzenie tagu do zbierania danych

Skopiuj swój identyfikator pomiaru i przejdź do Google Tag Managera dla obecnego konta. Stwórz w nim nowy tag. Zalecam utworzyć nowy folder w GTM tylko pod tagi GA4.

Chcemy obecnie stworzyć główny tag pod zbieranie ruchu na stronie. Wybierzmy zatem typ tagu: Google Analytics: konfiguracja GA4, a w identyfikator pomiaru wklejmy wcześniej skopiowany numer. Reguła będzie analogiczna do sytuacji z Universal – tag ma być uruchamiany na każdej stronie, dlatego dodajmy tam warunek All Pages.

Możemy to zapisać i opublikować. Warto sprawdzić na usłudze w Czasie Rzeczywistym, czy faktycznie GA4 odbiera eventy

Migracja tagu purchase do GA4 z Universal

Jeśli miałeś wdrożony Enhanced Ecommerce w Universal to wykorzystaj obecny Data Layer i przenieś go do GA4. Sama struktura danych w GA4 jest inna. Pełna specyfikacja dostępna jest pod adresem: https://developers.google.com/tag-manager/ecommerce-ga4. Google na szczęście mocno ułatwia życie i mając obecnie wdrożony Data Layer, zgodnie ze specyfikacją Enhanced Ecommerce, możemy go wykorzystać.

Wdróżmy tag purchase na nowej usłudze. Wdrożenie te zakłada, że posiadamy na stronie już DataLayer, w takiej postaci: https://developers.google.com/tag-manager/enhanced-ecommerce#purchases.

W Google Tag Managerze stwórzmy nowy tag: Google Analytics: zdarzenie GA4. W konfiguracji mamy możliwość wyboru wcześniej stworzonego tagu, który służy do zbierania całego ruchu. Wybierzmy go, a w nazwie zdarzenia wg specyfikacji od Google wpiszmy: purchase (https://support.google.com/analytics/answer/9267735?hl=pl).

W GA4 mamy nieco inną logikę tworzeniu tagów e-commerce. Wcześniej byliśmy przyzwyczajeni do zaznaczenia, aby tag korzystał z DataLayera. Ewentualnie dopisania innych parametrów, jeśli mieliśmy niestandardowy Data Layer. W przypadku GA4 musimy wejść w Parametry zdarzenia i w tym polu wskazać, co chcemy przekazywać w momencie purchase. Dla tego przykładu zadeklaruję, że chcę przekazać informację o walucie oraz o produktach, które zostały kupione w momencie wywołania eventu purchase. Pozostałe parametry (id transakcji, wartość itp.), które na pewno warto przekazać opisuję w kolejnych akapitach.

W nazwie parametru musimy wpisać: currency i items. W wartości dla currency na sztywno możemy przekazać PLN. Jeśli jednak na sklepie mamy możliwość płatności różnymi walutami to taką wartość musimy pobrać z DataLayera, aby przekazywała nam się zgodnie, z wyborem klientów. W przypadku items w wartości deklarujemy, aby pobierał on informacje o produktach z obecnego DataLayera. Będą to zatem wartości z ecommerce.purchase.products. Jeśli nie posiadamy takiej zmiennej w Google Tag Managerze to musimy ją stworzyć.

Po kliknięciu w plus przy pustej wartości dostaniemy możliwość wyboru zmiennej.

Aby stworzyć nową zmienną wybieramy kolejny raz + i tworzymy Zmienną warstwę danych, w której deklarujemy, że chcemy pobierać informację z ecommerce.purchase.products.

Po jej zapisaniu w polu wartości powinniśmy mieć ją automatycznie wybraną.

W tym momencie pozostało dodać regułę. W naszym przypadku będzie to w momencie dokonania zakupu, a więc na większości kont ten event będzie się nazywał purchase. Taka reguła powinna już istnieć, jeśli wykorzystujemy Enhanced Ecommerce w Universal, dlatego wybierzmy istniejącą regułę.

Tag jest gotowy. Możemy go zapisać. Najlepiej tag sprawdzić w trybie debuggowania. Jeśli jest wywoływany poprawnie – wrzucić na produkcję i sprawdzić na usłudze GA4 czy wszystko odkłada się poprawnie i wartości o produktach są analogiczne do danych z GA Universal.

W momencie purchase zostały wysłane 2 tagi. Do GA Universal oraz do GA4. Po wejściu w tag odpowiedzialny za wysyłkę danych do GA4 dostajemy informacje, co zostało wysłane. W zmiennej podaliśmy parametr currency oraz items. Oba zostały przekazane wg ustawień w Google Tag Managerze:

W GTM możemy podejrzeć, co jest dokładnie w przekazywanych danych po kliknięciu w Values. Musimy tu być jednak ostrożni. Do GA4 nie zostanie przekazane wszystko, co jest wyświetlane w Data Layerze. Tak samo, jak w przypadku GA Universal niestandardowe parametry nie zostaną przekazane. W tym przypadku taki parametr, jak np. stockLevel nie zostanie przekazany. Nie jest on zgodny z wymaganiami, więc GA4 nie wie, że ma go przekształcić do odpowiedniej struktury danych i przekazać. Warto zatem korzystać z nowego sposobu analizy danych, czyli z debuggera dostępnego w samym narzędziu GA4.

Tryb debuggowania w GA4

GA4 posiada DebugView. Oznacza to zatem, że w momencie debuggowania w GTM możemy podejrzeć również wszystkie eventy po kolei w GA4. Jest to wygodny widok, aby sprawdzić, jakie eventy są zbierane i jakie parametry są przekazywane.

Wybierając event, który nas interesuje możemy sprawdzić parametry i elementy, które zostały wysłane. Ważny odnotowania jest fakt, że GA4 automatycznie wykonuje za nas przekształcenie Data Layera i przekazuje te parametry, które rozpoznaje wg standardu Enhanced Ecommerce.

Dodatkowe parametry zdarzenia dla eventu purchase

W poprzednich punktach pokazywałem jak przekazać parametry currency i items. Warto jednak dodać wszystkie główne parametry, które podobnie zbieramy w GA Universal. Analogicznie do sposobu przekazywania parametru items dodajmy takie parametry jak: value, shipping i transaction_id. Robimy to za pomocą dodania parametrów zdarzenia.

W wartości przekazujemy wartość ze zmiennej z obecnego Data Layera. Po aktualizacji tagu otrzymamy nowe parametry w momencie dokonania transakcji (purchase). Pojawiły się w nim shipping, transaction_id oraz value wraz z wartościami zgodnymi z tym, co jest wysyłane w Data Layerze.