Markus Baersch

Software · Beratung · Lösungen

Suche im Blog

Sign In

Monday, 21 November 2016

Das Spam-Experiment: Referrer Spam in eTracker und Piwik Analytics

Zugegeben: Referrer Spam ist ein Google Analytics Problem. Dort finden sich in vielen ungefilterten Datenansichten solche künstlich generierten Einträge in der Liste der verweisenden Websites.

Referrer Spam in Google Analytics

Ebenso hinterlassen Spammer automatisiert erzeugte Spuren in anderen Reports zur Webanalyse: Event-Spam, Page-Spam... und sogar im Language Report werden Daten erzeugt, die im weitesten Sinne der "Bewerbung" zweifelhafter Angebote im Web dienen sollen. Wenngleich es zahlreiche Möglichkeiten zur Behandlung dieses Leids gibt, bleibt Analytics-Spam ein Ärgernis.

Das Measurement Protocol als Auslöser?

Wenn ich mit Webmastern oder Online-Marketern über das Google Analytics Measurement Protocol (GAMP) – und den naheliegenden Zusammenhang mit o. g. Spam – rede, begegne ich häufig der Meinung, dass Webanalyse-Spam ausschließlich deshalb existiert / möglich ist, weil es das Measurement Protocol gibt. Das ist m. E. ebenso zu kurz gedacht wie die daraus abgeleitete Meinung, dass ausschließlich Google Analytics betroffen sei.

Richtig ist: Das GAMP erleichtert Spam allein dadurch, dass hierbei alle Attribute, Signale und Informationen, die üblicherweise "implizit übertragen" werden, wenn ein Trackingaufruf erfolgt (z. B. Browser, Betriebssystem etc.), auf explizite Weise als Parameter mit beliebigen Werten belegt werden können. Denn das ist der Zweck des GAMP. Möglichst alle Informationen, die in Analytics ausgewertet werden können, sollen darüber losgelöst vom üblichen Tracking in Websites und Apps transportierbar werden.

Spammer brauchen Reichweite

Auch ist unbestreitbar, dass Google Analytics allein durch den hohen Marktanteil das meiste Potential für Webanalyse-Spammer bietet. Da ist Google Analytics nicht allein. Windows galt so lange als besonders angreifbar und "Virenplattform", bis auch der Mac – oder später das iPhone und Android-Smartphones – genug Marktanteil erreicht hatten, so dass es in Sinne einer hohen Verbreitung auch auf diesen Plattformen "sinnvoll" erschien, Viren und Schadprogramme bereitzustellen. Ebenso existieren nur deshalb so viele bekannte Hacks und Angriffsvektoren für Wordpress, weil es so weit verbreitet ist. Das bedeutet nicht, dass andere Systeme per se sicherer wären... nur eben "uninteressanter" für die Masse der Spammer.

Ebenso verhält es sich mit Webanalyse-Spam. Google Analytics bietet zwar zusätzlich zur hohen Verbreitung und dem Measurement Protocol noch den großen "Vorteil"; dass Spammer einfach beliebige Property-IDs "raten" und eine Zeitlang mit Daten beschießen können, ohne dass man solche Angriffe auf einzelne Websites richten muss, aber spätestens dann, wenn eine bestimmte Website im Visier steht, können mit vertretbarem Aufwand auch andere Systeme angegriffen werden.

Das Spam-Experiment

Eine besuchte Webseite mit einem Trackingcode eines beliebigen Anbieters muss die benötigten Informationen zum jeweiligen Trackingserver übertragen. Dazu werden i. d. R. durch den Trackingcode bestimmte URLs auf den Servern des Systemanbieters aufgerufen, deren Parameter einige der Angaben wie z. B. den Seitentitel, Informationen über die Herkunft des Besuchers und auch dessen Identifikation beinhalten. Hier sollte es also auch bei anderen Anbietern unter Verwendung der passenden Werte für die Identifizierung der jeweiligen Domain und des zugehörigen Tracking-Profils beim Trackinganbieter möglich sein, über automatisierte Aufrufe künstliche Daten in der Webanalyse zu erzeugen, die nichts mit realen Besuchern der Website zu tun haben und für die auch kein Browser erforderlich ist.

Aus dieser Perspektive habe ich mir eTracker und Piwik als verbreitete alternative Lösungen ausgewählt, dort Testaccounts zum Befeuern angelegt und dann den abgesetzten Hits der jeweiligen Trackingcodes über die Schulter geschaut.

Grundsätzlich braucht man für Referrer Spam nicht viel. Es müssen nur "irgendwie" künstliche Ereignisse wie z. B. Seitenaufrufe erzeugt werden, die als Herkunft eine bestimmte verweisende Website ausweisen müssen. Hat man dabei keinen besonderen Ehrgeiz, diese falschen Hits mit entweder möglichst vielen Informationen anzureichern oder auf der anderen Seite möglichst viele für das gesetzte Ziel unnötige Informationen zu übertragen, reichen i. d. R. ein paar wenige Versuche aus, die man für den Start sogar selbst direkt im Browser aufrufen kann. Gleicht man die Parameter zusätzlich mit den Informationen ab, die im jeweiligen Cookie gespeichert werden, den man sich beim ersten Testaufruf einer mit dem realen Code getaggten Seite einfängt, kann man auch eine beliebige Anzahl von verschiedenen Benutzern simulieren, wenn man nicht nur Seitenaufrufe, sondern auch möglichst viele Besucher / Sessions erzeugen möchte. Denn Spam ist ja nur dann wirkungsvoll, wenn er in Reports in den jeweiligen Top-Listen auftaucht.

Automatisierter Referrer-Spam

Für den reinen Nachweis der Machbarkeit würde jeweils ein einziger Hit ausreichen, den man ohne den üblichen Weg über die vermessene Website in die Webanalyse gebracht hat. Das macht aber zu wenig Spaß ;) Daher habe ich mein ursprünglich (freilich nur zu Demonstrationszwecken!) auf Google Analytics ausgerichtetes Spamscript (liebevoll den "Astleynator" genannt) so angepasst, dass auch passende Hits für eTracker und Piwik abgesetzt werden können.

Damit habe ich den jeweiligen Seitenbericht so lange mit Fakedaten bespielt, bis er den Text von Rick Astleys Jahrhundertwerk wiedergibt, wenn man die Seiten (bzw. im Fall von eTracker die Titel) absteigend nach Seitenaufrufen sortiert. Jeder der Hits hat der Einfachheit halber einen erfundenen Spam-Domainnamen als Referrer mitgebracht, um eben vor allem dort ähnliche Spuren zu hinterlassen, wie sie auch von Spammern in Google Analytics generiert werden.

Fake-Verweise im eTracker...

Das Ergebnis zeigt, dass auch mit eTracker vermessene Websites zum Ziel solcher Angriffe werden können. Allerdings nicht so "leicht" wie bei Google Analytics, denn man muss sich hier vorher tatsächlich vom realen Trackingcode abgesetzte Hits ansehen und sich dort neben der ID (die auch im Trackingcode selbst steht) noch einen Hashwert (Parameter dh) abholen, um dann eigene Hits erfolgreich in die Reports zu bekommen.

Referrer Spam in eTracker

Die hier ausgewiesenen Seitenaufrufe erzeugen korrekt sortiert den o. a. "Rick Astley Report":

eTracker Rickrolled

... und in Piwik

Nach gleichem Muster kann man auch Piwik mit falschen Daten versorgen. Dazu muss man hier offenbar nur wissen, an welchen Server (eigener Trackingserver oder Subdomain bei der Hosted-Variante) die Hits gesendet werden müssen; der Rest besteht aus wenigen Parametern wie URL, Titel der Seite und dem Referrer, den man vorspiegeln will. Schon kann man hier das gleiche Ergebnis erzeugen.

Referrer Spam in Piwik

Auch hierzu der passende "Rick Astley Report":

Piwik Rickrolled

Fazit

Zwei andere Systeme sind noch lange nicht "alle anderen". Es ist durchaus denkbar und mit recht simplen Mitteln lösbar, solche Spam-Attacken abzuwehren; es besteht nur kaum eine Veranlassung dazu, weil es dort kein vergleichbares massenhaftes Spam-Problem gibt. Auch kann man nicht überall (wie bei Google) alle beliebigen Attribute selbst mit Daten belegen. So wäre es im Fall des eTrackers z. B. auch etwas komplexer, dort Event-Spam zu hinterlassen oder jenseits von Kampagnenparametern, dem Referrer und der Seite andere Merkmale zu belegen. Jedenfalls nicht mit dokumentierten Parametern wie im Fall des Measurement Protocols.

Nur weil andere Systeme aber nicht im Fokus von Spammern stehen, sind diese nicht automatisch sicherer. Zumindest das sollte mit diesem Experiment ausreichend nachgewiesen sein. Und wer schon immer Lust hatte, etwas anderes als eine Website zu messen und dabei nicht auf Google Analytics zurückzugreifen, mag sein nächstes Logging – Projekt ja vielleicht mit Piwik statt Analytics umsetzen. Falls ja: Lass es mich wissen ;)

# 
Tuesday, 22 December 2015

Vergleich: Serverseitiges Bot-Tracking mit Analytics vs. Logfile-Analyse

Das hier im Blog gezeigte Verfahren zum Bot-Tracking nutzt die gewohnten Reports aus Google Analytics, um mehr über Häufigkeit und Tiefe der Besuche von Bots zu erfahren. Um herauszufinden, wie zuverlässig diese Methode ist, habe ich - konzentriert auf Besuche des Googlebot - exemplarische Daten einer Website von zehn Tagen aus Analytics mit den passenden Serverlogfiles verglichen. Das Ergebnis: Es besteht weniger als 2% Abweichung zwischen den Ergebnissen.

Methode und Datenquellen des Vergleichs

Im Fall der serverseitigen Datensammlung wurden ausschließlich Besuche des Googlebots als eigenes Segment in einem Analytics-Profil betrachtet und der Seitenreport des betreffenden Zeitraums als Vergleichsbasis verwendet. Dabei wurde das Tracking nach der im oben verlinkten Beitrag gezeigten zweiten Variante durchgeführt und durch Anpassung des "Bot-Arrays" auf den Googlebot beschränkt (ohne Mediapartners und AdsBot).

Um die passenden Daten aus den Serverlogs zu extrahieren, wurden die Logfiles mittels Graylog ausgewertet. Eine passende Umgebung nebst kleiner Anleitung dazu hat Michael Janssen auf GitHub beigetragen. Die mittels Graylog aufbereiteten Daten wurden exportiert und mit den ebenso aus Analytics an Excel übergebenen Daten in einer Tabelle zusammengeführt. Mit etwas Excel-Salz werden die Seitenaufrufe pro Tag und deren Verteilung auf einzelne Seiten miteinander vergleichbar.

