Universal Analytics vs. Google Analytics Version 4 – Unterschiede der beiden Google Analytics Plattformen

Google Analytics 4 (GA4) ist nun seit mehr als einem Jahr aus der Betaphase raus und auch bei uns auf dem Blog haben wir uns bereits in einigen Artikeln mit dem Thema GA 4 beschäftigt. Allen voran natürlich wie man es korrekt einrichtet. Danach folgten Themen zur Implementierung von Events und Conversions in Google Analytics 4. Aber die Frage, die noch nicht klar beantwortet ist: Was sind die Unterschiede von Universal Analytics (UA) und Google Analytics 4?

Der Tracking Pixel (analytics.js vs. gtag.js)

Bevor wir einen Blick in die Konten werfen, geht es erstmal um die Technik. Diese ist dafür verantwortlich, ob und wie Daten in UA oder GA4 übermittelt werden. Beim Tracking Pixel unterscheiden wir vereinfacht zwei Arten der Einbindung – über den Google Tag Manager (GTM) oder direkt im Quellcode der Webseite.

Arbeitet man, wie in den letzten Jahren üblich, mit dem GTM, fällt beim Anlegen neuer Analytics Tags auf, dass es nicht mehr nur das „Google Analytics: Universal Analytics“ Tag-Template gibt, sondern auch die Templates für „Google Analytics: GA Configuration“ und „Google Analytics: GA4 Event“. Je nachdem, ob man ein UA oder GA4 Tracking einbinden möchte, wählt man die entsprechenden Templates aus.

Beim Blick auf die Implementierung direkt im Quellcode ist schon länger klar, wohin die Entwicklung von Google geht: Von Analytics.js zum gtag.js (Global Site Tag). Dieses Global Site Tag ermöglich nicht nur die Einbindung vom Analytics-Tracking, egal ob UA oder GA4, sondern auch das Google Ads Tracking kann mit dem gtag.js in die Webseite implementiert werden. Google hat also ein Framework entwickelt mit dem „einfaches „Tracking für UA, GA4, Google Ads u.a.“ ermöglicht wird.

Gtag.js für GA4

Kontostruktur – administratives

Weg von der Implementierung, hin zum Blick in die Konten/Properties. Was direkt auffällt: Es gibt keine Datenansichten mehr in GA4. Damit fallen viele Funktionen aus UA weg, wie z.B. getrennte Datenansichten für Sprachen/Länder oder Unterbereiche der Webseite. Oder natürlich die BackUp Datenansicht, wenn doch mal ein Filter nicht das gemacht hat, wofür er gedacht war. Auf den Ausschluss von internem Traffic muss man aber zum Glück nicht verzichten. Mit dem vorgefertigten Datenfilter auf Property-Ebene „Internal Traffic“ lassen sich Ereignisse mit dem Parameter traffic_type=internal weiter ausschließen. Zusätzlich wird zu jedem eingerichteten Filter ein Modus definiert, „Testing“, „Active“ oder „Inactive“. Bei Testing wird der Filter nur zu Testzwecken angewendet und verändert die Daten nicht permanent.

Kontostruktur

Treffertypen/Datenmodell – von vielen Hits zu Ereignissen

Von Hits zu Events: So kann man die grundlegendste Änderung von UA zu GA4 beschreiben, allerdings wird das der Änderung in keinster Weise wirklich gerecht.

Zur Verdeutlichung: Sprechen wir in UA von Seiten-, Ereignis-, Ecommerce-, Sozialen Interaktions-Treffern und zusätzlich noch von User Timing, Exception Tracking und App/Screen Tracking, so reden wir bei GA4 von EINEM Treffertyp und genau genommen auch nicht von Treffer (Hit), sondern einfach nur von Ereignissen. Ein Seitentreffer in UA ist jetzt ein Ereignis des Typs Seitenaufruf. Ein Ecommerce Treffer ist jetzt z.B. ein Purchase oder Add_to_cart Ereignis.

Natürlich kommt jetzt direkt die Einordnung in Kategorie, Aktion und Label in den Sinn – analog zu UA. In GA4 allerdings können Ereignisse bis zu 25 Parameter enthalten, womit klar wird, welche Freiheit und Flexibilität nun vorhanden sind. Wenn du mehr über Ereignisse in GA wissen möchtest, lies am besten mal in unseren Blogartikel rein, der sich nur mit diesem Thema beschäftigt.

Ereignisse in GA4

Ziele bzw. Conversions

Bei der Arbeit in UA sind die sogenannten Zielvorhaben durch ihre Beschränkung auf die Typen Ziel, Dauer, Seiten/Bildschirm pro Sitzung und Ereignis eher unflexibel. Auch die Möglichkeit, Trichter zu erfassen, stand nur beim Typ Ziel zur Verfügung. Wie jetzt folgerichtig vermutet werden könnte, basieren Ziele im neuen GA4 (übrigens Conversions genannt) auf Ereignissen. Jedes Ereignis kann bequem über die Oberfläche als Conversion definiert werden und Trichter lassen sich über die Trichteranalyse zusammenstellen. Auch zu Conversions empfehlen wir dir unseren detaillierten Blogartikel.

Conversions in GA4

Quellen für Daten

In Universal Analytics gab es genau eine Quelle, nämlich die Webseite mit dem implementierten Tracking Code. Achtung: Diese ist nicht zu verwechseln mit der Dimension “Quelle” oder “Quelle/Medium”, also zum Beispiel “google/organic”. Vielmehr sprechen wir hier von dem Ort, an dem die Daten erzeugt werden, also zum Beispiel einer Webseite oder einer App.

