Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » Analytics / GA4

16.10.2020

Aha. Google Analytics 4 ist nun also da. War am Mittwoch bei Twitter nicht zu verpassen. Apps + Web ist damit mit einem Knall aus der Beta und "ab sofort" der neue Standard bei der Anlage einer neuen Property. Zuerst habe ich noch gedacht, es würde "Google Analytics 4 Properties" heißen. Was auch blöd wäre. Aber wieso eigentlich "4"? Urchin -> Classic GA -> Universal -> GA4? Oder pageTracker -> _gaq -> ga(), gtag()? Wie auch immer. Ich finde nicht nur den Namen verwirrend und halte den Zeitpunkt einer Beförderung zum Standard für zu früh. Here´s why...

Google Analytics 4: Habe ich das auch?

Entgegen der Ankündigung sind neue Properties nicht automatisch GA4 in allen Konten. Im Gegenteil habe ich noch nirgends eine Änderung im Workflow bei der Neuanlage gefunden. Aus einer großen Liste von Konten habe ich aber einige wenige Kandidaten gefunden, bei denen die neuen Google Analytics 4 Properties tatsächlich schon genutzt werden können. Die Umstellung der Sprache hat in diesem Fall übrigens keinen Einfluss. Ein sicheres Zeichen für GA4 Verfügbarkeit findet sich im Verwaltungsbereich in der Spalte zur Property. Existiert hier ein Menüpunkt für ein Upgrade, ist GA4 zu haben.

Upgrade Link auf GA4

Mir ist es nur über diesen Weg gelungen, eine GA 4 Property als Ziel eines "Upgrades" anzulegen. Dabei ist es davon abhängig, welches Tag auf der Site verbaut ist, deren Property im Parallelbetrieb mit Google Analytics 4 vermessen werden soll.

GA4 Property erstellen

Richtig: Es muss gtag.js im Einsatz sein. Auch ohne ist zumindest die Anlage der Property möglich.

Wie eine App+Web-Property gibt es bei einer Google Analytics 4 Property keine Datenansichten o. Ä. - der Funktionsumfang entspricht also dem bei App+Web. Mit allen Konsequenzen (siehe unten). Anders als klassische Properties, die mit "UA" beginnen, ist die Measurement Id wie bei App+Web nur noch numerisch.

Einstellungen einer GA4 Property

Auch ansonsten ist alles hier wie bei App+Web. Auch das UI, das trotz deutscher Sprache einen schnell umgesetzten und noch nicht lokalisierten Setup-Assistenten einblendet. Dieser verweist auf aktualisierte Hilfe Seiten... und das war es eigentlich auch schon

Google Analytics 4 Echtzeit-Startseite

Da fehlt doch was. Geht es nur mir so?

Irgendwann hat mal jemand sowas wie "Routine ist der Feind des Neuen" gesagt und es ist bei mir hängen geblieben. Die tief ausgeleuchteten Ecken und Kanten des "alten" Analytics sind zugegebenermaßen bekannt und das Tracking passt wie eine Lieblingsjacke. Daher bin ich unsicher, ob meine empfundene Ablehnung fair ist oder nicht. Sie richtet sich nicht gegen gtag.js oder die neuen Properties, die ich bis Dienstag als Apps+Web kannte. Ganz im Gegenteil habe ich mich in den letzten Wochen verstärkt damit befasst. Aber - oder gerade deshalb - halte ich das, was ich dabei kennen gelernt habe, nicht für wirklich geeignet, bei neuen Properties als Standard zu dienen. Zu viele Dinge fehlen mir da aktuell. Liegt das nun nur daran, dass ich existierende Lösungen für die folgenden Punkte nur nicht gefunden habe? Oder sind diese Lücken gar keine, sondern werden nur wahrgenommen im Vergleich zu dem, was wir von Universal Analytics gewohnt sind? Ich kann es nicht genau bestimmen.

Bevor ich den Finger in die von mir wahrgenommenen Wunden lege, daher zuerst ein Blick auf die Dinge, die mir als Vorteil erscheinen in der Übersicht. So zu sagen als Ausgleich für das, was darauf folgt.

