Google Analytics 4 [GA4] BigQuery - źródła ruchu, sesje, atrybucja, koszty marketingowe i gotowe dane do analiz
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
- #3 Google Analytics 4 BigQuery - źródła ruchu, sesje, atrybucja, koszty marketingowe i gotowe dane do analiz (obecnie go czytasz)
Ostatni wpis dotyczył wyzwań analitycznych związanych z analizą danych w Google BigQuery. Firmy oraz pracujący w nich analitycy jak i specjaliści powinny skupiać się głównie na podejmowaniu decyzji w oparciu o dane, a nie na mozolnym i kosztownym przygotowywaniu i obrabianiu danych do ich analizy.
W odpowiedzi na to wyzwanie, w naszej platformie WitCloud postanowiliśmy stworzyć moduł analityczny, który w oparciu o wyeksportowane dane Google Analytics 4 do Google BigQuery, rozwiąże problemy z ich obróbką i przygotuje te dane w takiej formie, aby były gotowe do wykorzystania w firmie do rozmaitych analiz lub integracji z innymi systemami.
W tym artykule, krok po kroku omówimy jakie modyfikacje wprowadziliśmy do danych i w jaki sposób podeszliśmy do zaprojektowania struktury danych w Google BigQuery.
Wzbogacenie tabeli events o źródła ruchu
Problem ubogich danych o źródłach ruchu w Google BigQuery
W artykule #2 Google Analytics 4 BigQuery - 9 wyzwań, które Cię zaskoczy podczas analizy danych, poruszyliśmy problem związany z brakiem obliczonych źródeł ruchu dla konkretnych sesji oraz ubogi dostęp do danych Google Ads. W domyślnie wyeksportowanej tabeli “events_” mamy dostępne tylko pola tj. traffic_source.source, traffic_source.medium, traffic_source.name (nazwa kampanii).
Nawiązując do naszego poprzedniego artykułu problem polega jednak na tym, że są to pola informujące nas o tym jakie źródło wystąpiło w pierwszej kampanii 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” w panelu Google Analytics 4. Oznacza to, że w panelu Google dostarcza nam obrobione dane, a korzystając z surowych danych w BigQuery musimy zrobić to sami.
Korzystając z tych pól w tabeli osiągniemy więc inny obraz niż w przypadku wymiaru “Session source / medium” w panelu.
Dodatkowo w tabeli brakuje nam bardziej szczegółowych informacji na temat kampanii Google Ads, tak jak miało to miejsce w eksporcie danych Google Analytics Universal 360 (wersja premium)
Rozwiązaniem problemu jest wzbogacenie tabeli events o źródła ruchu sesji w modelu Google Analytics 4 i Universal Analytics
W odpowiedzi na to wyzwanie postanowiliśmy wzbogacić tabelę “events_” o dodatkowe grupy pól, które zwracają informację na temat źródeł ruchu występujących w danej sesji oraz dodatkowe informacje na temat kampanii Google Ads.
Dane zostały wzbogacone w modelu Google Analytics 4, który nie tworzy nowej sesji przy zmianie źródła kampanii w trakcie trwania sesji oraz w modelu Google Universal Analytics, który tworzy nową sesję za każdym razem jak pojawi się nowe źródło ruchu.
Możliwość śledzenia użytkownika pomiędzy urządzeniami
Zanim omówimy sposób działania poszczególnych modeli na przypadkach, musimy wspomnieć o kluczowym elemencie jaki musieliśmy wziąć pod uwagę przy tworzeniu modułu czyli śledzeniu użytkowników pomiędzy urządzeniami takimi jak komputery, smartfony i tablety (cross-device).
Google Analytics 4 posiada do tego odpowiednie funkcjonalności, które potrafią połączyć zdarzenia na ścieżce użytkownika na podstawie 3 wymiarów tj.:
- Device ID, czyli ciasteczko przeglądarki lub identyfikator w aplikacji
- User ID, czyli możliwy do implementacji identyfikator użytkownika z naszej bazy danych np. po rejestracji/zalogowaniu na naszej stronie/aplikacji
- Google ID (Google Signals), czyli identyfikator połączony z zalogowanym użytkownikiem w Google (wymaga dodatkowej aktywacji w ustawieniach administracyjnych usługi)
Domyślnie Google Analytics śledzi użytkownika tylko na podstawie Device ID, czyli ciasteczka lub identyfikatora aplikacji. Oznacza to, że jeżeli wejdziemy na wybraną stronę z urządzenia mobilnego, a następnie z komputera stacjonarnego, to Google Analytics zaraportuje nam informacje o 2 różnych użytkownikach pozyskanych z 2 różnych kanałów. Na tej podstawie nie jest więc możliwe śledzenie użytkowników pomiędzy urządzeniami, gdyż każde urządzenie oraz każda przeglądarka będą miały inny identyfikator użytkownika.
Jeżeli jednak zdecydujemy się na przesłanie w implementacji własnego identyfikatora użytkownika np. po zalogowaniu/rejestracji lub na aktywację opcji Google Signals, to system Google przeprowadzi na wszystkich zebranych danych deduplikację użytkowników, czyli znajdzie połączenie pomiędzy urządzeniami i przedstawi nam w raportach dokładniejsze dane na temat użytkowników i ich zachowań.
W panelu Google Analytics 4 sami możemy decydować czy chcemy widzieć dane z deduplikacją lub bez na podstawie ustawień “Reporting Identity” (tłumaczone w dokumentacji w j. polskim jako “Tożsamość raportowania”).
W Google BigQuery deduplikację użytkowników możemy wykonać jedynie na podstawie 2 wymiarów tj. Device ID oraz User ID, gdyż ze względu na aspekty prawne, dane Google Signals nie są udostępniane w eksporcie danych Google Analytics 4.
Podejście do źródeł ruchu - Google Analytics 4 vs Google Analytics Universal
Poniższy schemat pozwoli nam lepiej odpowiedzieć na 2 kluczowe i powiązane ze sobą pytania:
- Jak wpływa na atrybucję źródeł ruchu, deduplikacja użytkowników z wykorzystaniem parametru user_id?
- W jaki sposób zmieniła się logika liczenia sesji w Google Analytics 4 vs Google Analytics Universal?
Krótki opis schematu:
- Użytkownik wszedł na stronę internetową z urządzenia mobilnego po odesłaniu z Facebooka, co spowodowało utworzenie nowej sesji
- W trakcie trwania sesji wygenerowanej przez Facebooka(przed upływem 30 minut od braku interakcji), użytkownik przeklikał się na stronę jeszcze raz przez reklamę Google
- Po jakimś czasie użytkownik postanowił wejść na stronę ponownie, tym razem z komputera stacjonarnego bez żadnego przekierowania (wejście bezpośrednie)
- Zarówno na urządzeniu mobilnym jak i stacjonarnym użytkownik był zalogowany i został wysłany parametr “user_id”
Spójrzmy teraz, w jaki sposób zachowa się atrybucja źródeł ruchu i kalkulacja sesji dla poszczególnych modeli.
Google Analytics 4 - Cross Device Model
W modelu Google Analytics 4 - Cross Device, po wejściu użytkownika z urządzenia mobilnego i odesłania z Facebooka, zostanie utworzona nowa sesja. W chwili, gdy użytkownik przeklika się przez reklamę Google z tego samego urządzenia w trakcie trwania sesji, nie zostanie utworzona nowa sesja, gdyż Google Analytics 4 nie tworzy nowej sesji w chwili, gdy zmienia się źródło kampanii w trakcie trwania poprzedniej sesji.
W chwili, gdy użytkownik wejdzie z urządzenia stacjonarnego i będzie to wejście bezpośrednie (ruch typu “Direct”), źródło to zostanie nadpisane ostatnim źródłem ruchu, które wystąpiło w poprzedniej sesji - nie będzie to Facebook, tylko Google, który wcześniej nie spowodował utworzenia nowej sesji na urządzeniu mobilnym.
Google Analytics 4 - Device Model
W modelu Google Analytics 4 opartym na Device ID (w przypadku strony internetowej będzie to ciasteczko), każda przeglądarka będzie miała wygenerowany nowy identyfikator użytkownika. W takiej sytuacji sesja pierwsza będzie miała przypisane źródło Facebook, a sesja druga, która odbyła się na innym urządzeniu będzie miała źródło “Direct”. Kampanie Google będzie w tym przypadku zignorowana, gdyż logika Google Analytics 4 nie uwzględnia tworzenia nowej sesji przy zmianie źródła ruchu. Druga sesja (wejście bezpośrednie) nie odziedziczy źródła ruchu, gdyż nie jest w żaden sposób powiązana z poprzednim urządzeniem (brak deduplikacji i wykorzystania user_id). Zostanie więc direct.
Universal Analytics - Device Model
W modelu Universal Analytics opartym na Device ID (obecnie i historycznie wykorzystywany w Google Analytics Universal), w pierwszej sesji zostanie przypisane źródło facebook. Następnie zostanie utworzona nowa sesja, dla źródła Google, gdyż Universal Analytics tworzy nową sesję za każdym razem kiedy źródło kampanii zostanie zmienione w trakcie sesji. Po bezpośrednim wejściu z urządzenia stacjonarnego zostanie utworzona trzecia sesja, która nie zostanie nadpisana wartością Google, gdyż nie jest w żaden sposób powiązana z poprzednim urządzeniem (brak deduplikacji i wykorzystania user_id). Zostanie więc direct.
Universal Analytics - Cross-Device Model
Model Universal Analytics oparty na cross-device to nowość, którą postanowiliśmy odtworzyć na podstawie dedykowanego podejścia związanego z deduplikacją użytkowników w Google Analytics 4, ale z zachowaniem starego podejścia, które zakłada tworzenie nowej sesji kiedy źródło kampanii ulegnie zmianie w trakcie sesji. W ten sposób, pierwsza sesja będzie miała wartość ‘facebook’, następnie zostanie utworzona nowa sesja, dla źródła Google, gdyż Universal Analytics tworzy nową sesję za każdym razem kiedy źródło kampanii zostanie zmienione w trakcie sesji. Po bezpośrednim wejściu z urządzenia stacjonarnego zostanie utworzona trzecia sesja, która zostanie nadpisana wartością Google, gdyż jesteśmy w stanie połączyć ze sobą użytkowników na podstawie deduplikacji z wykorzystaniem user_id.
Dlaczego przygotowaliśmy 3 modele danych?
Decyzje o raportowaniu wybranym modelu Google Analytics mogą zależeć od preferencji danej organizacji, w związku z tym zależało nam na tym, aby każda firma mogła samodzielnie podjąć decyzje na temat tego wyboru lub mieć możliwość porównania danych w różnych modelach.
Z tego względu przygotowaliśmy dane w 3 modelach tj.:
- Google Analytics 4 Cross Device z uwzględnieniem deduplikacji
- Google Analytics Universal Cross Device z uwzględnieniem deduplikacji
- Google Analytics Universal Device bez deduplikacji (znane i lubiane z Google Analytics Universal)
Grupowanie eventów w sesje, czyli tabele sesji dla danych Google Analytics 4
Tabela zdarzeń vs tabela sesji
Tabela zdarzeń, to taka tabela, w której każdy wiersz odpowiada jednemu zdarzeniu ze wszystkimi atrybutami zebranymi na podstawie implementacji na stronie lub w aplikacji. W ten sposób zrzucane są dane Google Analytics 4, w chwili gdy uruchomimy funkcję ich eksportu do Google BigQuery. Pozwala ona bardzo szczegółowo przeglądać wszystkie parametry zdarzeń.
Tabela sesji, to taka tabela, w której każdy wiersz odpowiada jednej sesji - znajdują się tam pogrupowane i obliczone informacje w oparciu o wszystkie zdarzenia, które wystąpiły w tabeli events.
Dlaczego zdecydowaliśmy się na utworzenie tabeli sesji?
Kluczową sprawą było dostarczenie stosunkowo lekkiej tabeli do narzędzi odpowiedzialnych za wizualizację danych. Tabela sesji, ze względu na to, że posiada zagregowane i przeliczone wartości, zajmuje znacznie mniej miejsca w porównaniu do tabeli events.
Dla przykładu tabela events, która miała w sobie 850 000 zdarzeń, miała wagę 1.5 GB.
Tabela sesji, która została utworzona na podstawie tych zdarzeń miała raptem 52 000 wierszy i jej waga wynosiła 83 MB.
Wszystkie narzędzia do wizualizacji zintegrowane z Google BigQuery wykonują zapytanie SQL, o czym pisaliśmy w naszym pierwszym artykule tutaj. Odpytując mniejszą tabelę, wizualizacje działają znacznie szybciej i taniej.
Przygotowując tabelę sesji pomyśleliśmy o obliczeniu najbardziej popularnych metryk wykorzystywanych przy różnych raportach oraz o dodaniu informacji o źródłach kampanii, gelokalizacji, urządzeniach czy też wszystkich informacjach dotyczących transakcji. W związku z tym zyskujemy znacznie lżejszą tabelę, z wciąż bardzo bogatymi informacjami, bez konieczności pisania dodatkowych zapytań SQL odnoszących się do tabeli events.
Moduł dostarcza 3 tabele sesji w modelach tj. Google Analytics 4, Universal Analytics Cross-Device oraz Universal Analytics Device
Na podstawie wyżej opisanych przykładów w sekcji dotyczącej tabeli “events”, wiemy już, że każdy model tj. Google Analytics 4, Universal Analytics Cross-Device oraz Universal Analytics Device, będzie mógł mieć różną liczbę sesji oraz różne źródła ruchu. Dlatego też postanowiliśmy stworzyć 3 tabele dla poszczególnych modeli, które mają taki sam schemat pól (metryk i wymiarów).
Tabele sesji uwzględniają konwersje walut dla sklepów sprzedających na wielu rynkach
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. Wymaga to pobierania kursu waluty z danego dnia poprzez API i utworzenia dodatkowych pól obliczeniowych. Postanowiliśmy więc ułatwić to zadanie i automatycznie przekonwertować wartości dla transakcji i produktów w naszej tabeli sesji, zgodnie z ustaloną walutą w ustawieniach administracyjnych Google Analytics 4.
Google Analytics 4 BigQuery - atrybucja konwersji
Atrybucja źródeł ruchu w Google BigQuery
Posiadając dane Google Analytics 4 w BigQuery, które zostały wzbogacone o źródła ruchu w różnych modelach, nie mogliśmy się powstrzymać od przygotowania dodatkowych tabel zawierających atrybucję kanałów marketingowych. Tak jak w przypadku tabeli sesji, uwzględniliśmy tutaj tabele w 3 modelach tj. Google Analytics 4 Cross Device, Google Analytics Universal Cross Device i Google Analytics Universal Device.
Atrybucja jest wykonywana dla wszystkich zdarzeń, które zostały oznaczone jako konwersja w panelu Google Analytics.
Co zawierają tabele atrybucji?
Tabele atrybucji zawierają w sobie informacje na temat ścieżek konwersji w 5 modelach atrybucji tj. last click non direct, first click, linear, position based oraz timedecay.
Dane pozwalają na szczegółową analizę wszystkich ścieżek użytkowników prowadzących do konwersji. Posiadając obliczoną punktację dla każdego modelu możemy pomnożyć wagę (attribution_score) przez wartość konwersji i uzyskać dokładny wynik w celach raportowych.
Jeżeli naszą konwersją jest zdarzenie “purchase”, w tabeli odnajdziemy również wszystkie informacje o transakcjach i sprzedawanych produktach. Daje to wiele dodatkowych możliwości np. możemy połączyć na podstawie identyfikatora transakcji oraz produktu, dane z CRM na temat zysku i sprawdzić, które kanały marketingowe wspierają konkretne grupy produktów na ścieżce zakupowej.
Moduł Google Analytics 4 BigQuery w WitCloud - zacznij swoją przygodę analityczną w 30 minut
Konfiguracja eksportu danych w Google BigQuery i utworzenie konta w platformie WitCloud
Przygodę z wyżej opisanymi danymi można rozpocząć w mniej niż 30 minut. Potrzebny jest do tego projekt na Google Cloud Platform oraz uruchomiony eksport danych Google Analytics 4 do BigQuery.
Jeżeli zakładamy konto rozliczeniowe w Google Cloud Platform po raz pierwszy, na start dostaniemy 300$ do wykorzystania przez pierwsze 90 dni.
Instrukcja założenia projektu na Google Cloud Platform
Instrukcja uruchomienia eksportu danych Google Analytics 4 do BigQuery
Kolejnym krokiem jest założenie konta i projektu w platformie WitCloud. Oferujemy okres próbny, który trwa 14 dni. Biorąc więc pod uwagę 300$ na start od Google oraz nasz okres próbny, analizę danych można rozpocząć za darmo.
Instrukcja założenia projektu na platformie WitCloud
Uruchomienie modułu Google Analytics 4 i innych integracji
Platforma WitCloud potrafi automatycznie pobierać i procesować dane w BigQuery nie tylko dla systemu Google Analytics 4, ale również dla popularnych systemów reklamowych, platform e-commerce, danych search console oraz arkuszy Google.
W pierwszej kolejności rekomendujemy uruchomienie modułów:
- Google Ads - w celu późniejszego połączenia danych o kampaniach Google Ads z modułem GA4
- Google Analytics 4 BigQuery - w celu uzyskania tabel omawianych w artykule
W następnym etapie sugerujemy skonfigurować pozostałe źródła marketingowe:
Jeżeli zdecydujesz się spróbować i pojawią się jakiekolwiek trudności podczas aktywacji integracji nie wahaj się zadać nam pytania poprzez chat znajdujący się w prawym dolnym rogu na stronie.