Markus Baersch

OK, nun hat Google Universal Analytics also mit dem 1.7.2023 ein definitives Ablaufdatum bekommen. Eben noch frisch wirkende Tracking-Setups wirken plötzlich wie lebende Leichen und das rudimentäre parallele GA4 Tracking, das ggf. schon seit einiger Zeit mitläuft, braucht dringend mehr Aufmerksamkeit. Genau jetzt.

Ein Umstieg hat eine Menge Hürden. Allen voran Google Analytics 4 mit seinem komplett neu erfundenen Event-Modell, Tracking-Konzept, Setup und Benutzeroberfläche. Das alles kann und wird dieser Blogbeitrag nicht lösen. Hier wird es primär darum gehen, wie man an ein zu Universal Analytics vergleichbares GA4-Tagging kommt - möglichst mit einem Minimum an Planung, aber nicht, ohne die neue Struktur von GA4 zu berücksichtigen. Vermeidbare Tagging-Fehler gleich am Anfang sind ärgerlich - schlussendlich wird GA4 noch einige Änderungen erfahren, bis der Todestag von Universal angebrochen ist. Denn alle, die ab dem 1.7.2023 beim Last-Minute-Umstieg auf GA4 historische Daten haben möchten, sollten vor dem 1.7.2022 mit dem dem Datensammeln beginnen - auch wenn es noch nicht perfekt sein wird kann. Also Ärmel hoch und los...

Disclaimer: Viel Anleitung, kaum Taktik, Null Strategie

Man kann unglaublich viele Aspekte einer gut geplanten Umstellung auf GA4 betrachten. Sollte man auch. Das neue Tool als Chance zu sehen, einen vernünftigen Trackingplan zu erstellen, mit den aktuellen Gegebenheiten abzugleichen und bestehende Schwächen auszumerzen.

Zu groß ist bei einer überhasteten Migration des Bestehenden (oft über Jahre gewachsen) am Ende mit dem gleichen Mist da zu stehen, nur mit GA4 Geschmack. Wer muss wann und wo mit GA4 und den Daten arbeiten? Wie kann Routine in diesem sehr anderen Tool gesammelt werden? Welche Schnittstellen muss man bedienen? Was davon ist schon da und wo muss man warten, bis Google (hoffentlich) noch nachlegt? Wichtige Punkte. Dennoch muss dieser Beitrag all das ignorieren, wenn er kein Buch werden will. Die folgende Anleitung fokussiert sich auf das Minimum der Vorbereitung und Migration eines Universal Analytics Trackings für GA4 (im Google Tag Manager). Das wird schon lang genug ausfallen.

Hochprofessionelle Visualisierung einer GA4 Migration. Ehrlich!

Gemische Ausgangslage

In vielen Tag Managern ist bereits "etwas GA4" vorhanden - oder im Backend des Shops wurde parallel zur Universal Property ID irgendwann die Mess-ID eines GA4 Datenstroms angegeben, weil der Anbieter oder das Plugin dies nun unterstützt. Für den zweiten Fall: Wer bisher in Universal mit dem leben konnte, was er durch ein Setup des Systems von der Stange bekommen hat, mag auch in GA4 auf diese Weise zurechtkommen. Man ist (da GA4 neu und laufenden Anpassungen unterworfen ist) dann zu 100% auf den jeweiligen Hersteller angewiesen. Das kann eine valide Entscheidung sein... sie sollte aber wenigstens bewusst getroffen werden. Es ist erwartbar, dass die Innovationen in GA4 nur langsam und unvollständig in solche Lösungen einfließen werden.

Daher ist der Google Tag Manager oder ein anderes flexibleres System zum Tagging i. d. R. die bessere Lösung. So oder so: Wenn bereits Daten gesammelt werden, ist vermutlich ein Überdenken der aktuellen Versorgung von GA4 ein lohnender Schritt, wenn man nachher mit den Daten wirklich etwas anfangen möchte.

Pageview automatisch oder manuell senden?

