So aktualisieren Sie Ihre Berichte für Google Analytics 4 ohne Kopfschmerzen
Veröffentlicht: 2023-03-16Nutzer von Google Analytics Universal (GAU) müssen im Sommer 2023 auf Google Analytics 4 (GA4) umsteigen. Das Hauptproblem dabei ist, dass das Datenmodell und die Berechnungslogik der Metriken in GA4 radikal anders sind als in GAU. Nach der Umstellung auf GA4 wird ein Teil der historischen Daten in der GAU-Struktur gehalten, während neue Daten in der GA4-Struktur gespeichert werden. Aus diesem Grund müssen Unternehmen ernsthafte Anstrengungen unternehmen, um die Metriken im Jahresvergleich (YoY) nach dem Wechsel auszuwerten (mindestens 100+ Arbeitsstunden für Datenanalysten auf mittlerer Ebene).
Für Analysten bedeutet dies, dass sie Tag für Tag damit verbringen, Seiten mit SQL-Abfragen zu schreiben und anzuordnen, um eine Angleichung zwischen den Metriken von Google Analytics Universal und Google Analytics 4 zu erreichen. Es gibt jedoch eine Möglichkeit, dies zu umgehen! Analysten können innerhalb von Minuten Ad-hoc-Berichte erstellen, ohne ständig SQL-Abfragen neu schreiben zu müssen, und in diesem Artikel erklären wir Ihnen, wie das geht.
Melden Sie sich für eine Demo von OWOX BI an, wenn Sie Hilfe beim Aktualisieren von Berichten auf das Google Analytics 4-Datenschema benötigen. Wir sagen Ihnen, wie Sie dies am besten auf eine für Ihr Unternehmen relevante Weise tun können.
Inhaltsverzeichnis
- Probleme beim Aktualisieren von Berichten auf Google Analytics 4
- So beschleunigen und vereinfachen Sie die Aktualisierung von Berichten für Google Analytics 4 mit OWOX BI
- Was ist ein Datenmodell
- Was ist Datenmodellierung
- Warum Sie Datenmodellierung brauchen
- Wie OWOX BI mit der Datenmodellierung arbeitet
- Vor- und Nachteile der Datenmodellierung
- Vorteile
- Nachteile
- Die zentralen Thesen
Probleme beim Aktualisieren von Berichten auf Google Analytics 4
Universal Analytics wird am 1. Juli 2023 eingestellt und durch Google Analytics 4 ersetzt. Für Kunden von Google Analytics 360 (der kostenpflichtigen Version von GA) wurde die Übergangsfrist bis zum 1. Juli 2024 verlängert. Aber egal Welche Version von GA Sie verwenden, es ist nur eine Frage der Zeit, bis Ihre Berichte auf das neue Datenschema aktualisiert werden.
Angesichts dieser Umstellung besteht eine der größten Herausforderungen für Analysten darin, Daten aus Google Analytics Universal und Google Analytics 4 in einem einheitlichen Format bereitzustellen.
Umstände, die diese Aufgabe erschweren:
- Die Metrikberechnungslogik unterscheidet sich erheblich zwischen GAU und GA4. Bemerkenswerterweise berechnen diese Produktversionen sogar herkömmliche Metriken anders. Sie können nicht alle Metriken von GAU und GA4 in ein Diagramm ziehen und erwarten, dass alles reibungslos verläuft.
- Auch die Datenschemata von Google BigQuery unterscheiden sich erheblich. Universal Analytics wendet sitzungsbasierte Datenschemata an, während Google Analytics 4 über ereignisbasierte Datenschemata verfügt.
- Dashboards enthalten YoY-Metriken und saisonale Trends. Die Frage ist also, wie man weiterhin Dashboards mit all diesen Metriken verwenden kann.
Schauen wir uns ein konkretes Beispiel an. Angenommen, wir haben dieses Dashboard:

Der wichtigste Teil dieses Dashboards sind die saisonalen Metriken, die einen Vergleich spezifischer Metriken für den aktuellen und vergangenen Zeitraum darstellen. Historische und operative Daten müssen im gleichen Format vorliegen, um YoY-Metriken auf Marketing-Dashboards zu unterstützen.
In diesem Fall besteht die Herausforderung für den Analysten darin, N+ Legacy-SQL-Abfragen zu aktualisieren, um zuverlässige Berichte für das Marketingteam bereitzustellen. Es ist schwierig, alles zu testen und zu debuggen, was selbst durch geringfügige Korrekturen an SQL-Abfragen beeinträchtigt werden kann.

