GTM: Warum du das native Scrolltracking von Google nicht einsetzen solltest12 min Lesezeit

Vor kurzem hat Krista Seiden, Google Evangelist, in ihrem Blogposte das neue Scrolltracking-Feature im Google Tag Manager vorgestellt: Und seitdem wird im Netz über nichts anderes mehr gesprochen. Ich meine, man sollte einen zweiten Blick auf die Details werfen…

Natives Scroll Tracking: Worum geht es?

Google Analytics verfügt leider nicht über eine Visualisierung der Scroll-Tiefe, wie wir es beispielsweise von Hotjar kennen:

Screenshot: Scrolltracking mit Hotjar auf hausdorf.at

Trotzdem ist es super interessant zu wissen, wie weit User auf der Website scrollen bzw. ob sie überhaupt scrollen – und die oft mühsam aufbereiteten Inhalte vollends ansehen. Dieses User Engagement ist bei Content Websites wie Blogs genauso spannend wie für alle anderen Websites, wenn es um die Startseite oder sehr lange Produktdetailseiten geht.

Deswegen haben geniale Tekkis einen Weg gefunden, das Scroll-Verhalten via Event-Tracking über den Google Tag Manager zu erfassen: Tolle Lösungen gibt es bei OptimizeSmart, bei LunaMetrics oder AmazeeMetrics.

Natürlich erforderte der Einbau dieser Lösungen ein wenig technisches Grundverständnis und vielleicht ein bisschen mehr Arbeit. Aber: Es hat gut funktioniert und die Lösung sah in etwa so in Google Analytics aus.

Screenshot: Scrolltracking in GA via GTM bisher

>> Nun die Revolution: Google hat im Google Tag Manager einen neuen Trigger hinzugefügt. Genau das selbe Scrolltracking lässt sich jetzt auch super bequem und direkt über den Google Tag Manager aktivieren: Ohne technisches Grundverständnis, ohne Arbeitsaufwand. Setup Zeit: 5 Minuten. ????

NEU: Scroll Tracking Setup im GTM…

Wie das Scroll Tracking Setup im GTM geht, kannst du direkt bei Krista im Blog nachlesen: „Step-by-Step: New Scroll Depth Trigger in Google Tag Manager“

Kurzgefasst: Es sind 3 sehr einfache Schritte notwendig.

• Neue Scroll-Tracking Build-In Variablen aktivieren: Dazu gehst du einfach im GTM auf Variablen → Built-In Variablen Konfiugration. Es öffnet sich rechts im Browser ein Pop Up. Du scrollst runter bis Scrolling und wählst alle 3 Variablen aus.

Screenshot: GTM Built-In Variable konfigurieren

• Neuen Scroll-Tracking Tag anlegen:
  • Name: z.B. GA – Event – Scolltracking
  • Tag Typ: Universal Analytics
  • Track Typ: Event
  • Event Category: z.B. Scrolltracking
  • Event Action: die neue Build-In Variable “Scroll Depth Threshold”
  • Event Label: die Build-In Variable “Page Path”, damit du weißt auf welcher Seite gescrollt wurde.

Screenshot: GTM Scroll Tracking Tag anlegen

•  Dem Scroll-Tracking Tag den neuen Trigger zuordnen: Und das ist eigentlich das spannende Neue! 
  • Trigger Typ: „Scroll Depth“ unter “User Engagement”
  • Vertical oder Horizontal Srcolling auswählen.
  • Prozentwerte auswählen:  Ab wie viel Prozent gescrollt, das Event ausgelöst werden soll.
  • Auf allen Seiten oder bestimmte Seiten auswählen.

Screenshot: GTM Scroll Tracking Trigger aktivieren

Speichern. Publishen. Fertig.

… und warum ich nicht so begeistert davon bin

Krista hat ihrem Blogartikel auf jeden Fall nicht übertrieben: In 5 Minuten hatte ich das neue Scrolltracking in meinem Blog schon aktiv.

Ein Blick in die Developer-Console… und beim scrollen schossen mir nur so die Events um die Ohren: Ich habe in meinem Trigger 10er Schritte eingebaut, d.h. wenn ich auf meinem Blog 10%, 20%, 30%… 90%, 100% scrolle, dann wird jedes Mal ein Event abgefeuert. Sprich: 10 Events pro Blogartikel.

