Nowa struktura danych i kompletnie inny interfejs w nowym narzędziu Google Analytics 4 (GA4) na pewno nie ułatwia procesu migracji. Google stara nam się to usprawnić i dla stron, które obecnie korzystają z rekomendowanego Data Layera pod rozszerzony e-commerce (enhanced ecommerce) stwarza możliwość wykorzystania obecnych parametrów i wysłania ich do GA4. Dzięki tej możliwości możemy zaoszczędzić dużo czasu i nie tworzyć całej struktury danych od zera.
Przejście na najnowszą wersję najbardziej popularnego narzędzia analitycznego jest konieczne ze względu na podjęcie decyzji o zamknięciu wysyłki danych do Google Analytics Universal (GA3) od 1 lipca 2023 roku. Po tej dacie (dla posiadaczy kont płatnych 360 data jest przesunięta o trzy miesiące) nie będziemy otrzymywać żadnych nowych danych na starej usłudze.
Oprócz konieczności przejścia, GA4 daje nam większe możliwości. Jedną z głównych zalet jest możliwość zbierania danych z aplikacji i stron internetowych w jednej usłudze. Będzie to szczególnie zauważalne w tych firmach, gdzie aplikacja i strona internetowa mają wiele punktów styku. Analiza tych ścieżek w GA3 była bardzo utrudniona ze względu na różną strukturę danych. W nowej wersji, przy odpowiednim zarządzaniu danymi, możemy budować ścieżki klienckie między tymi dwoma światami. Jest to bardzo ważne z perspektywy zachowań użytkowników i użytkowniczek oraz rosnącej roli aplikacji w dostarczaniu sprzedaży.
Posiadając rozbudowane konto w GA3, zbierające wszystkie główne mikro i makro cele naszej strony, konieczne jest zadbanie o przeniesienie wszystkich zdarzeń do nowej usługi. To odpowiedni moment, aby zweryfikować wszelkie dotychczas zbierane dane i ich sposób wykorzystania. W niektórych przypadkach rozsądne będzie zbudowanie pewnych zdarzeń od początku lub przebudowana ich logiki.
Nazwy zdarzeń typowo sprzedażowych różnią się od tego, do czego byliśmy przyzwyczajeni w GA3. W dokumentacji Google pojawiają się nowe rekomendowane zdarzenia np. add_payment_info czy add_shipping_info. Mogą być one różnie użyte w zależności od ścieżki zakupowej w danym sklepie, ale na pierwszy rzut oka bardzo mocna przypominają znany nam checkout z GA3 z parametrem odpowiadającym za dany krok na ścieżce. Na liście są również dobrze znane zdarzenia, takie jak purchase i add_to_cart.
Dobrą praktyką przy migracji na GA4 jest stworzenie listy wszystkich zdarzeń, które zbieramy na obecnym koncie. Pomoże nam to odtworzyć wszystkie dane na nowej usłudze, a także będziemy świadomi tego, co chcemy zbierać.
Data Layer Purchase w GA4
Głównym celem wielu stron jest sprzedaż. Z perspektywy Google Analytics jest to event o nazwie purchase. Naturalnie dla każdej strony ten event może być różnie wykorzystywany – dla stron leadowych może to być akcja pozostawienia numeru, a dla bloga przeczytanie całego artykułu. Jednak w większości przypadków purchase na kontach Google oznacza dokonanie zakupu z przesłaniem różnych parametrów związanych ze sprzedażą (wartość zakupu, zakupione produkty, wykorzystany kupon przy sprzedaży itp.)
Struktura Data Layer w GA3 i GA4 różni się od siebie, ale mamy również sporo podobieństw. Ważnym punktem odnotowania w tym miejscu jest sposób wysyłki category – wielopoziomowa kategoria w GA4 jest wysyłana w indywidualnych parametrach: item_category i item_category2. Nie znajdziemy tu również parametru products. W nowej dokumentacji jest to parametr o nazwie items.
Implementując zdarzenia przy użyciu Google Tag Managera, mimo zmienionego standardu Data Layer pod GA4 mamy możliwość jego wykorzystania i dopasowania pod wysyłkę danych do GA4.
Na przykładzie jednego ze sklepów możemy zobaczyć warstwę danych, która jest wysyłana w momencie zakupu. Struktura jest znana i dopasowana pod wymagania GA3.
W Google Tag Managerze jesteśmy w stanie wykorzystać powyższy Data Layer i przesłać wszystkie dane do nowo stworzonej usługi. Dokumentacja dostępna na stronie developers.google.com: wskazuje na obowiązkowe parametry dla eventu purchase. Są to:
Oznacza to, że jeśli chcemy, aby nasz event poprawnie został wysłany i odłożył się w Google Analytics 4, to musimy wysłać wszystkie obowiązkowe parametry z jego wartościami. Wszystkie te parametry są dostępne w obecnej warstwie, ale pod nieco innymi nazwami:
| Parametr GA3 | Odpowiednik GA4 |
| currencyCode | currency |
| id | transaction_id |
| revenue | value |
| products | items |
| products.id | items_id |
| products.name | item_name |
Korzystając z danych ze starego Data Layer, dostępnego już na stronie, możemy stworzyć tag pod wysyłkę do Google Analytics 4. W samym tagu powinniśmy w nazwie zdarzenia wpisać event, który chcemy mierzyć. W omawianym przykładzie jest to purchase. Pod nazwą zdarzenia mamy do wypełnienia pola z parametrami. Dla eventu purchase jest kilka obowiązkowych, które musimy podać, aby jakiekolwiek dane pojawiły się w GA4.
W widocznych parametrach currency w tym przypadku przekazuję ze stałą wartością PLN – jest ona wpisana ręcznie, ponieważ w sklepie nie ma możliwości zapłacenia inną walutą. Wartość dla parametru value przekazywana jest bezpośrednio z Data Layera ze zmiennej o nazwie ecommerce.purchase.actionField.revenue. Analogicznie i w bardzo podobny sposób przekazywane wartości są dla shipping, transaction_id oraz items.
Warto tutaj podkreślić sposób przekazywania wartości items. W wartości przekazywany jest cały obiekt ecommerce.purchase.products z parametrami poniżej.
Mamy tu duże ułatwienie, ponieważ jeśli struktura danych jest zgodna z wymaganiami pod GA3 to Google Analytics 4 w sposób automatyczny będzie w stanie odczytać zmienne i je dopasować w nowym narzędziu. W praktyce oznacza to, że do GA4 wysłane zostaną parametry z wartościami:
Po publikacji tagu, do którego należy jeszcze dodać trigger (event=purchase), dane będą zbierane w GA4 i dostępne między innymi w raporcie Generowanie Przychodu – Zakupy e-commerce
Pomimo nowej struktury Data Layer stworzonej pod najnowszą wersję, Google Analytics 4 jest kompatybilny ze strukturą używaną przy wysyłce danych do Google Analytics Universal. Jest to duże ułatwienie pod względem finansowym i czasowym, ponieważ większość zmian możliwa jest do przeprowadzenia w Google Tag Managerze.
Są oczywiście pewne wyjątki i przy budowie usługi dedykowanej dla aplikacji i WWW warto zastanowić się, czy przebudowanie struktury nie będzie miało wymiernych korzyści w przyszłości – łatwiejsza agregacja danych i jednakowe parametry oraz ich wartości. Wiele stron bazuje jednak na jednym streamingu danych (WWW) i posiadając stworzonego wcześniej Data Layer’a będzie mogła z niego w pełni lub dużym wymiarze skorzystać.
Potrzebujesz pomocy w migracji na Google Analytics 4? Skontaktuj się z nami!