Auch Übergangsrisiken sollten berücksichtigt werden. Nach der Übertragung eines Berichts an die neue Quelle (von GAU zu GA4) können Analysten grundlegende Unterschiede im Datenschema und in der Metrikberechnungslogik nicht berücksichtigen. Beispielsweise werden Sitzungen unterschiedlich gebildet: In GA4 wird nur die erste Benutzerquelle berücksichtigt, alle anderen Quellen, die zu einer Sitzung führen, werden vernachlässigt. Daher sind einige Zugriffsquellen im Bericht nicht sichtbar.
Dies kann zunächst unbemerkt bleiben. Aber in zwei bis drei Quartalen führt ein falsches Dashboard zu ineffizienten Werbeausgaben mit Budgetverlusten von 30 % oder mehr.
Das Vorbereiten und Erstellen von Dashboards erinnert uns an Jenga. Jedes Mal, wenn sie einen Block in einem Bericht ersetzen müssen, drücken Analysten die Daumen und hoffen, dass die gesamte Struktur nicht zusammenbricht.

Bei OWOX lösen wir bereits erfolgreich ähnliche Probleme bei der Übertragung der Berichte unserer Kunden aus dem Datenschema von Universal Analytics (oder GA 360) in das Datenschema von Google Analytics 4. Deshalb möchten wir unsere Lösung und einige SQL-Abfragen mit unseren Blog-Lesern teilen. Hoffentlich helfen Ihnen diese Informationen dabei, Ihre Berichterstattung ohne Kopfschmerzen zu übertragen.
So beschleunigen und vereinfachen Sie die Aktualisierung von Berichten für Google Analytics 4 mit OWOX BI
Unser Ansatz zur Erstellung von Berichten (unabhängig vom Geschäftsbereich, für den sie erstellt werden) basiert eher auf Rohdaten als auf Modelldaten.
Was ist ein Datenmodell
Ein Datenmodell beschreibt Datenentitäten, ihre Attribute und die Beziehungen zwischen Entitäten. Beispielsweise werden die Aktionen der Benutzer auf der Website für eine bestimmte Sitzung zusammengeführt, und ein Benutzer kann in einer Sitzung mehrere Online-Conversions vornehmen.
Es gibt vier Objekte – Aktionen, Benutzer, Sitzung und Online-Konvertierung – und drei Verbindungen: Eins-zu-Viele zwischen Sitzungen und Aktionen, Eins-zu-Viele zwischen dem Benutzer und Online-Konvertierungen und Eins-zu-Viele zwischen Sitzungen und Online-Konvertierungen.
Das Datenmodell spiegelt unsere Wahrnehmung der realen Welt wider und beantwortet Fragen wieWorum geht es in unseren Daten?Wie hängt es zusammen?Welche Bedingungen und Einschränkungen gelten bei der Arbeit mit Daten?Ein Datenmodell ist notwendig, damit Menschen einander klar verstehen.
Was ist Datenmodellierung
Datenmodellierung ist der Prozess der Transformation von Daten in ein Format, das die Anforderungen Ihres Datenmodells erfüllt.
Warum Sie Datenmodellierung brauchen
- Steigern Sie den Wert und die Effizienz der Analysearbeit durch:
- Beschleunigen von Änderungen an Berichtsstrukturen und Metrikberechnungslogik
- Reduzierung der Kosten für die Unterstützung von Berichten und Dashboards
- Vereinfachung von Diskussionen und Genehmigungen von Berichten
- Erhöhen Sie die Datenqualität in Berichten durch:
- Vermeidung von Doppelarbeit bei der Implementierung von Parameter- und Metrikberechnungslogik
- Eine Datenschicht zu haben, die die Quelle genauer Daten ist
Das Datenmodell ersetzt zahlreiche Tools und beschreibt die Logik eines Reports, da es Objekte und deren Berechnungslogik (die für alle Reports gilt) beschreibt.
Wie OWOX BI mit der Datenmodellierung arbeitet
OWOX BI wandelt Rohdaten in ein analysebereites Format um und erspart Ihnen Stunden der Datenvorbereitung. Es integriert nahtlos sowohl Universal Analytics- als auch Google Analytics 4-Daten in Ihre Berichte.
Hier ist ein Beispiel für ein Datenmodell, das auf der Grundlage von Google Analytics-Daten erstellt wurde:

