Mehr als nur Pageviews: Events

Pageviews oder Seitenaufrufe waren viele Jahre die Hauptwährung in der Webanalyse. Im Prinzip sind sie aber relativ sinnfrei, denn wir wissen ja nicht, ob ein Nutzer die Inhalte auf der Seite tatsächlich gelesen hat oder nicht. Auch wissen wir zum Beispiel bei der letzten Seite, die ein Nutzer besucht, nicht, wie lange er auf dieser Seite gewesen ist (siehe Details hier).

JavaScript ermöglicht das Auslösen von Events bzw. Ereignissen, zum Beispiel durch eine Nutzeraktion, aber auch automatisiert, nachdem eine Seite ausgeliefert wurde. Dadurch ist ein granulareres Messen der Interaktion von Nutzern mit einer Seite möglich.

Natürlich lädt dies auf den ersten Blick dazu ein, einfach einmal alles zu tracken; allerdings “schießt” jedes Event einen Hit an Google Analytics, von denen aber nur bis zu 10.000.000 pro Monat kostenlos sind. Außerdem werden nur 500 Events pro Session gezählt. Daher ist es umso wichtiger, dass man sich genau überlegt, welche Events wirklich wichtig sind zur Messung der Zielerreichung. Auch bedeutet das Sammeln von Daten nicht, dass diese auch sinnvoll ausgewertet werden können. Bei der Scroll-Tiefe zum Beispiel kann ein Wert von 75% für zwei Seiten unterschiedliche Bedeutungen haben, je nachdem wie unterschiedlich lang die beiden Seiten sind.

Der Ablauf

Ein Nutzer kommt auf eine Seite und löst zunächst einen Page View aus. Zwar können auch mit dem Pageview Events ausgelöst werden, die Nützlichkeit ist in diesem Fall aber fraglich. In unserem Beispiel werden Events durch Nutzerinteraktionen mit der Seite ausgelöst, zum Beispiel

  • wenn ein Nutzer herunter scrollt
  • wenn ein Element auf der Seite sichtbar ist
  • wenn ein Video auf der Seite gestartet, pausiert oder bis zum Schluß geschaut wird.

Tracking Plan

Events haben 4 Felder, Kategorie, Aktion, Label und Wert. Um Events sinnvoll auswerten zu können, ist eine einheitliche Benennung der einzelnen Felder notwendig. In einem Tracking Plan wird die Benennung festgelegt; zu diesem Zeitpunkt muss schon klar sein, warum und wie man das Auftreten von Events lösen will.

Event Tracking Plan
Event Tracking Plan

Implementierung von Events im Google Tag Manager

Erst dann werden die Tags erstellt. Für den Page YARPP Visible Event Tag sieht das zum Beispiel so aus:

Lediglich der Wert wird durch eine Variable gefüllt (erkennbar an den {{}} Klammern). Dieses Event wird ausgelöst, wenn auf dem Bildschirm des Nutzers der Bereich “Ähnliche Beiträge” oder “Mehr lesen” erscheint, der Inhalt vom Nutzer also anscheinend zuende gelesen wurde. Dieses Event ist wichtig, da das Ziel dieser Seite ist, dass die Inhalte auch gelesen werden (ansonsten lohnt es sich nicht, ein Skript zur Veranstaltung zur Verfügung zu stellen). Die Scroll-Tiefe ist in diesem Fall nicht unbedingt notwendig, aber wir nehmen sie trotzdem mit.

Eine häufige Stolperfalle ist Non-Interaction Hit. Diese ist in diesem Beispiel auf false gesetzt. Man könnte dies wie eine doppelte Verneinung verstehen: Keine-Interaktion: Falsch, also ist es eine Interaktion. Dahinter verbirgt sich ein entscheidender Faktor für die Berechnung der Bounce Rate: Stünde hier True, so würden Nutzer, die auf eine Seite gelangen und das Element Visibility Event auslösen, immer noch als Bounce gezählt werden, wenn sie keinen weiteren Pageview auslösen. In der oben beschriebenen Konfiguration aber sind sie keine Bouncer.

Was macht man nun damit?

Schaut man sich die Ergebnisse des Events an, so wird die oben beschriebene Einschränkung des KPIs Scroll-Tiefe deutlich:

In den ersten Zeilen der Daten sehen wir Hits für das Sichtbarkeits-Event, bei denen die Scrolltiefe bei 0% liegt. Wie kann es sein, dass ein Nutzer die “Ähnlichen Artikel” gesehen hat, wenn er noch nicht mal herunter gescrollt hat? Die Antwort ist ganz einfach: Unter dem Artikel befinden sich so viele Kommentare, dass der Nutzer nur so wenig herunter scrollen muss bis er das Element sieht, dass der Trigger für die 25% Scrolltiefe noch nicht ausgelöst ist! Gleichzeitig sieht man in den anderen Zeilen für eine Seite unterschiedliche Scrolltiefen, was daran liegt, dass diese auf unterschiedlichen Geräteklassen ausgeliefert wurden.

