Markus Baersch

Ich wollte den Beitrag eigentlich "20+ Dinge, die Du über GA4 wissen musst" nennen, aber das roch mir dann doch zu sehr nach Clickbait. Obschon er genau das bietet: Es ist eine Sammlung an besonderen Eigenschaften und Unterschieden zum Vorgänger und anderen Tools, die einen Umstieg einfacher machen, wenn man sie weiß. Zur Vermeidung von Missverständnissen, unnötigen Umwegen oder unerfüllbarer Erwartungen an die Ergebnisse einer Implementierung. Schlussendlich ist GA4 schon anders genug.

Die Liste ist eine Zusammenführung verschiedener Posts und kleinen Hinweisen, die ich auf verschiedenen Plattformen veröffentlicht habe. Sie ist weder vollständig, noch auf bestimmte Aspekte fokussiert. Die Kategorisierung ist zudem nicht sehr trennscharf, denn Implementierung, Konfiguration und Ergebnisse in den Reports hängen freilich stark voneinander ab. Hilfreich ist die Liste m. E. trotzdem.

Datensammlung und Implementierung

Kardinalität ist nicht Dein Freund. Kontrolliere daher die Anzahl der Werte, die bestehende und vor allem eigene Dimensionen bekommen können. Mehr als 500 Werte pro Tag gelten als "viel" für alle Standard-Reports und führen gern zu (other) statt Daten. Gilt offenbar leider auch für die kaum vermeidbare "page_location". Kontrolle über die Parameter sind daher extra wichtig. Aus Gründen ist also auch sowas wie ein Zeitstempel oder eine eindeutige Event ID sind auf einmal schlechte Kandidaten für eine eigene Dimension (senden ist aber nicht verboten, wenn man den ganzen Kram in BQ betrachten will).

Das ist zudem nicht das einzige Limit, mit man man in Reports leben muss. Wenn alle Felder eines Reports zusammen z. B. 50.000 unterschiedliche Werte erreichen, steht man vor vergleichbaren Problemen und es werden Zeilen zu (other) konsolidiert.

Filtern ist (zumindest derzeit) Sache für den Client, nicht den GA4 Server. Eine ganze Menge inkl. internen Traffic etc. kann man hier aber gut bedienen und auch die typischen Aufgaben wie "Kleinschreiben" verschiedener Werte sind im GTM für wesentliche Felder machbar... aber eben leider mühselig.

Benennung: Du kannst eine Menge an Event-Namen nutzen. Es gibt nur ein Limit für Apps, nicht das Web - das kann und sollte man nutzen, wenn man eine bunte Event-Landschaft bedient. Bei den User- und Event-Eigenschaften, die man auch zur Dimension erheben will, ist aber Generalisierung und Sparsamkeit angesagt. Also z. B. lieber element_type und element_id ("Hat Tip" an Julius Fedorovicius) statt form_type, link_type, accordion_id und so weiter, wenn man sowas braucht - das spart Dimensionen.

Mach Dir eine Liste für die Umstellung: Idealerweise kommen alle Events aus dem Tag Manager. Mit dem GTM Check bei Analytrix ist das schnell erledigt.

Zwischenablage, Google Drive, neue Spalten zur Planung dazu (Ausmisten erlaubt!) und schon hat man einen guten Anfang. Auch bereits bestehende GA4 Events zum Abgleich werden aufgelistet. Praktisches Tool (ich kenne den Autor ;))

PII: Filtern in Datenansichten ist keine Option mehr. Die geliebten customTasks leider auch. Als Ersatz (wenngleich nicht vollständig, weil nicht alle Felder betreffend) gibt es zahlreiche Lösungen für den client- und auch den serverseitigen GTM. Eine davon ist der URL Cleaner, der per Whitelist alle unbekannten / unerwünschte Parameter entfernt und beim Rest wahlweise auch verbleibende Mailadressen behandelt.

Damit ist es aber nicht getan: Oft sind eigene Mailadressen (und Telefonnummern) im Analytics hausgemacht, weil sie als Label oder sonstwie bei Click-Events in UA landen, wenn Telefon- oder Maillinks angeklickt werden. Hier ist Abhilfe einfach: Man passt das Event an. Es sind zwar nur die eigenen Daten, aber genauer betrachtet sind da oft auch persönliche Daten von Mitarbeitern dabei - auch die haben in GA nix zu suchen!