Wie Sie sehen können, gibt es mehrere Objekte, darunter Sitzungen, Transaktionen, Seiten und Geräte.

Das Interessanteste und Wichtigste dabei ist, dass die Struktur dieser Objekte nicht miteinander verbunden ist und nichts mit den Datenquellen zu tun hat. Dabei spielt es keine Rolle, aus welchen Quellen diese Objekte mit Live-Daten gefüllt werden (Matomo, Adobe, Google Analytics etc.). Unabhängig von der Datenquelle gibt das Modell dieselben Objekte zurück, die das Datenmodell für Ihr Unternehmen darstellt. Es veranschaulicht die realen Objekte und Metriken, mit denen Sie arbeiten.
Mal sehen, wie es in der realen Welt aussieht.

Anstatt SQL-Abfragen auf Rohdaten zu schreiben, wie z. B. aus Universal Analytics exportierte Sitzungen oder aus Google Analytics 4 exportierte Ereignisse, können Sie modellierte Daten erstellen. Es sind universelle und leicht verständliche Tabellen, die Objekte und Entitäten aus der realen Welt darstellen, wie z. B. Sitzungen, Benutzer und Seitenaufrufe.
Betrachten wir konkrete Beispiele und Datenschemata.
Hier ist ein Beispiel für Rohdaten. Dies sind Screenshots eines Datenschemas von Google BigQuery für Google Analytics Universal (links) und Google Analytics 4 (rechts).

Wie wir oben geschrieben haben, unterscheiden sich die Datenschemata. Wir müssen einen Weg finden, diese Daten mit dem Google Data Studio-Dashboard zu verknüpfen.
Unserer Erfahrung nach ist das Erstellen von modellierten Tabellen der beste Weg, um die Datenvorbereitung zu vereinfachen. So können sie aussehen:

Dies sind die Objektlisten aus dem obigen Datenmodell. Sie sehen, dass die Objektliste für Google Analytics 360 und Google Analytics 4 identisch ist.
Das bedeutet, dass Sie Ihre Dashboard-Abfrage mit diesen Daten über dieselben Abfragen verbinden können. Die Struktur dieser Abfrage ist dieselbe.

Vor- und Nachteile der Datenmodellierung
Sehen wir uns die wichtigen Gründe an, warum Sie erwägen sollten, Ihre Berichte auf modellierten Daten statt auf Rohdaten zu erstellen.

