Markus Baersch

Da in GA4 “alles ein Event” ist, erscheint die Implementierung zunächst einmal einfacher: Weniger Tag-Typen, jedes Ereignis ist gleichwertig und in Reports gemeinsam mit Seitenaufruf-Ereignissen verfügbar. Automatische Events und Enhanced Measurement erlauben zudem die Messung weiterer typischer Dinge, für die vormals separates Tagging erforderlich war. Wer bestimmte Events anhand von Eigenschaften dazu nutzen möchte, weitere Ereignisse und Conversions anzulegen, hat in GA4 dazu alle Mittel zur Hand. Warum also überhaupt mit dem Google Tag Manager arbeiten, wenn es auch so zu gehen scheint? Dieser Beitrag wirft einen Blick auf die Möglichkeiten und Unterschiede beider Optionen zur Generierung eines GA4 Event-Setups.

Events im Google Tag Manager auslösen

Üblicherweise existiert bereits ein Google Tag Manager, der auf der Website eingebunden ist und das aktuelle Tracking steuert. In Verbindung mit einem Consent Manager zum Beispiel. Daher ist er der beste Weg, um - egal für welche Setup-Variante - den “Basiscode” auszuspielen, der in Form eines GA4-Konfigurations-Tags eingebunden wird. Er kann wahlweise die Vermessung von Seitenaufrufen übernehmen... oder man erstellt ein GA4-Ereignis-Tag für den page_view genauso wie man es für andere Ereignisse kann.

Alle Ereignis-Tags nutzen das als Referenz dort hinterlegte Konfigurations-Tag für Dinge wie die Measurement-Id des Datenstreams und übernehmen dort bereits gesetzte Ereignis-Parameter und User-Eigenschaften. Hier ein Beispiel zur Vermessung eines Klicks auf eine Mailadresse mit einer Benutzerdefinierten Eigenschaft zur Unterscheidung verschiedener Ereignisse mit dem Namen initiate_lead.

Tipp: Wer mehr Details zum GA4 Setup via GTM wünscht: Dieses Beispiel wird - wie ebenso die Ereignisse der folgenden Abschnitte - auch in einem Video demonstriert, das diesen Blog-Beitrag begleitet.

Durch die Bestimmung eines passenden Ereignis-Namens und individueller Parameter werden so z. B. E-Commerce-Events vermessen oder die Generierung von Leads nach dem Absenden von Formularen, wichtige (interne oder externe) Klick-Ereignisse und alles andere, was ein Event-Plan üblicherweise beinhaltet.

Ob dabei jedes Ereignis über ein separates Tag vermessen wird oder der Name und bestimmte Eigenschaften anhand von Variablen, dem Trigger, dataLayer o. A. bestimmt wird, ist bei GA4 genauso flexibel im Tag Manager zu handhaben, wie es auch für alle anderen Trackingdienste oder Webanalyse-Systeme funktioniert.

Im GTM sind der Name des Events und Umfang und Inhalt der Eigenschaften selbst zu gestalten, solange dies mit dem eigenen Plan in Einklang zu bringen ist. Es wäre trotzdem gleichwertig, wenn ein auf diese Weise manuell gesendetes click Ereignis gesendet und die gleichen Parameter genutzt würden, die das automatische Ereignis haben würde. Automatisch? Ja, denn: Bei GA4 kann man sich vom “Enhanced Measurement” unterstützen lassen, wenn gewünscht.

GA4: Enhanced Measurement

Anders als sein Vorgänger vermisst GA4 nach der Implementierung des Tracking-Codes (also z. B. dem Konfigurations-Tag im GTM) eine ganze Menge weiterer Dinge optional und per Vorgabe aktiv:

• Historieänderungen in Single Page Applications
• Klicks auf externe Links
• Downloads
• Suchvorgänge
• Interaktion mit Formularen und Videos
• Scrolling (einmalig bei 90%)

All diese Dinge kann man sich also theoretisch im Tag Manager sparen und hier einfach per Knopfdruck ein- oder ausschalten. Dazu dient der Konfigurations-Bereich des Datenstreams - hier findet sich das Enhanced Measurement bzw. Funktionen für “Optimierte Analysen”, wie es in der Deutschen Übersetzung heißt.

Solange man mit den üblicherweise recht umfangreichen Events zurechtkommt und keine anderen Dienste wie Facebook die gleichen Ereignisse als Messpunkt bekommen sollen und daher ohnehin im Tag Manager mit einem Trigger versehen sind, spricht wenig dagegen. Vielleicht abgesehen vom Scroll-Tracking, das idealerweise (wenn überhaupt) nur gezielt bei bestimmten Content-Gruppen aktiv ist. Oder lieber durch die Messung von Sichtbarkeit des Hauptinhalts ersetzt wird. Ebenso kann es aus technischen Gründen besser sein, auf die automatische Vermessung zu verzichten, weil z. B. die Website oder deren Navigation auf Formularen basiert und somit eine Menge an vollkommen nutzlosen Events entsteht.

