Google Analytics 4 [GA4] BigQuery - 9 wyzwań, które Cię zaskoczy podczas analizy danych

Kontynuacja serii wpisów o danych Google Analytics 4 [GA4] w BigQuery

Artykuł ten jest elementem z serii wpisów o Google Analytics 4 i eksporcie danych do Google BigQuery, składającym się z następujących pozycji:

• #1 Google Analytics 4 BigQuery - dlaczego warto korzystać ?
• #2 Google Analytics 4 BigQuery - 9 wyzwań, które Cię zaskoczy podczas analizy danych (obecnie go czytasz)
• #3 Google Analytics 4 BigQuery - źródła ruchu, sesje, atrybucja, koszty marketingowe i gotowe dane do analiz
  
  

W poprzednim wpisie Google Analytics 4 BigQuery - dlaczego warto korzystać ? omówiliśmy szereg argumentów mówiących o tym dlaczego warto korzystać z eksportu danych Google Analytics 4 w BigQuery.
Podczas interakcji z danymi możemy jednak napotkać na różne trudności o których warto wiedzieć wcześniej, zanim spędzimy wiele godzin nad detektywistyczną próbą ich pokonania. Postanowiliśmy więc napisać artykuł informacyjny o tych problemach - jest to zbiór naszych doświadczeń z projektów bazujących na eksporcie danych z Google Analytics 4.

#1 Dane raportowane w Google BigQuery będą inne niż te, które widać w panelu Google Analytics 4 [GA4]

Pierwszym zadaniem jakie sobie postawiliśmy podczas pracy z eksportem danych Google Analytics 4 w BigQuery było odtworzenie logiki raportów, które możemy znaleźć w interfejsie. W ten sposób możemy bardzo dużo się nauczyć i zrozumieć dokładnie jak dane metryki i wymiary są liczone oraz zwalidować poprawność naszych zapytań.

Tutaj zadanie okazało się utrudnione, gdyż zgodnie z dokumentacją Google Analytics 4 dane w panelu mogą się różnić od tych, które będziemy obliczać w BigQuery.

Nawet jak dane w panelu Google Analytics 4 pokazują, że nie są próbkowane, to liczba sesji i tak jest estymacją na podstawie liczby unikalnych identyfikatorów sesji. Więcej o tym można poczytać w tym miejscu: Unique count approximation in Google Analytics

W BigQuery najczęściej nie korzystamy z funkcji estymacji, w związku z tym możemy zauważyć różnice np. w liczbie sesji w porównaniu z wynikami podawanymi w raportach standardowych i eksploracyjnych czy też w Looker Studio.

Dostajemy więc poniższe rekomendacje od Google:

• Jeżeli chcemy uzyskać dokładniejsze wyniki na podstawie nieprzetworzonych danych, powinniśmy użyć do tego eksportu danych w Google BigQuery
• Jeżeli zależy nam na szybkim otrzymaniu wyników uwzględniając margines błędu, najlepiej sprawdzać je w raportach w panelu
  
  

#2 Informacje o źródłach kampanii - w BigQuery mamy obliczone tylko pierwsze źródło pozyskania użytkownika

Najpopularniejszym raportem w Google Analytics Universal był niewątpliwie raport przedstawiający źródło/medium. Taki raport został również odtworzony w Google Analytics 4. Możemy go znaleźć w domyślnej sekcji Acquisition -> Traffic Acquisition.

W tym raporcie wykorzystywany jest wymiar o nazwie “Session source/medium”, który informuje nas o źródle pochodzenia danej sesji.

Przeglądając dane wyeksportowane do Google BigQuery dla GA4 napotykamy pola nazwane traffic_source.source, traffic_source.medium, traffic_source.name (nazwa kampanii), które bardzo często są błędnie wykorzystywane do odtworzenia powyższego raportu.




Problem polega jednak na tym, że są to pola informujące nas o tym co wystąpiło w pierwszej kampanii od czasu pozyskania tego użytkownika, a nie o źródle, które wystąpiło w danej sesji, tak jak możemy to przeglądać w raportach i wymiarze “Session source/medium”.





