Dobre praktyki w E-commerce. Najbardziej przydatne raporty w GA4. Q&A po webinarze

Webinar “Dobre praktyki w E-commerce. Najbardziej przydatne raporty w GA4” cieszył się ogromnym zainteresowaniem. Zadaliście Joannie Horoszko dużo ciekawych pytań, na które nasza Digital Analyst odpowiedziała także na łamach bloga Sempai.

Pytanie nr 1: Czy te Universale, które już nie działają to wynik wyłączenia przez Google czy przez wtyczkę?

Google zapowiadało, że od 1 lipca 2023 r. będzie wyłączać procesowanie danych w Universal Analytics. Nie stało się to na zasadzie wyłączenia wszystkich Universalów na raz, a na zasadzie wybiórczej przez Google. Google zapewnia jednak, że te Universale, które jeszcze działają wkrótce też zostaną wygaszone.

Także, o ile nie było żadnej niepomyślnej aktualizacji wtyczki do Universala dla danego silnika sklepu, to powodem niedziałania Twojego Universala najprawdopodobniej jest wyłączenie procesowania danych dla Twojej usługi Universal Analytics. 

Pytanie nr 2: A jeżeli chcemy użyć tego linku w GMF w celu zliczania wejść na stronę z wizytówki?

Spotykam się z tym, że Klienci chcą mieć w Analyticsie raportowane wejścia z GMF zrobione na jeden z dwóch sposobów:

1. niektórzy chcą by ten ruch wpadał do odesłań, czyli do Referrala. W takim przypadku UTM powinien być zbudowany w następujący sposób: https://adrestwojejdomeny.pl/?utm_source=gmf&utm_medium=referral

2. jeszcze inni chcą by ten ruch był nadal, tak jak to standardowo się dzieje, przypisywany do Organic Search, ale w źródle/medium chcą widzieć, że to był GMF, a nie google/organic. W tej sytuacji UTM powinien być zbudowany w  następujący sposób: https://adrestwojejdomeny.pl/?utm_source=gmf&utm_medium=organic 

Pytanie nr 3: Czy UTM, które były ustawiane do tej pory dla UA należy jakoś zmienić dla GA4?

Jeśli dotychczas ruch np. z emaili był w UA przypisywany prawidłowo do kanału Email a nie do (other), to GA4 też będzie prawidłowo przypisywać ten ruch do kanału Email. Podobnie jest z kanałami Affiliates, Referral, Social z UA → Organic Social w GA4.

W skrócie, należałoby się przyjrzeć tym źródłom/medium ruchu, które dotychczas były przypisywane w UA do kanału (other). Należałoby sprawdzić czy w (other) mamy taki rodzaj ruchu, który przez to, że są błędnie nadawane UTM’y, będzie przypisywany w GA4 do kanału Unassigned.

Poniżej zamieszczam link do dokumentacji Google:

• UTMy dla GA4: https://support.google.com/analytics/answer/9756891?hl=en (część dot. Channels for manual traffic)
• UTMy dla Universal Analytics: https://support.google.com/analytics/answer/3297892?hl=en 

Pytanie nr 4: Po wejściu na ten sam raport przy Unassigned dodając wymiar sesja – źródło/medium mam puste pola lub (not set), jak sobie z tym poradzić?

Jeśli masz wdrożony Consent Management Platform i uruchamianie kodów śledzących działa zgodnie z typem wyrażonej/niewyrażonej zgody, to w GA4 jako Unassigned sesja – źródło/medium będzie pojawiać się (not set). Jest to prawidłowe zjawisko, gdyż GA4 uruchomione w trybie zbierania pingów (czyli gdy użytkownik nie wyraził zgody na analytics_storage), zgodnie z prawem nie może zbierać pełnych danych o pochodzeniu użytkownika, jego wieku, płci, geolokalizacji itp. Taki ruch będzie przypisywany do kanału Unassigned, a w źródło/medium zobaczymy (not set). 

