Jak bez problemu uaktualnić raporty do Google Analytics 4

Użytkownicy Google Analytics Universal (GAU) będą musieli przejść na Google Analytics 4 (GA4) latem 2023 r. Główny problem polega na tym, że model danych i logika obliczania metryk są radykalnie różne w GA4 w porównaniu z GAU. Po przejściu na GA4 część danych historycznych będzie przechowywana w strukturze GAU, natomiast nowe dane będą przechowywane w strukturze GA4. Z tego powodu firmy muszą włożyć poważny wysiłek w ocenę wskaźników rok do roku (r/r) po zmianie (co najmniej 100+ godzin pracy dla analityków danych średniego szczebla).

Dla analityków oznacza to, że będą spędzać dzień po dniu na pisaniu i porządkowaniu stron zapytań SQL, aby uzyskać zgodność między danymi Google Analytics Universal i Google Analytics 4. Jest jednak sposób, aby to obejść! Analitycy mogą tworzyć raporty ad hoc w kilka minut bez ciągłego przepisywania zapytań SQL, aw tym artykule podpowiemy, jak to zrobić.

Universal Analytics zostanie wycofane 1 lipca 2023 r. i zastąpione przez Google Analytics 4. Dla klientów Google Analytics 360 (płatna wersja GA) okres przejściowy został przedłużony do 1 lipca 2024 r. Ale to nieważne której wersji GA używasz, to tylko kwestia czasu, zanim Twoje raporty zostaną zaktualizowane do nowego schematu danych.

W świetle tej zmiany jednym z najtrudniejszych zadań dla analityków jest dostarczenie danych z Google Analytics Universal i Google Analytics 4 w ujednoliconym formacie.

Okoliczności, które komplikują to zadanie:

• Logika obliczania metryk różni się znacząco między GAU a GA4. Warto zauważyć, że te wersje produktów inaczej obliczają nawet tradycyjne wskaźniki. Nie możesz przeciągnąć wszystkich danych z GAU i GA4 na jeden wykres i oczekiwać, że wszystko pójdzie gładko.
• Schematy danych Google BigQuery również znacznie się różnią. Universal Analytics stosuje schematy danych oparte na sesjach, podczas gdy Google Analytics 4 ma schematy danych oparte na zdarzeniach.
• Pulpity nawigacyjne obejmują wskaźniki rok do roku i trendy sezonowości. Pytanie brzmi więc, jak nadal korzystać z pulpitów nawigacyjnych ze wszystkimi tymi wskaźnikami.

Spójrzmy na konkretny przykład. Powiedzmy, że mamy ten pulpit nawigacyjny:

Najważniejszą częścią tego pulpitu nawigacyjnego są metryki sezonowości, które przedstawiają porównanie określonych metryk dla bieżącego i przeszłego okresu. Dane historyczne i operacyjne muszą być w tym samym formacie, aby obsługiwały metryki rok do roku na pulpitach marketingowych.

W tym przypadku wyzwaniem dla analityka jest aktualizacja N+ starszych zapytań SQL w celu dostarczania wiarygodnych raportów dla zespołu marketingowego. Trudno jest przetestować i debugować wszystko, na co mogą mieć wpływ nawet drobne poprawki zapytań SQL.

Należy również wziąć pod uwagę ryzyko związane z przejściem. Po przeniesieniu raportu do nowego źródła (z GAU do GA4) analitycy mogą nie uwzględnić fundamentalnych różnic w schemacie danych i logice obliczania metryk. Na przykład sesje są tworzone inaczej: w GA4 uwzględniane jest tylko pierwsze źródło użytkownika, a wszystkie inne źródła prowadzące do sesji są pomijane. Dlatego niektóre źródła ruchu nie będą widoczne w raporcie.

Na początku może to pozostać niezauważone. Ale za dwa do trzech kwartałów nieprawidłowy pulpit nawigacyjny doprowadzi do nieefektywnych wydatków na reklamę, z 30% lub wyższym wyciekiem budżetu.

Przygotowywanie i tworzenie dashboardów przypomina nam Jengę. Za każdym razem, gdy muszą wymienić blok w raporcie, analitycy trzymają kciuki i mają nadzieję, że cała struktura się nie zawali.

W OWOX już z powodzeniem rozwiązujemy podobne problemy podczas przenoszenia raportów naszych klientów ze schematu danych Universal Analytics (lub GA 360) do schematu danych Google Analytics 4. Dlatego chcemy podzielić się naszym rozwiązaniem i niektórymi zapytaniami SQL z czytelnikami naszego bloga. Mamy nadzieję, że te informacje pomogą Ci przenieść raporty bez problemów.