In GA4 ist das allerdings etwas anders: Wer alle Klicks per Enhanced Measurement einsammelt, wird im Explore Bereich für "click" Events schnell in der Dimension "Link URL" Telefonnummern und Mailadressen finden.

Ist das nun ein Beinbruch? Nicht unbedingt. Es wird wahrscheinlich auch niemandem wirklich auffallen. Hat Google sich da was bei gedacht? Vermutlich nicht. Aber die Gefahr, dass die GA4 Property wegen PII Problemen angezählt wird, ist allein dafür wohl bestimmt gering. Dennoch: man sollte sich dessen bewusst sein, so praktisch Enhanced Measurement in GA4 auch sein mag. Vielleicht also doch lieber relevante Click-Events selbst vermessen und auf die Vereinfachung verzichten?

DebugView ist Dein bester Freund, wenn Du sehen willst, was in GA ankommt. Eigentlich Dein einziger Freund, denn Realtime ist gern zu voll und Standardreports und „Erkunden“ zu träge.

Dafür kann man sich hier parallel zur GTM Vorschau beide Seiten ansehen – was geht raus und was kommt an. Bis auf die einzelnen Eigenschaften, Items und alles andere. Wer die Echtzeit aus UA also hauptsächlich vermisst, weil es als QA Werkzeug gedient hat, der wird sich mit der GA4 Variante schnell anfreunden.

Das Measurement Protocol für GA4 ist – anders als sein Vorgänger – nicht dazu gedacht, als vollständige Alternative zur Vermessung von Websites zu dienen. Dazu scheint auch bei GA4 viel zu viel an Kontrolle in den Browser verlagert worden zu sein, was bei UA und anderen Tools typischerweise Aufgabe des Tracking-Servers ist / war. Dennoch ist das Measurement Protocol inzwischen zumindest gut genug, eine Sitzung aufzumachen. Wer also beim ersten Versuch auf Basis der Alpha schnell das Handtuch geworfen hat, kann sich je nach Anwendungsfall nun nochmal neue Hoffnung machen.

„All in“ für gtag.js (oder bald das neue „Google Tag“) ist das, was Google bevorzugt, wenn es darum geht, GA4 mit Daten zu versorgen. Es gibt viele Hürden, wenn man es anders machen möchte. Was z. B. bedeutet, dass jedes gtag.js anders ist, denn der Browser kennt dank gtag.js je nach Datenstream welche Einstellungen hier in GA4 vorgenommen wurden. Dazu gehört, was als Conversion definiert ist, welche Events auf Basis anderer Events zu senden sind (siehe unten), wer als Verweisausschluss gilt und einiges mehr. Das ist grundsätzlich sehr anders im Vergleich zu Universal Analytics und den meisten anderen Digital Analyse Tools.

Events erstellen braucht den Browser: Besonders hier ist es i. d. R. eine Überraschung, wenn man betrachtet, welchen Weg solche selbst erstellten Events gehen, die auf Basis bestehender Ereignisse in GA4 beim Datenstrom definiert werden können. Die Definition erfolgt in GA4, also mehr oder weniger „am Tracking-Server“. Via gtag.js wird dies in jeden besuchenden Browser transportiert, damit dieser den Regeln entsprechend das „erstellte“ Event tatsächlich aus dem Browser sendet, wenn die Bedingungen erfüllt sind, statt dass es am Server entsteht, wenn die eingehenden Events dort verarbeitet werden. Hättest Du das so gewusst? Oder gar erwartet?

Konfiguration

Referrer bitte ignorieren: Es gibt noch immer eine Verweisausschluss-Liste in GA4. Diese findet sich in den Einstellungen des Streams. Will man nicht, dass sich für alle Conversions nach dem „Wiedereintritt“ von einem Zahlungsanbieter zumindest die Quelle auf dieser Ebene ändert (die Sitzungsquelle wird i. d. R. ohnehin nicht betroffen sein), so kann man paypal.com und andere Conversiondiebe auch in GA4 wieder sinnvoll hier eintragen. Diesmal zum Glück auch mit Platzhaltern – das haben wir uns bei UA schon immer gewünscht.