Importfehler = Messfehler

Es ist üblich, dass einzelne Einträge aus Logfiles nicht wunschgemäß verarbeitet werden können. Das war bei einigen Zeilen der Logs aus den untersuchten zehn Tagen - leider - ebenfalls so. Einige dieser fehlerhaften Zeilen betreffen vermutlich auch den Googlebot. Diese Fehler - und die relativ geringe Menge an Daten, die der wenigen Zeit geschuldet sind, die seit der Implementierung des serverseitigen Bot-Trackings auf meiner Domain vergangen ist - lässt die o. g. Zahl von 2% zurecht unsicher erscheinen. Ich war aber schlichtweg zu neugierig, um länger zu warten ;) Ich werde den Vorgang noch einmal mit den Daten eines Quartals wiederholen. Sollten die Ergebnisse nennenswert abweichen, werde ich Details hier nachreichen.

Ergebnis im Detail

Der Vergleich zeigt Abweichungen von maximal einem oder zwei Seitenaufrufen bei insgesamt 54 vom Googlebot besuchten URLs. Die Auswertung zeigt nur 53 davon. Die Startseite wurde - zu Gunsten der Aussagekraft von Balkendiagrammen - bei der Visualisierung ausgeklammert. Im Vergleichszeitraum hat der Googlebot jeden Tag mehrere Seiten besucht. Insgesamt wurden in Analytics 165 Seitenaufrufe von Unterseiten und 67 Aufrufe der Startseite verzeichnet.

Bot-Traffic nach Tagen

Die Besuche nach Tagen liefern in Summe eine übereinstimmende Anzahl an Hits. Allerdings liegt mal bei Analytics und mal im Logfile die Anzahl um einen, maximal zwei Hits höher. Eine Übereinstimmung in der Gesamtanzahl bedeutet, dass neben den potentiell fehlenden Hits in den ausgewerteten Logfiles (siehe oben) also gelegentlich auch Hits offenbar nicht in Analytics ankommen. Die Erklärung ist vermutlich die begrenzte Zeit, welche in das Absetzen der Messpunkte per Measurement Protocol beim serverseitigen Tracking investiert wird.

Auf Seitenebene ist das Bild ähnlich. Es gibt zwar Abweichungen von maximal zwei Hits pro Seite, dennoch sind in beiden Berichten jeweils alle betroffenen Seiten zu finden.

Bot-Traffic nach Seiten

Stört das Tracking den Googlebot?

Eine Frage, die sich im Zusammenhang mit der theoretisch vergrößerten Latenz der eigenen Website durch das serverseitige Tracking stellt, ist die nach unerwünschten Nebenwirkungen auf das Crawlverhalten. Soweit sich dies aus den (mit den üblichen Schwankungen versehenen) Diagrammen der Google Webmaster Tools (na gut: Google Search Console) ablesen lässt, scheint dies nicht der Fall zu sein. Sowohl die Ladezeiten als auch die Anzahl der besuchten Seiten zeigen keinen erkennbaren Trend.

GSC Crawling Statistik

Fazit

Mit dem Tracking aller Bot-Aufrufe via Measurement Protocol in Analytics sind die im o. g. Beitrag genannten Fragen wie z. B. nach Besuchstiefe, Frequenz oder dem Verhalten auf Ebene einzelner URLs mit vergleichbarer Zuverlässigkeit zu beantworten, ohne sich den üblichen Mühen der Logfileanalyse zu unterziehen. Vertraute Reports und simple Drill-Down-Möglichkeiten in Google Analytics liefern einen detaillierten Blick auf das Verhalten des Googlebots, soweit es um die dabei erfassten Inhalte geht.

Selbst mit den Einschränkungen, die die Beschränkung auf "Contentseiten" aus dem CMS bei der vorgestellten Implementierung mit sich bringt, ist diese Methode m. E. eine sinnvolle (weil nach einmaliger Implementierung jederzeit verfügbare) Ergänzung zur üblichen Logfileanalyse. Diese spielt zwar in den Bereichen Fehler, Statuscodes und Ressourcen nach wie vor ihre Stärken aus, wird aber i. d. R. nicht so regelmäßig durchgeführt, wie es angebracht wäre. Ohne diese eher technische Ebene steht in der Analytics-Variante aber eigentlich alles zur Verfügung, was die typischen "Marketingfragen" im Zusammenhang mit dem Googlebot betrifft.

# 
Monday, 23 November 2015

Das Google Analytics Measurement Protocol: Dem Googlebot zuschauen (serverseitiges Tracking)

Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol. Diesmal geht es wieder um den Kern von Analytics: Echte Webanalyse. Nur schauen wir nicht (nur) auf reale Besucher, sondern primär auf Bots, die sich naturgemäß sonst aus der Sache gern heraushalten. Statt Spambots auszuschließen, laden wir diesmal also Crawler ein, sich von uns über die Schulter schauen zu lassen.

Alle Teile dieser Serie

Serverside: Vor- und Nachteile

Wie im zweiten Beitrag angesprochen, kann man mit serverseitigem Tracking eine Menge Probleme umgehen. Nicht nur, aber auch das aktive Blockieren von Trackingmaßnahmen und die "Unsichtbarkeit" des Trackings sind für viele ein schlagendes Argument, auf diese Variante zu setzen.

Dafür werden Dinge plötzlich zu Problemen, die von Anbietern in diesem Bereich unterschiedlich angegangen werden müssen, während das clientseitige Tracking per JavaScript davon kaum betroffen ist. Der Cache des Browsers ist ein solcher Kandidat, denn eine vorher besuchte Seite wird damit nicht neu vom Server abgerufen, während das JavaScript-Tracking den Hit davon unbeeindruckt an die Webanalyse sendet. Proxies, CDNs etc. kommen als weitere Problemquellen dazu. Da wir uns hier aber nicht mit Problemen, sondern neuen Einsatzgebieten des Measurement Protocols befassen wollen, schieben wir diese Punkte erst einmal beiseite. Die meisten Sites betreiben ohnehin klassisches Tracking und auf diese Zahlen wollen wir auch gar nicht verzichten.

Serverside Tracking mit dem Measurement Protocol: Einsatzmöglichkeiten

Seitenaufrufe und Sitzungen der gleichen Website zu vergleichen, die sowohl client- als auch serverseitig gesammelt wurden, kann ungeachtet dieser Einschränkungen interessante Einblicke gewähren. Außerdem bekommen wir am Server alle Hits mit; also auch die vom geliebten Googlebot und anderer Besucher. Deren Spuren bleiben oft in nie ausgewerteten Serverlogs verborgen - das soll hier mit Hilfe von Google Analytics geändert werden.

Kein Ersatz für Logfileanalyse

Das folgende Beispiel soll möglichst alle Hits erfassen, die Seiten betreffen, welche von einem PHP-basierten CMS ausgeliefert werden. Das kann z. B. Wordpress sein. Alles andere wird allerdings dabei bewusst nicht abgedeckt. Nun besteht eine Website aber aus einer ganzen Menge an weiteren Dingen wie Bildern, Scriptfiles, CSS-Dateien, PDFs, Downloads und mehr. Während in einem Serverlog alle Zugriffe auf diese Ressourcen nachverfolgen lassen, beschränken wir uns auf "CMS-Inhalte" im weitesten Sinn. Durch andere Ansätze, die direkt am Server implementiert werden, können solche Lücken zwar geschlossen werden, aber im Sinne eines möglichst einfachen Beispiels begnügen wir uns mit dem, was das CMS ausliefert.

Ebenso kann anders als hier bei der Logfileanalyse auf Besonderheiten wie Zugriffe auf nicht vorhandene, nicht öffentlich zugängliche oder weitergeleitete URLs geschaut werden. Selbst mit diesen Einschränkungen kann ein "Bot-Tracking" über das Measurement Protocol viele spannende Fragen beantworten. Unter anderem:

  • Welche Bots kommen überhaupt auf meine Site?
  • In welcher Tiefe und Frequenz befasst sich der Googlebot (oder ein anderer) mit den Inhalten?
  • Wann wurde Seite x zuletzt von Bot y besucht?
  • Wie lange brauchen neue Inhalte, bis diese gefunden und besucht wurden?

Obwohl sich das unten stehende Implementierungsbeispiel primär auf Bots konzentriert, werden alle anderen Besucher mit getrackt und - zumindest zum Teil - anhand des _ga Cookies identifiziert, der für das klassische Tracking mit Analytics zuständig ist. Es wird also unterstellt, dass Analytics bereits genutzt wird. Ist das nicht der Fall, landen die "echten" Besucher alle in einem Segment für "Unbekannte" Hits.

Auch kein Ersatz für klassische Implementierung?

Nein, in dieser Form für die meisten Sites nicht. Das liegt an einer Einschränkung beim Tracking echter Besucher, die hier der Einfachheit halber nicht gelöst wurde: Der Einstieg eines Erstbesuchers. Dieser ist in diesem vereinfachten System problematisch, weil der zur Identifizierung erforderliche Cookie erst nach dem Aufruf der ersten Seite generiert wird. Ein Henne/Ei-Problem also. Das kann man lösen; es soll hier aber vereinfachend nicht beachtet werden. Für einen Vergleich von Zahlen reicht es zu wissen, dass ein Teil der Sitzungen "bekannter" Besucher im Segment für die "Unbekannten" steckt, so dass die Besuchsdauer, Anzahl der Seiten / Besuch und auch die Gesamtzahl aller Sitzungen direkt davon beeinflusst werden.

Für Portale oder Anwendungen, die hinter einem Login liegen, reicht das Beispiel hingegen schon aus, um alle Daten zu erheben, die bei der Auswertung normalerweise benötigt werden... solange es nicht um den Weg vor der Login-Seite geht.

PHP-Codebeispiel

Der folgende Code zeigt zwei Varianten einer abgeschlossenen Funktion, welcher als Parameter nur der Dokumenttitel übergeben werden muss, der beim Hit verzeichnet werden soll - diese Information hat man i. d. R. spätestens bei der Generierung des Footers einer Seite in einer Variable zur Verfügung. Ist der Titel unbekannt, wird die Funktion zur Not mit einem konstanten Titel versorgt... primär interessiert bei Besuchen von Bots ohnehin eher die URL. Die Variante A trackt alle Besucher, Variante B beschränkt sich auf Bots.

Was passiert da?

Zunächst benötigt die Funktion zur Konfiguration die Angabe der Profil-ID aus Analytics $ua und darunter als $segments ein Array von Angaben zu Bots, die zu einer eigenen "Quelle/Medium"-Kombination führen sollen. So sind diese später separat auszuwerten oder per Filter in eigenen Datenansichten zu sammeln.

Das "Bot-Array"