Damit lässt sich allerdings keine Conversion einrichten, die gezielt nur dann ausgelöst wird, wenn ein bestimmtes Formular abgesendet oder Seite aufgerufen wurde. Conversions werden auf Ereignisebene markiert und erfordern daher ggf. separate Events.

Genau dazu bietet GA4 eine Alternative zur Einrichtung solcher Ereignisse über den Google Tag Manager an: Die Generierung von Events auf Basis anderer Ereignisse, die bereits als Seitenaufruf oder durch die “Optimierten Analysen” des Enhanced Measurement erfasst werden.

Ereignisse erstellen

Die erste der beiden Optionen ist die Erstellung eines neuen, zusätzlichen Ereignisses, wann immer ein bereits gemessenes Event mit bestimmten Eigenschaften auftritt.

Als Beispiel dient hier ein als separater Messpunkt gewünschtes Ereignis namens phone_click. Dieses soll immer dann ausgelöst werden, wenn eine Telefonnummer auf der Website angeklickt wird. Die Generierung geschieht auf Basis aller click-Ereignisse, die durch die Vermessung aller “externer” Links entstehen. Denn auch ein Link, dessen Ziel-Adresse mit ”tel:” beginnt, gilt als “Outbound” Link im Sinne des Enhanced Measurement und wird davon erfasst.

Wenn auf einen solchen Link geklickt wird, sendet gtag.js (der für das GA4 Tagging verantwortliche Tracking Code) ein Ereignis an GA4, das man in der Netzwerkansicht der Konsole des Browsers, diversen Plugins, dem Tag Assistant beim Einsatz der GTM Vorschau oder im DebugView im GA4 zuschauen kann. Dabei sind alle Parameter zu sehen, welche u. a. auch die angeklickte URL enthalten (eine Liste findet sich in der Tabelle aller Ereignisse in der Hilfe zum Enhanced Measurement). Hier ist es die link_url, in der der angeklickte Link zu finden ist:

Soll hieraus nun ein weiteres Ereignis erstellt werden, das einen anderen Namen (phone_click) hat, kann dies unter Konfigurieren - Ereignisse - Ereignis erstellen durch Neuanlage eines Eintrags definiert werden.

Die Bedingung dieses Beispiels besagt, dass bei jedem Event mit dem Namen “click” und einer link_url, die mit ”tel:” beginnt, ein neues Ereignis phone_click erzeugt werden soll. Optional kann hierbei gleichzeitig eine Anpassung der Parameter erfolgen. Diese Möglichkeit wird hier genutzt, um die eigentliche link_url zu ersetzen (hier gegen die CSS-Klasse des Links) und so die angeklickte Telefonnummer aus den GA4 Daten zu halten. Das kann sinnvoll sein, wenn es sich um persönliche Daten handeln kann, da z. B. auf einer Team- oder Kontakt-Seite Durchwahlen zu finden sind.

Ereignisse bearbeiten

Auf eine ähnliche Weise können eingehende Ereignisse auch direkt verändert werden, ohne dass ein zusätzliches Event entsteht. Aus einem click Ereignis für eine E-Mail-Adresse kann so z. B. ersatzweise ein ganz anderes Event mit einem neuen Namen generiert werden; hier mail_click.

Die Konfiguration ist ähnlich wie beim vorherigen Fall, nur wird nach Speichern und Auslösen eines Klicks auf eine Mailadresse kein weiteres Event parallel zum click Ereignis gesendet, sondern das click Ereignis selbst wird verändert.

Hier gehört auch der Name zur Anpassung… muss es aber nicht. Es mag reichen, wenn man dem bestehenden click Ereignis einen neuen Parameter hinzufügt, anhand dessen er in Auswertungen identifiziert wird. Wenn das Klicken eines Mail-Links allerdings als Conversion markiert werden soll, ist ein abweichender Ereignisname erforderlich, denn sonst müssten alle click Events zur Conversion erhoben werden und das ist selten sinnvoll.

Dieses Beispiel verändert die link_url, um keine Mailadressen an GA4 zu senden. Dazu kann einfach ein leerer Wert oder - wie hier - eine Konstante angegeben werden. Selbst wenn also kein eigenes Event aus solchen Klicks generiert werden soll, kann eine Anpassung im Sinne der “Parameter-Datenschutz-Redaktion” sinnvoll sein. Da es sonst keine Möglichkeiten zur Filterung in GA4 gibt, ist dies bei Nutzung des Enhanced Measurements oft die einzige Option zum “Sauberhalten” von Daten. Oder eben der Verzicht und die Nutzung des GTM mit voller Kontrolle über die mit Ereignissen versendeten Eigenschaften und Parameter.

Mit der obigen Veränderung sieht man im DebugView, dass statt des vorher dort zu sehenden click Events bei einem Klick auf eine Mailadresse nun das neue Ereignis erscheint - mit den angepassten Ereignis-Parametern.

Wichtig: Eine solche Anpassung im Setup von GA4 wird direkt aktiv, sobald die Änderung gespeichert wird. Anders als beim Tag Manager gibt es also kein “Ausprobieren” im Sinne einer Vorschau und kontrollierter Veröffentlichung. Wer dem Speichern die eigene Seite neu lädt und dabei das gtag.js Tracking-Script neu in den Browser lädt, bekommt die aktuelle individuelle Fassung, die alle angelegten Veränderungen an bestehenden Events oder durch diese generierte neue Ereignisse enthält. So wie hier zu den beiden Anpassungen für phone_click und mail_click:

Das gilt übrigens auch für andere Einstellungen wie denen zu Conversions, Verweisausschlüssen u. a. Jedes gtag.js ist individuell und enthält alle Einstellungen, die der Browser zur Bedienung des zugehörigen GA4 Datenstroms benötigt.

Vor- und Nachteile

Jede der Optionen führt zum Ziel: Unter bestimmten Bedingungen soll ein individuelles Event ausgelöst werden, das zur Messung von besonderen Aktionen dienen soll. Also einzelne Ereignisse aus der Masse an Klicks oder Seitenaufrufen als Besonderheit hervorholen und / oder als Conversion-Event bzw. Schritt in einer Pfad- bzw. Trichteranalyse nutzbar machen. Somit ist jeder der Wege eine valide Option für ein zielgerichtetes Tracking Setup. Mit ein paar Besonderheiten, die beachtet werden sollten:

GTM Setup

Der Tag Manager erlaubt die größte Flexibilität, wenn er der alleinige Lieferant von Ereignissen ist. Sowohl was den Umfang der Ereignisse als auch deren Parameter angeht. Unter kompletten Verzicht auf Enhanced Measurement und mit Hilfe zielgerichteter Trigger, die nur dann feuern, wenn das jeweilige Ereignis wirklich “messenswert” ist, bleibt so die volle Kontrolle (und Verantwortung) im Tag Manager.

Als “Hürde” bleibt zu nennen, dass eine Implementierung des Tag Managers in manchen Fällen komplizierter ist, als der Einbau eines GA4 (gtag.js) Trackingcodes. Soll er zudem nur deshalb eingesetzt werden, um danach ein GA4 Konfigurations-Tag und ein paar vereinzelte Events nachzuladen und zu verwalten, ist der dadurch entstehende Overhead natürlich in Frage zu stellen. Davon abgesehen überwiegen i. d. R. die Vorteile und man sollte diese Form der Implementierung stets bevorzugen.

Nur selten ist zudem ein “GA4 Solo-Setup” in einem Tag Manager zu finden, sondern es werden auch andere Tags ausgespielt, die dann auf die gleiche Weise kontrolliert genutzt werden können. Spätestens in Anwendungsfällen, wo etwas vermessen werden soll, das nicht vom Enhanced Measurement abgedeckt wird, ist der Verzicht auf den GTM zudem schwierig. Natürlich kann jedes andere nachgeladene oder auf einer Seite direkt vorhandene JavaScript genauso gut direktes Tracking durchführen, wie Ereignisse in den dataLayer zu schreiben, dennoch sind komplexere Auslöser wie z. B. Trigger-Gruppen oder auf Element-Sichtbarkeit basierende Ereignisse mit dem GTM deutlich einfacher umzusetzen als ohne.

GA4 Setup (+ Enhanced Measurement)

Davon ausgehend, dass nicht alle Ereignisse, die auf einer Website relevant und wichtig sind, allein auf Basis von Seiten-URLs oder Titeln zu bestimmen sind, ist ein gewisser Umfang aktiver Enhanced Measurement Optionen üblicherweise sowohl vorauszusetzen als auch sinnvoll.

So schön die Generierung auf Basis von bestehenden Ereignissen klingt, so groß ist die Gefahr, nur einen Bruchteil der erhobenen Daten zu nutzen. Eine Gefahr steckt zudem in Änderungen, denn anders als im GTM ist es bei Event-Anpassungen in GA4 deutlich schwieriger, sich über evtl. Änderungen im Verlauf der Zeit zu informieren.