Technischer Hinweis: ignore_referrer als Event-Parameter auf „true“ setzen ist das Pendant zu vielen Bastelarbeiten in customTasks, die man (gern in Single Page Applications) zum Vermeiden von Fehlattribution eingesetzt hat und wo man nicht einfach mit der nach wie vor existierenden Verweisausschluss-Liste arbeiten kann. Keine Sorge: Wer nicht weiß, worum es dabei geht, wird diesen Hinweis nicht brauchen.

Mehrere Streams – wozu? Das Konzept der gemeinsamen „User Base“ in GA4 in einer Property vs. klassische Nutzung von Datenansichten oder mehreren Properties in UA schafft in einigen Konstellationen echte Probleme. Dazu muss man nicht einmal von Cross-Domain-Tracking reden. Blog, Website und Shop trennen? Früher ganz einfach, heute je nach Anforderung an eine Trennung fast aussichtslos. Abhilfe gibt es zwar in Form von Rollup- bzw. Sub-Properties, wenn man sich die kostenpflichtige 360-Variante gönnt, aber im Standard ist eine solche Trennung schlichtweg nicht vorgesehen. Als Lösung muss man wohl oder übel entweder mehrfach im Browser taggen oder durch halbseidene Konstruktionen an einem eigenen Endpunkt (wie dem ssGTM) die Daten eines Streams an mehrere Properties senden.

Denn ein Stream kann leider nicht in mehreren Properties verwendet werden – und mehrere Web-Streams in einer Property sind leider auch keine Lösung (davor wird sogar explizit gewarnt), da für jede Measurement ID die Sitzungen und deren Parameter getrennt verwaltet werden und so inkonsistente Daten entstehen. Entweder mit Lücken oder zu hohen Werten für Sitzungen etc.

Mehrere Streams sind tatsächlich nur dazu gedacht, die Daten aus unterschiedlichen Plattformen (Web, Android, iOS) in einem Datenpool zusammenzuführen. Nicht zur Trennung oder Mehrfachnutzung von Daten. Wer daher nicht wirklich „getrennte“ Properties mit unterschiedlichen Zugriffsberechtigungen o. Ä. braucht, sondern „nur“ getrennte Sichten auf die Daten haben will, wird sich eher mit Vergleichen, Filtern und Segmenten in GA4 begnügen müssen. Oder auch hier sein Heil in Big Query und der übergreifenden Auswertung einzelner Datenpools suchen. Wird das noch besser? Ich fürchte, die Antwort ist auch im Sommer 2023 noch „Nein“.

Datenaufbewahrung sehr begrenzt: Die Optionen in GA4 sind dünn: Es gibt die Wahl zwischen 2 und 14 Monaten. Umso ärgerlicher, dass per Standard erstmal nur 2 Monate angegeben sind. Das bedeutet zwar nicht, das alles nach 2 Monaten weg ist, aber Detailanalysen der meisten Dimensionen sind dann eben nicht mehr verfügbar und daher sollte man zumindest die längere Dauer aktivieren, sobald eine Property angelegt ist.

Wer Daten noch länger auswerten auch in Details möchte, hat eigentlich nur zwei Optionen: Den Export ausgewählter Daten aus Reports oder via API in eine eigene Datenbank (mühselig) oder eben die Verbindung zu Big Query. Wo auch für längere Zeit Rohdaten speicher- und auswertbar sind, aber eben nicht mehr mit den Bordmitteln von GA4.

Single Page Application? Dann aufgepasst: GA4 reagiert von Haus aus auf History Changes im Browser und bekommt so im Gegensatz zu UA in vielen Fällen auch so mit, wenn sich Inhalte ändern. Das muss nicht für alle SPAs gelten, aber man sollte es zumindest wissen, bevor sowohl der GTM als auch gtag.js sich beide darum kümmern und Events daher verdoppelt werden.

In den Einstellungen zum Enhanced Measurement kann beim Pageview, den man ansonsten nicht ausschalten kann, aber zumindest das Verhalten bei SPAs steuern.