Weil ich jedem Bot eine eigene ID geben will und mein Gesang besser ist als mein PHP, habe ich vermutlich nicht die effizienteste Lösung gewählt, um Bots zu erkennen. Sie reicht (mir) aber aus. Im Array ist für jeden Bot ein Key/Value-Paar vorhanden, in dem der Key der cid eines eindeutigen Nutzers entspricht, so dass jeder Bot als separater Nutzer in Analytics gezählt wird. Der String-Value enthält zuerst den gewünschten "Klarnamen" des Bots, wie er später im "Medium" wieder zu finden sein soll und nach einem "::" als Trenner ein RegEx-Filtermuster, anhand dessen der Bot erkannt wird.

Dabei muss man sich mit Regular Expressions nicht großartig auskennen, denn alle Bots, die als solche erkannt werden wollen, nennen sich "IrgendwasBot" in der einen oder anderen Form, so dass man mit reinen Zeichenketten ohne RegEx-Besonderheiten auskommt. So enthält im Beispiel (außer Google und Baidu) keine der angegebenen Regeln mehr als nur den Namen des Bots aus dem User Agent in Klammern. Im Fall von Baidu gibt es zwei unterschiedliche Schreibweisen, die beide abgedeckt werden sollen. Zur Trennung von optionalen Zeichenketten als Treffer dient in RegEx ein "|". Die "komplexeste" Definition ist der Googlebot in der ersten Zeile mit dem Muster (Googlebot|Mediapartners-Google|AdsBot-Google), der damit alle Varianten abdeckt. In anderen Fällen möchte man ggf. differenzierter segmentieren und erstellt genauere Muster gemäß der Liste der User Agents, die Google verwendet. Wer bestimmte Bots im Sinn hat, aber nicht genau weiß, welche Kennung(en) diese nutzen, kann entweder nach dem Betreiber bzw. Bot inkl. "User Agent" googeln oder bei UserAgentString.com nachsehen, wo eine beachtliche Liste zu finden ist.

Im Fall der Domain, die unten in den Beispielauswertungen genutzt wird, werden z. B. die Besuche des darauf zielenden Monitors UptimeRobot und ein paar SEO-Tools wie Majestic und andere separat getrackt. Jede Domain wird eine eigene sinnvolle Definition benötigen. Um einzusteigen, reicht ein unverändertes Array und es muss nur eine passende Analytics-ID eingetragen werden, um mit Hilfe des Beispielcodes Daten zu erhalten.

Funktionsweise

Da Variante A dazu dienen soll, alle Besuche zu erfassen, wird zuerst über die oben definierte Funktion get_client_id() der Analytics-Cookie ausgelesen und - wenn vorhanden - die cid des bekannten Besuchers zurückgegeben. In diesem Fall landet der Besucher in einem Medium namens "Tracked Users". Auf diese Weise wird auf ein in der Website integriertes Analytics-Tracking aufgesetzt. Troubleshooting Tipp für ältere Fassungen von Analytics: Wenn auf der Website noch der gute alte pageTracker im Einsatz sein sollte, wird das nicht funktionieren und alle Besucher landen im "Unknown"-Segment. Daher muss die Funktion zur Ermittlung der Id angepasst werden, weil die gesuchten Angaben im Cookie ___utma und nicht in __ga gespeichert sind. Die entsprechende Zeile wie folgt anpassen: $cv = explode('.', $_COOKIE["__utma"]);

Ist damit der Ursprung des Requests nicht geklärt, wird danach die Bot-Erkennung versucht und daraus ggf. eine cid für den Nutzer und ein Medium ermittelt. Schlägt auch das fehl, wird der Einfachheit halber eine konstante cid=555 verwendet und das Medium mit "Unknown" belegt. An dieser Stelle könnte alternativ eine Zufallszahl als cid zum Einsatz kommen, was die Anzahl der Nutzer in Analytics deutlich verändern würde. Für dieses Beispiel reicht ein "Sammelnutzer" aus.

Get To Know "Unknown"

Ganz unbekannt ist nicht, wer hier landet. Es sind zum Einen alle Besucher der Website, die ein Plugin zur Blockierung von Tracking im Allgemeinen oder Analytics im Besonderen einsetzen. Auf meiner Website wären es - wenn das Script in unveränderter Form dort eingesetzt würde - auch alle, die sich im Footer gegen ein Tracking ausgesprochen haben. Eine Echtimplementierung sollte daher ggf. vorhandene Cookies mit Informationen der Wünsche des Besuchers berücksichtigen und ein Tracking unterlassen.

Ebenso finden sich in diesem Segment alle Bots und Crawler wieder, die sich nicht im User Agent String als solcher outen und wie ein normaler Besucher daherkommen. Das ist in manchen Fällen übrigens auch Google (genau: um Cloaking zu entdecken). Und schlussendlich kommen (leider) in dieser vereinfachten Implementierung auch die Aufrufe von Einstiegsseiten aller Erstbesucher dazu, die zu diesem Zeitpunkt noch keinen Cookie des noch auszuliefernden Analytics-Scripts verpasst bekommen haben. Was das bedeutet (und warum das nicht so schlimm ist, wie es klingt), wird unten bei den Auswertungen aus Analytics noch gezeigt. Typischer Ghost-Spam hingegen sollte in einem solchen Profil kaum auftauchen, wenn die Id der Property nicht zufällig vom Spammer erraten und auf gut Glück mit Spam beballert wird.

Übertragung des Pageview-Hits über das Measurement Protocol

Ist eine Entscheidung für ein Medium getroffen und eine Id bestimmt, werden URL der Seite und Referrer ermittelt, die Tracking-URL zusammengesetzt und mittels CURL an Analytics übertragen. Das ist nicht die ideale Lösung, aber es werden zumindest neben dem restlichen Aufwand nicht mehr als 50 Millisekunden investiert, um den Hit abzusetzen. Mit dem Wert für CURLOPT_TIMEOUT_MS kann man je nach Ausstattung des eigenen Servers noch spielen und den Wert so lange reduzieren, bis im Echtzeitbericht des beschickten Profils keine Daten mehr ankommen, wenn man parallel in einem zweiten Tab eine Seite auf der eigenen Site neu lädt (via STRG+F5).

Troubleshooting Tipp 2: Sollte das Ganze übrigens nach Implementierung nicht funktionieren, kann das an der eingesetzten PHP-Version liegen. Im Verdachtsfall die Zeile o. g. auskommentieren. Wenn dann Daten ankommen, auf CURLOPT_TIMEOUT umsteigen und als Wert "1" verwenden, denn in diesem Fall reden wir von Sekunden statt Millisekunden. Mehr als eine Sekunde will bestimmt niemand investieren.

Bei Variante B passiert im Prinzip genau das Gleiche, nur ist die Funktion auf die Bot-Erkennung reduziert und kümmert sich nicht um Cookies oder Besucher mit "normalen" User-Agent-Kennungen. Die Reduktion dient dabei dazu, möglichst keine Zeit zu verschwenden und keine Hits an Analytics zu senden, die für die Erfüllung der Aufgabe des Bot-Trackings nicht erforderlich sind. Die Konfiguration und alles andere stimmen komplett mit Variante A überein.

Was es zu beachten gibt

Wer die Funktion in ein eigenes System implementieren möchte, sollte auf jeden Fall ein separates Profil dafür in Analytics anlegen und gerade bei größeren Sites engmaschig kontrollieren. In vielen Fällen kommen auf diesem Weg schnell sehr viele Daten zusammen, so dass man abwägen muss, welchen Wert man aus den Daten ziehen und wie man sie minimieren oder durch Anpassung des Trackings so organisieren kann, dass sie übersichtlich bleiben.

Das Tracking kostet Zeit. Diese geht direkt in die serverseitige Latenz der Website ein. Wenngleich der Beispielcode den Trackingaufruf bereits "quasiasynchron" absetzt und nicht auf Antwort wartet, sind ausgereiftere Methoden sinnvoll, wenn man damit jenseits von ein paar Tests länger arbeiten will. Es wurde zur Übersichtlichkeit des Beispiels bewusst auf "Overhead" verzichtet. Der Echtbetrieb sollte den Faktor "PageSpeed" aber nicht einfach so ignorieren.

Wer das Tracking z. B. in ein Wordpress-Blog einbauen will, muss dazu nur in der footer.php möglichst weit unten einen PHP-Block einfügen oder im letzten Block, in dem i. d. R. wp_footer() aufgerufen wird, die gewünschte Variante der Trackingfunktion anfügen. Id eintragen, ggf. Bot-Array anpassen und unter der Definition der Funktion diese direkt aufrufen (hier für Variante B, sonst analog mit track_hit()):

track_bot_hit(wp_title('-', false));

Nach dem Hochladen auf den Server sollte der Echtzeitbericht in Analytics direkt Daten anzeigen, wenn man sich für das Tracking aller Besucher entschieden hat und die Site selbst aufruft. Sonst dauert es ggf. etwas, bis der erste Bot vorbeikommt und Spuren hinterlässt. Auf jeden Fall sollte nach der Anpassung des Templates geprüft werden, ob die Site noch funktioniert oder ob Probleme durch die Änderung entstanden sind. Troubleshooting Tipp 3: Kommen keine oder nur verdächtig wenig Daten an, wird das am Einsatz eines der beliebten und sinnvollen Plugins zum Caching in Wordpress liegen. Das macht die Site zwar schnell, hilft aber nicht beim serverseitigen Tracking und muss deshalb wohl oder übel ausgeschaltet werden. Zumindest solange, wie man auf diese Weise Daten über Bots und / oder Besucher sammeln will.

Tipp: Variante B auf "benötigte" Bots beschränken

Wer den Code einsetzt und auf den Kernzweck des Trackings von Bots beschränken will, kann zur schrittweisen Konfiguration und Reduktion der Hits wie folgt vorgehen:

  1. Die eingeschränkte Variante B implementieren und mit den vorkonfigurierten Bots starten
  2. Das Medium für "Other" regelmäßig nach Bots durchsuchen, deren Besuche man separat tracken möchte. Dazu das Tracking so erweitern, dass der User-Agent-String ($agent) z. B. als benutzerdefinierte Dimension übergeben wird, die man dann in Analytics-Berichten einblenden und nach Kandidaten durchsuchen kann. Hier beispielhaft Details zum Googlebot aus einem Testprofil:
    User Agents des Googlebot in Analytics sichtbar gemacht
  3. Für diese Bots eigene Segmente über das Array erzeugen und so "Other" so weit wie möglich minimieren
  4. Bei vielen Hits für jeden relevanten Bot ggf. ein eigenes Profil anlegen.
  5. Nur Tracken, was man tracken muss: Mittelfristig unbekannte oder "irrelevante" Bots aus dem Tracking ausschließen, indem der letzte Eintrag des Segment-Arrays entfernt wird.

Tipp: Parameter ausbauen und Cache Buster nutzen