Schon beim ersten und ggf. bereits vorhandenen GA4 Tag geht es los. Wie bei UA ist auch in GA4 ein Seitenaufruf ein wichtiges Ereignis. Daher gibt es einen "GA4-Basistrackingcode", der das Tracking initialisiert und auf Wunsch einen Seitenaufruf vermisst, wenn das erledigt ist. Zudem kann GA4 eine ganze Menge anderes Zeug mit diesem Code vermessen. Er ist für Events wie das optionale Tracking von Downloads, externen Links, Scrolling (einmalig bei 90%) und ein paar andere "Automatische Events" zuständig, die im Daten-Stream konfiguriert werden können. Auch weitere Ereignisse wie den Start einer Sitzung, Engagement-Signale etc. sendet der "GA4 Basiscode". Also alles mit einem Tag. Wenn man es so will. Da das GA4-Konfigurations-Tag darüber hinaus als "Template" und Quelle für Daten wie die Mess-ID für alle anderen Events dient, übernimmt es zudem in gewisser Weise die Aufgabe der bisherigen Universal Analytics Einstellungsvariablen. So steht es im sehr knappen und wenig hilfreichen "Migrationsleitfädchen" von Google.

Zum Verständnis: Sorry - ich mische Event und Ereignis recht häufig, bitte daher als Synonym verstehen, wenn es um Analytics geht. Kann ich mir nicht abgewöhnen und bin damit auch nicht allein.

Ein Seitenaufruf ist für GA4 aber grundsätzlich nichts anderes, als jedes andere Ereignis auch. Mit einem ganz bestimmten Eventnamen und einigen vordefinierten Ereignisparametern - aber dennoch ein normales Event. Da die Konfigurationsvariable den Seitenaufruf zur Option macht, kann man ihn auch separat senden. Entweder mit einem zweiten Konfigurationstag inkl. Seitenaufruf (es gibt ein paar schräge Gründe dafür, welche die meisten Setups nicht betreffen) oder als normales GA4-Event.

Im Prinzip ist der automatisch abgesendete Seitenaufruf vollkommen ausreichend für die meisten Fälle. Es ist aber zu bedenken, dass auf diese Weise dabei keine weiteren Event-Parameter übergeben werden können, die man i. d. R. gern nutzt, um vormals auf Hit-Scope definierte benutzerdefinierte Dimensionen zu transportieren. Ist das im eigenen Setup der Fall, ist ein eigenes Event die bessere (derzeit einzige) Option, wenn man mit den Google Tag Vorlagen für GA4 im Tag Manager arbeiten will. Die Wahl wird sich irgendwann im Verlauf daher meistens klären, wenn man sich an die Umstellung macht. Vielleicht schon im ersten Schritt: Der Sichtung von Benutzerdefinierten Dimensionen.

Benutzerdefinierte Dimensionen und Metriken

In Universal sind bei der Property wahrscheinlich / hoffentlich einige "Benutzerdefinierte Dimensionen" (und vielleicht Metriken) angelegt worden. Diese gehören im ersten Schritt auf eine Liste - inkl. des Scope, also des "Geltungsbereichs", damit man diese später in Ereignis- oder Besucher-Eigenschaften übersetzen kann.

Ein stupides 1:1 Übertragen in entsprechende Pendants in GA4 ist aus mehreren Gründen nicht sinnvoll:

1. in GA4 gibt es (derzeit) weder einen Sitzungs- noch Produkt-Scope. Es mag je nach Einsatzzweck Auswege geben, generell gilt trotzdem:
   • Was auf Sitzungsebene definiert wurde, kommt auf eine Liste, die man im Kalender vor sich her schieben kann. Wenn Google nachgebessert hat, ist eine nachträgliche Migration noch denkbar. Workarounds mit Cookies etc. sind nur selten eine Lösung, können im Einzelfall bedacht werden - um dann aber ggf. wieder zu verschwinden, sobald es in GA4 einen passenderen Ersatz gibt. Doppelte Arbeit droht also!
   • Produkt-Scope gibt es ebenso nicht. Auf Ebene des E-Commerce-Events können und sollten zwar entsprechende Parameter gleich vorgesehen werden, aber in GA4 ergeben diese derzeit kaum einen Nutzen und sind nur dann "brauchbar", wenn man sich aus BigQuery-Richtung mit den Daten befasst. Auch hier: Es mag sich noch ändern, ist aber derzeit, wie es ist.
2. Einige der typischen Dimensionen sind schlichtweg nicht mehr erforderlich
   • Ein Hit-Zeitstempel für den Export von Daten aus UA als Rohdaten ist nicht mehr nötig, wenn man mit BigQuery arbeitet. Über die API ist diese Information derzeit nicht zu bekommen, wird aber ziemlich wahrscheinlich noch verfügbar werden. Für die Session ID - und Client ID gilt das Gleiche.
   • Einen "HitType" braucht man nicht, wenn alles ein Event ist wie in GA4. Auch ein "Analytics Geheimnis", wie es vormals gegen Server2Server-Spam eingesetzt wurde, kann man im Prinzip in Rente schicken