Korzystając z tych pól w tabeli osiągniemy więc inny obraz niż w przypadku wymiaru “Session source / medium” w panelu.

AKTUALIZACJA - poniższe parametry są aktualnie dostępne na poziomie parametrów zdarzeń oraz w kolumnach znajdujących się w grupie collected_traffic_source. Należy jednak pamiętać, że nie są to dane obliczone zgodnie z logikę wymiarów tj. Session source/medium/campaign

Aby odtworzyć ten wymiar musimy wyciągnąć parametry kampanii z poziomu eventów, a następnie samemu obliczyć te dane zgodnie z logiką opisaną w dokumentacji dla wszystkich sesji: [GA4] Scopes of traffic-source dimensions - Analytics Help

#3 Google Analytics 4 [GA4] wykonuje deduplikację na użytkownikach pomiędzy urządzeniami

Dużą rewolucją w Google Analytics 4 w porównaniu do Google Analytics Universal jest możliwość połączenia danych pomiędzy platformami/urządzeniami. Implementując usługę Google Analytics 4 na naszej stronie internetowej oraz w aplikacji mobilnej jesteśmy w stanie uzyskać jedno przejrzyste źródło analiz dla tych platform.

Domyślnie Google Analytics dla każdego urządzenia/przeglądarki generuje “user_pseudo_id”, czyli nowe ciasteczko (strona internetowa) lub identyfikator (aplikacja mobilna). Na podstawie tego identyfikatora wykonywane są obliczenia niezbędne do przedstawienia wszystkich metryk i wymiarów w panelu.
Jeden użytkownik może odwiedzić naszą stronę lub aplikację z różnych urządzeń. Jeżeli odwiedzi nas na stronie internetowej na komputerze, następnie na stronie internetowej na urządzeniu mobilnym, a na końcu w aplikacji mobilnej to będzie identyfikowany jako 3 różnych użytkowników.

Jeżeli zdecydujemy się na włączenie usługi Google Signals lub implementację funkcji User ID (np. własny identyfikator z bazy danych podczas logowania lub zakupu), Google Analytics przeprowadzi na Twoich danych deduplikację (na ile jest to możliwe w przypadku opcji Google Signals) , co wpłynie na liczbę użytkowników oraz atrybucję kanałów marketingowych. Dane możemy przeglądać na różnym poziomie (po deduplikacji lub bez deduplikacji) w zależności od naszych ustawień tożsamości w usłudze Google Analytics 4 - więcej o tym znajduje się tutaj: [GA4] Tożsamość raportowania - Analytics - Pomoc

Warto jednak pamiętać, że dane Google Signals to dane, które Google potrafi połączyć z użytkownikami, którzy zalogowali się na swoje konta Google i mają włączoną personalizację reklam. Powiązanie tych danych z zalogowanymi użytkownikami umożliwia przedstawienie dokładniejszej liczby użytkowników w raportach. Ze względu na politykę prywatności użytkowników, firma Google nie może nam tych danych udostępnić, co wpływa również na rozbieżności w danych pomiędzy interfejsem, a raportach w Google BigQuery. Więcej o tym można poczytać tutaj: [GA4] Aktywacja Google Signals w usługach Google Analytics 4





Warto pamiętać - jeżeli mamy zaimplementowany parametr user_id na swojej witrynie lub aplikacji, wciąż możemy starać się odtworzyć deduplikację użytkowników w BigQuery - tylko w ten sposób osiągniemy poprawną liczbę użytkowników oraz prawidłową atrybucję źródeł ruchu do sesji zgodnie z logikę “Cross-Device”.

Z problemem deduplikacji oraz potencjalnym rozwiązaniem można zapoznać się w artykule Complex Deduplication in BigQuery | by Benjamin Campbell

#4 Jeden identyfikator sesji (ga_session_id) może zostać przypisany do 2 różnych użytkowników

W programowaniu intensywnie wykorzystuje się znaczniki czasu, czyli tzw. timestamp.
Dana ta pozwala określić moment, w którym zaszło określone zdarzenie.
Wartość takiego znacznika definiowana jest na podstawie “Unix Time”, czyli systemie reprezentacji czasu mierzącego liczbę sekund od początku 1970 roku.