Nasze podejście do przygotowywania raportów (niezależnie od sfery biznesowej, dla której są tworzone) opiera się na surowych, a nie modelowanych danych.

Model danych opisuje jednostki danych, ich atrybuty i relacje między jednostkami. Na przykład działania użytkowników na stronie są łączone dla danej sesji, a jeden użytkownik może dokonać kilku konwersji online w jednej sesji.

Istnieją cztery obiekty — Akcje, Użytkownicy, Sesja i Konwersja online — oraz trzy połączenia: jeden do wielu między sesjami i akcjami, jeden do wielu między użytkownikiem a konwersjami online oraz jeden do wielu między sesjami i konwersje internetowe.

Model danych odzwierciedla nasze postrzeganie świata rzeczywistego i odpowiada na pytania typu: Czego dotyczą nasze dane?Jak to jest powiązane?Jakie warunki i ograniczenia stosujemy podczas pracy z danymi?Model danych jest niezbędny, aby ludzie mogli się dobrze zrozumieć.

Modelowanie danych to proces przekształcania danych do formatu spełniającego wymagania modelu danych.

• Zwiększ wartość i efektywność pracy analitycznej poprzez:
• Przyspieszenie zmian w strukturach raportów i logice obliczania metryk
• Zmniejszenie kosztów obsługi raportów i pulpitów nawigacyjnych
• Uproszczenie dyskusji i zatwierdzeń raportów
• Popraw jakość danych w raportach poprzez:
• Unikanie powielania podczas wdrażania logiki obliczania parametrów i metryk
• Posiadanie jednej warstwy danych, która jest źródłem dokładnych danych

Model danych zastępuje wiele narzędzi i opisuje logikę raportu, ponieważ opisuje obiekty i logikę ich obliczeń (co dotyczy wszystkich raportów).

OWOX BI przekształca surowe dane w format gotowy do analizy, oszczędzając godziny przygotowywania danych. Bezproblemowo integruje dane Universal Analytics i Google Analytics 4 z Twoimi raportami.

Oto przykład modelu danych zbudowanego na podstawie danych Google Analytics:

Jak widać, istnieje kilka obiektów, w tym sesje, transakcje, strony i urządzenia.

Najciekawsze i najważniejsze jest to, że struktura tych obiektów nie jest ze sobą powiązana i nie ma nic wspólnego ze źródłami danych. Nie ma znaczenia, jakie źródła są używane do wypełniania tych obiektów danymi na żywo (Matomo, Adobe, Google Analytics itp.). Niezależnie od źródła danych model zwraca te same obiekty, które model danych reprezentuje Twoją firmę. Ilustruje rzeczywiste obiekty i metryki, z którymi pracujesz.

Zobaczmy, jak to wygląda w realnym świecie.

Zamiast pisać zapytania SQL na podstawie nieprzetworzonych danych, takich jak sesje wyeksportowane z Universal Analytics lub zdarzenia wyeksportowane z Google Analytics 4, możesz tworzyć modelowane dane. To uniwersalne i łatwe do zrozumienia tabele na górze, które reprezentują obiekty i podmioty z rzeczywistego świata, takie jak sesje, użytkownicy i odsłony stron.

Rozważmy konkretne przykłady i schematy danych.

Oto przykład surowych danych. To są zrzuty ekranu przedstawiające schemat danych z Google BigQuery dla Google Analytics Universal (po lewej) i Google Analytics 4 (po prawej).

Jak pisaliśmy powyżej, schematy danych różnią się. Musimy znaleźć sposób na powiązanie tych danych z pulpitem Google Data Studio.

Bazując na naszym doświadczeniu, budowanie modelowanych tabel jest najlepszym sposobem na uproszczenie przygotowania danych. Oto jak mogą wyglądać:

To są listy obiektów z powyższego modelu danych. Jak widać, lista obiektów jest taka sama dla Google Analytics 360 i Google Analytics 4.

Oznacza to, że możesz połączyć zapytanie pulpitu z tymi danymi przy użyciu tych samych zapytań. Struktura tego zapytania jest taka sama.

Przyjrzyjmy się ważnym powodom, dla których warto rozważyć tworzenie raportów na podstawie modelowanych danych zamiast surowych danych.

1. Dane są jak owoce: należy je oczyścić przed zmiksowaniem.Analitycy zbierają dane z różnych usług i systemów. Oczywiście struktura i format tych danych różnią się w zależności od źródła. Aby zbudować raporty, dane z różnych źródeł muszą zostać poprawnie scalone. Same dane przesyłane przez łączniki lub różne usługi ETL są niedokładne (zawierają błędy, duplikaty i rozbieżności) oraz brakuje im ujednoliconej logiki i struktury. Niedokładne i pofragmentowane dane muszą zostać oczyszczone i znormalizowane do formatu gotowego do analizy.