3. Metriken? Ähnliche Geschichte. Nur Event-Scope derzeit

Aufräumen: Alles andere lohnt einen zweiten Blick, denn evtl. hat man es nur für Dinge genutzt, die in GA4 bereits vorhanden sind wie die URL eines Videos o. Ä. Übrig bleiben dürften dann im Idealfall eine Handvoll Dimensionen auf Hit- oder User-Ebene. Diese können in GA4 dann in entsprechende Event-Parameter oder User-Properties umgewandelt werden. Hier ist wiederum bei der Planung zu bedenken, was davon man in Analytics direkt im UI benutzen möchte (also vermutlich alles, was es bis hier geschafft hat). Denn damit Dimensionen in Reports erscheinen können, müssen diese in GA4 erst in den Einstellungen in GA4 unter "Konfigurieren - Benutzerdefinierte Dimensionen" angelegt werden - senden allein reicht nicht.

Tipp: Blick in die Datenschicht. Wer durch Aufräumen Platz macht, darf sich damit belohnen, ggf. etwas Neues für die freigewordene Stelle zu besorgen. Das soll kein Aufruf zum Einplanen aller verfügbarer Informationen aus dem dataLayer als Event-Parameter sein. Aber ein Blick auf das Angebot und sorgfältige Evaluierung des Nutzens muss erlaubt sein!

Wie soll das Kind heißen?

In GA hatten die Dimensionen oft sehr spannende Bezeichnungen - mit bunt gemischter Schreibweise. All Caps, mit Leerzeichen, Unterstrichen und Dimensionsnummer oder dem Scope im Namen. Oder in camelCase. Oder wie auch immer. All diese Bezeichnungen kann man - mit ein paar Einschränkungen - theoretisch beibehalten, wenn daraus Event-Parameter oder User Eigenschaften werden. Aber es ist nicht sinnvoll - ebenso wenig wie die Beibehaltung alter Bezeichnungen aus Events; sei es Kategorie, Aktion oder Label.

Neues Schema als Vorlage: Da GA4 durchgängig nach einem klaren Schema arbeitet, ist es i. d. R. zu empfehlen, sich daran zu halten. Idealerweise ggf. in Englisch - was freilich kein Muss ist, solange man zumindest Umlaute und Sonderzeichen vermeidet. Eine gute Regel ist: Alles klein schreiben und einzelne Begriffe oder Wort-Teile mit einem Unterstrich trennen. Aus User Status wird user_status, isLoggedIn zu logged_in und so weiter. Dieses Format kann man bei Events weiter beibehalten.

Vorsicht bei User Properties

Wer die Idee hat, der Konfiguration einen Standardwert für User Properties mitzugeben und diese in Events mit "besseren" Werten zu überschreiben, muss diese wieder verwerfen. Je Seitenaufruf (und Datenstrom) wird eine User Property nur einmal gesendet. Der erste Wert gewinnt also immer. Daher: Sende Properties nur an GA4, wenn der Wert bekannt ist. Das ist bei der Planung nicht unwichtig, wenn das Ergebnis den Wünschen entsprechen soll.

Tipp: Content Grouping gleich mitplanen

Die Gruppierung nach Content (also i. d. R. Seiten) in Universal Analytics ist ein super sinnvolles Feature, das leider viel zu selten genutzt wurde. Dabei finden sich sogar in den Dimensionen oft Angaben wie "page_type" o. Ä ., die sich geradezu als Content Grouping anbieten. Da auch GA4 eine Gruppierung nach Content bietet, können die Werte, die für diese Dimension (wenn man sie erhalten will) vorgesehen sind, als Feld "content_group" für das Konfigurations-Tag bei der Implementierung berücksichtigt werden.

Umstellung von Events

Hat man den Seitenaufruf und die Form der Implementierung geklärt und Dimensionen und Metriken in entsprechende Schlüssel für GA4 übersetzt, muss angegangen werden, was den größten Umfang in den meisten Universal Setups ausmacht: Die Events.

Einer der Hauptunterschiede für das Messen von Ereignissen in UA vs. GA4 liegt darin, dass es in GA4 keine mehr oder weniger "gleichberechtigten" Attribute gibt, mit denen das Event zu identifizieren ist. Kategorie, Aktion und Label sind in UA auf die abenteuerlichste Weise mit Daten befüllt und mal ist die Kategorie eher eine Aktion - oder das Label ist das Einzige, das die Events von anderen unterscheidet.

