R via ServiceUser mit Google APIs verbinden

Wenn man mit R automatisiert auf APIs zugreifen will, dann ist die Authoritisierung via Browser keine Option. Die Lösung nennt sich Service User: Mit einem Service User und dem dazu gehörenden JSON-File kann ein R-Programm auf die Google Analytics API, die Google Search Console API, aber auch all die anderen wunderbaren Machine Learning APIs zugreifen 🙂 Dieses kurze Tutorial zeigt, was für die Anbindung an die Google Search Console getan werden muss.

„R via ServiceUser mit Google APIs verbinden“ weiterlesen

Das Grundlagen der Webanalyse-Buch

Das Buch Grundlagen der Webanalyse erscheint im Frühjahr 2019. Um die Kontrolle über die Publikation zu behalten, habe ich mich dazu entschlossen, das Buch selbst zu verlegen. Es wird sowohl als ebook als auch als gedrucktes Taschenbuch bei allen üblichen Offline-Händlern und Online-Shops erhältlich sein.

Dashboards: Actionable Insights

Dashboards werden häufig gewählt, um wichtige Informationen an einem Ort parat zu haben. Hier gilt alles, was im vorherigen Abschnitt erwähnt wurde. Welche Information soll bei dem Nutzer des Dashboards ankommen?

In der Regel geht es darum, dass verständlich darüber informiert werden soll, wo auf dem Weg der Zielerreichung man sich gerade befindet. Ein Dashboard ist daher immer gekoppelt an ein Ziel. Es sagt aus:

  • wie weit man vom Ziel entfernt ist
  • Ob man das Ziel innerhalb der gesetzten Zeit erreichen wird
  • Was dazu beiträgt, ob das Ziel erreicht wird oder nicht

Dashboards schauen also nicht nur in die Vergangenheit, sie versuchen auch eine Prognose für die Zukunft abzugeben.

Visualisierung von Daten

Die Flut von einfach zu bedienenden und manchmal auch kostenlosen Werkzeugen hat dafür gesorgt, dass Daten nicht immer sinnvoll visualisiert werden. Excel bietet zum Beispiel viele verschiedene Diagramm-Arten, nicht jede davon ist sinnvoll für die Daten, die visualisiert werden sollen. Um es kurz zu machen: Daten-Visualisierung ist nicht einfach, selbst wenn die vielen Werkzeuge es einfach machen.

Tortendiagramme sind zum Beispiel eine häufig verwendete Visualisierung, um Anteile zu zeigen. Allerdings kann hier keine Entwicklung von Anteilen dargestellt werden.

Gestapelte Bar Charts sind dafür eventuell besser geeignet, aber was wenn wir mehrere Anteilsparteien haben und eine Entwicklung über mehrere Jahre zeigen wollen? Ist das dann immer noch eine gute Visualisierung?

Primär geht es bei einer Visualisierung, eine Erkenntnis zu verstärken oder sogar den Erkenntnisgewinn zu beschleunigen. Eine Visualisierung soll helfen, einen Sachverhalt schneller verstehen zu können. Es geht also darum, dass eine Information encodiert werden muss, damit diese schneller vom Empfänger decodiert werden kann.

Hinzu kommt, dass überlegt werden muss, welchen Effekt eine Visualisierung auf einen Betrachter haben soll. Was ist die Intention hinter der Visualisierung? Hier kommen wir wieder zurück auf die Dreifaltigkeit der Daten, nämlich dass nicht nur Daten und Informationen dargestellt werden sollen, sondern auch Aktionen daraus abgeleitet werden können.

Neben der erläuternden Darstellung eines Sachverhalts können Visualisierungen auch dazu genutzt werden, den Nutzer selbst Daten interaktiv explorieren zu lassen.

Logging von Google Analytics Requests via Google Chrome für sendBeacon/beforeUnload

Heute wirds mal etwas technischer. Über die Durchschnittliche Verweildauer in Google Analytics und anderen Webanalyse-Systemen habe ich schon viel geschrieben, sie stimmt in einer Standard-Installation nicht. In einem meiner Kurse sagte dann mal ein Teilnehmer, dass man doch einfach messen könne, wenn der Nutzer den Tab schließt, zum Beispiel mit onbeforeUnload. So ein Trigger ist schnell gebaut, hat aber auch Nachteile. Zunächst einmal ist das nicht zuverlässig, denn ein Benutzer kann auch einfach den Tab wechseln und nicht schließen, engagiert sich aber trotzdem nicht mit den Inhalten meiner Webseite, so dass die ermittelte Time on Site nicht richtig ist. Insbesondere auf mobilen Geräten sehe ich es eher selten, dass Nutzer ihre “Tabs” schließen. Aber darum geht es heute nicht, das ist mindestens einen weiteren Beitrag wert. In diesem Artikel geht es vor allem darum, wie wir überhaupt den Einsatz von onbeforeUnload messen debuggen können. „Logging von Google Analytics Requests via Google Chrome für sendBeacon/beforeUnload“ weiterlesen