Da die realistische Möglichkeit besteht, dass identische Requests mehrfach angesetzt werden, sollte die Tracking-URL noch um den Parameter z ergänzt werden, der mit einem Zufallswert zu belegen ist. In den meisten Fällen reicht es aus, dazu date("YmdHisu") zu verwenden.

Weitere Angaben wie die IP des Aufrufs sind per PHP auszulesen und dem Aufruf hinzuzufügen, wenn reale User getracked werden. Die IP dabei zu anonymisieren, sollte dann dazu gehören. Genau wie der Hostname und... Naja: eben möglichst alles, was man in der Referenz bei Google findet, leicht (meint: schnell) auslesen kann und auch wirklich auswerten will.

Das Ergebnis in Google Analytics

Implementiert man die eine oder andere Variante, sammelt selbst eine kleine Website schnell Daten und schon nach einem Tag lohnt sich ein Blick in die Auswertungen unter "Akquisition". Dort sieht man im Bericht zu "Quelle/Medium" die Verteilung der Sitzungen nach verschiedenen Bots - und im Fall von Variante A auch bekannte Besucher und den Rest.

Bots und User in einem Analytics-Profil

Dashboards

Mit diesen Daten lassen sich auch hilfreiche Dashboards aufsetzen, die z. B. neben einer Übersicht über alle Bots einen detaillierteren Blick auf Besuche oder Seitenaufrufe des Googlebots bieten.

Dashboard für Bots in Analytics

Googlebot-Besuche auf Seitenebene

Für jeden Bot lassen sich über das Medium separate Segmente bilden. Damit lässt sich ein zentraler Bericht wie "Verhalten - Website-Content - Alle Seiten" exklusiv für diesen besonderen Besucher anfertigen. Ein Klick auf eine Seite und schon ist erkennbar, wann und wie oft diese von Google besucht wurde. Auch die Information, welche Seiten nicht besucht wurden, ist ermittelbar, wenn man die Daten z. B. per API regelmäßig abgreift und mit der eigenen Sitemap abgleicht.

Seitenaufrufe der Startseite durch den Googlebot

Jede Menge Kennzahlen

Mit solchen Segmenten findet man in fast jedem Analytics-Bericht interessante Daten. Selbst wenn nicht alles stets sinnvoll ist - z. B interessiert die Absprungrate hier wenig -, kann ohne aufwändige Aufbereitung von Logfiledaten direkt in Analytics abgelesen werden, wie oft der Googlebot in einem beliebigen Zeitraum vorbeigekommen ist, wie viele Seiten er sich angesehen hat, wie viel Zeit er "auf der Site" verbracht hat. Nett, oder?

Eigene Analytics-Kennzahlen für den Googlebot

Und die echten Besucher?

Abschließend noch einmal zu den Segmenten "Tracked Users" und "Unknown". Wer sich entscheidet, auch diese serverseitig nachzuverfolgen, sollte ernsthaft über einen Ausbau des Systems nachdenken, um die "Tracked Users" möglichst auch um neue Einstiege zu ergänzen. Dazu reichen serverseitig verwaltete Kennungen als Ersatz zum Analytics-Cookie, der eine parallele clientseitige Implementierung voraussetzt.

Aber selbst ohne Anpassung sind die entstehenden Daten durchaus brauchbar. Vor allem, wenn man bedenkt, dass keine Webanalyse die Wahrheit sagt, wenn es um absolute Zahlen geht, reichen die so gesammelten Daten z. B. für Periodenvergleiche und Langzeittrends. Man sollte aber bedenken, dass clientseitig erhobene Daten in Analytics i. d. R. weitaus vollständiger sind, was den Umfang der pro Hit gesammelten Angaben angeht. Betrachtet man beide Methoden, sind die Ergebnisse zumindest "grob vergleichbar". Dennoch weichen die absoluten Zahlen je nach Zusammensetzung der Besucher sehr stark ab. Konzentriert man sich auf die "Tracked User", sind die Metriken potentiell zu klein, mit "Unknown" zusammengelegt oft um den Faktor 10 oder mehr höher als im parallel betriebenen "klasssischen" Profil. Trends hingegen lassen sich sowohl über längere Zeiträume als auch auf Tagesbasis vergleichen. Sieht man sich die beiden Kurven aus entsprechenden Profilen an, ist der Verlauf vergleichbar:

Das sieht Analytics im Client
Das hat Analytics an diesem Tag durch klassische Sammlung per Trackingcode am Client gesammelt.

Analytics-Verlauf aus Serversicht
Die Zahlen des gleichen Tages für die "Tracked User" des serverseitigen Analytics-Profils: Anders, aber nicht grundsätzlich falsch.

Dass hier bei der zweiten Variante z. B. die Absprungrate anders aussieht, ist nachvollziehbar, denn es fehlt dem zweiten Datenpool jeder Einstieg eines neuen Besuchers - darum sind auch Metriken wie die Seiten pro Besuch potentiell geringer. Trotz solcher Mängel ist diese Methode zur Sammlung von Daten für viele Anwendungsfälle interessant. Wo mit einer eigenen Id für den (z. B. angemeldeten) Benutzer gearbeitet werden kann, verschwinden die meisten Ursachen für die gezeigten Unterschiede zum "normalen" Tracking. Spätestens die Möglichkeit zum Tracking von Bots sollte ausreichen, um eine Implementierung in Betracht zu ziehen - auch parallel zur üblichen Webanalyse und tiefer Tauchgänge in Logfiledaten, die nach wie vor ihren Sinn haben.

Inspiriert?

Wer sich durch die ganze Artikelserie gekämpft hat, wurde hoffentlich mit einem tieferen Einblick und Verständnis für die zahlreichen Möglichkeiten beglückt, die sich mit dem Measurement Protocol ergeben. Ich für meinen Teil habe nun so viel an der Oberfläche gekratzt, dass mir praktisch jeden Tag neue Ideen für den Einsatz kommen. Einen Teil davon werde ich umsetzen und die Serie ggf. um Anwendungsbeispiele und Hinweise erweitern. Umgekehrt freue ich mich über jeden Kommentar mit Vorschlägen zur Verbesserung oder Erweiterung.

# 

Das Google Analytics Measurement Protocol: Stornierte Transaktionen und Retouren

Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol. Der Artikel zeigt auf, wie man bereits in der Webanalyse vermerkte Transaktionen sauber rückgängig macht und was genau dabei mit den Daten in Analytics passiert.

Alle Teile dieser Serie

Transaktionen in Google Analytics

Alle möglichen Quellen beschießen Google Analytics mit Transaktionsdaten. Ein Großteil davon sind Abschlussseiten von Checkout-Prozessen in Onlineshops. Jeder Verkauf wird als Transaktion inkl. einer eindeutigen Nummer und den im Warenkorb enthaltenen Artikeln nebst Mengen und Preisen in Analytics vermerkt und kann dort ausgewertet werden.

Davon abgesehen, dass der einzig richtige Platz zur Auswertung zuverlässiger Zahlen zu Online-Umsätzen nicht die Webanalyse, sondern die eigene Warenwirtschaft bzw. Buchhaltung ist, hat jeder Shopbetreiber trotzdem ein großes Interesse an möglichst sauberen Daten in Analytics. Nur so lassen sich Umsatz nach Kanal und Rentabilität von Kampagnen vernünftig auswerten und zur Steuerung von Budgets einsetzen.

Spielverderber Realität: Retouren und Stornos

Leider hat nicht jeder der erfassten Umsätze Bestand. Hohe Retouren- bzw. Stornoquoten können die Verhältnisse enorm verschieben. Da üblicherweise nicht alle Besucher aus allen Kanälen das gleiche Stornoverhalten aufzeigen, ist eine Korrektur von "gebuchten" Umsätzen parallel zu den eigenen ERP-Systemen auch in Analytics ein häufiger Wunsch.

Dazu liefert Google schon seit der Geburt des E-Commerce-Trackings Hinweise zu Stornomöglichkeiten. Die Hilfe erklärt genau, was zu tun ist. Auf dieser Basis existieren zahlreiche Systeme, die entweder von Haus aus oder per "angestrickter" Erweiterung in der Lage sind, Umsätze zu erkennen, welche aus einem Shopsystem stammen und gesondert zu behandeln. Die komfortabelste Lösung ist dabei bisher der Aufruf eines Links oder ein vom System automatisch geöffnetes Browserfensters. Geöffnet wird eine Seite, der als Parameter die erforderlichen Infos übergeben werden, um eine Stornotransaktion an Analytics zu übertragen. Dabei nimmt die "Gegentransaktion" den gleichen Weg wie der ursprünglich gebuchte Umsatz - über das Standard-Tracking von Google Analytics.

Auftritt Measurement Protocol

Seitdem es Universal Analytics und das Measurement Protocol gibt, besteht kein Bedarf mehr für Links und geöffnete Browserfenster. Jeder Client kann unter den gleichen Bedingungen entsprechende Hits direkt an den Analytics-Server senden.

GA MP FTW!

Dass ein System in der Lage ist, ohne Interaktion des Erfassers eines Stornovorgangs oder störender Eingriffe im Browser auszukommen, ist für sich genommen schon ein ausreichender Vorteil, um eine Umsetzung zu rechtfertigen. Man kann die Übertragung an Analytics zudem komplett entkoppeln und zu einem späteren Zeitpunkt erledigen. Das ist nicht nur, aber besonders bei mobilen Anwendungsfällen oder offline erfolgender Datenerfassung ggf. sogar der einzige Weg.

Unmittelbar in der Anwendung oder basierend auf Stornologs bzw. direktem Zugriff auf die Datenbank der ERP-Anwendung kann zentral (und bei zuverlässiger Internetverbindung) zu definierten Zeitpunkten der Abruf aller Stornodaten erfolgen, die dann im Batch an Analytics gesendet werden. Untersucht man dabei die Pakete auf Einhaltung der in den Praxistipps beschriebenen Limits, hat man einen sicheren und komfortablen Weg zur komplett automatisierten Abwicklung des Vorgangs. Dabei muss - lesenden Datenzugriff vorausgesetzt - noch nicht einmal das System selbst dazu in der Lage sein. Die Übergabe kann vollständig extern gelöst und angebunden sein - ein Zurückspielen von Informationen in die Datenbank ist nicht erforderlich (dort ist alles bereits passiert). Solche Lösungen sind zwar unter entsprechendem Aufwand auch auf dem klassischen Tracking-Weg umsetzbar... mit dem Measurement Protocol ist dieser Part aber ein Fünfzeiler und man kann sich voll auf den Datenzugriff und die Verarbeitungslogik konzentrieren. Das spart reichlich Code, Aufwand (auch in der Wartung), Zeit, Implementierungskosten. Und sorgt für weitestgehende Unabhängigkeit vom System sowie dessen Updatezyklen, solange sich in der Datenbank nicht zu viel ändert. Win Win Win Win!