Auch das ändert sich nun mit GA4. Als Quelle dient nicht mehr nur die Webseite, sondern auch Apps (iOS oder Android) können als Datenquelle für eine Property dienen. In diesem Zusammenhang spricht man nicht mehr von Datenquellen, sondern von Datenstreams, und diese müssen neben dem Tracking Code in der entsprechenden GA4 Property definiert werden.

Datenstreams

Sitzungen

Auch hier gibt es Änderungen von UA zu GA4, die zu einer einfacheren und eindeutigeren Regelung führen. Kampagnen starten keine neue Sitzung mehr, um Mitternacht wird die Sitzung nicht mehr automatisch beendet und eine Sitzung hat keine Limitierung für ihre Dauer. Eine Sitzung endet zwar weiterhin nach 30 Minuten Inaktivität, GA4 überprüft aber mit Hilfe des „user_engagement“ Events, ob die Webseite oder App im Vordergrund läuft oder nicht und kann somit Inaktivität eindeutiger feststellen.

Benutzerdefinierte Dimensionen und Messwerte

Diese Begrifflichkeiten haben im UA oft für Verwirrung gesorgt, einerseits beim grundlegenden Verständnis, aber auch wenn es um ihren Anwendungsbereich geht (engl. Scope). Hier sprechen wir über Hit-, Session, User und Product-Scopes.

Im Gegensatz zu UA liegt bei GA4 der Fokus auf NutzerInnen und Ereignissen. Erst mit etwas Verspätung hat Google die von UA bekannten, benutzerdefinierten Dimensionen und Metriken in GA4 eingeführt. Diese müssen jedoch erst manuell hinterlegt werden, bevor sie für die Analyse genutzt werden können.

Benutzerdefinierte Definitionen

Debugging

Ein kleiner Traum wird wahr, zumindest in Bezug auf GA4 und die Debugging-Möglichkeiten für neue Implementierungen. War man bisher auf die Vorschaufunktion des GTMs, die Browser Console und  den Google Tag Assistant beschränkt, gibt es nun einen Debugging View direkt in der GA4 Property.

Ja, zugegeben, die Live-Datenansicht gibt es im Universal Analytics auch noch. Aber wie praktikabel war diese in Konten, wo hunderte oder mehr Hits pro Stunde einlaufen, dort dann den einen Hit zu finden, den man selber verursacht hat?

Wenn jetzt mit der Tag Manager Vorschaufunktion gearbeitet wird, sind alle Events, die an GA4 gesendet werden, entsprechend markiert und lediglich diese sind im DebugView auch sichtbar. Als Alternative kann auch der Google Analytics Debugger für Chrome verwendet werden, der ohne die GTM Vorschaufunktion Events im DebugView auswertet.

DebugView in GA4

BigQuery Verknüpfung

Das große „Ding“ neben den bereits genannten Veränderungen ist die Möglichkeit, dass alle NutzerInnen kostenlos Daten nach BigQuery exportieren können. Bisher war das hinter der „Paywall“ für Analytics 360 Kunden verborgen. Mit diesem Schritt ist es nun jedem möglich, mittels SQL Zugriff auf die Rohdaten zu erhalten.

Und noch vieles mehr…

Zum Beispiel: Sampling findet nur noch in benutzerdefinierten Berichten mit über 10 Mio. Ereignissen Anwendung. Alle Standardberichte werden ohne Sampling erstellt, egal wie viele Daten analysiert werden.

Die Berichtsnavigation und -form im GA4 sind im Vergleich zu UA schlanker gestaltet, da sie sich im GA4 am Lebenszyklus des Kunden orientieren und viele Berichte aus UA nur noch in der Übersicht des jeweiligen Bereichs zu finden sind. Außerdem baut GA4 auf den Dashboard- und Explorer-Vorlagen auf. Dadurch ist die Gestaltung der Berichte deutlich ansprechender als noch im Universal Analytics.

Ein weiterer Vorteil von GA4 ist die nativ enthaltene IP-Adressanonymisierung. In UA musste bei jedem Tracking-Code oder TAG im GTM die Anonymisierung sichergestellt werden. Bei GA4 übernimmt das ohne zusätzliche Anpassungen automatisch der Tracking-Code oder Tag im GTM.

Ein eher technischer Punkt, aber nicht weniger interessant ist der Wechsel der Tracking-ID der Form UA-123456-X hin zur Mess-ID der Form G-ABCDEFGHIJ.

Zusammenfassung

Google Analytics 4 ist ein großer Schritt in Sachen Modernisierung und Verbesserung im Vergleich zum etwas angestaubten Universal Analytics. Die Veränderungen sind zahlreich und setzen an den richtigen Stellen an. Trotzdem wird es wohl noch eine Weile dauern, bis GA4 UA komplett ablöst und Google die Lichter bei Universal ausknipst. Der Umstieg auf GA bedeutet allerdings auch einiges an Arbeit. Auch wenn vieles besser und neu ist, so hat man doch mit UA ein Werkzeug an der Hand, das einem viele Standardberichte bietet, mit denen man schnell und einfach an Daten zu seiner Webseite gelangt. Bei GA4 bedarf es dafür erstmal Zeit und Knowhow, um die gewünschten Berichte zu erstellen und Eigenschaften aus UA zu übernehmen (z.B. Ereignisse). Unsere Empfehlung ist trotzdem, sich mittelfristig mit Google Analytics 4 auseinanderzusetzen und den Umstieg oder zumindest einen Parallelbetrieb mit UA vorzubereiten, um dann auch Erfahrungen mit GA4 sammeln zu können. Denn eines ist klar: GA4 ist die Zukunft.

Abonnieren
Benachrichtige mich bei
guest
0 Kommentare
Inline Feedbacks
View all comments