Was ich gut finde

  • Vereinheitlichung des Hit-Modells. Trennung von Pageviews und Events war nie eine "Idee", sondern ist historisch bedingt und es ist m. E. gut, das aufzulösen
  • UI Allgemein / Übersicht: Zumindest heute wird die neue Oberfläche für einen Einsteiger vermutlich weniger erschlagend sein als die alte mit ihrer Report-Vielfalt. Das macht aber den "Analytics-Hub" in der neuen Version allein m. E. nicht zum perfekten Ersatz (siehe unten). Die Echtzeit ist aber nützlicher als der alte Standard
  • Debug-View. Praktisch bei allen Änderungen. Im Regelbetrieb aber freilich kein echtes Pro-Argument
  • Big Query Verknüpfung (solange es sie noch gibt). Bin mir relativ sicher, dass das in ein 360 wandern wird. Wie genau das mit den neuen Standard-Properties aussehen wird, weiß ich ehrlich gesagt noch nicht. In meinen Testkonten ist die Anlage einer neuen Property nicht erkennbar anders und es kommt nichts raus, was nach Apps+Web aussieht
  • Kein Sampling. Zumindest derzeit sind alle Reports stets ungesampled. Ob das so bleibt, ist m. E. aber genau so offen wie der vorherige Punkt
  • Keine Dashboards. Wie, das finde ich gut? Ja, denn Dashboards bauen sich in Data Studio besser und die halbherzigen Dinger aus GA kann und sollte man daher über Bord werfen

Was mir fehlt (und was z. T. vermutlich auch "weg" bleiben wird)

Nach diesen überschaubaren (und unvollständigen) Vorteilen muss folgerichtig die "Mecker-Liste" kommen. Oder besser: Eine Aufzählung von m. E. ungeklärten Fragen.

  • Was ist mit der Möglichkeit zum Filtern? Fehlt das nur mir? Nicht nur wegen ggf. verschiedener Datenansichten, sondern eben auch für einfachere Transformationsaufgaben an den einlaufenden Daten waren Filter bisher ein mehr oder weniger unverzichtbarer Helfer. Muss das nun alles mit Segmenten gemacht werden?
    • Update 03/2021: Inzwischen sind erste Filteroptionen in GS4 zu finden und es gibt Konzepte, um internen Traffic und Developer-Traffic zu behandeln und aus den Daten zu halten. Allerdings eben - in Ermangelung mehrerer Datenansichten (was so bleiben wird; siehe unten) - in einer endgültigeren Manier. Meint: Weg ist weg, keine "Backupdaten" mit allen Hits.
  • Wo wir gerade von Filtern sprechen: Was ist mit verschiedenen Datenansichten? Muss ich für den Blog wirklich einen eigenen Stream anlegen und den (parallel) in eine eigene Property senden, wenn jemand nur die Daten des Blogs sehen soll?
    • Update 03/2021: Ich denke: Ja, das bleibt vermutlich so. Denn die verschiedenen Datenansichten in Universal Analytics sind ein echter "Speicherkiller" aus Sicht eines Anbieters. Hier sind die gleichen Daten - oft wirklich exakt übereinstimmend oder nur mit ganz geringen Unterschieden - in jeder Datenansicht separat gespeichert. Daher ist Google dieser Multiplikator des Platzbedarfs einer Property ein bekannter Dorn im Auge und es wäre nahezu dumm, hier bei GA4 diesen Fehler zu wiederholen. Datenansichten sind daher m. E. Geschichte, soweit es GA4 betrifft.
  • Allgemein scheint Filtern, Datenanpassung und selbst sowas wie das Verwalten von Verweisausschlüssen nun eher eine Aufgabe beim Tagging selbst (also im GTM) statt beim Empfänger zu sein. Da kann durchaus sinnvolle Absicht hinter stecken. Denn im Prinzip ist eine Validierung und Anpassung von Hits vor dem Versand natürlich eigentlich die bessere Idee. Nur ist der Aufwand bei einer "Migration" von UA auf GA4 im Einzelfall durch das Fehlen von Filtern enorm hoch.
  • Was ist mit dem ganzen Data Deletion Request - Kram?
    • Update 03/2021: Alles da inzwischen; analog zu Universal Analytics
  • Verknüpfungen wie AdSense, Search Console & Co. sind für einige ggf. wichtiger als für andere, fehlen bisher aber. Ebenso die zu Optimize - also keine Tests mit GA4 und Optimize
    • Update 03/2021: Google Ads Linking ist inzwischen da.
  • Datenimport: Fehlanzeige. Gerade im E-Commerce für Retouren, Produktdimensionen & Co. auch jenseits von Kosten nicht unwichtig
  • Update 03/2021: Produkt- und User-Daten sind inzwischen im Import zu finden.
  • Channels: Nur Quellmedium-Auswertungen mit allen Fehlern, die da i. d. R. drin stecken im Tagging? Neben Filtern zur Optimierung von Kampagnenangaben waren Channels bisher ein flexibles Mittel, um eine passende und wunschgemäß granulare "Gruppierung" verschiedener Quellmedien vorzunehmen. Muss man das nun alles selbst in die Hand nehmen (siehe nächster Punkt)?
  • Die Frage umfasst auch Content Groupings & Co. Alles ab jetzt über Event Properties und "von Hand"?
  • Conversions als Ersatz der alten Ziele nur auf Basis von Events? Nichts komplexeres? Muss ich meine Engagement-Events dann selbst senden, statt wie bisher Engagement-Ziele nutzen zu können?
    • Update 03/2021: Die Standard-Datensammlung ermittelt "Engaged Users" inzwischen selbst anhand von Verhalten. Außerdem können Events inzwischen bearbeitet, verändert und auch zu Conversions erhoben werden, ohne sie erst senden zu müssen. Das wird also langsam rund
  • Analysehub und Vorlagen schön und gut. Aber genau Null Hilfreiches "aus der Dose" für wesentliche Bereiche wie E-Commerce (ist ja gerade erst "fertig" geworden) ist m. E. zu wenig für den typischen reinen Anwender
    • Update 03/2021: Analysen sind inzwischen auch für E-Commerce zu haben. Generell ist das ganze Thema aber nach wie vor hürdenreich und es fehlen z. B. Navigation für paginierte Tabellenlisten und einige andere Dinge auch
  • Segmente: Gibt es, aber sind noch sehr einfach und man kann sie nicht mal ordentlich speichern? Muss man die wirklich jedes Mal selbst zurecht klicken?
    • Update 03/2021: Das ist nun zwar in den Standard-Reports nicht wirklich besser, aber im Analyse-Bereich gibt es ein Segmentierungs-Tool, das seinen Job macht und außerdem gibt es noch Audiences, die Segmenten je nach Zweck sehr nahe kommen.