So sehen Transaktionen und Stornos als MP-Hits aus

Da auch das Senden von Transaktionen und nicht nur deren Stornos über das Measurement Protocol interessante Anwendungsfälle (wie z. B. paralleles Tracking von Warenkörben mehrerer Shops an zentraler Stelle) erlaubt, fangen wir mit einer "normalen" (aber sehr simplen) Transaktion an:

//Transaktion - der Einfachheit ohne Affiliation, Steuer oder Versandkosten https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=transaction&ti=TRANS123&ta=&tr=300&ts=0&tt=0&cu=EUR&aip=1

//Der (einzige) enthaltene Artikel wird als Item hinterher gesendet. https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=item&ti=TRANS123&in=Artikelname+hier&ip=300&iq=1&ic=ART321&iv=green&cu=EUR&aip=1
//Hier könnten in anderen Fällen weitere Positionen folgen

Die Transaktion mit der Nummer TRANS123 übergibt einen Umsatz von 300,-- Euro an die Webanalyse. Der einzige Artikel (ein Stück) ist "Artikelname hier" (Nummer ART321) in grün. Normalerweise wird eine solche Transaktion nicht auf dem Weg des Measurement Protocols, sondern über das klassische Tracking übertragen. Will man sie wieder loswerden, können zwei passende Hits per Measurement Protocol den Vorgang rückgängig machen (wie spurlos das passiert, sehen wir noch). Zwei Hits bedeutet auch etwas, das vielleicht nicht für jeden offensichtlich ist: Artikel eines Auftrags verschwinden nicht automatisch, wenn die zugehörige Transaktion storniert wird. Es ist stets ein separater Hit des Artikels erforderlich - bzw. mehrere Hits, wenn beim Kauf mehr als nur ein Produkt im Warenkorb lag. Bleiben wir beim obigen Beispiel mit nur einem übergebenen Artikel. So sehen die beiden Hits zum kompletten Stornieren aus:

//Transaktion mit gleichen Angaben, diesmal aber mit negativem Vorzeichen beim Umsatz https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=transaction&ti=TRANS123&ta=&tr=-300&ts=0&tt=0&cu=EUR&aip=1 //Auch der Artikel wird storniert - durch negative Menge https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=item&ti=TRANS123&in=Artikelname+hier&ip=300&iq=-1&ic=ART321&iv=green&cu=EUR&aip=1

Bei Transaktionen erhält der Umsatz ein neues Vorzeichen, bei Artikeln die jeweilige Menge. Nicht der Betrag. Obwohl auch das - zumindest "ein wenig" - funktioniert. Was das bedeutet, zeigt der nächste Absatz. Wird der Artikel aber sauber storniert, gibt es zwar zwei Vorgänge in Form einzelner Käufe in Analytics dazu, aber Nullen beim Umsatz der resultierenden Menge.

Korrekt stornierter Artikel
Ein korrekt stornierter Artikel erlaubt saubere Auswertung von Stückzahlen und Umsätzen

Korrektes Stornieren... und wie es danach in Analytics wirklich aussieht

Vorbemerkung: Das obige Beispiel ist absichtlich stark vereinfacht. Sind Versandkosten und Steuern im Spiel, müssen auch diese bei der Transaktion entsprechend behandelt und deren Vorzeichen umgekehrt werden, wenn sie "ausgebucht" werden sollen. Außerdem ist es bei Stornos nicht immer erforderlich, die ganze Transaktion zu stornieren, sondern ggf. nur einzelne Positionen. Das Prinzip bleibt jedoch das Gleiche: Die Produkte werden je nach Umfang als komplette Position oder nur als negative Teilmenge storniert, Umsätze und Steuerbeträge der Transaktion um die Umsätze der stornierten Posten verringert.

Das beinhaltet, dass alle übrigen Umsätze der Transaktion und die verbleibenden Artikel in Analytics erhalten bleiben. Aber was bedeutet ein "Vollstorno"? Ist dann wirklich alles "weg"? Nein.

Stornieren ist nicht "Löschen"

Unterstellen wir eine Transaktion mit der schönen Nummer REINRAUS, deren "Storno-Hit" bereits verarbeitet wurde, deren Artikel aber noch im Datenbestand sind. Solange nicht alle Artikel einer Transaktion storniert werden, bleibt diese erwartungsgemäß bestehen.

Stornierte Transaktion, erhaltene Artikel

Nach dem Storno aller Artikel ist die Transaktion offenbar verschwunden, obschon man in der Grafik noch erkennen kann, dass es einen Hit mit negativem Umsatz gegeben haben muss. Die Summen, Durchschnitte etc. wurden aber erwartungsgemäß komplett korrigiert.

Transaktion mit letztem Artikel verschwunden

Was genau passiert sieht man genauer, wenn man wie gerade gezeigt einen Artikel erst einen Tag später als die Transaktion selbst storniert und sich die E-Commerce-Daten auf Tagesbasis ansieht. An Tag 1 sind Transaktion und Artikel zu sehen, der Umsatz ist frisch gebucht. An Tag 2 wird die Transaktion storniert, bleibt aber wegen der verbleibenden Artikel (bzw. deren Menge) noch in der Auswertung.

Transaktion ist noch da

Storniert man nun an Tag 3 auch den Artikel (mit korrekten Vorzeichen), gibt es keine Menge mehr zur Transaktion auszuweisen, so dass jede Auswertung, die Tag 2 und Tag 3 umfasst, keine Spuren der Transaktion aufweist.

Transaktion unsichtbar, da summen- und mengenneutral

Auswertungen einzelner Tage oder Perioden, die an Tag 2 enden oder Tag 3 beginnen, werden immer Spuren der Transaktion und / oder des Produkts aufweisen. Es verschwindet also nichts, sondern wird ggf. nur nicht mehr ausgewiesen, wenn Umsätze und Mengen komplett neutralisiert wurden.

Das bedeutet auch, dass Auswertungen auf Monatsbasis sich nach Stornierungen, die erst im Folgemonat passiert sind, nicht rückwirkend verändern. Der negative Umsatz ist vielmehr (der Realität entsprechend) im Folgemonat zu finden.

Negative Beträge bei stornierten Artikeln? Nein.

Man liest gelegentlich den Hinweis, dass für ein Storno negative Preise statt negativer Stückzahlen (oder beides negativ) übergeben werden soll. Das sorgt leider dafür, dass ggf. zwar Umsätze korrigiert sind, aber falsche Stückzahlen im System zurückbleiben. Das Ergebnis sind unzuverlässige Zahlen trotz erfolgter Stornierung. Auch bestehende Implementierungen sollten daher ggf. noch einmal überprüft werden, weil vermutlich viele auf den gleichen Quellen basieren, welche es beim Negieren etwas übertrieben haben.

Stornolüge durch Vorzeichenfehler
Pfui: Storno mit positiver Menge und negativem Vorzeichen. Das kommt davon!

Das Ergebnis würde auf die Realität übertragen bedeuten, dass dem stornierten (weil z. B. defekten) Produkt ein kostenfreier Ersatz hintergergeschickt wurde - nebst einem Scheck über den Kaufbetrag als Entschädigung. Das ist kundenfreundlich, aber fatal für das Unternehmen. Deshalb macht sowas auch niemand - also bitte auch nicht in der Form in Analytics abbilden ;)

Ein Tipp für mehr Übersicht

Wer einen einfachen Überblick über Stornovorgänge haben will, sollte sich dazu entweder eine eigene Datenansicht oder ein Segment für separate Auswertungen anlegen. Damit Stornos exklusiv darin betrachtet werden können, hängt man an die Storno-Aufrufe per zusätzlichem Parameter eine eindeutige Kennung an. Als Datenfeld bieten sich Benutzerdefinierte Dimensionen an. Oder die "Datenquelle", die üblicherweise bei Analytics mit "Web" oder "App" belegt ist. Es ist erlaubt, diesen Wert zu überschreiben und sich eine beliebige Kennung dort zu hinterlegen. Um die Datenquelle z. B. mit "ERPSys" zu belegen, hängt man &ds=ERPsys an die o. a. Hits an. So kann es aussehen, wenn eine benutzerdefinierte Dimension belegt und als sekundäre Dimension eingeblendet wird:

Filter auf Stornos aus dem System
Stornierte Artikel unter der Lupe - in einer gefilterten "Storno-Only" Datenansicht

In diesen separaten Segmenten oder Profilen kann so sehr einfach ein gezielter Blick auf stornierte Umsätze nach Monaten geworfen oder eine Hitliste der meiststornierten Produkte erstellt werden. Damit hat man den bestmöglichen Überblick über Metriken zu Stornos in einem eigenen Profil / Segment und realistischere Umsatzzahlen im Arbeitsprofil, die bessere Entscheidungen bei der Zuordnung von Umsatz zu Kanälen erlauben. Was will man mehr?

Im nächsten und vorläufig (aber nicht zwingend endgültig) letzten Beitrag der Serie wird es wieder technischer: Es geht um Tracking von Bots. Serverseitig per Measurement Protocol - auswertbar mit Google Analytics. Nerdig genug? ;)

# 

Das Google Analytics Measurement Protocol: LifeLogging mit Analytics und IFTTT

Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol. Jetzt geht es ans Eingemachte: Endlich empfängt Google Analytics mehr als nur Testdaten. Wir werden WLAN-Logins, Ladevorgänge, Anrufe und jede Menge anderen Kram in der Webanalyse versenken ;)

Alle Teile dieser Serie

Warum IFTTT?

Ich bin Diplom-Ingenieur der Elektrotechnik. Ein Lötkolbenmann. Trotzdem bin ich eigenartigerweise kein Bastler. Ungeachtet dessen waren meine ersten Ideen zu "messbaren Ereignissen aus dem echten Leben" als Kandidaten für Analytics Sensoren. Türsensoren, um genau zu sein. Dazu gibt es reichlich verschiedene Möglichkeiten. Und bei Nico Miceli habe ich sogar eine Anleitung für eine Lösung mit Türsensoren, Minicomputer und trackbaren Messungen gefunden, die das Ganze wie gewünscht an Analytics sendet.

Weil ich kein Bastler bin, habe ich nach fertigeren Ansätzen gesucht, Wireless Sensor Tags gefunden und bestellt ;) Weil auch hierbei der Weg zu Google Analytics erst einmal erarbeitet sein will, bin ich schlussendlich bei IFTTT ("If This Then That") gelandet, denn die Wireless Tags bieten dazu eine Schnittstelle.

Wer IFTTT kennt weiß, dass es hier jede Menge Adapter ("Channels" genannt) als Brücke zu Anwendungen, Geräten, Websites und Cloud-Diensten gibt, die als konfigurierbare Trigger ("This") für verschiedenste Aktionen ("That") dienen. MashUps zwischen Diensten bzw. Datenquellen und Empfängern sind damit mit wenigen Klicks eingerichtet und für eine Unzahl an Aufgaben existieren fertige "Rezepte". Klingt ideal, um Daten mit dem Measurement Protocol an die Webanalyse zu senden? Ist es auch!