Eigene Events bauen: Events bei besonderen Gelegenheiten „klassisch“ als Tag im GTM zu hinterlegen, obschon diese auf Aufrufen bestimmter URLs o. Ä. basieren, ist nicht der einzige Weg, um aus allgemeinen Events ganz spezielle Messpunkte in GA4 zu machen. Im Konfigurationsbereich kann unter „Events“ mittels „Create Event“ – Funktion definiert werden, dass andere Ereignisse unter bestimmten Bedingungen (eine bestimmte page_location bei einem page_view zum Beispiel) neue, weitere Ereignisse erzeugen sollen. Die dann wiederum als Conversion dienen können. Das ist in der Tat praktisch, allerdings gibt es auch hier (noch) Beschränkungen, wie an vielen anderen Stellen auch.

Conversions vs. Ziele: Conversions basieren in GA4 auf einem Event. Damit kann man 90% von dem abdecken, was in UA als Ziel verwendet wurde. Dennoch ist die sehr flexible Auswahl der Ziel-Optionen in UA (z. B. einschließlich Zeit, Abfolgen und komplexer Kombinationen) nicht ganz in GA4 abgedeckt. Ohne Workarounds im Browser (Seufz!) geht es daher oftmals leider nicht. Einiges, aber nicht alles, ist über den Umweg der Audiences abzudecken, bei denen z. B. Abfolgen von Events – auch sitzungsübergreifend – als Kriterium angegeben werden können. Da aber niemand Workarounds mag: Das wird hoffentlich noch besser in GA4 in den nächsten Monaten bis zum Ableben von UA.

Auswertungen und Reports

Content Gruppierung in Universal konnte auf verschiedenen Wegen stattfinden und es gab mehr als eine Gruppierung. In GA4 ist dazu derzeit nur eine Möglichkeit vorgesehen und die Gruppe muss als content_group bei Events mitgesendet werden. Alles andere muss einstweilen in eigene Dimensionen, wenn man einen page_type, eine blog_category oder was auch immer zusätzlich ablegen will. Ist das schlimm? Nein, eigentlich nicht. Der Unterschied von eigenen Dimensionen zur content_group ist (derzeit) nur, dass diese bereits im UI angeboten wird, während man andere erst selbst registrieren muss, um sie auf gleiche Weise zu nutzen. Trotzdem ein - schon in UA - unterbewerteter / zu wenig genutzter Weg, Besucherverhalten (und hoffentlich auch bald Bewegungen in Pathing-Explorations!) nach Seitenklassen oder Inhaltskategorien etc. zu bewerten.

Es gibt eine Absprungrate! Nanu, sollte es in GA4 sowas denn eigentlich nicht mehr geben und stattdessen das „Engagement“ gemessen werden? Ja, das stimmt: „Engaged“ ist man lt. GA4 schon sehr schnell und selbst ohne diese eigens dazu gedachten user_engagement Events (die auch zur Vermessung von „Nutzungsdauer“ zwischen Events dienen) würde es mehr „Non-Bouncer“ geben, als in einem Standard Universal-Setup, in dem die Signale oft (leider) nur aus Seitenaufrufen bestehen. Dennoch ist die Absprungrate in GA4 immer noch da. Als Gegenstück der Engagement Rate (meint: „1 minus Engagement-Rate“) und nur über die API. Die Abbildung zeigt bounceRate und engagementRate in trauter Zweisamkeit.

Wozu? Keine Ahnung – ganz ehrlich! Hinweis zum Engagement: Zu den Kriterien gehören z. B. 10 Sekunden Verweildauer.

Das kann und sollte man in GA bei den Einstellungen des Streams auf z. B. 30 Sekunden anheben.

Seitentitel statt URLs - warum? Es ist verwirrend, wenn man es gewohnt ist, in Reports zu Inhalten erst einmal die URLs oder Pfade von Seiten zu sehen. In GA4 stehen hier aber zunächst Seitentitel. Das hat mehrere Gründe. Einer davon ist, dass bei Mischung von Web und App Daten hier ein Titel einer Seite im Web viel vergleichbarer mit einem App Screen ist als eine URL. Zudem sind Seitentitel i. d. R. unabhängig davon, welche Parameter ggf. an einer URL vorhanden waren und so sind die Metriken oft weniger fragmentiert und auf mehrere Zeilen verteilt.

