Google Analytics 4 – śledzenie danych ecommerce

Dane ecommerce w Google Analytics 4 to temat równie ciekawy, co Ulepszony E-commerce w Universal Analytics. Z pozoru prosty (instalujesz dataLayer, tagi w GTM i działa), w praktyce pełen haczyków i pułapek.

Ten artykuł będzie głównie o aspekcie wdrożeniowym ze strategicznego punktu widzenia. Obecnie mamy tutaj całkiem spore zamieszanie. Przedstawię Ci najważniejsze punkty, dzięki którym decyzja o sposobie wdrożenia śledzenia ecommerce w GA4 będzie dla Ciebie łatwiejsza.

A już na pewno unikniesz kosztownych błędów i frustracji na zasadzie „miało być proste i działać, a nie działa”.

Dane ecommerce w GA4 vs GA3

Śledzenie danych ecommerce to kluczowa funkcjonalność zarówno w Universal Analytics, jak i w Google Analytics 4.

W GA4 wprowadzono kilka zmian, zwłaszcza pod kątem zdarzeń związanych ze ścieżką zakupową. Doszły też nowe akcje, jak add_to_wishlist czy view_cart. Pełne zestawienie poniżej:

Jak pewnie zauważyłeś, zmieniło się nazewnictwo. Uproszczono też strukturę kodów dataLayer. To zmiana na plus – potrzeba mniej zmiennych w GTM, aby uchwycić przydatne wymiary i metryki ecommerce’owe.

Implementacja śledzenia e-commerce dla Google Analytics 4

Wdrożenie śledzenia danych ecommerce zawsze wiąże się z koniecznością przekazywania dynamicznych danych, takich jak nazwa oglądanego produktu, cena, liczba przedmiotów w koszyku, id transakcji, wartość transakcji, etc.

Najlepszym wyjściem jest przekazywanie danych dynamicznych w dataLayer (warstwa danych, w skrócie DL), skąd tagi Google Tag Manager mogą je przechwycić, a następnie przesłać do Google Analytics 4 (czy też innych narzędzi).

Jeśli nie miałeś nigdy okazji wdrażać śledzenia ecommerce, to przygotuj się na to, że będzie zdecydowanie trudniej, niż przy wdrażaniu prostych zdarzeń na kliknięcie czy wypełnienie formularza.

Konieczna będzie albo współpraca z programistą, który według przekazanych instrukcji wdroży dataLayer na poszczególnych ekranach sklepu internetowego, albo skorzystanie z gotowej wtyczki, generującej warstwę danych.

Z mojego doświadczenia idealne wtyczki nie istnieją i zawsze pojawiają się mniejsze bądź większe problemy. Im bardziej zaawansowanego wdrożenia potrzebujesz, tym mocniej opłaca się postawić na customowe dataLayer, budowane przez programistę.

To tak tytułem wstępu.

Różne warianty wdrożenia

Obecnie jesteśmy w okresie przejściowym w historii Google Analytics. Niektórzy używają już głównie Google Analytics 4, ale w większości firm króluje nadal Universal Analytics. Oba narzędzia różnią się w wielu aspektach, a jednym z nich jest struktura dataLayer dla danych ecommerce.

Dlatego w tym momencie wspierane jest zarówno dataLayer w formacie Universal Analytics (GA3), jak i w formacie Google Analytics 4 (GA4).

I co z tym zrobić? Wdrożyć dataLayer dla GA3 czy GA4? A może oba? Jakie są tutaj skutki, ograniczenia i potencjalne problemy?

Zanim przedstawię Ci opcje, jakie masz do wyboru, wyjaśnię, dlaczego proste rozwiązania w wypadku śledzenia ecommerce dla GA4 niekoniecznie zadziałają tak, jakbyś tego sobie życzył.

Braki w kompatybilności – na co uważać

W tagach zdarzeń Google Analytics 4 możesz włączyć korzystanie z dataLayer. GA4 automatycznie rozpozna, czy jest to schemat GA3 czy GA4, i odpowiednio zmapuje dane (są tu wyjątki – o nich niżej).

Z kolei tagi GA3 długo nie były kompatybilne z dataLayer w formacie GA4, ale już są:

Teoretycznie jest łatwo. W Google Tag Manager zaznaczasz tylko odpowiedni checkbox w ustawieniach tagu i gotowe.

W praktyce pojawiają się komplikacje, wynikające z braku spójności w akcjach e-commerce, śledzonych w GA3 i GA4. Większość z nich jest identyczna, ale mamy też różnice, które wykrzaczą dane. Kluczowe kwestie:

• W GA3 checkout jest akcją wysyłaną na każdym kolejnym kroku procesu zakupowego. Kolejne kroki rozróżniane są wymiarem step, przyjmującym kolejno wartości 1, 2, 3, etc. Z kolei w GA4 mamy podział na kolejne etapy w ujęciu, że tak to nazwę, opisowym.
  
  Czyli view_cart (który nie ma jasnego odpowiednika w GA3, bo checkout: step 1 można definiować dowolnie), następnie begin_checkout, add_payment_info, add_shipping_info, gdzie dwa ostatnie zdarzenia nie mają jasno określonej kolejności, bo zależnie od konstrukcji checkoutu może ona być różna.
  
• W GA4 występują akcje, których nie ma w GA3. Włączenie korzystania z dataLayer w tagach zdarzeń ecommerce GA4 ma więc sens tylko wtedy, gdy dataLayer przygotujesz właśnie w formacie Google Analytics 4.Przy formacie GA3 nie wszystko zadziała.
  
  Owszem, add_to_cart, purchase czy view_item powinny być ok, ale już wspomniane wyżej zdarzenia związane z checkoutem wyglądają problematycznie. Po prostu nie da się tego zautomatyzować, bo nie ma tutaj jednego obowiązującego mechanizmu.
  
• Wymiary niestandardowe. W GA3 obowiązuje nazewnictwo w formacie dimensionXX, odpowiadające numerowi indeksu wymiaru niestandardowego. W GA4 z kolei dowolnie nazywamy parametry zdarzeń (wymiary niestandardowe).
  
  I teraz w tagach GA3, gdy zaznaczysz korzystanie z dataLayer w formacie GA4, to skąd GA3 będzie wiedzieć, do którego indeksu przypisać wymiar o nazwie – dajmy na to – product_color? W drugą stronę też jest problem – bo jeśli w dataLayer dla GA3 mamy dimension12, to skąd GA4 miałoby wiedzieć, że ta wartość ma być przypisana do product_color?

Pamiętaj, że największym problemem są wymiary niestandardowe, zwłaszcza o zakresie produkt. Jeśli z nich nie korzystasz, to korzystanie z checkboxów zapewni Ci całkiem dobre dane (poza zdarzeniami dla checkoutu).

Który schemat dataLayer wybrać?

Rekomenduję utrzymywanie dual-taggingu, czyli jednoczesnego zbierania danych w Universal Analytics i Google Analytics 4 tak długo, jak to tylko możliwe.

Oczywiście jeśli masz dość Universal Analytics lub konfiguracja pozostawia wiele do życzenia, to przejście do razu w 100% na GA4 może mieć sens. Wtedy sprawa jest prosta – budujesz dataLayer w formacie GA4 i jest elegancko.

Ale załóżmy, że chcesz utrzymać na stronie dual-tagging. Opcji jest kilka. Najlepszej nie ma. Kwestia tego, jaki poziom jakości danych chcesz uzyskać i jaką pracochłonność (koszt wdrożenia) jesteś skłonny zaakceptować.

Uprzedzając ewentualnie pytania, kwestia wtyczek dla GA / GTM / dataLayer. Korzystając z rozwiązań „z pudełka” jesteś zdany na to, co mądrego zmajstrowali jej twórcy. Ale ten scenariusz pomijam w poniższych rozważaniach, bo ile wtyczek, tyle potencjalnych problemów do rozwiązania.

Skupmy się na opcji, gdzie dataLayer wdrażasz customowo przy wsparciu programisty.

Opcja #1: Przesyłanie do dataLayer danych zarówno w formacie GA3, jak i formacie GA4