Das Telefon als Datenquelle, Analytics als Empfänger

Soweit der Plan. Zur Umsetzung führt folgender Weg:

  1. IFTTT Konto einrichten und App installieren
  2. Unter My Recipes via Create a Receipe ein neues Rezept anlegen. Über einen Klick auf "this" einen Trigger erzeugen. Bei der Auswahl des Kanals steht Android Phone Call weit oben, so dass eine Suche nicht erforderlich ist. Anklicken - das soll unser erster Beispiel-Trigger sein.

    IFTTT: this - Android Phone Call

    Wer ein iPhone sein eigen nennt, findet mit "iOS" als Suchbegriff ebenfalls ein paar Trigger, allerdings sind Anrufe leider nicht dabei. Trotzdem dranbleiben: Nach dem gleichen Prinzip finden sich für iOS sinnvolle andere Dinge wie den Upload eines neuen Fotos u. a., die man in ähnlicher Form als Event nutzen kann.
  3. Android weiter vorausgesetzt: Aus einer Liste wird jetzt die Aktion ausgewählt, für die man eine Reaktion definieren will. Any phone call placed als Trigger für ausgehende Anrufe ist der erste Eintrag - prima für ein Beispiel. Bei anderen Channels und Aktionen gibt es ggf. noch Optionen zu definieren, hier reicht ein Klick auf Create Trigger.
  4. Ein Klick auf "that" bestimmt nun, was passieren soll. Da wir Daten an den Analytics-Server senden wollen, benötigen wir einen Channel, der uns den Aufruf einer beliebigen URL erlaubt. Ich habe "Maker" dazu verwendet (es mag andere geben). Als "Action" steht nur Make a web request zur Wahl - genau, was gebraucht wird.

    IFTTT: that - Maker
  5. Um Daten an eine Analytics-Property (welche extra hierfür eingerichtet wurde - warum wurde im zweiten Teil ausführlich erläutert) zu senden, muss nun ein Tracking-Hit gesendet werden. Ich habe mich für Events entschieden. Mittels https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=666&t=event&ec=Logging+Calls&ea=Outgoing Call&el={{OccurredAt}}&aip=1 geht der Aufruf raus. Die Anatomie des Trackingaufrufs sollte vertraut wirken, wenn man die Beispiele aus dem zweiten Teil kennt. Einzige Ausnahme ist die eingesetzte "Variable": Werte, die ein Trigger liefert und die in der Aktion genutzt werden können, sind über den Schalter oben links in Eingabefeldern wie hier der URL wählbar ("Ingredients"). So ist auch der Zeitstempel {{OccurredAt}} in die URL gekommen.

    Konfiguration des Triggers
  6. Als Methode reicht GET, der Content Type kann noch auf text/plain gesetzt werden und schon ist das Rezept fertig.

Idealerweise wiederholt man diesen Vorgang nun für eingehende und verpasste Anrufe in zwei weiteren Rezepten, bei denen in der URL die Ereignisaktionen über den Parameter ea entsprechend angepasst werden. Vor allem mit den verpassten Anrufen hat man ein ideales Ereignis, das man beliebig selbst auslösen kann - also kann schon getestet werden.

In Echtzeit testen

Mit etwas Glück sollte es möglich sein, nach der Definition und automatisch erfolgenden Aktivierung des Rezepts verpasste Anrufe direkt nachzuverfolgen. Dazu mit einem zweiten Telefon die eigene Nummer des Geräts anrufen, auf dem die IF-App installiert (und angemeldet!) ist, ein paarmal klingeln lassen und wieder auflegen. Auf der IFTTT Website sollte es beim Blick in das Receipe Log recht schnell eine Bestätigung der Ausführung geben. Viel spannender ist es, im beschickten Profil nun die Übersicht des Echtzeitberichts in Analytics zu öffnen und zu sehen, ob es einen aktiven User gibt. Dieser sollte im Unterpunkt Ereignisse einen Eintrag hinterlassen haben.

Event in Echtzeit

Wer stattdessen nichts sieht, kann an der Unzuverlässigkeit der Echtzeitberichte gescheitert sein. Zum Glück findet man bei Anpassung der Periode auf das aktuelle Datum Events alternativ nach kurzer Wartezeit in den normalen Berichten unter "Verhalten - Ereignisse".

Ausbauen mit weiteren Events

Wenn diese Hürde genommen ist, kann man sehr einfach weitere Events mit Hilfe der anderen Android-Channels wie Location, SMS, Batterie und vor allem dem "Android Device" - Adapter erstellen, der An- und Abmeldungen bei Bluetooth-Geräten (im Auto) und WLAN-Netzwerken erlaubt. Mit der Netzwerkkennung kann dabei z. B. zwischen Home und Office unterschieden werden - reichlich Ansatzpunkte für Messungen.

Außerdem gibt es eine ganze Welt weiterer Channels zu entdecken. Es empfiehlt sich, die Liste später in Ruhe durchzugehen und sich inspirieren zu lassen - je nachdem, welche Dienste und Apps man selbst verwendet, finden sich hier noch jede Menge andere Ansätze für neue Messideen.

Hinweise und Tipps

Für ungetrübten Spaß sollten ein paar Dinge beim Einsatz beachtet werden:

  • Keine PII senden! Es mag verlockend sein, bei Triggern wie Telefonanrufen die Nummer oder den Namen als Zutat zu verwenden und als Benutzerdefinierte Dimension, Eventlabel oder Ähnliches zu verwenden. Widerstand ist hier unbedingt erforderlich. Solche persönlichen Informationen ("PII" in Neudeutsch) haben allein schon wegen der Nutzungsbedingungen von Analytics explizit nichts in der Webanalyse zu suchen. Vom Datenschutz im Allgemeinen mal abgesehen. Wer seine eigenen Standorte per Foursquare, iOS Location oder Android Location senden will, mag das ethisch mit sich vereinbaren können, aber "fremde" Infos sind stets sensibel zu behandeln.
  • URL Shortener abschalten: Je nachdem, was man genau anstellt, kann IFTTT URLs kürzen. Wer keine URLs mit seiner Tracking-Id bei solchen Diensten haben will, kann zur Sicherheit in den Einstellungen die Verwendung von Shortenern abschalten.
  • Who the f.. is "Maker"? Keine Ahnung. Was gemeint ist: Ein fremder Server setzt die Requests ab, die unsere Daten an Analytics senden. Das muss kein Problem sein und für ein reines Spielprofil ist das Risiko überschaubar. Wer ernsthaftes Tracking im Sinn hat, schaltet besser ein wenig PHP auf dem eigenen Server dazwischen. Einer "Brückenseite" muss man dann nur noch die erforderlichen Angaben für Events oder Pageviews senden, der Rest der URL und vor allem Parameter wie die tid hält man so unter Verschluss. So, Aluhut aus. Letzter Tipp:
  • Cache Buster nutzen. Der z-Parameter ist eine gute Sache, wenn man ansonsten nichts in seiner URL hat, das sich bei zwei Aufrufen unterscheiden würde. Denn in solchen Fällen besteht sonst die realistische Gefahr, dass zwei kurz aufeinander folgende Events wie verpasste Anrufe nicht beide in der Webanalyse ankommen. Wenn man keine veränderlichen Daten wie einen Zeitstempel mitsendet, kann zur Not sogar so etwas wie eine Telefonnummer o. Ä. als z=... genutzt werden, denn der Wert dient ausschließlich zur Schaffung eindeutiger URLs mit Zufallsdaten, die definitiv nicht in der Webanalyse landen und daher nicht unter den obigen "PII-Hinweis" fallen.

So sehen Ergebnisse in Analytics aus

Google Analytics zeigt je nach Anzahl der Trigger und Häufigkeit der Aktionen schnell erste Daten, über die man sich hermachen kann. Wer sich auf Events beschränkt, kann sich von den Eventkategorien über die Aktionen bis hin zu den Labels (wo man z. B. konsistent Zeitstempel unterbringen kann) durch die Ereignisse des Tages klicken.

Events in der Übersicht

Mit dem Verlauf mehrerer Tage kann man Trends zur Telefonnutzung darstellen, zur Häufigkeit der Logins zuhause und im Büro, Autofahrten, Checkins... und was sonst noch an Daten gesammelt werden soll. Damit: Ran an die eigenen Ideen und "Happy Tracking"! Der nächste Artikel wird nach diesem eher exotischen Beispiel wieder bodenständiger: Sauberes und effizientes Stornieren von bereits erfassten Transaktionen.

# 

Das Google Analytics Measurement Protocol: Praxistipps und Einsatzmöglichkeiten

Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol. Nach einigen Anwendungsmöglichkeiten und Denkanstößen folgt ein technischer Praxisteil mit Hinweisen zum Einsatz.

Alle Teile dieser Serie

Reale Anwendungen für Websitebetreiber

Im ersten Teil hat gezeigt, dass man mit dem Measurement Protocol die Grenzen von Websites und Apps sprengen und neue Bereiche mit Google Analytics erobern kann. Es gibt aber auch im Zusammenhang mit dem Web - und speziell den Herausforderungen im Marketing - reichlich Anwendungsszenarien, die mit "klassischem" Tracking oft viel aufwändiger oder z. T. unmöglich sind. Einige Beispiele:

Selektives und sekundäres Tracking

Um mehr als eine Property mit Daten versorgen, bieten Standardtracking und Tag Manager entsprechende Lösungen an. Diese sind entweder schwierig zu implementieren, unübersichtlich, fehleranfällig... oder alles zusammen. Um einer zweiten Id nur in ausgesuchten Fällen Daten zu senden, steht schnell viel Konfigurationsaufwand an, der den Bestand an Triggern und Tags im Google Tag Manager deutlich steigert. Folgeaufwand für die Pflege ist ebenso nicht ausgeschlossen. Auch Lösungen über hitCallback liefern u. U. unerwartete Ergebnisse; speziell bei nachträglicher Impelentierung in einem komplexeren Trackingsystem.

So ist es in der Praxis i. d. R. viel einfacher, die sekundäre Sammlung von Daten durch Anpassung des (ohnehin meistens lieblos in ein Template geschmissenen) Trackingcodes mit Hilfe des Measurement Protocols zu erledigen. Sollte es zwei oder drei weitere wesentliche Stellen mit zusätzlichen Events oder manuellen Hits geben, verfährt man damit ebenso und ist in wenigen Minuten fertig. Ja: Quick & Dirty, dafür (kosten-) effizient und damit i. d. R. im Sinne des Kunden. Überzeugt man so vom Mehrwert eines zusätzlichen Profils, folgen Budgets für tiefere Implementierungen viel einfacher ;)