Screenshot: Scrolltracking Check in der Developer Console

Das mag für meinen kleinen Blog mit 20 Seitenaufrufen am Tag und durchschnittlich 2,07 Seitenaufrufe pro Sitzung kein Problem sein: Werden eben 20 weitere Events abgefeuert.

ABER bei großen Seiten, egal ob Onlineshop, Informationsseite, Portal oder Applikation, wo im Schnitt 10+ Seiten aufgerufen werden, wo gestöbert und verweilt wird und wo auf jeder Seite 20, 50, 70 andere Events abgefeuert werden, sehe ich ein gröberes Problem.

Und zwar:

Google Analytics Limit: 500 Hit pro Session

Google Analytics hat ein Limit von max. 500 Hits, die garantiert innerhalb einer Session verarbeitet werden. Alles was darüber hinaus passiert, kann (muss aber nicht) einfach abgeschnitten und weggeworfen werden. Das gilt übrigens auch für Google Analytics 360 Kunden…

500 Hits pro Sessions klingt zwar im ersten Moment viel: Aber bei einer Ecommerce Website beispielsweise, bei dem Enhanced Ecommerce vollständig eingebaut ist und jeder Product View, jede interne Promotion getrackt wird und zusätzlich noch zig Events für diverse Button- und Link Klicks, eventuell sogar Wetter-Informationen und andere Third-Party Daten zur Session hinzu gespeichert werden, könnte das knapp werden.

Wenn es also passiert, dass jede oder zumindest jede zweite, dritte Session über 500 Hits erzeugt und der Rest weggeworfen wird, dann verfälscht das natürlich die Statistik im gröberen Ausmaß: Denn das restliche User-Verhalten wird einfach nicht mehr aufgezeichnet.

Das bedeutet, dass z.B. ab Seite 5 keine Scroll-Daten mehr für weitere Produktdetailseiten erfasst werden. Funktionieren diese Seiten dann schlechter? Nein, sie werden nur nicht mehr erfasst.

Noch schlimmer: Was ist, wenn erst nach 10 Seiten eine Transaktion erfolgt? Sie wird in Google Analytics möglicherweise nicht mehr aufgezeichnet… ?

Lösung #1: Nur auf bestimmten Seiten scrollen

Statt das Scroll-Tracking per Default auf allen Seiten zu aktivieren, kann es natürlich auch nur auf bestimmten Seiten aktiviert werden z.B. der Startseite, Kategorieseiten oder Content Seiten…

Doof ist dann, wenn plötzlich doch eine User Engagement Analyse für die Produktdetailseite verlangt wird und die Daten nicht vorhanden sind…

Zwar kann der Trigger im GTM sehr schnell angepasst werden – aber es dauert wieder ein paar Tage oder Wochen bis relevante Daten in Google Analytics verfügbar sind. Und wer will schon wochenlang auf seinen Report warten?

Lösung #2: Scroll-Prozentsatz verringern

Auch das ist eine mögliche Lösung: Statt in 10er Schritte kann das Scrollen auch auf 25er-Schritte reduziert werden. Statt zehn Events werden dann immerhin nur mehr vier pro Seite gefeuert: Eine Reduktion von 60%.

ABER: Auch dann gefällt mir die Lösung als Google-Analytics-Free User eigentlich nicht. Denn mich interessiert, wie viel Prozent des Website-Contents  die User gesehen haben und nicht wie viel sie hin & her scrollen.

Als Beispiel: Wenn ein User in Summe 75% scrollt, dann hat er zwangsweise 0%, 25% und 50% durchlaufen und 75% erreicht. Mich interessieren die 75%, nicht aber die 0-50%…

Wo diese Art von Tracking spannend sein könnte, ist bei GA360 Kunden, die sich mit Custom Funnels einen wunderschönen benutzerdefinierten Scroll-Trichter bauen können: Siehe als Beispiel mein Blogpost über Custom Funnels während meiner Zeit bei e-dialog.

Screenshot: Scroll Tracking Funnel bei GA360 Kunden