Dla przykładu Timestamp 1672481243 reprezentuje datę i godzinę: 2022-12-31 10:07:23
Jest to więc 1672481243 sekund od początku 1970 roku.

Przeglądając dane Google Analytics 4 w BigQuery również mamy dużo kontaktu ze znacznikami czasu np. pole o nazwie event_timestamp zawiera liczbę mikrosekund od roku 1970.

Kiedy przyjrzymy się identyfikatorowi o nazwie “ga_session_id” zobaczymy, że jest to przybliżony czas pierwszego zdarzenia rozpoczynającego sesje.

W związku z tym, że kilku użytkowników może rozpocząć sesje w tym samym czasie (dokładnie w tej samej sekundzie), sam parametr tj. ga_session_id nie daje unikalnego identyfikatora sesji. W tym celu musimy połączyć user_pseudo_id czyli identyfikator użytkownika oraz ga_session_id, aby otrzymać unikalny identyfikator sesji do naszych obliczeń. Możemy to zrobić dzięki funkcji CONCAT.

SELECT
   CONCAT(user_pseudo_id, ga_session_id) as session_id
FROM
   your_google_analytics_4_events


Powstanie nam wtedy unikalny ciąg znaków oznaczający identyfikator danej sesji:

1020668977.16723547091672354709

Ciekawostka - jeżeli przyjrzymy się wartości user_pseudo_id i zobaczymy z czego jest ona złożona, również zauważymy w nim timestamp oznaczający datę utworzenia danego użytkownika.

1020668977.1672354709 = {{random number}} + “.” + {{user created timestamp}}

#5 Jeden identyfikator sesji może wystąpić w 2 różnych dniach

Google Analytics Universal tworzył nową sesję za każdym razem, gdy:

• nie było interakcji przez więcej niż 30 min (na podstawie domyślnych ustawień)
• w chwili, gdy zmieniały się parametry kampanii ( tj. utm, gclid, referral)
• w chwili, gdy sesja odbywała pomiędzy jednym a drugim dniem

Przykładowo, jeżeli mieliśmy sytuację, w której użytkownik rozpoczął sesję o godz. 23:58, a zakupu dokonał nie odchodząc od komputera o godz. 00:05 następnego dnia, to Google Analytics Universal tworzył w takim przypadku 2 różne identyfikatory sesji - pierwsza trwała od 23:58 do 00:00 a druga od 00:00 do 00:05(zakładając, że zamknął przeglądarkę zaraz po zakupie).

W przypadku Google Analytics 4 identyfikator sesji pozostanie ten sam pomiędzy jednym a drugim dniem. W związku z tym jeżeli będzie nam zależeć na policzeniu dokładnych metryk dla danej sesji, musimy pamiętać, aby w trakcie analiz brać pod uwagę również dane z dnia poprzedniego np. w celu sprawdzenia strony wejścia/docelowej dla danej sesji. Wpływa to na wielkość procesowanych danych i konieczność stosowania dodatkowych modyfikacji w zapytaniach SQL.

#6 Adres url strony (page_location) może mieć maksymalnie 420 1000 znaków

AKTUALIZACJA - ograniczenia limitu znaków dla parametru page_location zostały zmienione z 420 na 1000 znaków

Jeżeli masz długie adresy url, wykorzystujące wiele parametrów to analiza tych danych w BigQuery może Cię zaskoczyć. Podczas jednego z projektów klient poprosił nas o analizę filtrów wybieranych przez użytkownika na podstawie parametrów znajdujących się w adresach url. Z optymizmem usiedliśmy do zadania, pisząc wyrażenia regularne pozwalające na ekstraktowanie parametrów z adresów url.
Po krótkiej analizie, zauważyliśmy, że części parametrów nie ma lub często są ucinane w adresach url. Postanowiliśmy więc sprawdzić maksymalną długość adresów url i okazało się, że spora część ma zawsze 420 znaków - wszystkie te adresy miały ucięte parametry ze względu na długość.