Programiści ogarniający wdrożenie Cię pewnie za to nie polubią, ale z perspektywy konfiguracji po stronie GTM jest to najprostsze wyjście. Pamiętaj tylko, aby wysyłać różne wartości zmiennej event pomiędzy GA3 i GA4. Przykładowo event: addToCart dla DL.push w formacie GA3 i event: add_to_cart w DL.push w formacie GA4. Wtedy łatwiej konfiguruje się reguły.

Opcja #2: dataLayer tylko w formacie GA4

Jeśli uznasz, że już teraz wiodącym narzędziem ma być GA4, to warto pójść w tym kierunku i stworzyć dataLayer w docelowym formacie „czwórki”

Tagi GA3 można od pewnego czasu obsłużyć na bazie dataLayer z GA4 za pomocą magicznego checkboxa. Jeśli zaakceptujesz pewne braki w danych, to konfiguracja będzie błyskawiczna.

Ale jeśli chcesz mieć idealne dane także w GA3, to w oparciu o DL z GA4 też to osiągniesz. Wymaga to większych nakładów pracy, bo musisz wtedy stworzyć szereg zmiennych przechwytujących dane z DL, a następnie napisać skrypty w tagach cHTML, które zbudują obiekt ecommerce w formacie GA3 i będą zawierać linijkę event, o którą oprzesz reguły dla zdarzeń GA3, finalnie przesyłających dane ecommerce do analyticsa.

Opcja #3: dataLayer tylko w formacie GA3

Opcja najłatwiejsza. Zazwyczaj jeśli śledzenie ecommerce na stronie już jest, to dataLayer ma format GA3. I tutaj ponownie można pójść łatwą ścieżką i zaznaczyć checkbox (nie polecam).

Lepiej jednak ręcznie skonfigurować przynajmniej te trudniejsze zdarzenia, jak begin_checkout, add_payment_info czy add_shipping_info. Prawdopodobnie będziesz musiał pokombinować z regułami, i przykładowo add_payment_info uruchamiać na event = checkout, ale tylko wtedy, gdy step = 2 (wszystko zależy od sposobu, w jaki zbudowany jest proces składania zamówienia).

Nierzadko zdarzenia związane z uzupełnieniem danych do wysyłki czy wyborem formy płatności powinny być wysyłane na kliknięciu przycisku. Jeśli tylko w takim momencie nadal dostępne są w dataLayer dane ecommerce, to możesz je przechwycić i na kliku wysłać do GA4.

Cóż, czasem trzeba będzie włączyć kreatywne myślenie. Ale pamiętaj – praktycznie wszystko jest do zrobienia, jeśli odpowiednio długo pogłówkujesz

Wymiary niestandardowe dla produktów

Wymiary niestandardowe o zakresie produkt to kluczowy element zaawansowanych konfiguracji śledzenia ecommerce. Zazwyczaj są wykorzystywane do przekazywania wymiarów dopasowanych do asortymentu oferowanego przez sklep.

Przykładowo księgarnia online może widzieć wartość w przesyłaniu do GA4 informacji o liczbie stron, nazwisku autora czy gatunku książki. Z kolei internetowy sklep z odzieżą chętnie dowie się, jakie rozmiary, kolory czy wzory sukienek sprzedają się najlepiej.

Pamiętaj, żeby taki wymiar niestandardowy – poza umieszczeniem go w dataLayer wraz z wymiarami opisującymi dany produkt – dodać także w panelu administracyjnym GA4 w sekcji Definicje niestandardowe, wybierając odpowiedni zakres.

Obowiązuje tu też limit maksymalnie 10 wymiarów niestandardowych, przekazywanych per produkt.

Podsumowanie

Wdrażanie dataLayer i śledzenia ecommerce potrafi być drogą przez mękę. W tym artykule zaledwie spojrzeliśmy na temat z lotu ptaka.

Przedstawiłem Ci dostępne opcje, ale jeśli chciałbyś szczegółowo nauczyć się części wdrożeniowej, sprawdź mój kurs online Google Tag Manager i kurs online Google Analytics 4, gdzie poświęciłem kilka godzin materiałów wideo, aby wyjaśnić wszystkie zawiłości związane z tym aspektem.

Zdjęcie: Pexels (Andrea Piacquadio)