Google Analytics 4 Recipes: BigQuery Export

Aus App+Web wird Google Analytics 4. App+Web Properties wurden Mitte 2019 eingeführt und seitdem immer weiter erweitert. Auch mit dem Rebranding zu Google Analytics 4 bleibt der Beta-Status des Produktes bestehen. Dennoch lohnt sich ein Blick auf Google Analytics 4 und einer Artikelserie dazu, den “Google Analytics 4 Recipes”.

Ein paar einführende Gedanken 

Als Google das Rebranding von App+Web Properties zu Google Analytics 4 angekündigte, folgten die üblichen positiven Resonanzen, als auch „Kritik“.

In meinen Augen ist Google Analytics 4 ein sehr interessantes Produkt, allerdings ist es weiterhin im Beta-Status. Das ist sehr deutlich zu spüren. Nicht nur dass einige Funktionen unausgereift wirken und der Funktionsumfang noch überschaubar ist, sondern auch daran, dass es sich ständig verändert. Die Ankündigung des Rebrandings und das Festlegen von Google Analytics 4 als Default Properties zu diesem Zeitpunkt überraschte mich doch etwas. Ich denke dann immer gern an das Zitat von Jerry Della Femina:

Nothing kills a bad product faster than good advertising. Everyone tries the thing and never buys it again.”

Google Analytics 4 ist zwar kein schlechtes Produkt, aber in meinen Augen noch in einem zu frühen Entwicklungsstadium, um Google Analytics 3 (Universal Analytics) im produktiven Einsatz abzulösen. Doch der Zeitpunkt wird wohl in nicht allzu fernen Zukunft kommen (2021?). Im Gegensatz zum Wechsel von Classic Analytics zu Universal Analytics bietet der Wechsel von Universal Analytics zu Google Analytics 4 nicht nur neue Funktionen, sondern eine andere Erfassungs- und damit Auswertungslogik. Dies resultiert vor allem aus der Angleichung der App Logik für Web. Daher bietet es sich an, frühzeitig den Umstieg zu planen, beispielsweise mit einem Dual Tagging: Universal Analytics und Google Analytics 4. Der Aufwand hierfür ist nicht sehr hoch, da teilweise eine Abwärtskompatibilität besteht, beispielsweise bei E-Commerce Objekten. (siehe App+Web Ecommerce Daten mit Enhanced E-Commerce (EEC) Implementierung)

Mit Google Analytics 4 werden bisher nur Google Analytics 360 Kunden vorbehaltene Features in der Standard-Version angeboten, beispielsweise ein BigQuery Export. Gerade die Arbeit mit Rohdaten kann ein Quantensprung in der Webanalyse sein und vereinfacht die Operationalisierung der Ergebnisse.

Rohdaten statt Interface

Das Interface von Google Analytics (und auch das Interface aller anderen Webanalyse-Tools) bietet nur den vordefinierten und damit eingeschränkten Blick auf die Daten. Bezogen auf Universal Analytics einige Beispiele: Mehr zwei Dimensionen in Standard-Reports oder mehr als fünf Dimensionen in Custom Reports sind nicht möglich, Abfolgen lassen sich in Segmenten nur unzureichend definieren, nicht jede E-Commerce Ratio ist sinnvoll (Stichwort Impressions) und das Sampling in Reports. Auch in Google Analytics 4 werden einige dieser Einschränkungen wieder vorhanden sein. Sampling wird es zwar nach aktuellem Stand nicht in Standard-Reports geben, aber wird wohl im Analysis Hub verwendet. Ebenso bleiben die Einschränkungen der Dimensionen in Reports bestehen. 

Der BigQuery Export ermöglicht es, diesen vordefinierten Blick auf die Daten aufzubrechen. Er enthält auf Hitbasis alle Informationen die gesammelt werden. Damit lassen sich komplizierte Fragestellungen besser und skalierbarer beantworten als im Interface, beispielsweise die Frage der Reihenfolge von Kontaktpunkten in der User-Journey. 

Den Big Query Export einrichten

Wie bereits erwähnt, ist der BigQuery Export in Universal Analytics nur in der 360-Version verfügbar, in Google Analytics 4 allerdings auch in der Standard-Version.

Hierfür wird ein Google Cloud Platform (GCP) Projekt benötigt mit aktivierter Big Query API.  

Falls noch kein GCP Account vorhanden ist, kann dieser unter cloud.google.com angelegt werden. Nach der Einrichtung (und Hinterlegung der Zahlungsmethode) kann unter dem Menüpunkt “BigQuery” die API aktiviert werden. Danach ist BigQuery im Account für den Export verfügbar.

Der BigQuery Export kann einfach unter “Admin” > “Product Linking” > “BigQuery Linking” eingerichtet werden.

Im Google Analytics 4 BigQuery Linking Interface kann nun das Projekt, die zu exportierenden Datastreams und den Exporttyp ausgewählt werden. War in Google Analytics pro View nur ein Exporttyp, entweder Batch (4 mal täglich) oder Streaming (5 bis 15 Minuten Verzögerung), möglich, ist in Google Analytics 4 gleichzeitig ein Daily Export als auch ein Streaming Export, also quasi Realtime, möglich.