Das muss aufgelöst werden, weil es in GA4 genau ein hervorstechendes Merkmal ist und das ist der Eventname. Sein bestes Pendant ist die "Aktion" eines Universal-Events. Daher übersetzt es der server-side GTM z. B. so, wenn UA Daten in das Event-Modell gepresst werden sollen. Kategorie und Label werden damit zu untergeordneten Informationen, sobald man versucht, seine Events zu konvertieren.

Minimum an Dokumentation

Aufräumen, Part II: Ein neues Tracking ist eine Chance, die man nutzen sollte. An diesem Punkt kann prima hinterfragt werden, ob die derzeit gemessenen Dinge (noch immer) wert- und sinnvoll sind. Sonst kann man sie über Bord werfen. Vielleicht fehlen Messpunkte, die nun im neuen Setup berücksichtigt werden können. Wenn man sich schon die Arbeit macht, warum sollte das Ergebnis nicht besser sein, statt nur "möglichst nah am alten Kram"? Dieser ist meistens ohnehin nicht aus einem Plan entstanden oder wenn doch, dann ist dieser seit Jahren durch laufende Ergänzung des Tag Managers vermutlich längst über den Haufen geworfen worden.

Daher: Nein! Nicht einfach alles so übersetzen, dass die alte Aktion den neuen Eventnamen ergibt und die beiden anderen Attribute landen in den dafür angelegten Dimensionen event_category und event_label. Das ist zwar nicht zu 100% falsch, aber wer das wirklich tun will, um keine Daten zu verlieren, der setzt an der falschen Stelle an. Schon immer sollte eine Aktion in der Lage sein, das Event eindeutig zu identifizieren. Dummerweise heißt es gern "click" und nur die Kategorie sagt, um was für einen Klick es geht und das Label gibt evtl. Aufschluss darüber, was es für ein Ziel gab. In anderen Konstellationen sind die einzelnen Elemente generisch und voneinander abhängig benannt. Im Idealfall wenigstens einheitlich - aber selbst das ist in vielen UA Tracking Setups nicht garantiert. Auf dieser Basis nun mit den gleichen Fehlern an ein GA4 Setup zu gehen, ist der größte Fehler, den man bei einer Umstellung machen kann.

Jedes der neuen GA4 Events braucht also ohnehin einen neuen, vernünftigen und die Aktion eindeutig bezeichnenden Namen. Nicht "click" und in einer Property steht dann irgendwo "phone", sondern lieber "click_to_call" oder Ähnliches. Damit das vernünftig funktioniert, muss eine Bestandsaufnahme der Universal-Ereignisse her.

Unverzichtbar: Eventliste anlegen

Eine Liste kann man auf verschiedene Weise anlegen. Da alle Daten in Google Analytics zu finden sind, kann man sich dort z. B. eine Liste ziehen, in der alle Kategorie-, Aktion- und Label-Kombinationen zu finden sind. Das ist allerdings nur in einem benutzerdefinierten Report möglich, erfordert einen längeren Zeitraum zur Auswertung und ist alles andere als übersichtlich. Der bessere Ort, um eine Liste zu generieren, ist daher i. d. R. der Google Tag Manager, in dem schlussendlich alle Events verbaut sein sollten. Nicht jedes Event-Tag steht dabei unbedingt nur für ein Event, sondern kann für mehrere Ereignisse verwendet werden und dynamische Eigenschaften wie die Aktion beinhalten. E-Commerce-Transport-Events sind hierfür ein gutes Beispiel. Normalerweise ist glücklicherweise bekannt, welche Varianten es gibt - oder man kann diese im GTM aus den generierenden Variablen auslesen (Suchtabellen, JavaScript... ) Somit ist dieser Weg i. d. R. der schnellere, um eine Übersicht zu bekommen, was alles verbaut ist und wie Events an ihre Attribute kommen.

Tool-Tipp: Der Check für GTM Container bei Analytrix ist ein schneller Weg, eine Event-Liste zu erstellen - im Bedarfsfall ohne API Zugriff auf den GTM. Hier im Blog gibt es eine kurze Vorstellung des Tools. Unter anderem werden dort alle UA- und GA4-Event als Liste aufgeführt. Dabei sind neben dem Namen des Tags die wichtigen Merkmale Kategorie, Aktion und Label zu finden.

Ein Beispiel:

Eventliste aus Analytrix mit allen erforderlichen Angaben für eine geplante Umstellung

Kopiert man diese Liste in die Zwischenablage und fügt sie in Excel ein, kann das als Ausgangspunkt dienen, wenn es nicht bereits eine (vollständige, gepflegte und aktuelle) Event-Liste für Universal Analytics gibt. Der Aufzählung kann man für die GA4 Umstellung nun einfach einige weitere Felder hinzufügen und so die Migration in Ruhe planen und Event-Bezeichnungen und Parameter abstimmen. Dazu genügen die folgenden neuen Tabellenspalten:

1. GA4 Event-Name
2. GA4 Event Parameter
3. GA4 User Properties

Das Ziel dieser Liste ist es, am Ende alle relevanten Events bestimmt und die neuen Spalten mit konsistenten Angaben versehen zu haben, um daraus das Tracking im Tag Manager aufzubauen. Je nach Komplexität des Setups kann diese Liste natürlich länger ausfallen als in diesem Beispiel, der Prozess bleibt trotzdem der Gleiche. Nach dem Erstellen des Überblicks folgt im nächsten Schritt ein Abgleich mit a) bereits ggf. implementierten GA4 Events und b) den neuen Möglichkeiten des der automatischen Ereignis-Messung.

Wohin mit Kategorie, Label und Value?

Wie immer lautet die Antwort: "it depends". Das obige Beispiel zeigt schon, dass man nicht einfach alles als "event_category" und "event_label" etc. in das neue GA4 Event übernehmen sollte. In der Realität stehen in den Kategorien und Labels oft sehr unterschiedliche Dinge. Daher sollte man für jedes Event nur die Eigenschaften definieren, die erforderlich sind und sie passend benennen, statt überall generisch ein "Label" zu haben, das sehr unterschiedliche Verwendung findet. Zudem ist es üblich gewesen, das Label als Parkplatz für den Seitenpfad oder die URL zu nutzen. Da diese Informationen zum Standardumfang aller Ereignisse gehören (das war bei UA eigentlich nicht anders), braucht man deren Migration nicht vorzusehen. Daher kann man die meisten dieser Angaben aus UA Events entweder verwerfen oder unter einem weniger generischen Namen in das neue Event-Modell einplanen.

Abgleich mit bestehenden und automatischen Events

Es mag sein, dass bereits einige GA4 Events schon im Setup vorhanden sind. Diese sind in der Liste als erstes entsprechend zu berücksichtigen - und ggf. den nun erstmals bewusst gewählten Regeln zur Gestaltung des Eventamens zu unterwerfen. Oft gibt es Doubletten zu den bestehenden Universal Events. Der GTM Check in Analytrix bietet auch für GA4 eine passende Übersicht. Hier ein (leider) typisches Beispiel:

Gutes Beispiel für schlechte schon implementierte GA4-Events. Trotzdem hilfreich bei der Planung

Diese GA4-Events sind genau das, was bei einem ungeplanten Umstieg entsteht. Probleme:

• Die Eventnamen sind zum Teil vollkommen nutzlos ohne die übrigen Angaben, die platt aus den Universal Events übernommen wurden. "Set" ist  das beste Beispiel.
• Es werden Klick-URLs, Domains oder externe URLs mit sehr vielen möglichen Werten ("hohe Kardinalität") im Event-Namen verwendet. Das verdirbt jede Auswertung, wenn man nicht wieder auf die Eigenschaften zugreift, die die eigentliche Aktion beinhalten oder verständlich machen
• Angaben, die aus Dimensionen übernommen wurden, sind mit uneinheitlichen Werten belegt ("user_type")
• Eigenschaften, die auf Event-Ebene definiert werden, sind aus nicht nachvollziehbaren Gründen nicht immer belegt. Wenn es einen "service_type" gibt, warum fehlt er bei manchen Events?
• Werte-Benennung: Klartext statt Schlüssel machen Daten lesbarer. Wenn möglich also jetzt die Chance nutzen, dies zu korrigieren
• Unnötige Events werden manuell (und schlecht) vermessen, während es ein Auto-Event von GA4 ebenso gut tun würde. Das bedeutet nicht, dass die Auto-Events immer die bessere Lösung sind, aber wenn man diese selbst verwalten will, sollten sie sauber konfiguriert werden. Anderenfalls schmeißt man sie aus der Liste und dem bestehenden Setup

Empfohlene und automatische Events