Lösung #3: Eigenes Scroll-Tracking implementieren

Deswegen habe ich mich gegen den Einbau des neuen Scrolltrackings von Google entschieden: Weil es meiner Meinung nach keine optimale Lösung für große Websites ist. 

Vielmehr habe ich eine Lösung aus dem Netz auf meine Bedürfnisse angepasst: So wird lediglich EIN EINZIGES SCROLL-EVENT beim verlassen der Seite gefeuert.

Das kann sein, wenn der User auf die nächste Seite innerhalb meiner Website springt oder die Website verlässt, indem er im Browser eine neue Website öffnet, eine Suche durchführt, etc.

Vorteil: Schließt der User den Browser, wird das Scroll-Event dank Browser-Eventhandling „beforeunload“ trotzdem abgeschickt!

So sieht meine Scroll-Lösung im Detail aus

Meine Scrolltracking-Lösung besteht aus zwei Tags, zwei Trigger und einer neuen Variable.

• Neue Variable „percent“ anlegen: Damit die gescrollten Prozente in Google Analytics erfasst werden, brauchen wir eine neue benutzerdefinierte Variable im GTM.
  • Name: percent
  • Variablen Typ: Data Layer Variable
  • Data Layer Variable Name: percent

Scrennshot: GTM Neue Variable „percent“

• Neuen Scroll-Tracking Tag anlegen:
  • Name: z.B. GA – Custom HTML – Scolltracking
  • Tag Typ: Custom HTML
  • Inhalt: JS Code hinein kopieren (siehe graues Kästchen)
• Trigger: Page View – DOM Ready (Standard Trigger)

<script>
 var maxscrolled = 0;
 
 window.addEventListener("scroll", function(){
  var scrollpoint = (window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop || 0)+window.innerHeight;
 if(window.maxscrolled < scrollpoint){
 window.maxscrolled = scrollpoint;
 }
 });

window.addEventListener("beforeunload", function() {
 var percent = (Math.round(window.maxscrolled/document.body.scrollHeight*10)*10);
 dataLayer.push({
 'event': 'scrolltracking',
 'percent': (percent>100 ? 100 : percent)+""
 });
 });

</script>

Den Code kurz erklärt: Es wird eine globale Variable maxscrolled angelegt und zwei Event Listener (Funktionen) ausgeführt. Eine Funktion wird beim scrollen ausgelöst: Diese speichert jedes mal nach dem scrollen den Scrollpunkt in die globale Variable maxscrolled.  Die zweite Funktion wird bei „beforeunload“ (bevor die aktuelle Seite verlassen wird) ausgelöst: Sie nimmt den Wert von maxscrolled und setzt ihn in Relation zur Länge der Website.  Wird die Seite verlassen, wird der gescrollte Wert via dataLayer-Push Event an den GTM abgeschickt.

• Neuen Scroll-Tracking Event-Tag anlegen: Damit das abgefeuerte Event im GTM erfasst wird, muss ein weiterer Tag angelegt werden.
  • Name: z.B. GA – Event – Scolltracking
  • Tag Typ: Universal Analytics
  • Track Typ: Event
  • Event Category: z.B. Scrolltracking
  • Event Action: die benutzerdefinierte Variable „percent“ von vorhin
  • Event Label: die Build-In Variable “Page Path”, damit du weißt auf welcher Seite gescrollt wurde
  • Event Value: die benutzerdefinierte Variable „percent“ von vorhin
  • Non-Interaction Hit: True

Achtung: Events beeinflussen deine Bouncerate (>>Details siehe hier).

Ich setze den non-interaction Event Parameter im GTM deswegen auf „true“. D.h. die Scrollevents beinflussen meine Bouncerate NICHT. Würdest du mit meiner Lösung den ni-Parameter auf „false“ setzen, würden User die 0% gescrollt haben (also tatsächlich abgesprungen sind) fälschlicherweise nicht als Bouncer gewertet werden.

• Trigger: Es muss ein neuer Trigger angelegt werden, der auf das im Code genannten Event „scrolltracking“ hört.
  • Custom Event Name: z.B. Event – Scrolltracking
  • Trigger Typ: Custom Event
  • Event Name: scrolltracking