Vorteile
1. Daten sind wie Obst: Sie müssen sie reinigen, bevor Sie sie mischen.Analysten sammeln Daten von unterschiedlichen Diensten und Systemen. Natürlich variieren die Struktur und das Format dieser Daten je nach Quelle. Um Berichte zu erstellen, müssen Daten aus verschiedenen Quellen korrekt zusammengeführt werden. Daten, die über Konnektoren oder verschiedene ETL-Dienste hochgeladen werden, sind an sich ungenau (enthalten Fehler, Duplikate und Diskrepanzen) und haben keine einheitliche Logik und Struktur. Ungenaue und fragmentierte Daten müssen bereinigt und in ein für Analysen geeignetes Format normalisiert werden.
Mit OWOX BI müssen Sie Daten nicht manuell bereinigen, strukturieren und verarbeiten. Der Dienst normalisiert Rohdaten automatisch in ein für Analysen geeignetes Format.
2. Sie müssen die Geschäftslogik nicht für jeden Bericht kopieren und neu schreiben;Sie müssen beispielsweise nicht:
- Transaktionen deduplizieren
- Bot- und internen Datenverkehr filtern
- Kanalgruppierungsregeln definieren
- Definieren Sie Kriterien für neue und wiederkehrende Benutzer
- UTM-Parameter-Tracking behoben
Zweifellos hat jeder Datenanalyst solche Anfragen von Vermarktern gehört: Wir möchten unsere Channel-Gruppierungsregeln basierend auf historischen Daten anpassen oder verbessern, oder Wir möchten Kriterien für neue und wiederkehrende Benutzer identifizieren, die nicht so funktionieren, wie es funktioniert in Google Analytics, aber auf unsere eigene Weise oder Wir möchten nur diejenigen Benutzer als zurückkehrend betrachten, die innerhalb der letzten sechs Monate einen Kauf getätigt haben.
Wenn Sie Berichte basierend auf Rohdaten erstellen, müssen alle Datentransformationen und Vorbereitungsaktivitäten auf Berichtsebene ausgeführt werden. Das bedeutet, dass Sie viel Zeit damit verbringen müssen, die Geschäftslogik in jeden Bericht zu kopieren.
Wenn Sie Berichte auf modellierten Daten erstellen, müssen Sie die Geschäftslogik nicht kopieren. Sie erstellen es einmal in der Modellierungsphase.
3. Das Erstellen von Berichten basierend auf modellierten Daten beschleunigt die Ad-hoc-Analyse.Sie können Zeit sparen, indem Sie neue SQL- und Orchestrierungstransformationen schreiben, um eine jährliche Analyse zu ermöglichen.
4. Dank Datenmodellierung können Sie eine Single Source of Truth für alle Berichte erstellen.Wenn Sie die Datenquelle in einem Bericht ändern, müssen Sie nicht mehr jede problematische Abfrage klären. Sie können sich auf diese Quelle für Sitzungen, Transaktionen und Ereignisdaten verlassen.
5. Vereinfachen Sie die Berichtsebene.Das Erstellen von Berichten auf modellierten Daten ist einfacher als der Umgang mit verschachtelten Feldern und Datensatzfeldern sowie das Schreiben einiger komplizierter Fensterfunktionen oder sogar JSON-Extraktionsfunktionen.
Nachteile
1. Modellierte Daten sind eine weitere mittlere Schicht.Die Anpassung braucht Zeit, und Sie müssen auch modellierte Daten überwachen und debuggen.
2. Komplexe JOINs für Normalisierungen.
3. Zusätzliche Datenverarbeitung.Um Daten in ein Modellformat zu konvertieren, müssen Sie Daten abfragen. Wir empfehlen Ihnen, eine Partitionstabelle für ein Datum zu verwenden. Mit einer Partitionstabelle, die um Datumsdimensionen herum aufgebaut ist, können Sie nur die notwendigen Daten aktualisieren. Sie müssen nicht alle riesigen Tabellen neu schreiben und für alle verarbeiteten Daten und Gigabyte oder Terabyte an Daten in Google BigQuery bezahlen. Sie können einfach die benötigte Partition aktualisieren und aktualisieren. Dieser Ansatz ist wirtschaftlicher als die Handhabung aller Datentabellen.
Um Ihnen bei der Bewältigung dieser Nachteile zu helfen, haben wir SQL-Vorlagen für die Modellierung von Google Analytics 360- und Google Analytics 4-Daten vorbereitet. Sie können sie überprüfen, indem Sie die zusätzlichen Materialien herunterladen, die in diesem Artikel bereitgestellt werden.


SQL-Vorlagen für Google Analytics 360- und Google Analytics 4-Schemas
herunterladenDie zentralen Thesen
Wie einfach ist es, Ihre Berichte auf das neue Google Analytics 4-Datenschema zu aktualisieren? Verwenden Sie modellierte Daten. Anstatt Berichte auf Rohdaten zu erstellen, können Sie universelle und leicht verständliche flache Tabellen auf der Grundlage der GA Universal- und GA 4-Schemata erstellen.
Dadurch entfällt die Notwendigkeit, Daten zu kopieren und Normalisierungslogik in Dutzende von SQL-Abfragen einzufügen. Sie tun dies einmal in der Phase der Datenmodellierung. Obwohl es nicht für jedes Projekt eine Wunderwaffe ist, ist es die optimale Methode für diejenigen, die regelmäßig Sonderberichte benötigen.
Melden Sie sich für eine Demo von OWOX BI an, wenn Sie modellierte Tabellen einrichten und orchestrieren möchten. Gerne teilen wir Ihnen Details zur Erstellung ähnlicher Tabellen in Ihren Projekten auf der Grundlage Ihrer Daten mit.