Einige Features, die bereits in Blogposts beschrieben werden, sind in meiner Fassung noch nicht zu sehen. Diese scheinen Lücken wie Datenimport zu schließen bzw. in Features wie Event Modeling vermutlich einen Ersatz für viele Einsatzszenarien bisheriger Filter darstellen. Warten wir es ab...

Einfach noch zu früh?

Ich verstehe die Eile gerade nicht. Die Ankündigung hat mich auf jeden Fall überrascht. Und vermutlich die Entwickler auch 😉 Wie sonst ist zu erklären, dass nun zwar ein Measurement Protocol V2 nun mit API Secret und sicher vielen anderen Ergänzungen zu kommen scheint (das ist toll! nicht falsch verstehen)... aber: "aus der Beta" ohne Referenz in der Hilfe? Sieht für mich nach Schnellschuss aus.

Auch Dinge, über die ich vor ein paar Wochen noch bei der Data Collection gestolpert bin, sind immer noch aktuell. Ein Beispiel: der zum Verhindern des Setzens von Cookies bei der Initialisierung des gtag-Trackingcodes mittels client_storage:"none" funktioniert wunderbar, wenn man den Code mit einer Universal Analytics Property betreibt. Tauscht man aber die Property-Id gegen eine Measurement-Id eines Apps+Web Datenstroms aus, fängt man sich doch wieder Cookies ein. Meint: Es funktioniert einfach noch nicht alles so, wie es soll. Vielleicht ist das anders, wenn es mir wirklich gelingt, eine der neuen Standard-Properties anzulegen. Allein mir fehlt der Glaube daran.

Ab jetzt trotzdem nur noch Google Analytics 4?

Mich lässt dieser Launch etwas ratlos zurück; keine Ahnung, wie ich damit umgehen soll. Es mag an meiner fehlenden Routine mit GA4 liegen, dass ich auch morgen noch jede neue Property lieber mit Universal Analytics und den bekannten Problemen betreiben würde, statt dies mit dem fancy neuen Dingsi zu tun und dabei schon jetzt absehbare Einschränkungen und zudem noch unbekannte Probleme in Kauf zu nehmen.

Wie siehst Du das? Ab sofort nur noch mit GA4; Augen zu und durch? Wer bezahlt für den Mehraufwand bei der Arbeit an der Grenze des noch Unbekannten? Was ist mit Hürden, die sich als unüberwindlich erweisen? Ich wüsste nicht, ob und wie ich morgen ein typisches E-Commerce-Projekt auf Shopware- oder WooCommerce-Basis mit einem GA4-Tracking versehen kann, wie ich es aus mit Universal Analytics kenne. Und ich bin nicht sicher, ob das nur daran liegt, dass GA4 ein unbekanntes Tool ist wie jedes andere "Nicht Google-Analytics" und man Implementierung im Kontext eines anderen Tools stets anders denken muss, statt sich auf die o. a. "fehlenden" Dinge zu konzentrieren. Auch Matomo ist kein GA und dennoch bekommt man sinnvolle Setups hin. Ich bin gespannt,  wie sich das mit Google Analytics 4 gestalten wird, sobald sich eine Gelegenheit bietet.

Hat Dir der Beitrag geholfen?

Dann freue ich mich, wenn Du ihn mit anderen teilst! Wenn Du magst, gib einen aus ;)

© 2001 - 2024 Markus Baersch