Aber Vorsicht: Auch der Seitentitel ist nicht perfekt, denn er stammt aus dem Browser und kann daher in verschiedenen Varianten daherkommen. Hauptgrund sind i. d. R. Browser, in denen die Inhalte in eine andere Sprache übersetzt wurden. Zudem gibt es mehrere Gründe, warum ein Seitenaufruf eine URL, aber ggf. keinen Titel hat. Wer lieber wieder mit Seitenpfad und Parametern arbeitet: Die primäre Dimension kann im Report zu Seiten und Bildschirmen jederzeit geändert werden. Wer das nicht jedes Mal wieder neu tun mag, verwendet das Stiftsymbol oben rechts und passt den Report so an. Was übrigens auch für alle anderen Reports ein guter Weg ist, mehr aus den Standardberichten zu machen.

Source / Medium hoch drei? Sowohl praktisch als auch verwirrend ist die Tatsache, dass es mehr als eine Quell-/Medium Kombination gibt. In UA gab es diese jeweils nur für die Sitzung und alle Messpunkte einer Sitzung sind der Quelle und dem Medium des Besuchs zugeordnet. OK: oder des vorherigen, wenn es ein direkter Besuch war – wer soll das schon kapieren?

GA4 gibt uns gleich drei solcher Kombinationen und weist in unterschiedlichen Reports auch verschiedene Versionen aus. Der Nutzer bekommt z. B. in seiner ersten Sitzung einmalig „Nutzerquelle und Nutzermedium“ zugeordnet. Diese Daten stehen auch in allen folgenden Sitzungen zur Verfügung – was sehr praktisch ist. Ebenso hat – wie in UA – auch die Sitzung eine Quelle und ein Medium. Diese stimmen also zwingend nur beim ersten Besuch überein. Und wenn jemand innerhalb einer bestehenden Sitzung nochmals über eine erkennbare Quelle (ein weiterer Klick in Suchergebnissen, ein Klick auf einen Link in einer Mail mit UTM Parametern, ein Gutscheinpublisher oder was auch immer) daherkommt, bleibt die Sitzung bestehen und alle folgenden Conversion-Ereignisse (nur diese) haben eine abweichende Quelle und Medium – eben die letzte Information, die innerhalb der Sitzung (ggf. abweichend vom Start) bekannt war. So kann eine Conversion also der ursprünglichen Quelle des Nutzers zugeordnet werden, der Quelle der Sitzung und ggf. der abweichenden letzten Quelle vor oder bei diesem Conversion-Ereignis selbst. Das ist deutlich anders als das Verhalten von UA und sorgt beim ersten Umsehen in GA4 gern für Missverständnisse. Daher: Gut, dass wir das geklärt haben! 😊

Endlich Attributionsmodelle! Machen wir uns nichts vor: Die Attribution in UA als „Last-Non-Direct“ / Beinahe-Last-Click“ war nicht ideal und man konnte in Reports jenseits des Multi-Channel-Bereichs nichts dagegen tun. In GA4 trägt man nach Erprobung seine Lieblings-Attribution ein oder überlässt das Ganze dem datengetriebenen Modell (inzwischen die Vorgabe).

Noch besser: Änderungen betreffen auch historische Daten.

OK, so ganz supi ist das nicht, wenn man alte gespeicherte Reports mit neuen für den gleichen Zeitraum vergleicht und keine Ahnung hat, dass dies umgestellt wurde. Von diesem Schwachpunkt abgesehen ist das aber einer der größten Pluspunkte für GA4. Man kann zwar die Parameter eines Modells wie dem positionsbasierten nicht mehr weiter beeinflussen (das geht aber in anderen Tools), ohne auf BQ zu setzen und die Attribution selbst zu bestimmen, aber es ist einfach um Welten besser als vorher.

view_search_results Events via Enhanced Measurement für Site-Search Suchergebnisse, aber gar keine Suchfunktion? Das kann schon sein. in UA musste man die Auswertung der internen Suche aktivieren und durch Angabe von Suchparametern konfigurieren. Das scheint zu wenig Nutzung gefunden zu haben und so ist in GA4 nun die Auswertung per Standard aktiv im Enhanced Measurement und hat einen Satz von Standard-Parametern, die dieses Event bei einem Seitenaufruf auslösen. Diese sind in den Einstellungen aufgeführt:

Wenn also einer dieser Parameter auf der Site genutzt wird, aber eine ganz andere Funktion erfüllt, kann in den Einstellungen des Streams die Auswertung der Suche deaktiviert oder zumindest passend konfiguriert werden, was die Parameter angeht.