Standardfehler und Konfidenzintervall

Wie in der Population gibt es auch in einer Stichprobe Abweichungen vom Mittelwert. Die Streuung um den Mittelwert wird mit der Standardabweichung angegeben, und das gilt auch für eine Stichprobe. Nun haben wir gerade schon die Stichprobenverteilung kennen gelernt, und die Standardabweichung der Mittelwertverteilung (Stichprobenverteilung des Mittelwerts) wird als Standardfehler des Mittels bezeichnet. Das hat nichts mit Fehlern zu tun, es wird damit lediglich die Genauigkeit der Schätzung des Mittelwerts beziffert. Denn tatsächlich wollen wir wissen, wie nah wir wahrscheinlich mit dem Mittelwert unseres Stichprobe an dem tatsächlichen Mittelwert der Population dran sind.

Allerdings haben wir nur theoretisch unendlich viele Stichproben gezogen. In der Realität haben wir meistens nur eine gezogen. Daher können wir den Standardfehler nur schätzen. Dies wird getan, indem die Standardabweichung der Stichprobe durch die Wurzel der Stichprobengröße teilt. Je größer die Stichprobe, desto geringer der Standardfehler.

Das Konfidenzintervall

Der Standardfehler wird benötigt, um das Konfidenzintervall zu bestimmen. Vereinfacht gesagt kann der Standardfehler einfach mit 1.96 multipliziert werden, wenn ein Konfidenzniveau von 95% verwendet wird (die Zahlen sind schon aus den Standardabweichungen bekannt. Das Konfidenzintervall ist also zwischen dem Stichprobenmittelwert minus Standardfehler * 1.96 und Stichprobenmittelwert plus Standardfehler.

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

Erweiterte Tracking-Ansätze

Wir haben bisher nur Web-Daten gesammelt, aber wie in der Einleitung betont, kann heute weit mehr in Google Analytics & Co getrackt werden. Darüber hinaus kann Google Analytics mit einem CRM (Customer Relationship Management-Tool) verbunden werden, so dass die Webdaten nicht für sich allein stehen, sondern mit bestehenden Kunden in Verbindung gebracht werden können.

Das Measurement-Protokoll

Zwischendurch taucht in der Google Analytics-Hilfe ab und zu der Produktname Universal Analytics auf, auch im Tag Manager ist es noch zu sehen (Stand Oktober 2018). Universal Analytics ist eine Weiterentwicklung von Google Analytics und hat die alte Google Analytics-Version (Classic) abgesetzt. Die neue Version hatte viele neue Features, aus denen zwei heraus stachen, das Measurement Protokoll sowie die User ID, die im nächsten Abschnitt behandelt wird.

Das Measurement Protokoll ermöglicht das Senden von Nutzer-Interaktionen über eine API als Rohdaten an Google Analytics, so dass jedes Gerät, das irgendwie ins Internet kann und das HTTP-Protokoll beherrscht, Daten an Google Analytics senden kann. Somit könnte ein mit dem WLAN verbundener Toaster ebenso Tracking-Informationen senden wie eine WLAN-fähige Waage. Die Offline-Welt wird hierdurch mit der Online-Welt verbunden!

Die User ID

Das zweite besondere Feature von Universal Analytics war die Einführung der User ID. Jeder Nutzer erhält von Google Analytics eine Client ID, die aber nur für den jeweiligen Browser auf dem jeweiligen Gerät gilt. Wechselt der Nutzer Browser oder Gerät, so ist er für Google Analytics ein anderer Nutzer.

Mit der User ID kann ein Nutzer über verschiedene Geräte und Browser eindeutig identifiziert werden. Allerdings muss diese User ID von der Webseite generiert und an Google Analytics geschickt werden. Dies ist also nur möglich, wenn sich die Nutzer bei einer Webseite oder App anmelden und somit eine einheitliche ID über verschiedene Geräte und Browser überhaupt möglich ist.

Ein Beispiel, wie diese Techniken miteinander verbunden werden können

Ein Kunde kommt in einen Laden, sucht die Produkte zusammen, die er haben will und geht an die Kasse. Dort zeigt er seine Kundenkarte vor. An Google Analytics wird nun die Nummer der Kundenkarte geschickt (die im CRM mit einer User ID verbunden ist). Gleichzeitig schickt die Kasse noch mit, was der Kunde gekauft hat, in welchem Shop, wie das Wetter draußen ist oder wie lange die Schlange an der Kasse war (was mit Sensoren heutzutage ohne Probleme möglich ist). Am nächsten Tag loggt sich der Nutzer auf der Webseite des Unternehmens ein und prüft, ob seine Loyalty-Punkte gutgeschrieben wurden. Auch hier verwendet er seine Kundenkartennummer, um sich zu identifizieren. Somit können die Besuche on- und offline zusammengeführt werden.

Benutzerdefinierte Dimensionen / Custom Dimensions

Wenn wie im vorherigen Abschnitt erwähnt, zusätzliche Informationen wie Wetter etc gesammelt werden, wo können diese gespeichert werden? Natürlich könnten diese Daten zu einem späteren Zeitpunkt zusammengeführt werden, aber auch Google Analytics bietet in den Bordmitteln bereits die Möglichkeit, weitere Dimensionen zu nutzen, die vom Benutzer selbst definiert werden. In der kostenlosen Variante stehen 20 dieser Dimensionen zur Verfügung.

Für jede Custom Dimension wird ein Scope festgelegt (siehe dazu vor allem die Google Analytics-Hilfe). Dieser Scope kann momentan entweder Hit, Session, User oder Product sein. Beispiel: Für jede Interaktion des Nutzers soll ein Zeitstempel mitgeschickt werden, dies wäre eine Hit-scoped Dimension, da sie sich bei jedem Hit ändert (bei jedem Hit ist die Zeit vorgerückt). Möchte ich aber zum Beispiel einem Benutzer eine eindeutige ID innerhalb einer Session geben, so wäre das eine Custom Dimension mit dem Scope Session. Wichtig: Auch wenn ich bei jedem Hit einen anderen Wert in eine solche Benutzerdefinierte Dimension mitschickte, so würde nachher nur der letzte innerhalb der Session mitgeschickte Wert später in jedem Hit stehen, da dieser dann für die ganze Session gilt.

In diesem Beispiel vergeben wir eine Client ID (das ist die ID aus dem GA-Cookie), die für den User gilt und daher auch diesen Scope hat. Bei jedem Hit schicken wir in der Custom Dimension 2 mit, welcher Art von Hit wir hier haben (pageview, event), in der Benutzerdefinierten Dimension 3 schicken wir für jeden Hit einen UNIX Timestamp mit (das ist die Anzahl der (Mili-)Sekunden seit dem 1.1.1970, so dass es einfacher ist, Differenzen zwischen verschiedenen Zeiten zu berechnen). Die Session ID ist wie oben beschrieben mit dem Scope Session versehen. Und schließlich wird noch die Anzahl der Wörter der gerade besuchten Seite mitgeschickt, hier auch Hit-basiert, denn die Anzahl der Wörter auf einer Seite kann sich von Seite zu Seite ändern.

Die Einführung von Benutzerdefinierten Dimensionen auf Hit-Ebene kann dazu führen, dass die Google Analytics-Daten den ansonsten in der freien Version verwehrten Rohdaten sehr ähnlich werden. Hier ein Beispiel, wie die Daten aussehen, wenn wir sie aus der API holen:

Google Analytics Rohdaten

In diesem Beispiel sieht man 4 der in dem zuvor abgebildeten Screenshot 5 Custom Dimensions, nämlich die Client ID, den Hit Type, den UNIX Timestamp und eine Session ID. Der Nutzer hatte zunächst einen Page View und danach Events ausgelöst, nämlich Scrollen, Starten eines Videos (er schaut es nicht bis zum Schluß an) und dann Scrollen bis zu 75% der Seite. Er löst kein Visibility Event aus, das implizieren würde, dass der Nutzer den Text bis zum Schluss gelesen hat. Diese Sicht auf einzelne Hits der Nutzer ist dann interessant, wenn daraus weitergehende Analysen entstehen sollen wie in dem Abschnitt über die Datenanalyse mit R beschrieben.

Custom Dimensions mit GTM befüllen

Es reicht nicht, die Benutzerdefinierten Dimensionen in Google Analytics zu definieren, irgendwie müssen sie auch befüllt werden. In dem folgenden Beispiel soll das illustriert werden:

Die Custom Dimensions 3 und 4 werden durch Variablen gefüllt, die widerum Custom JavaScript-Variablen sind. D.h., diese kleinen JavaScripte werden zur Laufzeit ausgeführt und ihr Ergebnis in die Variable geschrieben. Das Custom JavaScript für die Variable UNIXTimestamp wird zum Beispiel so erzeugt:

function() {
return new Date().getTime();
}

Da diese Custom Dimension in der Variable für die Google Analytics-Einstellungen definiert ist, wird sie automatiscj bei jedem Hit gefüllt, der diese Variable nutzt. Die Custom Dimensions 1 und 2 werden in diesem Fall in einem customTask erzeugt.