Nasza rekomendacja: jeżeli wiemy, że dane parametry url będą dla nas bardzo istotne podczas analizy danych, powinniśmy je wtedy przekazać jako parametry zdarzenia. Pamiętajmy jednak, że page_location to parametr systemowy, który może mieć 420 1000 znaków. W przypadku niestandardowych parametrów limit znaków wynosi 100. Więcej o limitach można przeczytaj tutaj: [GA4] Event collection limits - Analytics Help

#7 Dane bez zgody analitycznej nie zawierają informacji o user_pseudo_id i ga_session_id

Jeżeli mamy poprawnie zaimplementowaną funkcję consent mode od Google, dane mogą trafiać do Google Analytics w różnej postaci. Jeżeli użytkownik nie wyraził zgody na jego identyfikację poprzez cookie, jego zdarzenia będą wysyłane do Google BigQuery, ale parametry tj. user_pseudo_id oraz session_id będą miały wartość null. Jeżeli planujemy więc podczas analiz wykorzystywać te dane do łączenia lub innych obliczeń warto o tym pamiętać, gdyż wiele danych może nam się zgrupować do jednego nieistniejącego użytkownika lub do jednej nieistniejącej sesji.

#8 W chwili, gdy nasze transakcje trafiają do Google Analytics w różnych walutach, musimy zadbać o ich przeliczenie

Jeżeli na naszej stronie lub w aplikacji użytkownicy mogą dokonywać zakupów w różnych walutach, musimy zadbać o przekonwertowanie wartości do waluty, która została ustawiona w ustawieniach danej usługi.
W przypadku przesyłania w implementacji parametru zdarzenia “currency”, Google Analytics 4 udostępnia nam dodatkowe pola, w których znajdują się automatycznie przekonwertowane dane do waluty USD. Niestety nie możemy nigdzie zdefiniować waluty, w której chcielibyśmy zrzucać dane do Google BigQuery. W związku z tym jeżeli mamy w swoich ustawieniach usługi wybraną walutę np. PLN, to w takim przypadku będziemy musieli ściągnąć do Google BigQuery informacje o kursie z danego dnia i samodzielnie przekonwertować te informację, aby móc odwzorować to co widzimy w panelu.

#9 Brak pełnych informacji o pełnych danych Google Ads oraz podatność na zmiany nazw kampanii

W eksporcie danych Google Analytics Universal do BigQuery byliśmy przyzwyczajeni do bogatych informacji na temat kampanii Google Ads.



Tak jak wcześniej wspomnieliśmy, w przypadku danych Google BigQuery mamy obliczone tylko 3 pola tj. traffic_source.source, traffic_source.medium oraz traffic_source.name i są to pola, które mówią o pozyskaniu użytkownika, a nie o źródłach danej sesji.
W przypadku chęci wzbogacenia danych Google Analytics 4 o dodatkowe informacje z Google Ads między innymi identyfikator konta reklamowego, identyfikator kampanii, typ kampanii, musimy zadbać o zaciągnięcie tabel Google Ads do Google BigQuery, a dopiero w następnym kroku o połączenie ich za pomocą dodatkowych instrukcji SQL. Proces ten potrafi dosyć mocno rozbudowywać logikę zapytań, w związku z tym jest to kolejne utrudnienie, na które musimy być gotowi podczas eksploracji danych.

Podsumowanie

Google Analytics 4 i możliwość eksportu danych do Google BigQuery to świetne rozwiązanie, dla wszystkich firm, które chcą podejmować sprawne decyzje na podstawie danych. Jeżeli chcemy jednak w pełni wykorzystać ich potencjał i działać zgodnie z najnowszymi praktykami związanymi z mierzeniem ruchu pomiędzy urządzeniami musimy poświęcić sporo czasu na przeprocesowanie tych danych (deduplikacja użytkowników, atrybucja źródeł ruchu, łączenie danych Google Ads). Musimy być również gotowi na rozbieżności danych pomiędzy panelem Google Analytics 4, a tym co dostaniemy jako wynik w Google BigQUery.

Na szczęście większość problemów związanych z procesowaniem danych da się zautomatyzować - o tym jak do tego podeszliśmy napisaliśmy kolejny artykuł “Google Analytics 4 BigQuery - sesje, atrybucja i gotowe dane do analiz”.