Auf der anderen Seite werden ggf. wesentliche Ereignisse vom Enhanced Measurement nicht abgedeckt, sondern erfordern eine Implementierung in Abstimmung mit dem dataLayer einer Website oder die Berücksichtigung von Rahmenbedingungen im Browser, die zur Laufzeit im GTM problemlos ausgewertet werden können, aber bei der Modellierung / Veränderung von Events in GA4 nicht (mehr) zur Verfügung stehen.

Sendet man zudem alle (“externen”) Klicks an GA4, nur um aus einem kleinen Teil Conversions oder relevante Messpunkte zu extrahieren, kann man den Rest an Daten eigentlich nur in der Analyse ignorieren - oder mit den Mitteln der o. A. Anpassung dafür sorgen, dass diese z. B. in einen Filter für internen Traffic fallen oder ähnliche Scherze. Es bleibt aber in jedem Fall so, dass die Hits im Browser generiert und an GA4 gesendet werden müssen… möglicherweise zum größten Teil ohne konkreten Nutzen. Das gilt natürlich nicht nur für Klicks oder Formularinteraktionen,  aber besonders hier. Denn zusätzlich zu echten externen Klicks kann eine ganze Menge an Schrott anfallen, wenn die Site Gebrauch von Links macht, die keine echten internen oder externen URLs als Ziel haben, sondern Funktionen aufrufen. Ein (konstruiertes) Beispiel:

Ein solches Event richtet kaum Schaden an, wenn es vereinzelt auftritt und “mit gemessen” wird. Passiert dies stets, wann immer ein interner Link angeklickt oder ein Filter in einer Liste verwendet wird, ist die manuelle Vermessung der wichtigen Klicks im Tag Manager die bessere Option.

Mischbetrieb

Eine gemischte Nutzung von Google Tag Manager zur Definition von Ereignissen, gepaart mit ausgesuchten Enhanced Measurement Optionen, ist eine gebräuchliche Variante. Beide Methoden haben - wie gezeigt - Vor- und Nachteile. Wenn nicht das CMS bzw. dessen Möglichkeiten die Auswahl der Mittel nicht zu sehr einschränkt, ist der Mischbetrieb aus GTM und Enhanced Measurement eine gute Option. Zumindest solange es um die Implementierung von Tracking geht.

Mit Vorsicht zu genießen ist allerdings die Vermischung von individuellen Ereignissen, die mal aus dem Tag Manager gesendet und mal mit den Setup-Mitteln von GA4 durch Anpassung oder Generierung von Events erzeugt werden. Zu schnell werden sonst bei Problemen vermeidbare Stunden damit verschwendet, die Ursache für Probleme an der falschen Stelle zu suchen. Gerade dort, wo unterschiedliche Personen die Pflege von GA4 Setup und Tag Manager verantworten oder nur ein Teil der Konfiguration mit einem Zugang erreicht werden kann, sind Verwirrung und Frust vorprogrammiert, wenn ein Setup alt genug werden konnte oder Zuständigkeiten wechseln. Wenn es nicht zu vermeiden ist, muss daher in einem wirklich aktuellen Eventplan hinterlegt sein, auf welche Weise ein Ereignis implementiert wurde.

Zusammenfassung und Empfehlung

Das Event-Setup via GTM erfordert die meiste Konfigurationsarbeit, wenn “unnötige” Events vermieden werden sollen und berücksichtigt / ermöglicht die kontrollierte Nutzung von mehr als nur GA4. Es ist daher vor allem dort, wo ohnehin ein GTM vorhanden ist, die beste Option und erlaubt den gezielten Einsatz von ausgewählten Enhanced Measurement Features für GA4 genauso wie die Steuerung anderer Tags mit vergleichbaren oder sogar den gleichen Triggern.

Kommen in GA4 erstellte oder angepasste Ereignisse hinzu, muss abgewogen werden, ob der Tag Manager dann ausschließlich zum Ausspielen des Konfigurations-Tags genutzt wird, um die volle Kontrolle über die Ereignis-Generierung an zentraler Stelle im GA4 Setup zu halten oder ob die potenziellen Nachteile eines Mischbetriebs (s. o.) so unwesentlich sind, dass ausgewählte Events aus dem Tag Manager stammen und andere durch Generierung erzeugt werden.

Egal welche Konfiguration gewählt wird: Da die im GA4 Setup erstellten Events ebenso wie diejenigen aus dem Google Tag Manager im Browser generiert und an GA4 gesendet werden, ist der technische Unterschied sehr gering. In beiden Fällen wird per JavaScript dafür gesorgt, dass das Tracking-Script die Ereignisse unter bestimmten Bedingungen im Browser erzeugt und versendet.

Viel wichtiger ist, dass alle Ereignisse, die in GA4 vermessen werden, in einem Eventplan zu finden sind und sie alle das Potenzial haben, zur Optimierung der vermessenen Website beizutragen.