Bei allen anderen Events sollte bedacht werden, dass es für viele Dinge in GA4 bereits vorgesehene Events mit empfohlenen Namen und Parametern gibt. Daher ist es klug, bei der "Konvertierung" von UA Events zu GA4 darauf zu achten, diese ggf. so anzupassen, dass sie in das GA4 Schema passen. Auch sind einige Standard-Eigenschaften wie die page_location und andere immer vorhanden und müssen nicht manuell belegt werden (wenn diese nicht abweichend definiert werden sollen).

Eine Liste der von Google empfohlenen Events nach Kategorien findet sich in der Hilfe. Entscheidet man sich dazu, alle externen Links und Downloads von GA4 automatisch sammeln zu lassen, kann man das Event bei der Implementierung also ganz übergehen (sollte es aber auf der Event-Liste erst einmal lassen). Bei manueller Implementierung (z. B. deshalb, weil nicht alle Downloads relevant sind, sondern nur bestimmte) kann und sollte man sich wiederum an die Event-Eigenschaften halten, die im GA4-Modell vorgesehen sind und das Rad nicht neu erfinden.

Events in GA4 selbst erstellen

Nicht alles muss unbedingt an GA4 gesendet werden, um dort (auch) als separates Ereignis oder gar Conversion gezählt werden zu können. Wo z. B. im GTM der Trigger für ein Event allein auf Seitenaufrufen bestimmter Pfade basiert, kann man sich das Senden an GA4 komplett sparen und auf Basis des Pfades ein neues Event in GA4 erstellen. Diese sehr nützliche Funktion ist viel zu schade, um sie nur für "Ereignis-Kosmetik" einzusetzen.

Sonderfall E-Commerce

In Universal Analytics hat das E-Commerce Tracking eine besondere Rolle und eigene Historie. Wer in UA noch eine klassische Transaktion sendet, muss ein Pandant für ein purchase Event für GA4 einplanen. Nutzer des erweiterten E-Commerce in UA haben entweder bisher fahrlässiger Weise alle E-Commerce Nutzlasten den Pageviews (und unkontrolliert allen anderen Events) überlassen oder Transport-Events für die E-Commerce Ereignisse vorgesehen. Diese sind gern zusammengefasst, so dass es im GTM möglicherweise nur ein oder zwei Tags für E-Commerce verantwortlich sind, mit denen zahlreiche Events behandelt werden.

In GA4  ist in der Liste (und in der Umsetzung) i. d. R. für jedes E-Commerce-Ereignis ein eigenes Tag vorzusehen. Das muss nicht immer so sein, aber selbst wenn die Implementierung am Ende sparsamer ausfallen sollte, ist zumindest bei der Planung für jedes Event eine eigene Zeile vorzusehen. Hierbei übrigens weitere Event-Properties anzugeben, die nicht zum Standard-Schema gehören, ist weder verboten noch schädlich. Sie können zumindest in BigQuery verwendet werden. Als Mindestumfang für Properties ist sinnvoll, was Google Analytics 4 im E-Commerce-Schema vorsieht. Was nicht bedeutet, dass alles gemessen werden muss, was angeboten wird. Wie bei Universal gilt auch bei GA4: Wer nichts mit Daten zu Promotions oder Impressions und Klicks in Listen anfangen kann, um die Website wirklich zu verändern und verbessern, benötigt in GA4 diese Ereignisse (vorläufig) nicht. Von der Transaktion rückwärts das zu implementieren, was man nutzen kann, bleibt daher eine gute Daumenregel.

Welches Format für E-Commerce?

Die Frage nach dem "richtigen" Format für Produkt- und E-Commerce-Informationen beantwortet sich normalerweise aus der Praxis. Man hat, was man hat. Das ist üblicherweise (noch) UA Format. Hieraus eine für die GA4 Tags passende Struktur zu erstellen, ist im GTM kein Hexenwerk. Wer bei Variablen in der Community Gallery nach "GA4" sucht, findet eine gute Auswahl von Konvertern. Wer kann, aktiviert ggf. zwei Versionen der E-Commerce-Ereignisse in der Datenschicht. Woocommerce und das GTM Plugin ist eine typische Kombination, die dies leistet. Solange sich beide dataLayer nicht in die Quere kommen, kann das so bleiben. Ab dem Entfall von UA Tracking muss mittelfristig ohnehin das UA Format irgendwann dem GA4 Format weichen.