Nachdem der BigQuery Export eingerichtet ist, wird innerhalb der nächsten Stunden ein Dataset unter dem Namen “analytics_<Property ID>” mit ein für Table für den Daily Export, sowie einen Table für den Streamingexport des aktuellen Tages in BigQuery erstellt, der die Daten enthält. 

Der Table “events_” für den Daily Export ist auf Tagesbasis partitioniert, so dass bei einem Query auf diesem Table die Menge der zu verarbeitenden Daten durch Datumsangaben eingeschränkt werden kann. Das heißt, obwohl nur ein Table angezeigt wird, existieren im Hintergrund pro Tag einzelne Tables. Diese können durch den Query in die Datenverarbeitung eingeschlossen oder davon ausgeschlossen werden. Wir wenden dies nun an.

Das BigQuery Schema von Google Analytics 4 und einfache SQLs anwenden

Um mit dem Export-Daten zu arbeiten, benötigen wir eine Beschreibung des Schema der Daten. Da Google Analytics 4 eine Verbindung von App und Web Tracking ist, ist der Export von Google Analytics 4 gleich dem Firebase Export. Die Beschreibung der Spalten ist unter
https://support.google.com/firebase/answer/7029846?hl=de verfügbar.

In der Datenbank sieht das dann wie folgt aus:

Im Gegensatz zum Universal Analytics 360 BigQuery Export ist in diesem Export nicht pro Row eine Session abgebildet, sondern pro Events. Also jedes Event befindet sich in einer eigenen Row.

Mit SQL lassen sich nun Analysen aus diesen Daten extrahieren. In dieser Artikelserie wird die Analyse mit SQL einen großen Anteil haben. Nehmen wir nun ein einfaches Beispiel, um das Schema besser zu verstehen. Wie viele Sessions gab es am gestrigen Tag?

SELECT COUNT(event_name) as Sessions FROM `<Project.Dataset>.events_*` WHERE event_name="session_start" and _TABLE_SUFFIX = FORMAT_DATE("%Y%m%d", DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)) 

In dem SQL werden einfach die session_start events in der Spalte “event_name” für den gestrigen Tag (aktueller Tag minus 1) gezählt. Wie bereits erwähnt, ist der Table auf Tagesbasis partioniert. Daher wird bei der Abfrage der Table „events_“ mit der Wildcard * versehen und über _TABLE_SUFFIX die zu durchsuchenden Tage und damit im Hintergrund die Tabellen auf Tagesbasis definiert.

Schauen wir uns die Anzahl Session heruntergebrochen auf einzelne User an:

SELECT user_pseudo_id, COUNT(event_name) as Sessions FROM `<Projekt.Dataset>.events_*` WHERE event_name="session_start" and _TABLE_SUFFIX = FORMAT_DATE("%Y%m%d", DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)) GROUP BY user_pseudo_id

Das Hinzufügen der Spalte “user_pseudo_id” zu den Ausgaben splittet die session_start events auf. Wird die Ausgabe um einen nicht aggregierte Wert geändert, muss das “GROUP BY” Statement ergänzt werden.

Die Beispiele sind recht einfach. Nehmen wir ein etwas komplizierteres Beispiel. Wieviel Pageviews gab es auf meinem Artikel „App+Web Ecommerce Daten mit Enhanced E-Commerce (EEC) Implementierung“? Hierfür muss auf page_location nach der URL „https://www.marcusstade.de/appweb-ecommerce-daten-mit-enhanced-e-commerce-eec-implementierung/“ in den event_param.key gesucht werden und der entsprechende event_param.value.string_value zurückgeliefert werden. Ein direkter Zugriff auf Spalten des Typs RECORDs wie “event_params” ist leider nicht möglich, da diese NESTED sind, das heißt, alle dem Hit angehängten Parameter befinden sich in einer Row, aber als verschachtelte Daten. Um diese für Ausgaben und Filter aufzulösen, kann “UNNEST” verwendet werden. Der Query sieht dann wie folgt aus:

SELECT COUNT(event_name) as Pageview FROM `<Projekt.Dataset>.events_*`, unnest(event_params) as e WHERE e.key="page_location" and e.value.string_value="https://www.marcusstade.de/appweb-ecommerce-daten-mit-enhanced-e-commerce-eec-implementierung/" and event_name="page_view" and _TABLE_SUFFIX = FORMAT_DATE("%Y%m%d", DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))

Das Ergebnis des Query ist:

Die nicht aggregierten Ergebnisse können eingesehen werden mit

SELECT * FROM `<Projekt.Dataset>.events_*`, unnest(event_params) as e WHERE e.key="page_location" and e.value.string_value="https://www.marcusstade.de/appweb-ecommerce-daten-mit-enhanced-e-commerce-eec-implementierung/" and event_name="page_view" and _TABLE_SUFFIX = FORMAT_DATE("%Y%m%d", DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))

Hier das Ergebnis:

In den nächsten Beiträgen der Artikelserie werden einige komplizierte Fragestellungen analysiert.