Dzięki OWOX BI nie musisz ręcznie czyścić, porządkować i przetwarzać danych. Usługa automatycznie znormalizuje surowe dane do formatu gotowego do analizy.

2. Nie musisz kopiować i przepisywać logiki biznesowej dla każdego raportu;na przykład nie musisz:

• Deduplikuj transakcje
• Filtruj boty i ruch wewnętrzny
• Zdefiniuj reguły grupowania kanałów
• Zdefiniuj kryteria dla nowych i powracających użytkowników
• Napraw śledzenie parametrów UTM

Bez wątpienia każdy analityk danych słyszał takie prośby od marketerów : Chcielibyśmy dostosować lub ulepszyć nasze zasady grupowania kanałów na podstawie danych historycznych lub Chcielibyśmy określić kryteria dla nowych i powracających użytkowników w inny sposób niż to działa w Google Analytics, ale na swój własny sposób lub Chcielibyśmy rozważyć jako powracających tylko tych użytkowników, którzy dokonali zakupu w ciągu ostatnich sześciu miesięcy.

Jeśli budujesz raporty na podstawie surowych danych, wszystkie transformacje danych i czynności przygotowawcze muszą być wykonywane na poziomie raportu. Oznacza to, że musisz poświęcić dużo czasu na kopiowanie logiki biznesowej do każdego raportu.

Jeśli tworzysz raporty na modelowanych danych, nie musisz kopiować logiki biznesowej. Tworzy się go raz na etapie modelowania.

3. Tworzenie raportów na podstawie modelowanych danych przyspiesza analizę ad hoc.Możesz zaoszczędzić czas na pisaniu nowych transformacji SQL i aranżacji, aby umożliwić coroczną analizę.

4. Dzięki modelowaniu danych możesz stworzyć jedno źródło prawdy dla wszystkich raportów.Gdy zmieniasz źródło danych w raporcie, nie musisz już rozstrzygać każdego problematycznego zapytania. Możesz polegać na tym źródle w przypadku sesji, transakcji i danych o zdarzeniach.

5. Uprość warstwę raportowania.Tworzenie raportów na podstawie modelowanych danych jest łatwiejsze niż radzenie sobie z zagnieżdżonymi polami i polami rekordów, wraz z pisaniem niektórych skomplikowanych funkcji okien, a nawet funkcji wyodrębniania JSON.

1. Modelowane dane to jeszcze jedna warstwa środkowa.Dostosowanie wymaga czasu, a ponadto należy monitorować i debugować modelowane dane.

2. Złożone JOIN dla normalizacji.

3. Dodatkowe przetwarzanie danych.Aby przekonwertować dane w formacie modelu, musisz wykonać zapytanie o dane. Radzimy używać tabeli partycji w dniu. Dzięki tabeli partycji zbudowanej wokół wymiarów dat możesz aktualizować tylko niezbędne dane. Nie musisz przepisywać wszystkich ogromnych tabel i płacić za wszystkie przetworzone dane i gigabajty lub terabajty danych w Google BigQuery. Możesz po prostu uaktualnić i zaktualizować potrzebną partycję. Takie podejście jest bardziej ekonomiczne niż obsługa wszystkich tabel danych.

Aby pomóc Ci poradzić sobie z tymi wadami, przygotowaliśmy szablony SQL do modelowania danych Google Analytics 360 i Google Analytics 4. Możesz je sprawdzić, pobierając dodatkowe materiały zawarte w tym artykule.

Jak łatwo zaktualizować raporty do nowego schematu danych Google Analytics 4? Użyj modelowanych danych. Zamiast tworzyć raporty na podstawie nieprzetworzonych danych, możesz tworzyć uniwersalne i łatwe do zrozumienia płaskie tabele na podstawie schematów GA Universal i GA 4.

W ten sposób wyeliminujesz konieczność kopiowania danych i wstawiania logiki normalizacji do dziesiątek zapytań SQL. Zrobisz to raz na etapie modelowania danych. Chociaż nie jest to srebrna kula dla każdego projektu, jest to optymalna metoda dla tych, którzy wymagają regularnych raportów specjalnych.

Zapisz się na demo OWOX BI, jeśli chcesz konfigurować i koordynować modelowane tabele. Chętnie podzielimy się szczegółami, jak przygotować podobne tabele w Twoich projektach na podstawie Twoich danych.