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.

Eine kleine Checkliste

  1. Measurement-Plan erstellen
  2. Webseite erstellen
  3. Google Analytics, Google Tag Manager und Search Console-Accounts einrichten
  4. GTM-Code auf der Webseite einbauen
  5. Tracking in GTM implementieren (Tags, Trigger & Variablen) sowie IP-Anonymisierung und OptOut einrichten
  6. Ziele sowie Custom Dimensions in Google Analytics einrichten
  7. Search Console verifizieren und mit Google Analytics verbinden
  8. Testen, testen, testen 🙂

Eine gute Einführung, wie ein Datenschutz-kompatibler Optout-Link für Google Analytics im Google Tag Manager bereitgestellt werden kann, findet sich hier.

Stichprobenverteilung des Mittelwerts

Die Stichprobenverteilung des Mittelwerts ist zentral für viele Konzepte in der Statistik.

Wenn wir eine Stichprobe aus einer Population ziehen und das Mean berechnen, dann wissen wir nicht, wie weit das Mean unserer Stichprobe von dem Mean unserer Population entfernt ist. Wir könnten uns zum Beispiel dafür interessieren, wie der IQ aller Schüler oder Studierenden im Gebäude ist, aber das es zu aufwändig ist, alle zu testen, nehmen wir eine Stichprobe. Wie wahrscheinlich ist es, dass das arithmetische Mittel des IQs unseres Samples genau mit dem Mittelwert des IQs übereinstimmt?

Tatsächlich wissen wir es nicht. Aber stellen wir uns einmal vor, dass wir nicht nur ein Sample nehmen, sondern ganz viele Samples. Und bei jedem Sample berechnen wir den Mittelwert. Dann können wir alle erhaltenen Mittelwerte der Stichproben plotten, zum Beispiel in einem Histogramm, und dann erhalten wir meistens etwas, das sehr ähnlich aussieht wie eine Normalverteilung. Und das funktioniert auch, wenn unsere Population nicht normalverteilt ist! Ein sehr schönes Tool, um das selber festzustellen, findet sich hier. Dies ist die Aussage des Zentralen Grenzwertsatzes, sofern die Samples groß genug sind. “Groß genug” bedeutet hier, dass sie größer als 30 sein sollten. Dies wird häufig damit verwechselt, dass man nur 30 Beobachtungen benötigt, um statistisch signifikant zu sein. Tatsächlich ist damit nur besagt, dass wir dann annähernd eine Normalverteilung bei der Stichprobenverteilung des Mittelwerts erhalten. Allerdings haben Normalverteilungen viele Eigenschaften, die wir kennen und mit denen wir leichter arbeiten können 🙂 So ist der Mittelwert dieser Mittelwertverteilung ein erwartungstreuer Schätzer des Mittelwerts der Population.

Zur Verdeutlichung dieses Konzepts kann noch dieses Video angesehen werden:

Nun kommt die große Überraschung: Wir nehmen gar nicht mehrere Samples. Wir bleiben bei einem Sample. Alles andere wäre eh zu aufwändig. Aber schon bei einem Sample wissen wir eine ganze Menge, denn da wir uns in einer Normalverteilung befinden, wissen wir, dass sich ca. 95% aller Sample-Means innerhalb von 2 Standardabweichungen +/- vom Mean befinden, von dem wir wissen, dass es dem Populations-Mean sehr nah ist. Der Mittelwert unseres Samples ist also mit einer Wahrscheinlichkeit von ca. 95% innerhalb von 2 Standardabweichungem! Vielleicht haben wir Pech, und wir sind in den 5% außerhalb der beiden Standardabweichungen. Aber vielleicht auch nicht. Statistik ist, wie wir gerade sehen, keine Wissenschaft, in der man sich konkret festlegt, dass etwas zu 100% sicher ist 🙂

Vergleichen wir also 2 Means miteinander, zum Beispiel aus einem Sample mit der Gesamtpopulation und einem Sample aus einer Population, die ein Treatment hatte (ein Kurs bei mir, der Statistik-Verständnis-Pillen genommen hat), dann ist es unwahrscheinlich, dass sich kein Unterschied im Statistik-Verständnis ergeben hat, wenn meine Studierenden nach Konsum der Statisik-Verständnis-Pille im Mean mehr als 2 Standardabweichungen besser abgeschnitten haben. Wir befinden uns also nun bereits im Gebiet der Statistischen Signifikanz und den p-Werten…

Verteilungen

Wir haben im vorherigen Abschnitt über Mean, Median und Modus schon kurz den Begriff der Verteilung angeschnitten: Haben wir sowohl Mean als auch Median, so können wir schon ein bisschen was über die Verteilung aussagen, was an dem folgenden Beispiel deutlich wird:

In einer Normalverteilung liegen Mean, Median und Mode an derselben Stelle. In einer rechtsschiefen Verteilung wie im zweiten Bild, liegen sie nicht an derselben Stelle: Der Mode bei den häufigsten Werten, der Median bei den Werten in der Mitte, und das Mean durch die Ausreißer rechts von Modus und Median.

Denken wir nun noch einmal an das Zielgruppen-Dashboard von Google Analytics zurück. Wir haben hier Durchschnittswerte für

  • Seiten pro Session
  • Sessions pro Nutzer
  • Verweildauer

