Das gtm.historyChange-v2 dataLayer Event

Vielleicht hast du dich gefragt, was das gtm.historyChange-v2 Event macht und warum es im dataLayer und in deinem Google Tag Manager Vorschau-Modus auftaucht:

Wie der Name schon sagt, gibt es auch eine v1-Version des Events, die einfach gtm.historyChange genannt wird.

Beide werden immer ausgelöst, wenn sich die URL einer Seite ändert, ohne dass der Browser die Seite vollständig neu lädt. Das passiert normalerweise in Single Page Applications (SPA). Sie sind dort sehr hilfreich, denn wenn du keine regulären Seitenladevorgänge hast, aber trotzdem tracken möchtest, wie du es bei normalen Seitenladevorgängen tun würdest, brauchst du irgendein Signal, um die URL-Änderung zu erkennen. Dafür sind gtm.historyChange und gtm.historyChange-v2 da.

Google Tag Manager: gtm.historyChange (das originale v1)

Das übliche Event gtm.historyChange ohne das -v2 Suffix wird von Google Tag Manager ausgelöst, wenn du einen Trigger in deinem Container hast, der auf eine History Change hört.

GA4 Enhanced Measurement: gtm.historyChange-v2

Das gtm.historyChange-v2 Event ist Teil des Enhanced Measurement von Google Analytics 4, d.h. der nützlichen Events, die GA4 neben regulären Seitenaufrufen automatisch sammelt.

Da diese Funktionalität Teil von GA4 ist, funktioniert sie unabhängig von Google Tag Manager. Wenn du ein GA4-Tag über GTM implementiert hast und irgendwo im Container einen aktiven History Change Trigger hast, siehst du sowohl gtm.historyChange als auch gtm.historyChange-v2 Events.

Wie man gtm.historyChange-v2 ein- oder ausschaltet

Die Einstellung zum Deaktivieren der gtm.historyChange-v2 Events ist in den Einstellungen des Data Streams im GA4 Admin-UI versteckt.

Gehe in deine Property-Einstellungen und klicke auf deinen Web Data Stream:

Klicke auf das Zahnradsymbol, um die Einstellungen für das Enhanced Measurement zu konfigurieren:

Unter der Zeile für Seitenaufrufe klicke auf “Erweiterte Einstellungen anzeigen”. Wenn du das Kästchen deaktivierst und speicherst, erscheint gtm.historyChange-v2 nicht mehr im dataLayer und das Event wird nicht mehr automatisch an GA4 gesendet.

Edge Cases

Vor allem, wenn du mit einer sehr alten Single Page Application arbeitest, könnte es sein, dass sie die moderne History Browser API nicht verwendet. In diesem Fall löst der Browser kein pushState Event aus und es werden keine nachfolgenden historyChange Events im dataLayer auftreten.

Auch wenn sich die URL nicht ändert, obwohl sich der Seiteninhalt ändert, gibt es keine History Change, die ein Event auslösen könnte.

In beiden Fällen solltest du nach einem dataLayer Event fragen, das von der Anwendung ausgelöst wird, nicht von GTM oder GA4. Ein detaillierter Leitfaden zum Tracking von Single Page Applications findest du auf Julians MeasureSchool Blog.