Trigger anpassen: Wenn die Events im GTM implementiert werden, muss man beim E-Commerce (anders als bei anderen migrierten UA Events) daran denken, dass vermutlich nicht die gleichen Trigger verwendet werden können. Speziell da, wo UA und GA4-Formate parallel in den dataLayer geschrieben werden (viele Shops nutzen dies in der "Parallelphase"), sind i. d. R. an den GA4-Eventnamen orientierte dataLayer Events zu finden, die als Trigger verwendet werden können.

Übersetzen von Werten

Es kann sein, dass man nicht die volle Kontrolle darüber hat, was vorher als Event-Aktion, Kategorie etc. verwendet wurde. In solchen Fällen ist es erforderlich, die Generierung dieser Werte zu kontrollieren und z. B. alle Variablen, die derzeit anhand von Trigger-Bedingungen oder dem Zustand im dataLayer bestimmen, welche Event-Aktion z. B. verwendet werden soll, für GA4 anzupassen. Entweder als Kopie, die dann für GA4 Tags genutzt wird - oder man stellt diese auch für Universal um und gewöhnt sich schonmal an die neue Nomenklatur. Was allerdings nur dann möglich ist, wenn dann kein Regelwerk im nachgelagerten Reporting zusammenbricht, weil bestimmte Bezeichnungen dort erwartet werden. Ebenso müssen Ziele in UA in diesem Fall evtl. angepasst werden.

Haarig wird es dort, wo die Werte für Eventeigenschaften entweder aus dem dataLayer stammen oder gar aus Dingen wie der ID des geklickten Links o. Ä. bestehen. Solange diese Werte nicht den Eventnamen in GA4 bestimmen, sondern nur selbst gewählte Parameter mit Werten beschicken, ist die Welt nicht untergegangen und man muss bestenfalls damit leben, dass es Inkonsistenzen in den Daten gibt, was die Sprache oder das Format angeht. Das ist meistens kein neues Problem; nun aber ist es schlichtweg zu lösen. Dazu kann es notwendig sein, zumindest für die wichtigsten Werte eine Suchtabelle im GTM dazwischen zu schalten. Daten aus dem dataLayer könnten evtl. in einem neuen Format (also unabhängig von bestehenden Schlüsseln, die schon  für Universal oder andere Dienste im Einsatz sind) von der Anwendung explizit für GA4 bereitgestellt werden.

Liste fertigstellen und umsetzen

Hat man sich durch die obigen Schritte gearbeitet, gibt es eine fertige Liste aller Events, die aus dem Universal-Setup übernommen werden müssen. Da alle Dimensionen (Bezeichnungen und Herkunft der Werte) zumindest in der Wunschvorstellung nun steht und die Liste ggf. noch mit bisher fehlenden Events ergänzt wurde, kann damit das Tagging im GTM aufgebaut werden. Im schlimmsten Fall also eine Menge Fleißarbeit, die man bei Bedarf in mehrere Phasen aufteilen kann, die einzeln veröffentlicht und kontrolliert werden. Noch ist zum Glück Zeit dazu.

Es empfiehlt sich ohnehin, bei größeren Setups mit mehreren Duzend unterschiedlicher Events, die Implementierung nicht auf einen Schlag zu veröffentlichen. Zu schnell wird ein schwierig zu testendes Event wie der Kaufabschluss in einem Shop sonst nicht ausreichend getestet. Oder der Kaufabschluss bekommt als zentrales Ereignis alle Aufmerksamkeit und erst nach Monaten fällt auf, dass die Vermessung der Wunschliste oder des Newsletters gar nicht funktioniert. Passiert immer und überall - selbst ohne (selbst auferlegten) Termindruck. Also lieber kleine Schritte einplanen, viel testen und oft veröffentlichen. Gerade beim Testing ist die Debug-Ansicht von GA4 eine sehr hilfreiche Ergänzung zur GTM Vorschau, denn so kann man nicht nur sehen, was den Browser verlässt, sondern auch das, was in GA4 davon ankommt.

Better Done Than Perfect?

Mit diesem Prozess hat man vermutlich nicht das beste Setup, das man bekommen kann. Aber es ist zumindest eine geplante und dokumentierte Implementierung. Früh genug gestartet, kann man Fehler und Lücken noch rechtzeitig erkennen und behandeln, bevor in Universal Analytics keine neuen Daten mehr ankommen. Und selbst wenn der laute Ruf nach Migration von Daten aus UA zu GA4 vielleicht noch erhört wird: Es sind Daten aus einem anderen Tool mit einem anderen Event-Modell und Tracking Konzept. Ich denke daher, dass direkt in GA4 gesammelte Daten besser sein werden für einen Vergleich, selbst wenn sie noch nicht perfekt sein mögen. Daher gilt diesmal ausnahmsweise, dass Datenqualität ein nachgelagerter Prozess sein darf. Es wird durch die unvermeidliche laufende Evolution von GA4 vermutlich ohnehin nicht anders gehen.

Auch bei GA4 steckt ein guter Teil der Datenqualität in einem sorgfältigen Setup der Property und des Datenstroms. Verweisausschlüsse, Dimensionen etc. wollen konfiguriert werden. Gerade hier wird außerdem mit mehr Filtern und neuen Optionen noch einiges passieren. Ist GA4 daher erstmals aufgesetzt und aktiv, kann und sollte ein regelmäßiges "Review" der ggf. hinzugekommenen Möglichkeiten im eigenen Kalender geplant werden.

Nebenbemerkung: Consent Mode nutzen? Nein

Hat man bisher den Consent Mode in Universal Analytics vermieden und sich ohnehin über die ganze zusätzliche Komplexität geärgert, die Consent Management in das Spiel gebracht hat, ist vielleicht versucht, den Consent Mode nun zu aktivieren. Schließlich predigt Google bei jeder Gelegenheit die Vorzüge und der Name suggeriert, dass er dem Datenschutz dienlich ist. Ohne diesen Nebenstrang zu umfangreich werden zu lassen: Diesem Drang sollte man unbedingt widerstehen, wenn man den schönen Datenschutz-Mantel, den man sich mit einem Consent Tool übergeworfen hat, in des Kaisers neue Kleider verwandeln will. Es wird fast alles gesammelt und zustimmungsfrei an Analytics gesendet, was auch bei Zustimmung stattfindet. Bis auf die Lebensdauer einer Client ID, die ohne Cookies bei jedem Neuladen einer Seite entsteht. Und man bekommt dafür (außer inzwischen in BigQuery) nicht nur keine Daten, sondern hat zudem keine Kontrolle darüber, was damit sonst noch passiert. Schlimmer noch: Man kann dem Wunsch nach Datenlöschung für einen Besuch nicht nachgehen, wenn dabei x verschiedene Sitzungen unterschiedlicher zufälliger Client IDs entstehen, die man in GA4 selbst nicht sehen kann und dessen Spuren in BigQuery ebenfalls keine Referenzen auf diese Client IDs enthalten (weil das ja nicht gewünscht war). Gesamt betrachtet handelt man sich mit dem Consent Mode also nur potentielle Probleme ein, ohne etwas Sinnvolles zu bekommen. Modellierte Conversions sind mir da zu wenig, selbst als Marketing-Mensch. Change my mind.

The Time is Now!

Mit dem feststehenden Ablaufdatum der Sammlung von Daten in Universal Analytics hat GA4 Tagging unzweifelhaft einen größeren Stellenwert bekommen. Ob man vielleicht doch noch eine Migration von Altdaten in das neue GA bekommt, bleibt aktuell offen... Genauso wie einige andere und im Einzelfall sehr wesentliche Features, die noch fehlen. Es hilft aber nichts, darauf zu warten, bis GA4 alles kann, was man sich wünscht. Entweder startet man a) jetzt mit dem, was da ist und hat einen Plan B für alles Wesentliche, was derzeit in GA4 noch fehlen mag (dafür gibt es reichlich Lösungsmöglichkeiten), wenn es am Todestag von UA noch nicht da ist - oder es ist b) Zeit für die Auswahl eines neuen Tools. Beides erfordert eine Lösung, mit deren Umsetzung man nicht mehr lange warten sollte.

Selbst das Durchsetzen einer einheitlichen Struktur bei Event-Namen in GA4 kann zu einer größeren Herausforderung werden, als man anfangs angenommen hat. Daher ist es so wichtig, damit heute zu starten. Spätestens morgen.

Wer bei der Vorbereitung einer Umstellung nach dem obigen Vorbild Hilfe benötigt oder Unterstützung bei der Umsetzung im Tag Manager wünscht, kann sich gern bei mir melden. Ich habe inzwischen schon einige Umstellungen hinter mir... Und es werden sicher in den kommenden Monaten noch einige folgen. Folgerichtig wird diese "Anleitung" nicht der letzte Stand oder gar einzige Weg sein. Sie hat hoffentlich trotzdem ausgereicht, um einen Startschuss zu geben. Oder wenigstens zu planen 😉