Damit kann man nicht nur bei separat existierenden Properties für mehrere Sites schnell ein gemeinsames Tracking implementieren, sondern ausgewählte Daten mehrerer Domains in einen Topf werfen. Ein umgesetztes Beispiel aus der Online-Marketingpraxis: Ein Verbund mehrerer Shops sammelt via Measurement Protocol in einem gemeinsamen Profil Daten zu Besuchern und Checkouts, die zur übergreifenden Auswertung dienen. Ohne aufwändige Implementierung von Cross-Domain-Tracking oder mehreren Instanzen des Standardtrackings.

Daten anreichern

Zusätzliche Daten wie Zeitpunkte von Tagespreisanpassungen, Wetterdaten, Änderungen im Produktportfolio u. Ä. immer direkt in der Webanalyse? Das geht unter Einsatz des Measurement Protocols. So kann ein Dashboard z. B. den Verlauf des Transaktionsvolumens unmittelbar mit anderen Messdaten kombiniert darstellen.

Online meets Offline

Wenn noch ein paar der Ideen aus dem ersten Beitrag hinzugefügt werden, finden sich weitere Kombinationen: Per Measurement Protocol und Lichtschranke erfasstes Kommen und Gehen, Bewegungsmuster in Ladengeschäften, Websitenutzung und ebenso eingeschossene Wetterdaten in einer GA-Datenansicht erlauben Auswertungen, die sonst ohne Datenaufbereitung in Drittanwendungen nicht möglich sind. Direkt in Google Analytics.

Stornos und Retouren

Mit dem Datenimport wird Google Analytics nicht nur mit zusätzlichen Informationen versehen oder bestehendes Datenmaterial durch weitere Dimensionen und Metriken angereichert, sondern auch um Stornos und Retouren bereinigt. Für die meisten in der Hilfe von Google aufgeführten Anwendungsszenarien ist ein echter Import tatsächlich der beste Weg. Bei der "Korrektur" von bereits erfassten Transaktionen können aber weder Import noch webgestützte Lösungen mit dem Measurement Protocol mithalten... weshalb dem Thema Stornos ein eigener Beitrag dieser Serie gehört.

Serverseitiges Tracking

Um mit dem Measurement Protocol ein serverseitig implementiertes Tracking umzusetzen, braucht man überraschend wenig, wenn man sich selbst um die Verwaltung des Users - z. B. am Client in einem eigenen Cookie - kümmert und auf Pageviews beschränkt. Oder sich in aufwändigeren Implementierungen selbst Tracking-Aufrufe vom Browser an den eigenen Server senden lässt, um Events oder alles andere ebenfalls abzudecken... auf der Serverseite. Die Website ist frei von Trackingcode, der geblockt werden könnte (huch, habe ich das jetzt laut gesagt?). Klar, das leisten auch andere Webanalyse-Anbieter - aber hier kann man auf der Auswertungsseite beim gewohnten Google Analytics bleiben. Zugegebenermaßen ist die Abdeckung aller Optionen des regulären GA-Trackings auf diesem Weg mühselig. Solcher Bedarf besteht selten. Außerdem kann man dazu auf bereits bestehende Implementierungen zurückgreifen, wenn man sich den Spaß des Eigenbaus unbedingt verwehren will ;)

Zwar werden Proxies, CDNs & Co. plötzlich zum Problem und Details wie die saubere Zuordnung einer Einstiegsseite eines Erstbesuchers sind in diesem Kontext problematisch (aber lösbar). Soll das Ganze die Performance der eigenen Website nicht zu sehr belasten, bringt die Implementierung einer asynchronen Lösung weitere Herausforderungen. Und wenn viele der eingehenden Hits auf dem eigenen Server zusätzlich einen ausgehenden Hit mitbringen, ist das je nach Serverauslastung ein weiterer Faktor, der zu berücksichtigen ist. Dafür bietet diese Variante ein paar nette Vorteile. So kommen z. B. nicht nur Besucher, sondern auch der Googlebot und seine Freunde in die Webanalyse. Hier können deren Bewegungen in eigenen Profilen oder als Segment komfortabel analysiert werden. Zumindest solange es nicht zu viel Traffic gibt, so dass das einsetzende Sampling in der Webanalyse den Plan verdirbt. Der Einsatz eigener Properties für jeden Bot - oder GA Premium - relativieren dieses Problem jedoch. Weil das Thema so spannend ist, enthält diese Serie einen eigenen Beitrag zum serverseitigen Tracking mit Analytics voller Details und Beispielen ;)

Measurement Protocol im Einsatz

Um von einer Idee zur lebenden Implementierung zu kommen, muss der Sprung in die Praxis her. Für alle, die sich auf technischer Ebene damit zu befassen haben, schließt dieser Beitrag daher mit Tipps ab, die den Einstieg erleichtern und typische Stolperfallen aufzeigen. Wer Technisches meidet, darf an dieser Stelle aussteigen und findet zum Trost im nächsten Beitrag der Serie eine Anleitung, wie man auch als "Nicht-Techie" etwas aus dem Measurement Protocol herausholen kann.

Tipp 1: Vermeide (not set), wo immer es geht

In der Referenz zum Measurement Protocol gibt es für alle Hit-Typen ausführliche Beispiele. Wer stets nur diejenigen Parameter nutzt, die mehr oder weniger zwingend zu einem Hit-Typ gehören, reißt an anderen Stellen ggf. Lücken, die die Auswertung später erschweren.

Oberstes Gebot ist es, zumindest die "optionalen" Angaben, die direkt zu einem Hit wie einem Event gehören, nicht zu vernachlässigen. Denn es können durchaus wichtige Parameter ungenutzt bleiben und dennoch Spuren des Aufrufs in Analytics bleiben. Als Beispiel: Ein Aufruf von v=1&tid=UA-xxx-1&cid=555&t=event&ec=Uncomplete+Event funktioniert zwar, doch in Analytics bleibt die Ereignisaktion dann (not set). Wer nur auf Kategorien und Werte blickt und sich um Aktionen nicht kümmert, mag damit zurecht kommen, aber solche Aufrufe reißen Lücken.

Leider kann u. U. nicht einmal das Weglassen von Pflichtangaben verhindern, dass dennoch "irgendwas" ankommt: v=1&tid=UA-xxx-1&cid=555&t=event&dt=Ich+darf+nirgends+ankommen überträgt ein Event ohne erforderliche Parameter; hat aber den Titel einer Seite im Gepäck. So erzeugt man zwar kein Ereignis, doch es bleibt eine (z. B. im Echtzeitbericht sichtbare) Interaktion im Bereich "Content". Diese wird, da der Pfad fehlt, der Standardseite zugeschlagen. Folgerichtig gibt es bei Übergabe eines Pfades statt eines Titels ebenso einen Eintrag. Das ist kein Drama, solange man nichts mit Echtzeitdaten anfängt, aber es ist unsauber. Debugging von Grenzfällen ist daher angesagt, bevor entsprechende Systeme auf Echtdatenprofile losgelassen werden.

Alle Informationen über den Client wie Browser etc. fehlen, wenn man sie nicht explizit mit überträgt. Ich sage nicht, dass man diese alle mit irgendwelchen Standardwerten belegen soll, aber wer Reports zu diesen Informationen nutzt, muss sich darüber im Klaren sein, woher die ganzen "Ausreißer" stammen. Zumindest einen Hostnamen sollte man daher möglichst bei jedem Aufruf befüllen; genau wie alles andere, was ggf. in Segmenten oder Filtern aktiv in Google Analytics genutzt werden soll. Die Verwendung des "Cache Busters" z mit einer Zufallszahl ist ebenso eine gute Erweiterung und darf in Echtanwendungen nicht fehlen, um Proxies und Caching aller Art auszuhebeln.

Merke: Aufgesattelte Seiteninfos bedeuten keinen Pageview!

Wie gerade gezeigt, können Angaben zu einer Seite, die typischerweise zu einem Pageview gehören, bei einem Event oder einer Transaktion "im Bundle" übertragen werden. Das ist sinnvoll, um diese Attribute in Berichten wie "Seiten" unter "Ereignisse" wiederzufinden oder als sekundäre Dimension zu nutzen. Allerdings findet sich die so übertragene "auslösende" Seite auch wirklich nur dort wieder, jedoch nicht in Berichten zum Website-Content. Um dort Spuren zu erzeugen, ist ein zusätzlicher Hit erforderlich, der einen separaten Pageview überträgt.

Tipp 2: Status 200 bedeutet nicht, dass alles OK ist

So einfach es erscheint, unvollständige Daten zu übertragen: einige Dinge sind wirklich unverzichtbar. Logisch ist, dass ohne Property-Id nichts zugestellt werden kann. Weniger offensichtlich ist vielleicht, dass auch eine Client Id cid zwingend erforderlich ist.

Wer z. B. v=1&tid=UA-xxx-1&t=event&ec=TestEventOhneCid&ea=Nirvana testet, bekommt den Statuscode 200 als Antwort, es entstehen aber keine Daten in der Webanalyse. Das gilt für unvollständige Requests aller Art: Selbst bei einem Aufruf ohne tid liefert Google brav ein Pixelchen zurück.

Tipp 3: So bekommt man eine cid

Die gute Nachricht: Eine einfache Id wie "1234" funktioniert einwandfrei. Wer nur ein wenig testet, muss sich daher nicht weiter mit diesem Parameter herumplagen - alle Aufrufe kommen einfach vom selben Nutzer. Soll eine echte Id erzeugt und z. B. in einem eigenen System oder Cookie verwaltet werden, findet man dazu entsprechende Bauanleitungen und Code in JavaScript oder PHP. Alternativ setzt man auf den Cookie von Google Analytics des aktiven Users auf, wenn denn ein Browser im Spiel ist oder z. B. serverseitiges Tracking stattfindet.

Tipp 4: Sammeln und per Batch übertragen

Statt Aufrufe einzeln abzusetzen, können mehrere Hits in einem Rutsch per POST statt GET übertragen werden. Nicht zu früh freuen: Auch "batchen" hat seine Grenzen. Ein Paket darf nicht mehr als 20 Hits enthalten und muss mit max. 16K auskommen, wobei keiner der einzelnen Hits größer als 8K sein darf. Die Größenbeschränkung klingt unkritisch, kann aber - genau wie die übliche Grenze von 2K für einzelne Werte - im Einzelfall zum Problem werden. Jedenfalls wenn man etwas anderes als Webtraffic misst.

Um zuerst in einem Log zwischengelagerte Daten zu bestimmten Zeitpunkten zu verarbeiten und an Analytics zu übertragen, bringt der Batchbetrieb einen deutlichen Zeitgewinn und ist deshalb fast Pflicht.