Hier wird der Mean genutzt, aber wir wissen in diesem Dashboard nichts über die Verteilung dieser Werte. Daher wissen wir auch nicht, wie aussagekräftig der Mean allein als Kennwert für die zentrale Tendenz einer Verteilung ist. Wie wir im vorherigen Abschnitt gesehen haben, kann er uns zu Fehlinterpretationen verleiten.

Umgekehrt können wir nicht davon ausgehen, dass wir nie eine Normalverteilung bei den oben genannten KPIs haben werden. Der Mean kann also, muss aber nicht aussagekräftig sein, so dass den Werten in diesen Dashboards zunächst misstraut werden sollte. Dies ist auch ein Grund, warum daten-getriebene Unternehmen eher selbst mit den Rohdaten von Google Analytics & Co arbeiten als dass sie die GUI nutzen, da sie dann selbst entscheiden können, welche die richtigen Maßzahlen sind.

Nächster Abschnitt: Standardabweichung

Warum Neue und Wiederkehrende Besucher in Google Analytics manchmal mit Vorsicht zu genießen sind

Google Analytics kann mitunter fies sein, denn manche Dimensionen gepaart mit Segmenten verhalten sich nicht so, wie man das zunächst denken mag. Dank Michael Janssens und Maik Bruns‘ Kommentare auf meine Frage in der von Maik gegründeten Analyse-Gruppe kann ich heute beruhigt schlafen gehen und bin wieder ein bisschen schlauer geworden.

Die Frage kam heute im Analytics-Kurs auf: Wie kann es sein, dass ich mehr Neue Nutzer als Transaktionen habe, wenn ich in dem Segment “Hat einen Kauf getätigt” bin? Den Link zum Bericht gibt es hier, die Annahme, die ich hatte, war die: Wenn ich ein Segment von Nutzern habe, die einen Kauf getätigt haben, und dieses Segment im Bericht “Neue vs. wiederkehrende Nutzer” verwende, dann gehe ich davon aus, dass ich in dem Bereich Neue Besucher + Haben einen Kauf getätigt nur die Nutzer sehe, die in ihrem ersten Besuch etwas gekauft haben. Allerdings sehen wir hier in diesem Bericht 691 Nutzer, aber nur 376 Transaktionen. Wenn meine Erwartungshaltung stimmen würde, dann müsste die Zahl hier gleich sein. Ist sie aber nicht. “Warum Neue und Wiederkehrende Besucher in Google Analytics manchmal mit Vorsicht zu genießen sind” weiterlesen

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

Glossar

Absprungrate Es existieren zwei Definitionen. In der einen Definition ist die Absprungrate der Anteil der Nutzer, die sich nur eine Seite ansehen, in der anderen Definition der Anteil der Nutzer, die auf eine Seite kommen und diese “sofort” wieder verlassen. Die letztere Absprungrate wird auch Adjusted Bounce Rate oder angepasste Bounce Rate genannt. Der Standard in den meisten Systemen ist die einfache Absprungrate.
Adjusted Bounce Rate Siehe Absprungrate
Bounce Rate Siehe Absprungrate
CLV Customer Lifetime Value; ein Kunde kauft eventuell nicht nur einmal, sondern mehrmals. Der erste Kauf ist für den Verkäufer nicht profitabel, die weiteren aber schon. Ein gutes Beispiel sind hier Drucker und Tintenpatronen.
CPA Cost per Acquisition, ähnlich wie CPO, wird aber für Transaktionen genutzt, die keine Order sind, zum Beispiel Kosten pro Fan bei Facebook.
CPC Cost per Click, Kosten pro Klick. Bei AdWords wird der Preis für einen Klick auf eine Anzeige zum Beispiel in einer Auktion bestimmt.
CPO Cost per Order, Kosten pro Bestellung. Angenommen, wir bezahlen für die 100 Nutzer im vorigen Beispiel 100 Euro (1 Euro CPC), dann läge der CPO bei einer CVR von 1% bei 100 Euro
CPM/TKP Cost per Mille oder Tausendkontaktpreis. Der TKP ist eine Währung, die schon bei Printmagazinen genutzt wurde und beschreibt wie viel Geld man für eine Anzeige zahlt bei einer Auflage pro 1000 Stück.
CTR Abkürzung für Click Through Rate, auf Deutsch Klickrate. Wird eine Anzeige zum Beispiel 100 Mal eingeblendet und 2 Mal angeklickt, so ergäbe das eine Klickrate von 2%.
CVR ConversionRate, Konversionsrate .Von 100 Besuchern auf einer Website kauft nur einer etwas im Shop, so dass die CVR dann bei 1% liegt
KUR Kosten-Umsatz-Relation, eine Alternative zum CPO. Hier werden die Gesamtkosten (CPO) durch den Umsatz geteilt, auch nach Retouren.
Sitzung/Session Kommt ein Benutzer auf eine Website, so beginnt das,was in Google Analytics eine Sitzung oder auf Englisch Session genannt wird. Der Benutzer schaut sich mehrere Seiten der Website an, alles innerhalb einer Sitzung. In Analytics ist eine Sitzung mit 30 Minuten definiert, wobei diese 30 Minuten immer wieder neu beginnen, wenn der Benutzer mit der Website interagiert. Die Session endet aber spätestens um Mitternacht oder wenn der Benutzer die Website verlässt und über einen anderen Kanal zurückkehrt. Die Sessiondauer kann außerdem definiert werden.
TKP Siehe CPM
Unique User Derselbe Benutzer kann mehrmals auf eine Website kommen und mehrere Sitzungen auslösen. Es ist aber immer derselbe Nutzer und wird als unique user bezeichnet.