Screenshot: GTM Trigger Scrolltracking Event

Speichern. Publishen. Fertig.

Hinweis: Um die durchschnittliche Scrolltiefe pro Seite zu analysieren, wird die Scrolltiefe zusätzlich zur „Event Action“ in den „Event Value“ geschrieben. In Google Analytics unter Verhalten –> Ereignisse –> Seiten erhälst du dadurch eine wunderbare Übersicht über die durchschnittliche Scrolltiefe pro Seite.

Vorteil dieser Lösung

Der große Vorteil dieser Lösung ist einerseits, dass sich die Anzahl der Hits im Rahmen halten – auch wenn das Scrolltracking auf allen Seiten aktiviert wird.

Andererseits wird die Auswertung wesentlich vereinfacht, denn wenn in 500 Sessions die Website bei 60% verlassen wurde, dann sind das 500 Sessions. In dieser Anzahl befinden sich nicht auch noch die Sessions, welche auf der Website zu 70%, 80%, 90% oder gar 100% gescrollt haben.

Ein bisschen so wie: Einfach ehrlich, einfach Granny’s. ????

Screenshot: Scrolltracking via GTM

Außerdem ist es mit dieser Lösung möglich, die durchschnittliche Scrolltiefe pro Seite zu erfassen – was zusätzlich einen schönen Überblick über die meist gescrollten Seiten liefert:

Google Analytics – Avg. Scrolldepth per Page

Ein weiterer Vorteil: Meine Lösung ist schnell kopiert und im eigenen GTM aufgesetzt – mit Copy & Paste auch ohne technische Kenntnisse.

Fazit: GTM Scrolltracking nativ vs. selbst implementiert

Der neue Scroll-Trigger im GTM ist zweifellos großartig und es ist kein Wunder, dass die ganze Webanalyse Community gerade völlig aus dem Häuschen ist: Scroll Tracking ist schnell und super easy aufgesetzt, sogar in weniger als 5 Minuten.

Man muss sich nicht selbst um die Lösung kümmern, mit JS-Workarounds arbeiten und läuft auch nicht Gefahr “irgendwas falsch zu machen”. Für kleine Blogs, Websites mit überschaubaren Traffic und geringer Seitentiefe der Himmel auf Erden…

ABER große Websites mit Tonnen an Traffic oder einer hohen Seitentiefe empfehle ich nicht, von einer Sekunde auf die andere von der eigenen Lösung auf die Neue umzusteigen.

Vielmehr solltest du vorher überprüfen, ob du nicht Gefahr läufst ins 500-Hit-Limit pro Session zu gelangen – oder es andere Gründe gibt, die eigene Lösung weiterhin laufen zu lassen z.B. weil die Analyse genau auf dich zugeschnitten ist.

Und wen du bisher keine Lösung implementiert hast: Dann solltest du dir ebenfalls vorher Gedanken machen, ob das neue Feature für deine Website das Passende ist. In erster Linie geht es nicht um ein perfektes Scroll-Tracking! Vielmehr geht es darum, keine wichtigen Hits zu verlieren und die Website durch hunderte Events (wenn auch nur geringfügig) zu verlangsamen. 

So, jetzt aber ran an den Ein- und Umbau der neuen Trigger in deinem GTM… und danach auf ins Scroll-Analyse Abenteuer!

<Hier folgt ein Screenshot, wie viele User diesen Blogartikel bis zum Ende gescrollt haben>

Alles klar?

Dann freue ich mich über ein Like, ein Share und ein Kommentar von dir. Abonniere gerne meinen Newsletter und meine Facebook Seite und lass dich automatisch über neue Beiträge informieren.

Noch nicht ganz? Schreibe mir gerne deine Fragen in die Kommentare.

Ich helfe, wo ich kann.

???? Happy Analyzing,

Deine Michaela

Das könnte dich auch interessieren:

Praxis Handbuch: 10 Scrolltracking Analysemöglichkeiten für Google Analytics29 min Lesezeit Wegweiser: Scopes in Universal Analytics verstehen und richtig einsetzen12 min Lesezeit PII Check: Warum du deine Analytics Daten verlieren könntest (und was du dagegen tun kannst)16 min Lesezeit