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

Michaela Linhart 18 Comments

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:

Scrolltracking mit Hotjar auf hausdorf.at

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.

Scrolltracking via GTM bisher

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.
GTM Built-In Variable konfigurieren

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.
GTM Scroll Tracking Tag anlegen

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.
GTM Scroll Tracking Trigger aktivieren

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.

Scrolltracking Check in der Developer Console

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.

Scroll Tracking Funnel bei GA360 User

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
GTM Neue Variable 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
  • 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
GTM Trigger Scrolltracking Event

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. 🍎

Scrolltracking via GTM bisher

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

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>

Comments 18

  1. Hi Michaela,
    nice! Sehr gute Lösung mit dem Script.

    Habe ein paar Gedanken zu dem Thema

    1. Ich überlege, vielleicht hat es auch Sinn die Gesamthöhe in Pixel zu messen, dann könnte man mittellange Artikel untereinander vergleichen und in Event Action zB zu speichern, Scrollwert als Integer könnte man in Event Value setzen (dann sieht man auch Durchschnitt des Wertes), page Path gar nicht eintragen (ist in Dimension „Page“ eher gespeichert), dafür in Event Label könnte man theoretisch Stufe des Wertes wie 25,50,75,100% für weitere Zwecke (zb Funnelbildung) eintragen. Und in Custom Report in Flat Table alles abbilden.

    2. Noch eine Idee: mit meinem Kommentar wird sich die Gesamthöhe der Seite sich erhöhen. Falls hier noch eine Diskussion mit mehreren Teilnehmern entsteht, wird die Seite noch länger. Also, es wäre hilfreich, ein Anker nach dem Artikelende zu setzen und die Scrolltiefe nur bis seiner Position zu messen.

    LG
    Igor

    1. Post
      Author

      Hi Igor,

      vielen Dank für deine Anmerkungen. 🙂

      Ich bin mir nicht sicher ob es Sinn macht, die Gesamthöhe in Pixel zu messen, da die Bildschirmgröße je nach Device immer unterschiedlich ist: Beispiel Smartphone Nexus 5X vs. 27“ Desktop Bildschirm….

      Um lange / kurze / mittellange Artikel zu vergleichen, könnte man auch die Anzahl der Wörter in eine Custom Dimension mitspeichern und vergleichen. Oder: Man definiert ab z.B. 500 Wörter ist der Artikel mittellang und schreibt in eine Custom Dimension „Artikellänge“ „mittellang“ hinein.

      -> Für Blogs gibt es unzählige, geniale Tracking- und Analyse Möglichkeiten. Dazu habe ich zusammen mit Siegfried Stepke einen Beitrag im Suchradar-Magazin veröffentlicht (Ausgabe Juni 2016). Hier der Inhalt auch im e-dialog Blog: https://www.e-dialog.at/blog/webanalyse/google-analytics-advanced-content-tracking-am-beispiel-blog/

      Bezüglich Anker nach Artikelende: Das ist eine großartige Idee für Blogs! Werde ich bei mir auf jeden Fall ausprobieren! 🙂 Für Ecommerce Seiten macht das vermutlich weniger Sinn… 1) weil die Seiten meist nicht länger werden und 2) weil das Scrolling bis zum Footer nicht mehr trackbar wäre. Hier müsste man sich also auf jeden Fall Gedanken machen ob das für die eigene Website sinnvoll ist… Für Blogs macht es aber definitiv Sinn. 🙂

      Liebe Grüße,
      Michaela

      1. Hi Michaela, hast Recht, Gesamthöhe in Pixel zu messen hat kein Sinn ^^ Guter Tipp mit den Worte zählen! Und danke für den Link (ich werde demnächst Blogtracking konzipieren, soll nicht all zu wild sein, aber Scrolltracking finde ich schon wichtig).

        Bei Ecommerce-Seiten bin fast deiner Meinung. Fast, weil in Category-Seiten würde ich doch schon gern quantitativ Scrolltiefe auswerten.

        LG
        Igor

  2. Sehr coole Methode. Mich hat das mit den vielen Ereignissen auch immer gestört, aber so geht das natürlich viel feiner. Gratuliere zu der eleganten Lösung. Habe ich schon im Einsatz!

  3. Eventuell verbesserbar: bei Nicht-Scrollen gibt es ein „undefined“, besser wäre „0“. Und mir kommt vor, dass manchmal nicht der korrekt Wert übergeben wird …. Möglicherweise gibt es da Störungen durch Page Builder?

    1. Post
      Author

      Hi Heinz,

      viiielen Dank für dein Kommentar. Code ist ausbessert.:-)

      Es wird jetzt „0“ übergeben, wenn nicht gescrollt wird. Dazu musste der percent-Parameter als String umgewandelt werden… Weil maxscrolled wird ja eigentlich mit 0 initialisiert und wenn nicht gescrollt wird, müsste auch „0“ übergeben werden. Aber Google wandelt den Integer „0“ in undefined um… Problem gelöst indem einfach ein String übergeben wird. 🙂

      Bezüglich falsche Werte: Tatsächlich! Das passiert, wenn ich nur in meinem eigenen Browser teste… Die 1. Codezeile in der 1. Funktion hat sich geändert. Die Berechnung müsste jetzt auch in allen anderen Browsern und nicht nur Google Chrome funktionieren. 😉

      Gerne den Code einfach austauschen, dann sollte das Tracking jetzt korrekt funktionieren. 🙂

      Liebe Grüße,
      Michaela

  4. Hallo Michaela,

    super Artikel (wie ja immer!), aber ich musste schmunzeln über den zweiten Teil des Blog-Beitrags, weil auch du die grandiose Neuerung Element Visible Trigger im Beitrag „versteckt“ hast, obwohl sie durchaus einen eigenen Beitrag verdient hätte.
    Was sagt denn Krista Seiden (oder Simo Ahava) zu den 500 Hits?
    Und dann hattest du geschrieben, dass auf Seite 5 die Anzahl der Hits evtl. erschöpft sein könnte. 100 Hits pro Seite ist aber schon recht üppig, selbst auf einer großen Seite, oder?

    1. Post
      Author

      Hi Arne,
      da hast du recht: Der Element Visible Trigger verdient auf jeden Fall einen eigenen Beitrag. Danke für den Hinweis. 🙂

      Tatsächlich habe ich zum 500 Hit-Limit noch gar nicht so viel gelesen. Vermutlich wird das gerne „unter den Teppich gekehrt“…

      Ob man in dieses 500 Hit-Limit fällt kommt ganz stark auf die Implementierung an: Einmal ist das tatsächlich bei einem Kunden vorgekommen – und das war kein Ecommerce Anbieter. Allerdings wurden Product Views und Internal Promotion Events Ende nie gefeuert. Und wenn auf einer Website 50 „Produkte“ (mit lazy loading „unendlich“ viele), 20 Internal Promotions, plus zusätzliche Events und der Pageview gefeuert werden, dann kann das schon auch auf 100 Hits pro Seite kommen.

      Allerdings können Ecommerce Events zusammengefasst werden: Wenn statt 50 einzelne Events, zwei oder drei Events gefeuert werden, dann reduziert sich die Anzahl der Hits natürlich deutlich. Also es gibt mit Sicherheit ein paar Workarounds: Dazu muss man aber wissen, dass es dieses Limit gibt und das die eigene Implementierung optimierungs-bedürftig ist…

      Ich gehe also schon davon aus, dass es Websites gibt, die mit dem Tracking übertreiben. Dazu eine nicht so gute Implementierung und es kann passieren, dass wegen dem Scrolltracking ins Hit-Limit gefallen wird.

      Aber: Du hast auf jeden Fall recht – 100 Hits pro Event ist tatsächlich üppig. Und 500 Hits pro Sessions reichen in der Regel völlig aus. 🙂

      Ganz liebe Grüße,
      Michaela

  5. Hi Michaela,

    danke für diese sehr coole Idee zum Scrolltracking. Das gefällt mir wirklich gut. 🙂

    Zwei kleine Ideen sind mir bei der Implementierung gekommen:
    – Wenn man das sessionStorage statt der globalen Variablen maxscrolled nutzt, könnte man den Code mit
    (function() {

    })();
    kapseln. Damit würde man evtl. Probleme mit dem globalen Namespace verhindern. Gerade bei großen Websites gibt’s ja vielleicht schon Variablen mit dem gleichen Namen.

    – Wenn man die Scrolltiefe zusätzlich als Event Value an GA sendet, kann man sich dort sehr schön die durchschnittliche Scrolltiefe für die einzelnen Seiten ausweisen lassen. Damit bekommt deine Lösung dann noch einmal mehr Charme…

    Schöne Grüße
    Christian

    1. Post
      Author

      Hi Christian,

      vielen Dank für deinen Input! Klasse Ideen!

      zu 1) Stimmt, das wäre technisch auf jeden Fall eine sauberere Lösung, an die ich gar nicht gedacht hatte.

      Allerdings kann die Variable auch im sessionStorage schon vorhanden sein – deswegen sollte auch hier ein eindeutiger Name genutzt werden. Wobei die Wahrscheinlichkeit vermutlich viel geringer ist…

      Deswegen sollte man generell mit eindeutigen Variablen-Namen arbeiten und z.B. einen Prefix nutzen. Beispiel: ml_maxscrolled (für Michaela Linhart) oder ak_maxscrolled (für AnalyticsKiste)

      Dann ist man auf jeden Fall auf der sicheren Seite – egal ob mit meiner aktuellen Lösung oder deiner technisch schöneren Lösung über den sessionStorage.

      zu 2) Die Scrolltiefe zusätzlich als Event Value setzen ist eine suuuper Idee. Daran hatte ich auch gar nicht gedacht…

      Das baue ich gleich noch in den Blogartikel ein – vielen Dank. 🙂

      Liebe Grüße,
      Michaela

  6. Sali Michaela

    Danke für den spannenden Post. Ist eingebaut. 🙂

    Wie wertest Du die Daten bei was für Cases wie aus? Wie sind hier deine Erfahrungen? Schaust Du vor allem auf die Durchschnittswerte oder auch auf die Verteilung der Werte auf der 0-100 Achse?

    Vielen Dank und liebe Grüsse
    Michael

    1. Post
      Author

      Hi Michael,

      großartig! Das freut mich sehr.

      Die Auswertung mache ich ganz nach Use Case. In diesem Blogartikel habe ich ein paar Use Cases und Analysemöglichkeiten zusammengefasst.

      Ich hoffe, dass hilft dir weiter.

      Liebe Grüße,
      Michaela

  7. Ihr Artikel ist super…habe alles genauso gemacht (Custom Lösung) wie beschrieben.

    Im Debug Modus habe ich auch beim Verlassen den scrolltrigger (das event) im Debug Window…
    (meine GTM Kenntnisse sind sehr begrenzt)

    Doch leider werden GAR KEINE Daten/Event hits in GA angezeigt.
    Die GA ID habe ich manuell eingetragen…non interactive habe ich auf true gestellt…

    Haben Sie irgendeine Idee?

    Eine Auswertung des Debug kann ich leider ebenfalls nicht nachvollziehen, denn beim Verlassen der Seite wird es ja alles gezündet, die neue Seite lädt sich und das Debug Window wird gelöscht / neu befüllt.

    1. Post
      Author

      Hallo Andreas,

      ich frag zuerst mal vorsichtig: Hast du deine Einstellungen nach dem testen im Vorschaumodus auch gepublished?

      Wenn in der Vorschau alles passt, nur in GA keine Daten einlaufen, klingt es so, als wäre das Tracking noch nicht live.

      Vermutlich wird das aber nicht das Problem sein:

      Tipp #1: Es kann bis zu 24h dauern bis Daten in GA verarbeitet sind. D.h. wenn du das Event heute einbaust, wirst du nicht sofort Daten im Ereignis-Report sehen.

      Du kannst aber in den Real-Time Reports überprüfen, ob die Events korrekt einlaufen. Gehe dazu in GA auf Real-Time –> Events. Hier siehst du die gerade aktiven Events und alle Events, die in den letzten 30 Minuten gefeuert wurden.

      Tipp #2: Eine weitere Überprüfungs-Möglichkeit gibt es über die Developer Console (F12 in Google Chrome). Hier kannst du den Network-Stream anschauen, d.h. alle Parameter die an GA gesendet wurden. Gib ins Suchfeld „collect“ ein, damit du überprüfen kannst ob deine Events korrekt versendet werden.

      Außerdem kannst du nachsehen ob dein Code eine Fehlermeldung wirft; ggfs. hast du irgendeine Einstellung vergessen?

      Liebe Grüße,
      Michaela

  8. Pingback: Liste an Google Tag Manager Anleitungen - eWerkzeug.info

  9. Hallo Michaela,

    danke dir für die Tipps ! Bei uns führt diese Lösung allerdings zu einem deutlichem Anstieg an Sessions mit 0 PageViews. MeineVermutung ist, dass User das Scroll-Tracking-Event auslösen, nachdem die Session expired ist. Hast du eine Möglichkeit, das zu verhindern? Das führt natürlich dazu, dass die Daten unvollständig sind, allerdings wäre mir das lieber als Sessions ohne Page Views.

    Liebe Grüße,
    Philip

    1. Post
      Author

      Hi Philip,

      ich hatte dieses Problem früher auch schon mal und es lag daran, dass das Event VOR dem Pageview gefeuert wurde. Auch das Event initiiert eine Session in GA, allerdings eben ohne Pageview.

      Es ist also super, super wichtig, dass immer zuerst der Pageview und dann erst Events gefeuert werden.

      Am einfachsten geht das mit Tag Sequencing: Du kannst direkt beim Scroll Tracking Tag unter Advanced > Tag Sequencing sagen: „Fire a tag before Scroll Tracking Tag“ Hier kannst du dann den Pageview auswählen.

      Damit ist sichergestellt, dass immer zuerst der Pageview und erst danach dein Scroll Tag ausgelöst wird und im besten Fall sollte dies dein Problem lösen.

      Liebe Grüße,
      Michaela

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.