Beim Batch werden die Daten statt an /collect an /batch gesendet - und zwar spätestens jetzt per POST statt einfach mittels GET. Dabei können die einzelnen Hits im POST-Payload durch Zeilenumbrüche ("\n") getrennt werden. Man mag auf die Idee kommen, dass die Reihenfolge ggf. eine Rolle spielt und ein Event-Hit nach einem Pageview-Hit so vielleicht zu einer zugeordneten auslösenden Seite führt. Das stimmt leider nicht. Soll ein Event Infos zur auslösenden Seite beinhalten, müssen die zusätzlichen Parameter direkt im Hit enthalten sein - genau wie bei der einzelnen Übertragung an /collect.

Dennoch ist eine zeitliche Dimension im Batch vorhanden: Hängt man einem Hit z. B. den "Queue Time" Parameter qt=20000 an, wird eine 20 Sekunden "Verweildauer" zwischen diesem und dem vorherigen Hit definiert. So kann der Zeitpunkt des Hits in Millisekunden in die Vergangenheit verlegt werden; relativ zum Verarbeitungszeitpunkt. Das hilft allerdings weder bei Echtzeitberichten (dort landet stets nur der letzte Eintrag eines Batchs), noch kann es zum nachträglichen Korrigieren von Webanalysedaten verwendet werden. Der Grund ist die Grenze der Hit-Zeitmaschine, die nicht weiter als 4 Stunden in die Vergangenheit fliegt. Alles was lt. QueueTime älter ist als 4 Stunden, kommt definitiv nicht in Analytics an.

Tipp 5: SSL verwenden

OK, eigentlich muss es wohl TLS heißen. Egal. Gesicherte Übertragung der Daten ist im Fall eines installierten Clients oder serverseitiger Aufrufe von einem Server mit Zertifikat auf keinen Fall eine schlechte Idee. Dazu in allen Aufrufen http://www.google-analytics.com/collect gegen https://ssl.google-analytics.com/collect (oder batch/) austauschen.

Inspiriert zu eigenen Anwendungen? Dann freue ich mich über Kommentare aller Art. Die nächsten Teile dieser Serie beleuchten ein paar der aufgeführten Szenarien im Detail. Sie zeigen, was alles im Measurement Protocol steckt - also gleich weiterlesen im Artikel zum LifeLogging mit IFTTT ;)

# 

Das Google Analytics Measurement Protocol: Überblick und Anwendung

Der Titel lässt es vermuten: Dieser Beitrag ist der erste aus einer Serie von Artikeln rund um das Measurement Protocol. Im ersten Teil geht es um Zweck, Einsatzmöglichkeiten und eine Anleitung für erste Gehversuche.

Alle Teile dieser Serie

Tracking mit dem... was? Kurzvorstellung GA Measurement Protocol

Google Analytics dient(e) primär dazu, Seitenaufrufe und Interaktionen auf Websites auf verschiedene Weise mess- und analysierbar zu machen. In den letzten 10 Jahren hat sich die technische Basis dahinter mehrfach geändert. Weil Markt, Wettbewerb und Anwender laufend neue Fähigkeiten bei Tracking und Auswertung fordern, sind neben vielen notwendigen Feature-Erweiterungen spannende Dinge wie die API oder der Tag Manager dabei herausgekommen.

Einer der größten Evolutionssprünge hat Analytics mit der Einführung von Universal Analytics gemacht. Damit wurden nicht nur Apps und Websites unter einen Hut gebracht, sondern es entstand auch als "Nebenprodukt" das Measurement Protocol als direkte Kommunikationsbasis mit den Analytics-Servern. Oder besser: Über das Measurement Protocol kann jeder Client mit Internetzugang genauso Daten an Google Analytics senden, wie es Apps und Websites über die Standardimplementierung des Analytics-Trackings tun. Wie sieht sowas aus?

Google Analytics Hits unter der Lupe

Wenn eine Website den aktuellen (Universal-) GA Trackingcode beinhaltet und dieser bei der Ausführung irgendwann einen "Pageview" als Hit an den Analytics-Server sendet, kann man ihm dabei z. B. mit dem Tag Assistant im Chrome oder der Netzwerkansicht im Inspektor über die Schulter schauen.

Pageview-Hit im Netzwerkprotokoll
Ein Klick auf den "collect"-Eintrag für den Pageview enthüllt alle Details der Request-URL

Wer lieber in den Tag Assistant schaut:

Pageview im Tag Assistant
Der Tag Assistant zeigt auf einem eigenen Tab die aufgerufene URL, die den Pageview-Hit auslöst

Betrachtet man die übergebenen Parameter, findet sich neben IDs für User, Analytics Property und dem "Pageview" als Hit-Typ eine bunte Mischung aus Metriken und Dimensionen, die den Aufruf begleiten. Ähnlich macht es eine App, wenn sie Google Analytics-Tracking nutzt. Das Measurement Protocol macht mehr oder weniger das Gleiche. Ein paar Parameter mehr, einige weniger... aber im Prinzip basieren alle Trackingmethoden auf einer gemeinsamen Basis und funktionieren sehr ähnlich.

Measurement Protocol: Tracking über Websites & Apps hinaus

Will man über das Measurement Protocol Daten an "seine" Webanalyse senden, muss lediglich eine URL zusammengebaut und aufgerufen werden. Das kann im Browser passieren... oder aus einer beliebigen Anwendung heraus. Ein potentieller Client muss in der Lage sein, den Analytics-Server mit diesem Aufuf zu erreichen. Er muss aber nicht zwingend auf einem komplexen Rechner installiert sein und braucht keinen Anwender, der ihn bedient.

Genau da beginnt der Spaß. Ein einfacher Minicomputer wie ein Raspberry Pi mit Verbindung zum Internet reicht, solange es etwas zu verarbeiten gibt: Signale von externen Quellen wie Lichtschranken oder Türsensoren zum Beispiel. Oder Zugriff auf eine Logdatei, die regelmäßig nach neuen Einträgen durchsucht wird, um diese per Measurement Protocol in Analytics zu versenken. Über Dienste wie If This Then That lassen sich Events auslösen, die man üblicherweise nicht in einer Webanalyse findet - ein Beispiel gibt es in dieser Artikelserie.

Mit dem Measurement Protocol lässt sich die Nutzung von sehr vielen unterschiedlichen Dingen messen. Als Event, Pageview, Transaktion oder "exotischere" Hit-Typen wie Timings oder Fehler. Jemand betätigt die intelligente Türklingel? Das kann ein Ereignis in Analytics auslösen. Der Bewegungsmelder springt an? Für Bastler kein Hexenwerk, Anzahl und / oder Dauer von Auslösungen zu tracken. Die Kühlschranktür hat einen Sensor? Wenn man die Möglichkeiten des Measurement Protocols weiter denkt, ergeben sich zahllose Anwendungsgebiete.

"Bodenständigere" Szenarien gefällig? Das Tracking von offline erfolgten Käufen oder traurigeren Vorgängen wie Retouren und Stornierungen von bereits in Analytics gemessenen Transaktionen sind Beispiele, um die es in dieser Artikelserie noch gehen wird.

Wo man dem Measurement Protocol vermutlich schon begegnet ist

Das "Internet of Things" mag einigen spätestens jetzt durch den Kopf schießen. Stimmt. Das ist sogar ein Riesenpotential. "Google Analytics Spam" denken andere. Auch die haben (leider) Recht! In fast jeder Datenansicht finden sich Spuren vom Einsatz des Measurement Protocols: Referrer- und Eventspam sind schwer zu bekämpfen und gehören zum traurigen Alltag vieler Nutzer... bewusst oder unbewusst. Nicht ganz unschuldig daran ist das Measurement Protocol, denn damit kann jeder Daten an jede Property senden, solange die Id stimmt. Gängige, auf Filtern beruhende Methoden zur Abwehr helfen nur bedingt, da sich Dinge wie IP, Hostname und andere Merkmale über das Measurement Protocol so gestalten lassen, dass "gut gemachter" Spam wie ein normaler Hit wirkt und entsprechende Filter daher umgeht. Wer das Problem kennt und eine einfache, aber wirkungsvolle Methode zur Filterung unerwünschter Verschmutzung der eigenen Daten sucht, freut sich bestimmt über eine Anleitung zur Anpassung des Trackings, um Analytics Spam zu verhindern.

Mein erster eigener Hit!

Wer wollte nicht schon immer irgendwann selbst einen Hit schreiben? Na gut: Mit einem selbstgeschriebenen Hit für Google Analytics wird man vielleicht nicht reich... dafür ist er auch viel einfacher gestrickt. Damit sich nachvollziehen lässt, ob das Ganze funktioniert, empfehle ich ungeachtet meiner Hinweise aus dem vorherigen Abschnitt die Verwendung einer eigenen Property (:)). Nur so kann man das Ergebnis direkt in der Echtzeit-Übersicht in Google Analytics sehen.

Um zu verhindern, dass dabei die Echtdaten der eigenen Website verwässert werden, sollte der erste Schritt die Anlage einer neuen Property sein, welche für die ersten Gehversuche mit dem Measurement Protocol genutzt wird. Danach kann der gefahrlose Einstieg mit einem Event erfolgen. Mit den folgenden Schritten senden wir einen Event-Hit via Measurement Protocol in die Datenansicht der neuen Test-Property:

  1. Eigene ID: Google Analytics öffnen und die ID der (Test-) Property notieren.
    Property-ID in Suchfunktion
  2. Echtzeit öffnen: In der Navigation der Test-Datenansicht den Bericht Echtzeit -> Ereignisse aufrufen.
  3. Roll Your Own: Um ein Ereignis zu erzeugen, die folgende URL kopieren, in einem neuen Reiter in die Adresszeile des Browsers einfügen und die ID "UA-xxxxx-1" gegen die eigene ID austauschen:
    https://www.google-analytics.com/collect?v=1&tid=UA-xxxxx-1&cid=666&t=event&ec=TestEvents&ea=MP+Test+angekommen
  4. Jetzt die ergänzte URL aufrufen. Das Ergebnis ist unspektakulär: Es kommt ein Zählpixel zurück, mehr Sichtbares passiert an dieser Stelle nicht.
  5. Der Echtzeitbericht sollte bereits aktualisiert worden sein und einen Eintrag für unser gerade ausgelöstes Ereignis aufweisem:
    Hit in Analytics angekommen

Unspektakulär? Vielleicht. Aber so einfach ist es, Daten in die Webanalyse zu bekommen... wie gesagt nicht nur die eigene. Wer jetzt weiter spielen und andere Hit-Typen austesten möchte, findet bei Google eine ausführliche Beschreibung aller Parameter und den Hit Builder (ein Werkzeug zur Zusammenstellung von Tracking-Anfragen). Vor dem Beschießen eines Echtdaten-Profils empfehle ich den nächsten Teil, in dem es Praxistipps für den realen Einsatz gibt.

#