Nächster Abschnitt: Implementierung testen

Implementierung testen

Google Tag Manager

Nach der Implementierung muss das korrekte Einfließen der Daten kontrolliert werden. Beim Google Tag Manager geht das mit dem Vorschau-/Debug-Modus, bei dem die Seite aufgerufen wird und im unteren Teil der Seite angezeigt wird, welche Tags wann gefeuert wurden und wie der Inhalt des Data Layers aussieht (siehe Abbildung). Dies funktioniert natürlich nur, wenn man Zugriff auf den Google Tag Manager der Seite hat.

Wichtig: Ist der Preview-Modus bereits aktiviert und wird dann noch etwas am Setup geändert, dann muss die Vorschau aktualisiert werden. Allerdings werden nicht immer alle Variablen-Werte angezeigt, zum Beispiel wenn ein customTask verwendet wird:

In diesem Fall können Tools weiterhelfen, die übrigens auch Außenstehende nutzen können, ohne dass sie selbst Zugriff auf ein mit der Seite verbundenes Google-Konto besitzen.

Google Analytics

Google Analytics bietet den Bereich Echtzeit an, in dem Seitenzugriffe, aber auch Events mit einer kleinen Verzögerung von wenigen Sekunden beobachtet werden können:

Dadurch kann das Ankommen der Daten in Google Analytics getestet werden.

Google Tag Assistant

Der Google Tag Assistant für Chrome erlaubt das Beobachten von Tags und den von ihnen gespeicherten Variablen.

Dieses Tool kann genutzt werden, auch wenn man keinen Zugriff auf die Google Analytics Property hat. Es zeigt zudem auch Werte an, die im Debugger noch nicht zu sehen sind, wie zum Beispiel hier die Werte der Custom Dimensions.

Das Killer Feature ist hier aber die Möglichkeit, die feuernden Tags aufzunehmen und sich sozusagen eine Sequenz anzeigen zu lassen, die “gefilmt” wird, während man selbst die Seite lädt oder mit ihr interagiert. Dies ist ein sehr guter Weg, um Fehler zu finden, aber auch um herauszufinden, was eine Seite eigentlich genau trackt.

Der Google Tag Assistant funktioniert nicht, wenn Google Analytics über sendBeacon die Daten schickt, da hier ein Post-Request genutzt wird und kein Get-Request. Für den Anwender sieht es so aus als ob Google Analytics nicht mal installiert wäre. Hier hilft der Google Analytics Debugger.

Google Analytics Debugger

Ein weiteres Tool, um zu beobachten, ob ein Tracking funktioniert oder was von einer Seite getracked wird, ohne dass wir Zugriff auf die Seite haben, ist der Google Analytics Debugger. Dieser kommt etwas technischer daher, aber auch hier kann sehr genau nachvollzogen werden, was im Tracking passiert.

Um die Daten zu sehen, muss in Chrome unter Anzeigen -> Entwickler -> Entwicklertools die Console ausgewählt werden.

Adobe Debugger

Similar to the Google Tag Manager, Adobe has their own debugger. The nice thing here is that you can see everything that happens in a second browser window.

Tracker-unabhängige Ansätze

Entwicklertools/Network

In Chrome unter Ansicht -> Entwickler -> Entwickler-Tools den Abschnitt Network auswählen, Seite laden und dann beobachten, was alles genau geladen wird.

Wählt man wie in dem Beispiel oben “collect” aus, so sieht man, was Google Analytics gerade “nach Hause” schickt, in diesem Fall ein Event für Element Visibility.

Ghostery

Finally, Ghostery is not only a great tool for blocking ads, but also for monitoring ads since all the products above mostly monitor their own breed (Google sees Google products, Adobe sees Adobe products).

Wird mein Content gelesen? Sichtbarkeit von Elementen messen!

Im September 2017 hatte ich noch darüber geschrieben, dass die Scrolltiefe ein besserer Indikator dafür wäre, ob ein Inhalt gelesen wurde als die reine Sitzungsdauer, die eh Quatsch ist. Einen Monat später veröffentlichte Google dann eine neue Funktion im Google Tag Manager, einen Trigger für die Sichtbarkeit von Elementen (in der deutschen Version der Release Notes fehlte der Hinweis). Damit lassen sich einige Nachteile des Scrolltiefen-Ansatzes kompensieren, vor allem die Einschränkung, dass nicht jede Seite gleich lang ist und “75% gelesen” nicht immer bedeuten muss, dass der Inhalt auch bis zum Ende gelesen wurde (75% wurde deswegen gewählt, weil viele Seiten einen immensen Footer haben und die Nutzer daher nicht zu 100% runterscrollen). Eine Seite bei mir hat so viele Kommentare, dass sie mehr als die Hälfte des Inhalts ausmachen. “Wird mein Content gelesen? Sichtbarkeit von Elementen messen!” weiterlesen