Z kolei jeśli nie masz jeszcze poprawnie działającego Consent Mode a masz (not set) w Unassigned to tu przyczyn może być wiele. Takie najpopularniejsze przyczyny to:

1. Zbyt świeże dane – GA4 przetwarza podstawowe dane o ruchu przez 24-48h, do tego jeśli podczas wizyty wydarzyła się konwersja, to procesowanie danych może potrwać nawet 7 dni. Przez ten czas w raportach możemy widzieć ruch i konwersje przypisywane do kanału Unassigned (not set), a po kilku dniach ten ruch może stamtąd zniknąć, a pojawi się w kanale np. Cross-network. Więcej o tym co mówi Google na temat długości przetwarzania danych znajdziesz tutaj: https://support.google.com/analytics/answer/9333790?hl=pl i tutaj: https://support.google.com/analytics/answer/11986666?hl=pl#goals_vs_conversions&zippy=%2Cin-this-article%2Ctematy-w-tym-artykule [“GA4 może np. aktualizować przypisane konwersje przez 7 dni od momentu zarejestrowania konwersji”].

2. Problem z wtyczką w panelu sklepu, która ma przesyłać dane ze sklepu do GA4 za pomocą Measurement Protocol (bardzo częste zjawisko na silnikach PrestaShop).

3. Problem z połączonymi tagami witryny.

Pytanie nr 5: Czy jest opcja zdefiniowania własnych kanałów w GA4? Pytam w kontekście tego, czy jest inna opcja niż trzymać się 100% instrukcji Google do tworzenia UTM-ów?

Tak, w GA4 pojawiła się już opcja definiowania własnych kanałów. Można znaleźć ją tutaj: Administracja > Usługa > Ustawienia danych > Grupy kanałów. 

Jednak z naszych dotychczasowych obserwacji tworzenie własnych grup kanałów może przysparzać problemy przy późniejszym raportowaniu. Jak chociażby raportowanie ścieżek konwersji, gdzie nie zobaczymy utworzonych przez siebie grup kanałów.

Więcej o niestandardowych grupach kanałów znajdziesz na stronie: https://support.google.com/analytics/answer/13051316?hl=pl#zippy=%2Cin-this-article%2Ctematy-w-tym-artykule 

Pytanie nr 6: Co zrobić, jak jest więcej niż jeden zakup e-commerce przy identyfikatorze transakcji?

Kroki, które należy podjąć w takiej sytuacji to:

1. Sprawdzamy, jak duża jest skala takiego zjawiska – po ile razy dubluje się zdarzenie zakupu dla danego ID transakcji.

2. Przyglądamy się, co widać na wykresie liniowym, na którym mamy zaznaczony czas, ID transakcji i ilość zakupów – na wykresie możemy zobaczyć od kiedy dane zjawisko występuje. Pomoże to nam w ustaleniu, co było wdrażane w sklepie w tym samym okresie gdy kilkukrotnie zaczęło się uruchamiać zdarzenie zakupu.

3. Robimy testową transakcję w trybie debugowania. Więcej o tym jak debugować znajdziesz w artykule na naszym blogu: https://sempai.pl/blog/krok-4-dodatek-jak-debugowac-w-gtm-i-ga4/ 

Debugujemy przy użyciu Google Tag Managera i konsoli, po czym patrzymy co się dzieje w warstwach danych podczas zdarzenia zakupu. Być może masz taką sytuację, że zdarzenie purchase uruchamia się 2, 3 lub nawet 4 razy (bo np. jeden purchase ma w warstwie danych zapisane dane dla GA4, drugi dla remarketingu, trzeci dla FB, a czwarty dla UA), a w Google Tag Managerze masz taki tag, który ma w ustawieniach uruchamiać się za każdym razem, gdy wystąpi zdarzenie purchase. W takiej sytuacji należałoby zmienić ustawienia tagu w taki sposób, by uruchamiał się tylko na tym zdarzeniu purchase, które ma w warstwie danych dane dla GA4. Przykład konfiguracji takiego tagu:

Pytanie nr 7: A w kolumnie zdarzenia nie można wyszukać tego zdarzenia?

W kolumnie „zdarzenia” można wyszukać liczbę zdarzeń ogółem, ale nie dowiemy się jakie konkretnie było wyszukiwane hasło (dowiemy się ile było zdarzeń view_search_results). Tak samo analiza samej liczby zdarzeń „purchase” bez zestawienia tego z „ID transakcji” nie da nam pełnego obrazu kiedy dubluje się „purchase”. Jeśli mamy zestawione „ID transakcji” z daną „zakupy e-commerce” to możemy zobaczyć dokładnie dla których „ID zamówienia” dubluje się „purchase”. Może okazać się, że np. jakaś forma płatności, którą mamy w sklepie, generuje podwójne uruchamianie zdarzenia „purchase”. 

Pytanie nr 8: Co w przypadku, gdy nie pokazuje żadnego wyszukiwanego hasła, błędna konfiguracja zdarzeń?

Najprawdopobniej Twoja witryna/sklep ma inny parametr zapytania niż standardowo “wbudowane do czytania” przez GA4. GA4 wychwytuje wyszukiwane hasła w witrynie pod warunkiem, że przed wyszukiwanym hasłem w URL-u pojawią się takie parametry zapytań, jak któreś z listy: ?q=,?s=, ?search=, ?query=, ?keyword=

Jeśli w Twojej witrynie/sklepie występuje inny parametr zapytania, jak np. ?url=

to należy ten niestandardowy parametr zapytania dodać do Twojego GA4 w następujący sposób:

Gdzie to się konfiguruje: Administracja > Usługa > Strumienie danych > Strumień danych z sieci > Pomiar zaawansowany > ikonka ⚙️

Pytanie nr 9: A co zrobić jak mamy jednoetapowy koszyk i chcemy zobaczyć na jakim etapie użytkownik rezygnuje z zakupu, np. gdy jak zobaczy płatności czy dostawy. Czy można sprawdzić np. ile strony zescrollował?

Mierzenie jaki procent strony (konkretnego URL) z jednoetapowym koszykiem został zescrollowany jest jedną z możliwości, jednak najlepszym rozwiązaniem (jeśli nie mamy zdarzeń add_payment_info i add_shipping_info uruchamianych za każdym razem, gdy zostanie wybrana konkretna opcja płatności lub dostawy) będzie zbudowanie w GTM tagów, które będą wyłapywać z frontu strony kliknięcia w poszczególne elementy, np.:

uruchomienie tagu “Zdarzenie GA4” o nazwie zdarzenia “wybranie_metody_płatności” z regułą uruchamiania na kliknięcie elementu o clasie el-radio__input is-checked

Pytanie nr 10: A czy w raporcie ID transakcji jest możliwość edytowania, zmieniania dat?

Tak, jest taka możliwość, tylko trzeba wyjść z trybu edytowania raportu.

Pytanie nr 11: Co zrobić, żeby GA nie zmieniał na zakres dat standardowy last 28 dni, a trzymał te, które wybraliśmy, np. przy przeklikiwaniu się między kilkoma domenami, np. z PL na DE?

Wiemy, że jest to irytujące, ale na ten moment GA4 niestety “nie zapamiętuje” zakresu dat tak, jak to robił Universal Analytics.

Jednak dostrzegliśmy pewną zależność – jeśli mamy kilka usług GA4 w ramach tego samego konta Analytics (np. jedna usługa na rynek PL, a druga na DE) to podczas przełączania się między usługami w ramach tego samego konta, zakres dat zostaje “zapamiętany”. Jednak gdy zdecydujemy się przejść do usługi, która znajduje się na innym koncie Analytics, to GA4 domyślnie pokaże nam ostatnie 28 dni.

Przeczytaj również: Automatyczna konfiguracja GA4 – zgadzać się czy rezygnować?