GA4-Konfigurationstag in GTM

2. April 2022• Webtracking

In diesem Beitrag geht es um das GA4-Konfigurationstag im Google Tag Manager:

Bei der Implementierung von Google Analytics 4 mit dem Google Tag Manager fällt schnell auf, dass man bei der Tag-Konfiguration zwischen zwei möglichen GA4-Tags wählen kann:

Während man mit “Google Analytics: GA4-Ereignis” einzelne Events an Google Analytics 4 schicken kann, dient das “Google Analytics: GA-Konfiguration” dazu den Tracker zu konfigurieren. Das Konfigurationstag ist für verschiedene Aufgaben zuständig:

Das Global Site Tag (gtag.js) wird angefragt und zur Seite hinzugefügt
Erstellen des Trackers und Konfiguration der wichtigsten Einstellungen
Laden und anwenden aller Einstellungen aus der GA4-Property
Es kann mit dem Laden des Konfigurationstags auch gleichzeitig ein Pageview-Event gesendet werden
Zudem können Event-Parameter hinzugefügt werden, die für alle Events, die nach dem Config-Tag laden, gelten sollen
Nutzereigenschaften (User Properties) können ebenfalls beim Konfig-Tag definiert werden

Das GA4-Konfig-Tag hat “nur” ein Pflichtfeld, um die Kernfunktionalitäten ausführen zu können – die Mess-ID:

Diese bekommt man in den Datastream-Einstellungen innerhalb der GA4-Benutzeroberfläche:

Ist die Mess-ID in das dazugehörige Feld angegeben und der GTM-Container veröffentlicht, dann wird zunächst folgendes Skript ausgeführt:

<script type="text/javascript" async src="https://www.googletagmanager.com/gtag/js?id=G-BLKKP3RJVD&l=dataLayer&cx=c"></script>

Dadurch wird ein entsprechender Request erzeugt:

Der GA4-Container wird über diesen Request bereitgestellt. Auffällig ist hier vor allem, dass sich der Request von der nativen GA4-Implementierung – also die Implementierung von GA4 mittels gtag.js direkt auf der Website – etwas unterscheidet. Hier der Unterschied:

// Request über Google Tag Manager https://www.googletagmanager.com/gtag/js?id=G-BLKKP3RJVD&l=dataLayer&cx=c // Direkte Implementierung von gtag.js https://www.googletagmanager.com/gtag/js?id=G-BLKKP3RJVD

Die Implementierung mittels Google Tag Manager hat zur Folge, dass weitere Parameter angehängt werden. Vor allem “l=dataLayer” ist hier relevant. Dieser sorgt dafür, dass der GA4-Container im google_tag_manager-Objekt abgelegt wird:

Dadurch fällt folgender Skript-Teil der direkten gtag.js-Implementierung weg:

<script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'MEASUREMENT_ID'); </script>

Entsprechend ist auch die gtag-Funktion im window-Objekt nicht verfügbar:

Die gtag-Kommandos fallen hier ebenfalls weg bzw. wird jetzt alles vom GA4-Konfigurationstag des Google Tag Managers übernommen. Das Tag übernimmt somit in einer gewissen Weise folgenden Kommando-Aufruf:

gtag('config', 'MEASUREMENT_ID');

Die Mess-ID wird über das entsprechende Feld im GA4-Tag gesetzt und nicht mehr über das config-Kommando. Auch werden damit Events nicht mehr wie folgt an GA gesendet:

gtag('event', 'login', { 'method': 'Google' });

Events müssen stattdessen in den dataLayer gepusht werden. Im GTM werden dann die zu sendenden Events konfiguriert.

Gut zu wissen
Die gtag-Funktion macht eigentlich das gleiche wie dataLayer.push. gtag würde man bei einer direkten Implementierung nutzen, um Events zu schicken. dataLayer.push wird mit dem GTM genutzt.

Dadurch, dass der GA4-Container im google_tag_manager-Objekt abgelegt wird, ist der Container auch über den Vorschaumodus des GTMs aktiv:

Wenn man ein GA4-Konfig-Tag implementiert hat, kann das zu einigen Fragezeichen im Vorschaumodus führen. Erstens sieht man bspw. dass im GTM-Container ein Scroll-Event gefeuert wird, obwohl dazu nichts im Google Tag Manager konfiguriert wurde:

Im Network-Tag sieht man aber, dass ein Scroll-Event an GA4 geschickt wird:

Wie kann das sein? Schaut man nun in den GA4-Container innerhalb des GTM-Vorschaumodus, dann löst sich das auf. Das Scroll-Event wird von hier aus gefeuert:

Nun stellst du dir sicher die Frage, wieso dieses Event gefeuert wird, obwohl nichts im GTM konfiguriert worden ist? Die Antwort: Das Event kommt nicht aus dem GTM, sondern – wie wir im Vorschaumodus gesehen haben – aus dem GA4-Container bzw. aus Google Analytics 4. Und zwar handelt es sich dabei um die optimierten Analysen a/k/a Enhanced Measurement:

Der geladene GA4-Container enthält also auch Einstellungen, die man in der GA4-Benutzeroberfläche festlegt. Am Screenshot fällt dir vielleicht auch auf, dass über die optimierten Analysen das Pageview-Event aktiviert wurde, aber im Vorschaudmodus vorhin das Pageview-Event nicht auftaucht. Wie kann das sein? Das liegt daran, dass ich folgende Einstellung im GA4-Konfigurationstag nicht aktiviert habe:

Diese Option kommt folgender gtag-Funktion gleich:

gtag('config', 'G-XXXXXX', {'send_page_view': false});

Ich deaktiviere also aktiv das Senden eines Pageview-Events. Diese Option hat vor der Option in der GA4-Benutzeroberfläche Vorrang. Bzw. lässt sich die Option “Seitenaufrufe” in GA4 sowieso nicht deaktivieren:

Ebenfalls über das GA4-Konfigurationstag werden folgende Events geschickt:

session_start: Dieses Event wird automatisch geschickt, sobald der Nutzer eine neue Sitzung startet.
first_visit: Wird automatisch gefeuert, sobald der Nutzer die Website zum ersten Mal besucht.
user_engagement: Dieses Event wird laut Google versendet, wenn der Nutzer min. 10 Sekunden auf einer Seite war. Zudem wird es immer wird nach einer bestimmten Zeit auf der Seite ausgelöst, um festzustellen, ob der Nutzer noch aktiv ist. Man vermutet, dass damit versucht wird, die durchschnittliche Zeit auf der Seite besser kalkulieren zu können. Das user_engagement-Event hat auch einen besonderen Parameter namens engagement_time_sec. Dieser Parameter gibt die verstrichene Zeit seit dem letzten user_engagement-Event in Millisekunden an.

Weiters kann man über das GA4-Konfigurationstag konfigurieren, ob der Hit an einer Servercontainer-URL gehen soll:

Mehr dazu gibt es in meinem Beitrag “Google Analytics 4 mit serverside GTM”.

Zwei weitere wichtige Optionen im GA4-Konfig-Tag sind “Festzulegende Felder” und “Nutzereigenschaften”:

Über die festzulegenden Felder kann man Event-Parameter definieren, die für alle Events, die nach dem Config-Tag feuern, gelten sollen. Sprich: Wird hier ein Parameter festgelegt, dann wird dieser allen nachfolgenden Events drangehängt. Hier ein Beispiel was passiert wenn wir folgende Test-Parameter hinzufügen:

Wenn das Config-Tag feuert, dann sind die Werte im Config-Tag selbst gesetzt:

Am darauf folgenden Pageview-Event hängt es nun auch:

Wichtig dabei ist, dass man diesen Event-Parameter in der GA4-UI konfiguriert bzw. erstellt, damit es für Reporting-Zwecke genutzt werden kann. Mit Nutzereigenschaften funktioniert das ähnlich: