Markus Baersch

Software · Beratung · Lösungen

Suche im Blog

Sign In

Monday, 13 February 2017

Ist Analytics Spam besiegt?

Nachdem Analytics Spam in einigen Konten Ende des letzten Jahres deutlichen Aufwind zeigen konnte, während andere Analytics-Benutzer einen deutlichen Rückgang oder gar komplettes Ausbleiben von Spam beobachtet haben, ist es nach der Welle von unerwünschten Nachrichten rund um das Finale des US Wahlkampfs offenbar allgemein ruhiger geworden.

Da ich in anderem Zusammenhang wieder über das Thema gestolpert bin, wollte ich herausfinden, ob sich ein allgemeiner Trend auch anhand von Daten belegen lässt. Aus verschiedenen Gründen ist die Klassifizierung von Webanalyse-Spam in "normalen" Google Analytics Konten ohne entsprechende Filter und gesonderte "Spam-Datenansichten" zwar nicht einfach bzw. besonders zuverlässig, aber dennoch wollte ich zumindest wissen, ob sich eine grobe Richtung erkennen lässt.

Spam-Auswertung: Der Trend nach Monaten

Zur Beantwortung der Frage habe ich Verweisquellenberichte von Oktober 2015 bis Mitte Februar 2017 zu 180 unterschiedlichen Google Analytics Properties aus 90 verschiedenen Konten als Basis genutzt. In den Berichten sind die Sessions je Verweisquelle monatlich aufgeführt. Insgesamt wurden dabei knapp 5,6 Millionen Sessions ausgewertet. Die Klassifizierung nach "Spam" oder "Nicht-Spam" erfolgte anhand einer Liste bekannter Spam-Domains, deren Einträge aus verschiedenen Quellen stammen.

(Leider) dennoch wackelige Beine

Es gibt zugegebenermaßen einige Schwachpunkte, wenn man auf diese Weise versucht, das Spamaufkommen zu bestimmen:

  1. Auch bei dieser hoch erscheinenden Anzahl der Sessions ist die Anzahl der Datensätze in den Rohdaten nicht ganz so beeindruckend. Die etwa 165.000 Zeilen passen locker auch in Excel. Allerdings: Wären diese nicht monatlich, sondern täglich oder wöchentlich erhoben, wären es zwar mehr Zeilen, aber außer besserer "Auflösung" bei der Betrachtung des Verlaufs kommt kaum ein Unterschied zusammen. Eine breitere Basis in Form von mehr Konten und Properties wäre da die bessere Lösung.
  2. Es werden nur Verweise betrachtet. Webanalyse-Spam ist aber vielseitiger als nur Referrer-Spam. Events, Sprachen, Seitenberichte... Spammer können überall Spuren hinterlassen und tun das auch. Die Beschränkung auf den Verweisbericht betrachtet also nur einen Teilaspekt des ganzen Problems.
  3. Wenn man Spammer anhand von Listen bekannter Spammer identifiziert, funktioniert das eben auch nur bei denen, die bereits als Spammer in einer Liste gelandet sind. Da aber jederzeit neue Spam-Domains hinzukommen und andere dafür den Betreib einstellen (siehe unten), ist ein Rückgang im so "messbaren" Spam kein Garant dafür, dass er in der Realität wirklich weniger wird.
  4. Viele Properties haben mehr als nur eine Datenansicht. Es ist aber je Property nur eine Ansicht sinnvoll auswertbar und das ist idealerweise eine ungefilterte Rohdatenansicht. Da bei der Analyse stets die erste Ansicht verwendet wurde, wenn mehrere vorhanden waren, muss das nicht immer die ungefilterte Ansicht gewesen sein. Trost spendet dabei aber die Tatsache, dass sich evtl. Fehler hierdurch konstant in allen Monaten zeigen und so zumindest keine Trends versauen können.

Ergebnisse

Es bleibt bei allen Unsicherheiten eine Erkenntnis: Spam findet nach wie vor statt. Das Problem ist nicht "erledigt", wie mancher bei der einen oder anderen Meldung gehofft haben mag, und braucht nach wie vor Aufmerksamkeit bzw. sinnvolle Behandlung, um die naturgemäß ohnehin nicht exakt sein könnenden Zahlen aus der Webanalyse nicht noch weiter verwässern zu lassen.

Spam-Anteil der Verweisquellen schwankt um ca. 2,8%, Tendenz fallend (...wirklich?)

Der Anteil von Sessions, die von bekannten Spam-Domains stammen, schwankt im untersuchten Zeitraum zwischen 0,8% und ganzen 5,4% im November 2015, wobei der November ohnehin ein "Top-Spam-Monat" zu sein scheint. Über die Sessions betrachtet liegt der Schnitt 2016 bei 2,7%

Spamanteil

Betrachtet man nicht die Sessions, sondern die Verweisquellen selbst, so liegt der Anteil in dieser Stichprobe sogar bei 3,9% über die gesamte Zeit.

Spamanteil im Verweistraffic

Trends? Schwierig

Untersucht man die Daten aus verschiedenen Perspektiven, um damit die Vermutung zu bestätigen, dass Spam "besiegt" ist oder zumindest beim Großteil der Analytics-Konten zurückgeht, ist man auf Hoffnung angewiesen. Das deutlichste Zeichen wäre es, wenn man die Anzahl der Spam-Sessions für alle Properties über die Zeit abbildet und darin einen klaren Rückgang für die meisten Linien erkennen kann. Ohne dies besonders gut darstellen zu können, zeigt die folgende Abbildung für den Jahreswechsel auch ohne Legende, das diese Hoffnung nicht erfüllt wird:

Spam je Property

Kennt Spam eine Saison? Vielleicht!

Den deutlichsten Trend sieht man, wenn man sich die Verteilung der unterschiedlichen Spam-Quellen ansieht. Dort ist jeweils eine klare Spitze im November zu erkennen.

Verlauf Spamverhalten in Google Analytics

Diese lag 2016 vor allem an "Spam-Eintagsfliegen", die in dieser Zeit massenhaft entstanden und inzwischen schon wieder verschwunden sind (siehe unten).

Die vermutlich positivste Darstellung zeigt sich, wenn man die Anzahl der von Spam betroffenen Datenansichten in den Fokus stellt - dort sieht der aktuelle Februar wirklich vielversprechend aus.

Anzahl betroffener Properties

Überzeugender wäre das allerdings, wenn das vergangene Jahr nicht ähnliche Tendenzen gezeigt hätte. Zum Jubeln mag es also noch zu früh sein.

Spammer kommen und gehen

Top-10-Listen sind immer eine tolle Sache. So zeigen sie auch in diesem Fall, dass Spammer i. d. R. nicht ewig in den Charts dominieren. Dabei gilt, dass die meisten Sessions i d. R. von wenigen, gerade besonders aktiven Quellen generiert werden. So war z. B. im Februar des letzten Jahres das Thema "Responsive" besonders an zahlreichen Domains wie 1537930.responsive-test.net zu sehen, einen Monat später widmen sich die Domainnamen dem Shopping. Zur Verdeutlichung der Kurzlebigkeit exemplarisch September und Oktober 2016 im Vergleich:

Top-Spammer

Dort sieht man, dass die Nummer 2 aus dem September nach Sessions, die zudem die meisten Properties von allem Spammern in diesem Monat beglückt hat, im Oktober schon nicht mehr oben auftaucht.

Man darf dabei aber nicht vergessen, dass auch mit nur einer Session an anderer Stelle eine ganze Menge Impact entstehen kann, wenn z. B. tausende von Seitenaufrufen und / oder Events ausgelöst werden.

Das zeigen auch die o. a. "Eintagsfliegen" mit Namen wie 98765-1.compliance-irgendwer.xyz, die im November 2016 für einen dramatischen Anstieg bei der Anzahl der Spammer gesorgt haben. Deren meist einzige Session wurde dazu genutzt, Werbung für Donald Trump im Bericht zu den Besuchersprachen im Dashboard zu hinterlassen.

Eintagsfliegen - Spammer

Im Dezember geht auch dies wieder zurück. Der Newcomer website-analytics.online verdrängt site-auditor.online von Platz 1 der Charts und etabliert sich vorerst als Haupt-Spam-Quelle 2017.

Spam-Rückgang 2017

Auch wenn diese Toplisten und die obigen Abbildungen nur ein unvollständiges Bild abgeben, scheint Spam aber durchaus auf dem Rückzug zu sein... oder zumindest nicht mehr so dramatisch wie Ende 2016, wo nicht nur in der Onlinemarketing-Branche ungewöhnlich viele News und Blogbeiträge zu diesem Thema erschienen sind. Es ist aber fraglich, ob das wirklich ein dauerhafter Zustand und Ausdruck eines erfolgreichen automatisierten Filterns seitens Google ist oder der Rückgang eher auf veränderte Aktivität der Spammer zurückführt.

Und jetzt?

Es ist zu hoffen, dass eine Wiederholung der Messung im kommenden Monat bestätigt, dass Spam offenbar wirklich in weniger Konten ankommt. Wie man an der Liniengrafik oben sehen kann, muss das nicht gleich als allgemeine Entwarnung interpretiert werden. Denn solange die Daten nach wie vor gestört werden, die man gerade betrachtet, hilft es wenig, dass es anderswo Konten geben mag, die dieses Problem nicht mehr haben. Strategien zur Spamvermeidung sollte man aber noch nicht in Rente schicken oder bereits bestehende Lösungen gar in der Hoffnung abbauen, dass diese nicht mehr benötigt werden.

Mehr Sicherheit würde es bringen, möglichst viele einzelne Datenansichten zur "Spambeobachtung" einzusetzen, die konsolidiert ein genaueres Bild von der Entwicklung vermitteln. Ein paar davon habe ich selbst... aber für belastbarere Interpretationen müssen deutlich mehr her. Wer sich an einer solchen Sammlung beteiligen will, melde sich bitte unbedingt bei mir! Vielen Dank schon jetzt ;)

# 
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, 23 August 2016

Google Tag Manager endlich "angekommen"?

Seit fast genau 4 Jahren kenne und nutze ich den Google Tag Manager (GTM) für verschiedenste Aufgaben; hauptsächlich auf Websites von Agenturkunden. In den letzten Monaten ist mir dabei (zu meiner Freude) aufgefallen, dass man den GTM verstärkt bereits implementiert findet, statt zuerst von A wie Analytics bis Z wie Zauberei den ganzen Evangelisierungsschmus runterleiern zu müssen.

Mehr (unterforderte) Implementierungen in KMUs

Zugegeben: Die meisten Implementierungen, die mir dabei unterkommen, sind simpel und tun selten mehr, als einen Analytics-Code auszuspielen; der dataLayer ist i. d. R. ungenutzt und das Potential nicht mal da angekratzt, wo es nicht nur technisch möglich, sondern aus der Businessperspektive wirklich erforderlich wäre. Trotzdem scheint die "gefühlte Menge" der Installationen in B2B- und B2C-Websites kleiner Unternehmen, Nischen-Shops und den anderen eher "kleineren Kandidaten", die unser Agenturgeschäft prägen, durchaus angestiegen zu sein.

Was sagen "die Zahlen"?

Gute Frage. Wo suchen? Bei den meisten Diensten wie Ghostery & Co. findet man so hilfreiche Angaben wie "not many". Im Vergleich zu den Zahlen zu Google Analytics, die man beim gleichen Anbieter findet, mag man aber darauf tippen, dass der Google Tag Manager eben immer noch ein Exot ist. Deutlich hilfreicher ist da die GTM-Statistik bei BuiltWith, die zwar keine absolute Zahl für "das ganze Internet" liefern kann, aber bei der man zumindest ein beachtliches Wachstum auf Basis einer recht großen Stichprobe erkennen kann.

Nutzung Google Tag Manager 2014 - 2016

Wenn die Zahlen so auch für "alle Websites" stimmen sollten, hat sich die Anzahl der Installationen innerhalb von zwei Jahren fast verdreifacht. Wenn man übersieht, dass den Ordinaten weiter oben eine signifikante Stelle abgeht und sich den Verlauf für die angebotenen Segmente der Top X - Websites anschaut, dann scheinen die Großen auch eher die Vorreiter gewesen zu sein, so dass ich in diesen Segmenten im Vergleich deutlich weniger Wachstum abspielt. Oder anders: Die "Normalo-Websites" holen auf.

Was sagt Deine Erfahrung?

Wenn Du, geschätzter Leser, dazu auch Erfahrungen beisteuern oder gar mehr, andere oder einfach nur bessere Zahlen hast, dann lass es mich bitte wissen. Danke dafür schon jetzt! ;)

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

# 
Friday, 09 October 2015

Google Analytics: Bots und Spider ausschließen

In den Einstellungen einer Datenansicht in Google Analytics findet sich schon seit einiger Zeit die Option "Alle Treffer von bekannten Bots und Spidern ausschließen". Ich muss zugeben, diese recht lange ignoriert zu haben. Vielleicht weil mich absolute Zahlen wenig interessieren und ich i. d. R. auf ein Rauschen ohne große Ausreißer hoffe. Also den idealen "Messfehler": Konstant und bei Betrachtung von Tendenzen und Kennzahlen im Kontext eher irrelevant. Aber stimmt das eigentlich?

Den letzten Schubser habe ich von Michael Janssen bekommen, als er sich mit den gängigen Mythen rund um Referral Spam auseinandergesetzt hat. Denn auch in diesem Zusammenhang liest man gern, dass die Option zum Ausschluss von Bots und Spidern hier helfen soll. Wirklich? Ich habe da eher auf "Nein" getippt und wollte es genauer wissen

Hilfe? Nicht hilfreich!

Schaut man in der Hilfe zu Analytics bei den Hinweisen zu den Einstellungen der Datenansicht nach, wird man nicht schlauer:

"Bot-Filterung: Aktivieren Sie diese Option, um Sitzungen bekannter Bots und Spider auszuschließen."

Ja, super. Danke auch. Die englische Fassung ist ebenso keine Hilfe: Bot Filtering: Select this option to exclude sessions from known bots and spiders.. Siehe oben.

Auch sonst findet sich nur wenig zu der Option. Allerdings hat das Analytics-Team dazu an anderer Stelle ein paar erhellende Worte verloren, unter anderem bei Google Plus:

Der wichtige Part:

"... exclude all hits that come from bots and spiders on the IAB know bots and spiders list. The backend will exclude hits matching the User Agents named in the list..."

Aha. Es geht also "nur" um bekannten Traffic von sich entsprechend im User Agent outenden Maschinen, die auf der IAB-Liste zu finden sind. Ich habe zwar keinen Einblick in diese Liste (das wäre auch teuer), aber es ist davon auszugehen, dass es hier eher um Crawler und Bots von verbreiteten und bekannten Systemen geht (Similarweb gehört ganz sicher dazu ;)). Nicht um knöppe-für-websites.irgendwo & Co. Damit wäre das Thema "Referral Spam" wohl vom Tisch. Ich habe deren Requests zwar noch nie gesehen, aber wenn ein identifizierbarer User Agent String zu sehen wäre, würde mich das sehr wundern. Analytics zeigt in Datenansichten ohne diese Option auch nichts, was diese Meinung ändern würde. Außer vielleicht neben "not set" hier und da "PTST" - den "Browser" von webpagetest.org und anderen, die durch die Option abgefangen werden, wenn sie denn aktiviert ist. Referral Spam kommt aber freilich immer noch durch. Ganz andere Baustelle!

Woher kommt der ganze "Direct Traffic"?

Für diese Frage ist die Option viel relevanter. Denn mit der Option ausgeschlossener Traffic landet sonst in einem übergroßen "Direct"-Topf, bei dem man sich auch schon mal bei unreflektierter Betrachtung zu Unrecht auf die Schulter klopft. Hat man doch den internen Traffic mühselig ausgeschlossen, um "echte" Besucher zu zählen. Hier kann die Option zu Bots und Spidern bei einzelnen Sites wirklich einen nennenswerten Unterschied ausmachen.

Auswirkungen des Ausschlusses

Bleibt noch zu klären, wie groß das Rauschen durch diese Bots ist und welchen Schwankungen der Traffic unterworfen ist. Ich habe mir dazu Datenansichten von ca. 20 Websites unterschiedlicher Größe angesehen, die ich eigens dazu gleich nach Michaels Beitrag angelegt hatte. In diesen Vergleichsprofilen wurde nur die Option aktiviert und ansonsten keine weiteren Filter angewendet, um diese mit den vorhandenen "Rohdatenprofilen" zu vergleichen.

Das Ergebnis liefert leider keinen klaren Trend und auch keine besonders belastbaren Fakten. Aber: Kleine Sites haben i. d. R. auch weniger Traffic aus diesen Quellen als größere... aber dafür kann der prozentuale Anteil maschineller Besucher dort schnell Überhand gewinnen, wenn man bei zwei oder drei fleißigen Tools auf der Liste steht. Der Unterschied ist fast überall spürbar. Der Anteil der ausgefilterten Sitzungen über 2 Wochen schwankte im Testfeld zwischen 2 bis zu knapp 60 Prozent; eine Null war bei meinen Kandidaten gar nicht dabei (mag es aber geben). Leider ist der Zeitraum mit weniger als 30 Tagen nicht besonders lang - dass es dennoch messbare Unterschiede gibt, spricht aber für einen deutlichen Nutzen der Option.

Ein Beispiel, das ich für zumindest typisch für viele Websites halte, zeigt die Auswirkungen auf den direkten Traffic. Dazu zuerst ein Blick auf die Verteilung der Trafficquellen aus dem ungefilterten Profil:

Traffic inkl. Bots

Sieht man sich den gleichen Zeitraum im Vergleichsprofil an, wird der Anteil der direkten Besuche deutlich reduziert und schon steht ein anderer Kandidat auf dem ersten Rang:

Traffic ohne Bots

Sind diese Zahlen nun richtig? Natürlich nicht. Absolute Zahlen in der Webanalyse stimmen eigentlich nie. Aber die Werte sind zweifelsfrei "richtiger". Auch andere Kennzahlen wie Absprungrate, Besuchstiefe und Verweildauer sind von der Filterung betroffen und geben das tatsächliche Verhalten ohne Bots zweifelsfrei besser wieder. Die Verwendung in einem Arbeitsprofil sollte also auf jeden Fall Pflicht sein.

Schwankungen in den Werten sind definitiv nicht zu vernachlässigen. Auf Tagesbasis schwankt der Anteil der Bots, die im Topf "Direct" enthalten sind, anhand der hierbei untersuchten Daten zwischen 0% und 95%. Oder anders gesagt: an machen Tagen kommt gar kein Bot vorbei, an anderen kaum jemand anderes.

Dazu Zahlen aus Analytics zur Veranschaulichung. Zu sehen sind die direkten Besucher des Gesamtprofils und des gefilterten Vergleichsprofils. Daraus berechnet werden Anzahl und Anteil der Bots im direkten Traffic:

Datum Gesamtprofil   Gefiltert   -> Bots   Anteil Bots
24. Sep 143 52 91 64%
25. Sep 136 50 86 63%
26. Sep 107 14 93 87%
27. Sep 104 13 91 88%
28. Sep 123 37 86 70%
29. Sep 140 59 81 58%
30. Sep 133 48 85 64%
01. Okt 124 41 83 67%
02. Okt 125 30 95 76%
03. Okt 105 11 94 90%
04. Okt 107 17 90 84%
05. Okt 134 63 71 53%
06. Okt 142 49 93 65%
07. Okt 101 48 53 52%
08. Okt 51 46 5 10%

Fazit und Empfehlung

Das gezeigte Ergebnis mag nicht jeden überraschen; ich hatte aber mit einem weniger wankelmütigen Messfehler gerechnet. Die Auswirkungen auf absolute Zahlen bzw. Trends sowie der Größe des Direct-Segments sind zum Teil enorm. Zum Wohl der Daten sollte man die Option daher nicht übergehen. Traffic von Bots, die sich mit dieser Einstellung abdecken lassen, sollten auf jeden Fall ausgeschlossen werden.... nur eben nicht mit dem Ziel, damit Referral Spam loszuwerden. Dazu sind nach wie vor individuelle und regelmäßig zu ergänzende Filter erforderlich, bis Google sich endlich etwas Skalierbares dazu einfallen lässt.


# 
Saturday, 12 September 2015

Rettet die Webanalyse: Meta-Referrer bei SSL-Umstellung einplanen

Besucher kommen, bleiben und gehen wieder. Auch heute passiert das erste und letzte noch oft über Links von A nach B. Daher ist es für jeden Webmaster nach wie vor interessant zu wissen, welche Seiten (und Domains) Traffic auf die eigene Website bringen.

Na und? Was ändert sich durch SSL?

Wenn Site A auf HTTPS umstellt - wozu es reichlich gute Gründe auch jenseits der Hoffnung auf bessere Rankings gibt -, dann kommt die Information der Quelle im Fall eines Links von A nach B nicht mehr unbedingt in der Webanalyse von B an. Vielmehr steigt dort im gleichen Maße, wie Verweistraffic sinkt, die Anzahl der Besucher an, die nun über "direct" kommen. Die Information geht also auf dem Weg verloren.

Help Me, Meta Referrer!

Um dem entgegenzuwirken, ist Site A gefragt. Hier kann aktiv entschieden werden, ob und welche Informationen weitergegeben werden sollen. Dazu dient eine entsprechende Angabe im Header der Seite. Die verschiedenen Optionen und der Aufbau werden z. B. hier in der Spezifikation bei w3.org beschrieben. Prinzipiell reicht es, in die Metadaten folgende Zeile aufzunehmen.

<meta name="referrer" content="unsafe-url">

Hierbei wird mehr oder weniger genau das an die den Traffic empfangende Website übermittelt, was auch vor der SSL Umstellung übergeben wurde. Es mag (wenig valide) Gründe dafür geben, diese Variante mit der vollständigen URL nicht umsetzen zu wollen (einfach nur Angst für dem "unsafe" im Namen zählt nicht!). Für diese Ausnahmen sollte aber auf jeden Fall ein

<meta name="referrer" content="origin">

akzeptabel sein - eine Variante, bei der es zumindest noch Schema und Host (also z. B. http://www.markus-baersch.de bei einem Verweis von einer URL wie http://www.markus-baersch.de/impressum.html) bis in die Webanalyse der verlinkten Site schaffen und so die Quelle wieder identifizierbar machen.

Unterstützung im Browsermarkt: Ja, schon...

Natürlich machen nicht alle Browser mit bei der Unterstützung dieser Anweisung. Es ist sicher keine Überraschung, dass ausgerechtet der IE (inkl. Edge) die meiste rote Farbe zur Visualisierung der Unterstützung nach Browser bei caniuse.com beisteuert:

Referrer Policy Unterstützung
Quelle: caniuse.com

Mit heute knapp 65% aller Browser weltweit und fast 75% der in DE verwendeten Browser bedeutet eine Implementierung des Tags aber sicher mehr, als nur die Unterstützung ein Exotenfeatures.

Bringt es also was?

Ja, unbedingt! Die mitunter enormen Auswirkungen auf die Zahlen in der Trafficzuordnung zeigt man am besten an einer anschaulichen Grafik. Leider habe ich aber keine zur Hand ;). Zum Glück gibt es aber ein schönes Beispiel aus der realen Google Analytics - Welt hierzu im Moz-Blog.

Warum "unsafe-url"?

"Warum nicht?" frage ich zurück. In den meisten Fällen hat man sich vorher auch keine Gedanken darüber gemacht. Ganz im Gegenteil wird oft eher vollkommen ungeniert gegen die Nutzungsbedingungen von Webanalysesystemen inkl. Google Analytics verstoßen, indem persönliche Informationen wie Mailadressen, Namen etc. mit der URL an die eigene Webanalyse gesendet werden. Wer jetzt plötzlich Bedenken entwickelt, sollte erst prüfen, wie es im eigenen System aussieht. Vielleicht mag es Szenarien geben, in denen ein Besucher einen für ihn auf irgendeine Weise wertvollen ausgehenden Link erst durch Ausfüllen eines (warum dann GET?) Formulars mit seinen Angaben "freischaltet"... aber selbst dann hilft eine interne Linkbrücke viel besser gegen Einblicke in das eigene System oder die Weitergabe persönlicher Daten als eine Beschneidung des Referrers durch https.

Erst meckern alle über das (not-provided)-Desaster und verschlimmern das Problem dann auch noch selbst? Wenngleich das - selbst bei großen Sites - im Vergleich zu Google "in viel kleinerem Stil" erfolgen mag, erscheint mir dieses Verhalten bestenfalls gedankenlos (oder wissend: scheinheilig).

Außer einer Anwendung, in der über in der Referrer-URL enthaltenen Pfade auf der verlinkten Website Rückschlüsse über den internen Aufbau, das Nutzerverhalten oder (wenngleich dann meist anonym; z. B. durch Mandantenkennungen o. Ä.) die Nutzungshäufigkeit für einzelne User erlaubt, kann ich keinen Grund sehen, warum man der Webanalyse seiner "Trafficnehmer" nicht wieder alles zurückgibt, was man ihr durch die SSL-Einführung zuvor genommen hat. In einer URL (nicht als Parameter) direkt enthaltene kritische Angaben wie Username und Passwort werden - genau wie Fragmente - ohnehin vor der Weitergabe ausgefiltert - egal ob bei einer HTTP - Verbindung oder via Metatag reaktivierter Übergabe bei HTTPS-Verweisquellen. Und o. g. Grenzfälle werden sich mit origin statt kompletter Beschneidung ganz sicher kein Bein brechen.

Die Einführung von SSL wird; auch getrieben durch die Hoffnungen auf bessere Rankings, die Google in vielen Webmastern weckt, weiter fortschreiten. Auch bei Sites, bei denen es eigentlich keinen wirklichen Grund dazu gibt. Die Browserhersteller (inzwischen ja nicht mehr nur Chrome) treiben den Ball ebenfalls weiter in diese Richtung. Wenn es aber nicht irgendwie gelingt, die Implementierung von Meta Referrer Tags in Checklisten für eine erfolgreiche SSL-Einführung zu bekommen, wird die Webanalyse darunter recht bald deutlich mehr leiden, als es jetzt schon der Fall ist. Das wäre ebenso schade wie unnötig, finde ich. Realistisch betrachtet wird eine bewusst gesteuerte Reaktivierung der Referrer-Information aber wohl leider der Ausnahmefall bleiben. Schade eigentlich.


# 
Friday, 11 September 2015

ConversionBoosting Coaching-Programm 2015

Ähnlich wertvoll wie das Stipendium aus dem letzten Jahr für den glücklichen Gewinner sollte das in diesem Jahr angebotene Coaching von ConversionBoosting ausfallen.

Betreiber eines Onlineshops oder sonstigem Business im Web und ausreichendem Budget (mind. 10.000,-- / Monat für Marketing) können sich in diesem Jahr bewerben, um umfangreiche Unterstützung über drei Monate zu erhalten.

Wer sich angesprochen fühlt, sollte sich beeilen, denn die Anmeldefrist endet schon am 30.09. Weitere Infos zum Coaching und Anmeldung.

# 
Wednesday, 27 August 2014

Standard-Auswertungszeitraum für Google Analytics anpassen?

Wer über den "normalen" Weg der Anmeldung unter www.google.de/analytics zu seinen Daten gelangt, sieht stets die letzten 31 vollständigen Tage... also eine Statistik bis gestern. Wer aber gern auch (oder gar nur) den Traffic des laufenden Tages betrachten will, muss anschließend als erstes stets den Zeitraum anpassen. Ärgerlich.

Es gibt auch leider in der Verwaltung keine Einstellung, mit der dieser Standardzeitraum angepasst werden kann. Es ist allerdings möglich, schon beim Aufruf von Analytics in der Adresse die gewünschten Datumswerte zu übergeben, z. B. via Browser-Lesezeichen. Ansätze dazu finden sich z. B. bei der allwissenden Müllhalde. Dort - und in vielen anderen Lösungen, die sich ergoogeln lassen, ist allerdings die URL-Struktur zwischenzeitlich - wenig überraschend - "veraltet", weil sich bei Analytics in den letzten Monaten viel bewegt hat.

Die dahinter steckende Lösung funktioniert aber dennoch nach wie vor. Wer es ausprobieren will oder gebrauchen kann, findet hier ein paar Beispiele. Achtung: Damit diese funktionieren, muss in einigen Browsern wie z. b. Firefox bereits ein Reiter mit irgendeiner anderen Seite geöffnet sein.

ID bestimmen

In allen Beispielen ist vorher die rot markierte ID gegen die ID des Profils ("Datenansicht") austauschen, welches geöffnet werden soll. Diese ID ist in der im Browser angezeigten Adresse zu finden, nachdem die gewünschte Datenansicht in Analytics geöffnet wurde. Dort steht dann z. B. etwas wie

https://www.google.com/analytics/web/?authuser=0#report/visitors-overview/a123456w123456p123456/.

An der rot markierten Stelle findet sich die ID der Datenansicht, die in den folgenden Beispiel-"Links" ausgetauscht werden muss:

Lesezeichen anlegen

Zur Anlage eines neuen Lesezeichens in die Lesezeichenleiste (hier: Chrome) "rechtsklicken" und im Kontextmenü "Neues Lesezeichen" wählen.

Neues Lesezeichen anlegen

Hier einen beliebigen Namen für das Lesezeichen eingeben und einen mit "Ihrer ID" versehenen Eintrag aus den folgenden Beispielen für die gewünschte Ansicht per Copy & Paste einfügen:

Beispiel Analytics Lesezeichen

Analytics Zielgruppe "heute"

Um die Übersicht des Bereichs "Zielgruppe" zu öffnen, die auch der ersten Ansicht entspricht, die auf dem o. a. "normalen" Weg zu einer Datenansicht als erstes zu sehen ist, aber nur den Traffic des aktuellen Tages statt der üblichen 32 Tage zu betrachten, verwenden Sie folgenden "Link" als Bookmark:

javascript:(function(){function d(a){a=String(a); a.length<2&&(a='0'+a); return a}var prfl='a123456w123456p123456',c=new Date, b=c.getFullYear()+d(c.getMonth()+1)+d(c.getDate()); window.open('https://www.google.com/analytics/web/?#report/visitors-overview/' + prfl + '/%3F_u.date00%3D'+b+'%26_u.date01%3D'+b+'/=');})();

Dabei kann auch, wenn Sie einen anderen Report sehen wollen, eine andere URL angegeben werden, die Sie sich einfach aus der Adresse einer beliebigen Ansicht in Analytics raussuchen können. Das folgende Beispiel öffnet die Trafficquellen statt der besucherübersicht, indem der grün markierte Teil der URL angepasst wird:

Analytics Akquisition "heute"

javascript:(function(){function d(a){a=String(a); a.length<2&&(a='0'+a); return a}var prfl='a123456w123456p123456',c=new Date, b=c.getFullYear()+d(c.getMonth()+1)+d(c.getDate()); window.open('https://www.google.com/analytics/web/?#report/trafficsources-overview/' + prfl + '/%3F_u.date00%3D'+b+'%26_u.date01%3D'+b+'/=');})();

Soll nicht nur "heute", sondern z. B. alles seit Monatsanfang inkl. des laufenden Tages dargestellt werden, müssen zwei unterschiedliche Datumswerte berechnet und übergeben werden. Auch hierzu ein Beispiel:

Analytics Akquisition "Monatsanfang bis heute"

javascript:(function(){function d(a){a=String(a); a.length<2&&(a='0'+a);return a}var prfl='a123456w123456p123456',c=new Date,a=c.getFullYear()+d(c.getMonth()+1)+'01', b=c.getFullYear()+d(c.getMonth()+1)+d(c.getDate()); window.open('https://www.google.com/analytics/web/?#report/trafficsources-overview/' + prfl + '/%3F_u.date00%3D'+a+'%26_u.date01%3D'+b+'/=');})();

Auf gleiche Weise können durch passend gestaltete Datumswerte auch Übersichten für das ganze Jahr oder die letzten n Tage berechnet werden, wenn die Ermittlung der Datumswerte a und b entsprechend ausgetauscht wird. Dabei ist nur die Maximallänge für Lesezeichen-URLs zu beachten, die je nach Browser i. d. R. irgendwo oberhalb von 2000 Zeichen liegt – alles darunter ist als „Bookmarklet“ also durchaus machbar.

# 
Monday, 11 February 2013

Webanalyse mit Yandex.Metrica

Nachdem in diesem Blog schon eine ganze Weile nichts mehr passiert ist und der letzte Beitrag das Aussterben von Yahoo! Webanalytics zum Thema hatte, finde ich als Wiedereinstieg den Überblick eines denkbaren Ersatzes als würdiges Thema.

Durch Zufall bin ich auf Yandex.Metrica gestoßen - dem "Google Analytics dieser anderen Suchmaschine". Und mein erster Eindruck lässt mich hoffen, dass hier eine echte Alternative zu Analytics lauert. Sicher nicht auf dem gleichen Stand - und leider auch nicht mit den gleichen Stärken und Besonderheiten von Yahoo! Webanalytics gesegnet -, aber dennoch ein interessanter Kandidat.

Datenschutz?

Datenschutz ist hier nicht das eigentliche Thema und ich bin weder Fachmann noch Jurist. Metrica ist halt wie viele andere ein Tool, dass Daten auf dem Server des Anbieters speichert. Genau wie Clicktale und tausend andere gängige Tags, die in Webseiten nisten. IP-Adressen werden nicht offenkundig verarbeitet und ob diese gespeichert werden, kann ich nicht beantworten. Die Nutzungsbedingungen sprechen von einer anonymen Aufzeichnung und Speicherung - mehr weiß ich zu diesem Zeitpunkt auch nicht. Die Cookies enthalten eine verschlüsselte ID, die keine direkten Rückschlüsse auf private Daten des Surfers zu geben scheint. Es sind keine "untergejubelten" FirstParty-Cookies, sondern Drittanbieterkekse. Das macht allein schon hinsichtlich der Browsereinstellungen einen Unterschied. Solange man aber keine persönlichen Daten in URLs o. Ä. an das System überträgt, besteht wohl kaum ein Nachteil ggü. vielen anderen Webanalysesystemen und so sollte es auch für Deutschland "reichen". Auch die in der Hilfe aufgezählten gesammelten Daten sind eine Auflistung der üblichen Kennzahlen. Der europäische, speziell der deutsche Markt wird für Yandex vermutlich noch nicht so schwierig erscheinen, wie er es vermutlich noch werden kann, sobald die Datenschützer bei wachsender Verbreitung hellhörig werden. Schließlich ist "Yandex das Google von vor 5 Jahren", wenngleich (noch) in einem anderen Markt und wer weiß schon, wie sich dieser noch entwickelt. Wenn es spezielle Anforderungen gibt, wird man diese bestimmt bald auch bei Yandex kennen...

Konfiguration und Einrichtung

Die Installation ist denkbar einfach und die Konfiguration erscheint durchdacht. Nach Anlage eines Yandex-Accounts (der wie bei Google Zugriff auf eine ganze Menge weiterer Dienste inkl. Mail etc. erlaubt) kann der "Counter", der ungeachtet des altmodisch klingenden Namens mehr als nur ein Besucherzähler ist, konfiguriert und der Code angerufen werden.

Konfiguration Y.M Counter

Dabei sind bereits eine ganze Menge an Optionen möglich und es können auch mehrere "Mirror"-Domains eingegeben werden, die die gleichen Inhalte ausliefern.

Optionen Y.M Trackingcode

Mehrere Sites in einem Profil scheinen aber nicht vorgesehen zu sein und obschon ich es nicht getestet habe, scheint die "Mirror"-Option eher darauf hinzudeuten, dass aller Traffic von hier nicht angegebenen Domains nicht im Profil ankommt. Auf der anderen Seite könnte genau diese Option auch ein Tracking mehrerer Domains dennoch ermöglichen... der ThirdParty-Cookie wäre dabei dann hilfreich. Wer es schon ausprobiert hat, dem bin ich für eine Nachricht oder einen Kommentar dankbar.

Als Besonderheit bietet Yandex die eigene Definition des Timeouts für Sessions, Infos über wichtige Probleme mit der Site per Mail und / oder SMS (also Webmaster Tools Light gleich eingebaut ;)), (gute, auch nicht-klickbare Bereiche umfassende) Clickmaps, Tracking von Downloads, externen Links und Shares, benutzerdefinierte Variablen und für zahlende (Werbe-) Kunden gibt es mit WebVisor sogar aufgezeichnete Einzelsessions zu sehen. Alles direkt aus der Dose und ohne viel Anpassungsarbeit.

Wer mehr braucht, findet in der Hilfe passende Hinweise eher mittels Suchfunktion, denn die in per Navigation erreichbaren Angaben kratzen wirklich nur an der Oberfläche. So gibt es eCommerce-Tracking, Zieltrichter (hier: "Multi Step Goals"), manuell aufgerufene "Zielerreichung", die als Ersatz für Events verwendet werden können, eine (offenbar nicht immer auf Anhieb funktionierende) Analyse von Formularabbrüchen, Steuerung und Reporting per API... und jede Menge weitere Optionen, mit denen sich vermutlich auch die meisten tieferen Implementierungen von Google Analytics weitestgehend ersetzen lassen.

Der so konfigurierte Code zum Einbau auf der eigenen Website funktioniert wahlweise klassisch (was für Tagmanagement Systeme hilfreich sein sollte) oder asynchron. Man kann bis zu 100 Ziele pro Site und unbegrenzt viele Filter definieren. Das ist im Zweifelsfall auch erforderlich, denn ausgefuchste Filter mittels Regex scheinen hier nicht möglich zu sein, so dass es auch schon mal ein paar mehr sein müssen als vielleicht bei Google Analytics. Auch einen Nutzermanager gibt es, mit dem man zusätzlichen Usern Zugriff auf die Daten eines Counters (oder aller Counter eines Kontos) gewähren kann.

Reports

Die Oberfläche ist etwas gewöhnungsbedürftig und sieht eher sparsam aus. Jeder Report kann in verschiedenen Darstellungsformen als Diagramm angezeigt; Daten können für weitere Analysen exportiert werden. Außerdem sind alle Reports in einem Editor anpass- und erweiterbar. Dabei sind die Freiheiten zwar zugegebenermaßen nicht so groß wie bei Google, aber Kennzahlauswahl und Filtermöglichkeiten reichen für sinnvolle vorsegmentierte eigene Reports locker aus. Avinash´s "ABO"-Reports kann man so mit etwas Mühe einmalig konfigurieren und schnell wieder finden. Nett ist es, dass alle Zahlen absolut und als Prozentwert dargestellt und zur optischen Unterstützung mit Balken hinterlegt sind.

Reports Y.M

Aufgeteilt in die üblichen Bereiche finden sich eigentlich alle Kennzahlen, die man von einer Webanalyse erwarten darf; auch mobiler Traffic hat hier seinen eigenen Platz in der Navigation. Gegen "not provided" ist man freilich auch hier nicht immun, aber zumindest wird der hier unter "Unknown" laufende Riesenanteil in nach Traffic sortierten Listen nicht oben angezeigt, sondern an das Ende gestellt, so dass man sich auf die Daten beschränken kann, die vorhanden und auswertbar sind. Zu den vorgefertigten Berichten gehören bei Yandex Schätze wie Ladezeiten und die Servererreichbarkeit. Die Auswertungsperiode und Auflösung ist leicht einzustellen; allerdings scheint es keine Vergleichszeiträume zu geben - das ist schon ein wenig eigenartig. Auch gewöhnungsbedürftig (aber praktisch) ist die Eigenart, dass eine "Segmentierung"; die man z. B. durch Drill Down auf einzelne Ziele o. Ä. vorgenommen hat, beim Wechsel eines Reports bestehen bleibt. Die Vielfalt der Reports kennt aber auch deutliche Grenzen.

Dashboard Y.M

Einschränkungen

Es gibt nur ein Dashboard und die Möglichkeiten zur Anpassung sind vergleichsweise begrenzt. Dafür gibt es hier aber zum Trost eine Vorschau auf den zu erwartenden Traffic für den nächsten Tag. Wird diese Prognose aber unter- oder überschritten, scheint es genau so wenig eine Möglichkeit zur Benachrichtigung zu geben, wie für andere Auffälligkeiten, die dem "Radar" in Google Analytics entsprechen würden. Auch so praktische Dinge wie AdHoc-Trichteranalysen aus Yahoo! oder andere echte "Knaller", die Alleinstellungsmerkmale oder zumindest echte "Premiumfunktionen" ausmachen können, scheint man hier vergeblich zu suchen. Sicher: Die Darstellung der Keywords als Wortwolke ist nett, aber das reicht 2013 bestimmt nicht mehr, um damit in die Zeitung zu kommen.

Auch nach Vergleichbarem zum Goal- oder Visitor-Flow, haarkleinen Segmentierungsmöglichkeiten oder vielen neueren Dingen (z. B. Multi-Channel Reports, definierbare Attributionsmodelle etc.), die in den letzten Monaten in Google Analytics Einzug gehalten haben, gibt es nicht (oder ich habe sie nicht gefunden). Auch keine RealTime - dafür werden die Daten aber mehrfach in der Stunde aktualisiert und unter den Reports findet sich stets die Angabe, wie alt die Datenbasis einer Tabelle oder eines Diagramms ist.

Ich habe den Eindruck, dass auch bei Yandex noch nicht das Ende der Fahnenstange erreicht ist und in den nächsten Monaten werde ich ja mitbekommen, wie schnell sich hier das Rad dreht und in welcher Schlagzahl Innovationen und nachgeholte Funktionen aus dem Wettbewerb hier Einzug halten. Oder eben nicht...

# 
Wednesday, 13 June 2012

Schade: Yahoo! Web Analytics geht von uns

Es gab viele Gründe für Yahoo! Web Analytics und ich habe es gern, wenn auch nicht sehr häufig, genutzt. Die Oberfläche mag nicht so sexy gewesen sein wie bei vielen Wettbewerbern, aber wenn man speziell man den Vergleich mit Google Analytics zieht, gibt es doch auch jetzt noch eine ganze Menge Punkte, die in Y!WA besser laufen. Simples Cross-Domain-Tracking, flexible und historiekompatible Trichter, Berichte und Dashboards und andere Vorteile, die Y!WA von den IndexTools geerbt hatte, werde ich sicher vermissen. Aber es war ja nach dem Aus für andere Yahoo-Zweige eigentlich schon zu erwarten, dass auch hier der Rotstift zuschlägt, zumal es in letzter Zeit nicht gerade vor Innovationen in Y!WA gewimmelt hat.

Und so endet das Datensammeln am 31. August - und pünktlich zu Halloween ist dann endgültig Feierabend und die Accounts machen für immer dicht. Wer (9 Minuten dauernde) 5 Minuten mit mir trauern mag, darf dazu gern statt schicksalsschwangerer Musik das folgende Video laufen lassen.

# 
Monday, 04 June 2012

Analytics Content Experiments: (noch) schlechter Ersatz für Google Website Optimizer

Mit großem Trara beerdigt Google zum 1. August den Google Website Optimizer und bietet als Ersatz neue "Content Experiments" in Google Analytics an. Wer sich nur die Ankündigungs-E-Mail von Google dazu durchliest könnte meinen, es handelt sich um alten Wein in neuen Schläuchen und das Tool sei nur "umgezogen". Die dort verwendete Formulierung "To elevate website optimization and provide one fully integrated tool for testing, content optimization will now have a new home within Google Analytics." klingt ja auch vollmundig und lässt auf Umsetzung vieler Wünsche hoffen, die man ggf. bisher im Einsatz des Website Optimizers entwickelt hat.

Zickige Validierung in GA

Mein erstes Fazit lautet aber leider: Pustekuchen. Es sind zwar ein paar erfreuliche Vereinfachungen mit dem Umzug gekommen, aber leider auch eine Menge Einschränkungen. Die überwiegend guten Nachrichten daher lieber zuerst.

Das mag (meistens) nett sein:

  • Ein separates Script für eine Conversion kann man sich nun i. d. R. sparen, denn es werden Analytics-Ziele als Grundlage für einen Test verwendet. Da dieser Punkt aber auch bedeutet, dass man für bisher per Script herbeigeführte Extrawürste wie Auslösen einer Conversion nach Erreichen einer Mindestanzahl von "Microconversions" o. Ä. nun ggf. (temporäre) "Hilfsziele" einrichten muss, muss das nicht zwingend ein Vorteil für jeden Anwendungsfall bedeuten. Zumindest aber geht dadurch keine Flexibilität verloren, macht bestimmte Szenarien nur ggf. etwas umständlicher oder erfordert (wenn alle Ziele "belegt sind") evtl. sogar ein neues Profil für Tests (zumal die Anzahl der Tests pro Profil in Analytics nun auf 12[wieso 12?] begrenzt ist)
  • Überhaupt werden weniger Scripts in Seiten benötigt, denn auch die Varianten müssen nicht mehr separat verwanzt werden, sondern nur noch die Originalseite. Klingt gut. Das "Aber" kommt dann nachher in der nächsten Liste...
  • Google steuert den Traffic auf die Varianten "schlau" selbst. Ziel ist es hier, die Seiten mit offenkundig schlechterer Konversionsrate nach einer gewissen Sicherheit mit weniger Traffic zu beschicken, um den Schaden für die Website zu minimieren. Klingt erst einmal gut, bedeutet aber durch die zwingende Nutzung dieser nicht-optionalen "Gutwillensautomatik" in gewisser Weise auch Kontrollverlust beim Experiment.
  • Wollte man bisher die Besucher einer bestimmten Variante separat in Analytics auswerten, musste man diese explizit mit einer benutzerdefinierten variable zu diesem Zweck markieren und konnte so Segmente bilden. Das ist jetzt durch die Integration einfacher, so dass das Verhalten jenseits der reinen Zielerreichung durch Segmentierung nach Varianten leichter beobachtet werden kann. Spart aber grundsätzlich erst einmal nur (geringen) Aufwand beim Aufsetzen es Experiments im Vergleich zur alten Lösung
  • Adieu Langzeittests: Tests in Analytics enden spätestens nach 3 Monaten. Das ist prinzipiell mal ein Vorteil, denn so ist man gezwungen, sich von der Idee zu verabschieden, einen Test nur lange genug laufen lassen zu müssen, um einen Gewinner zu finden, obschon die getesteten Variablen offenbar überhaupt keinen Einfluss auf die Ergebnisse des Tests haben ;). Das das im Einzelfall aber auch wieder ein Nachteil sein kann, ist ja fast schon klar...
  • Keine kollidierenden Tracker-Objekte mehr. Wer bisher GA und GWO parallel genutzt hat, musste ggf. die Scriptcodes anpassen, damit der Spaß überhaupt funktioniert. Außerdem wurde auf diese Weise auch mehr Code angezogen und ausgeführt, als das jetzt der Fall zu sein scheint, da keine zwei "Analytics-Codes" und unterschiedliche Profile mehr im Spiel sind. Die Content Experiments funktionieren sowohl mit dem neuen, als auch dem alten (synchronen) Trackingcode.

Das war es aber eigentlich auch schon. Ein wenig schöner mag das UI durch die Integration in Analytics ja geworden sein, aber wesentlich und / oder besonders bemerkenswert (weil nun einfacher oder besser oder sonstwas) finde ich das nicht. Mit Tools wie Optimizely hat man damit jedenfalls noch lange nicht aufgeschlossen. Vielmehr scheint es schon jetzt einige leicht zu identifizierende Nachteile zu geben... und es steht zu befürchten, dass mit steigender Erfahrung mit dieser Integration (noch ist kein einziger Test, der hier in Analytics gestartet wurde, bereits beendet) noch weitere Punkte dazu kommen werden.

Nicht so schön:

  • Der wichtigste Punkt zuerst: Die Flexibilität wird damit stark eingeschränkt. Denn sowohl (wie bisher dynamisch generierte) Multivariate Experimente als auch Experimente mit mehr als 5 Varianten sind mit den Content Experiments in Google Analytics nicht umsetzbar. Mehr muss man dazu auch eigentlich nicht schreiben, aber es ist eine wirklich fette Kröte, die man damit schlucken muss und ich würde mich nicht wundern, wenn das im ersten Schritt den Wettbewerb mehr stärkt, als dass es Analytics-Benutzer neu auf das Thema "Testing" bringt...
  • Ein Punkt, den viele sicher auch der Liste der Vorteile zuordnen würden: Es dauert mindestens 2 Wochen, bis ein Test "sichere" Ergebnisse liefert. Ob dies nun wirklich dazu dient, voreilige Schlüsse zu vermeiden oder nicht: Wer wirklich Traffic hat, konnte bisher nach Ablauf von mindestens 7 Tagen (um Schwankungen im Wochenverlauf nicht zu ignorieren) oftmals bereits fertig sein. Natürlich: Google zeigt wie früher stets den aktuellen Stand der Dinge an und verbietet auch nicht, einen Test "vorzeitig" zu beenden, aber es ist zu erwarten, dass eine Vielzahl von Benutzern erst dann Vertrauen in ein Ergebnis hat, wenn auch das Tool sagt, dass es "fertig" ist...
  • Folgetests auf der gleichen Seite erfordern offenbar stets einen neuen Code, denn jeder Test hat eine eigene ID
  • bei einer Implementierung in die Webanalyse naheliegende Wünsche wie die Beschränkung der Teilnahme an Tests nach verschiedenen Segmentierungskriterien o. Ä. sind (noch) nicht umgesetzt. Das bedeutet, dass die Integration in Analytics bis auf die Verwendung von dort bereits definierten Zielen noch keine der erwarteten funktionalen Verbesserungen mit sich gebracht hat. Auch die Berücksichtigung mehrerer Ziele o. Ä. (sei es gewichtet oder nicht) bleibt so folgerichtig noch offen
  • Die Validierung ist noch zickiger als bisher. Wenn man das Script in der Originalseite z. B. nun nicht direkt nach dem head-Tag einfügt, gibt es Gemecker.
    Zickige Validierung in GA
    Das bedeutet zwar nicht, dass man das Script nicht genau wie vorher zur Not (wenn es das CMS z. B. nicht anders zulässt) an anderer Stelle unterbringen, die Meldung ignorieren und trotzdem Ergebnisse erhalten kann, aber aus Sicht des typischen Analytics-Anwenders ist das vielleicht schon ein Grund, bereits nach dem ersten Einrichtungsversuch dauerhaft das Handtuch zu werfen
  • Die Integration wirkt teilweise noch fehlerbehaftet. Ob z. B. Vorschaubilder der beteiligten Seiten dargestellt werden oder nicht, scheint noch dem Zufall unterworfen zu sein. Das sind zwar Kleinigkeiten und zumindest bis jetzt scheinen Tests durchaus zu funktionieren, aber auch das fördert normalerweise nicht das Vertrauen der potentiell durch die Integration neu zu gewinnenden Benutzer für diese Funktion
  • Wer wirklich viel testet, wird sich vermutlich schnell über die Limitierung auf 12 Tests pro Profil ärgern. Damit sind übrigens aktive Tests gemeint. Wenn ein Test also abgelaufen oder pausiert ist, zählt er nicht für dieses Limit

Also: Luft nach oben ist noch reichlich vorhanden. Es bleibt zu wünschen, dass zumindest wesentliche Funktionen wie multivariate Tests möglichst schnell wieder einen Weg in das Tool finden, denn ansonsten ist es absehbar, dass es sich für eine ganze Menge typischer Testszenarien vorerst disqualifiziert. Warum der GWO zumindest in der Übergangsphase nicht weiterhin verfügbar bleibt, muss man Google fragen. Es sei denn, die größten Lücken werden noch vor dem 1. August geschlossen. Wer weiß..?

# 
Monday, 09 January 2012

Scroll-Tracking in Google Analytics

Inspiriert durch die Ausgabe 23 von Web Analytics TV habe ich mich endlich aufgerafft, ein generelles Problem vieler Blog-Sites anzugehen: Hohe Absprungrate, geringe "Time On Site". Denn allzu oft landet ein Besucher mit einer sehr konkreten Anfrage auf einer Seite, die eine sehr konkrete Antwort gibt. Im Idealfall ist die Frage damit geklärt und der Besucher verlässt die Site... vermutlich durchaus zufrieden. Was er dabei aber in der Webanalyse hinterlässt, ist die gleiche Spur wie die eines "echten Bouncers", der kam, sah (dass er falsch war) und direkt wieder verschwand. Eine Seite, Null Sekunden, Weg.

Die Lösung kann in diesem Fall die Messung einer Interaktion sein, die man durchaus als "Engagement" betrachten darf: Scollen der Seite. Denn wird der Beitrag wirklich gelesen (und ist er länger als nur ein paar Sätze bzw. enthält Ressourcen wie Bilder, Tabellen o. Ä.), wird der komplette Inhalt kaum auf die erste Bildschirmseite passen. Es ist also im Sinne der Webanalyse, wenn man durch die Messung einer solchen Interaktion die Qualität der Daten verbessert. Gibt man GA die Möglichkeit durch virtuelle Pageviews (wer sich gern extra dick in die Tasche lügt) oder besser Events mitzubekommen, wenn weiter nach unten gescrollt wird, dann bedeutet dies sowohl eine bessere Messung der Verweildauer auf der Seite als auch eine gerechtere Bestimmung der Absprungrate. Denn sobald ein solches Event ausgelöst wird, gibt es ein Ereignis nach dem Betreten der Seite, so dass diese nicht mehr in den Übersichten der besuchten Seiten wie eine "Problemseite" erscheint, ohne es wirklich zu sein.

Ich habe bei der Suche nach bestehenden Lösungen zwei unterschiedliche Beispiele gefunden, an denen man sich bei der Umsetzung orientieren kann. Die erste, einfachere Variante fängt "nur" die Tatsache ein, dass gescrollt wurde und gibt sich damit zufrieden, die zweite Lösung ermittelt auch die "Scrolltiefe" und löst dazu ggf. mehr als ein Event aus, wenn weiter nach unten gescrollt wird. Und obschon die zweite Lösung eigentlich mehr Daten liefert und auch bei der Verweildauer auf einer einzelnen Seite genauere Werte liefert, habe ich mich mit einer leicht angepassten Variante nach dem ersten Vorbild entschieden. Erstens, weil es mir primär um eine bessere Betrachtung des Absprungverhaltens ging und weil ich (bei meinen meistens recht langen Beiträgen) eine "Eventüberschwemmung" befürchte, die mir die Auswertung anderer Events, die hier auch genutzt werden, nicht gerade vereinfachen würde.

Wie auch immer man sich entscheidet und wie "genau" man es wissen will: Schon nach kurzer Zeit sieht man den Erfolg der Anpassung in "realitätsnäheren" (und idealerweise an der richtigen Stelle gestiegenen bzw. gesunkenen) Kennzahlen. Hier am Beispiel dieses Blogs seit der Implementierung zum Jahreswechsel:

Statistik in Google Analytics

Das Diagramm zeigt schon nach wenigen Tagen den gewünschten Trend: Gesunkene Absprungrate, mehr Time On Site. Auch die absoluten Kennzahlen sind signifikant unterschiedlich für die Tage vor und nach der Implementierung:

Statistik in Google Analytics

Wer sich bei den o. A. Beispielen bedienen und eine eigene Implementierung vornehmen will, kann die dortigen Fassungen eigentlich unverändert übernehmen. Bitte aber daran denken, die Syntax des Eventtracking-Aufrufs für den jeweils verwendeten Google-Analytics-Trackingcode anpassen, also entweder nach der alten Variante mit dem pageTracker, wie es im ersten Beispiel der Fall ist oder asynchron wie im zweiten Beispiel mit der mehrfachen Messung.

# 
Friday, 21 October 2011

Google Analytics in Echtzeit

Ich will mich gar nicht an der Diskussion beteiligen, wie sinnvoll nun Realtime Webanalyse nun ist oder nicht - jedenfalls nicht hier und jetzt.

Denn ich freue mich viel zu sehr über die Berichte, die erfreulich schnell nach der Anmeldung zur Teilnahme an der Beta zu Realtime in Google Analytics heute in meinem Konto verfügbar sind.

Realtime in GA

Was ich wirklich sinnvolles damit anfangen kann - und in welchem Profil - werde ich mir irgendwann später überlegen. Jetzt erst mal wieder zurück zur Betrachtung der Echtzeitanalyse ;)

# 
Thursday, 06 October 2011

Organische Impressions + Co. jetzt auch in Analytics

Und weiter geht´s mit der Verknüpfung von Analytics und den Google Webmaster Tools: Im neuen Bereich "Besucherquellen -> Suchmaschinenoptimierung" (nur in der neuen Oberfläche) finden sich nun nach Verknüpfung der Analytics-Web-Property mit dem passenden Eintrag aus den Webmaster Tools (ja genau: Gleiches Google - Konto erforderlich, logo!) zusätzliche Reports, die auch die Impressions, Seiten, Klickraten und geografische Angaben zu den Besuchern enthalten.

Suchanfragenbericht

Das ist zwar erst einmal nichts, was aus den Socken haut, aber man kann zumindest schon jetzt von den im Vergleich zu den WMT umfangreicheren Filteroptionen in Analytics profitieren, um sich die Impressions zu den Begriffen oder Seiten genauer anzusehen. Auch praktisch ist z. B. eine Sicht auf die Klickrate nach "Quelle" in Form unterschiedlicher Google-Dienste wie Suche, Bilder oder Mobile, in denen man durchaus signifikante Unterschiede feststellen kann ;). Ich hoffe doch, dass dieser Block noch ausgebaut wird. Gegen den m. E. nicht ganz so glücklich gewählten Namen "Suchmaschinenoptimierung" kann man ja vermutlich nun nichts mehr tun...

# 
Friday, 30 September 2011

Einfachere Verifikation: Google Analytics und Webmaster Tools wachsen weiter zusammen...

Das scheint wohl schon länger so zu funktionieren, aber mir ist es erst jetzt aufgefallen: Wenn in den Google Webmaster Tools eine neue Site hinzugefügt werden soll, kann dazu nun einfach der Analytics-Trackingcode verwendet werden. Meint: Wer als Administrator beim passenden Analytics-Konto zur Website eingetragen ist, muss sich künftig weder als Agentur noch Betreiber mit Uploads, Metadaten oder gar DNS-Konfiguration rumschlagen.

Webmaster Tools

Ich find´s praktisch. Die engere Verknüpfung beider Werkzeuge ist damit zwar nicht wirklich vorangetrieben, aber trotzdem eine große Hilfe. Wer weiß: Es mag ja auch was mit dem kommenden "Analytics Premium" zu tun haben;) Wenn man jetzt noch die neue "schöne" Startseite der WMT wieder auf eine übersichtlichere Listenansicht umstellen könnte. Aber ich habe ja immer was zu meckern...

# 
Friday, 04 March 2011

Man kann Google Webmastertools + Analytics verbinden... aber wozu?

Um die Frage gleich zu beantworten: Aktuell ist die Verknüpfung zwischen Webmastertools und Analytics eigentlich noch zu gar nichts gut. Aber das kann sich ja durchaus noch ändern... Speziell die Google Webmastertools haben sich in den letzten Monaten ja durch stetige kleinere und größere Verbesserungen hervorgetan. Da dort vor allem der Bereich der Analyse von Klicks und Impressions im Suchanfragenbericht immer hilfreicher wird, ist der Wunsch nach ähnlichen Reports direkt in Google Analytics nicht ungewöhnlich. Aktuell findet man aber nichts weiter als zwei sehr unspannende Links aus den WMT zu Google Analytics. Nichts in der anderen Richtung oder praktischere / engere Integration beider Produkte.

Ich glaube aber trotzdem, dass sich die "Mühe" der Verknüpfung lohnt und je nach Resonanz auch relativ schnell nicht nur weitere Brücken zwischen beiden Produkten geschlagen werden, sondern die wesentlichen Daten aus den Webmaster-Tools kurz oder lang deutlich näher an Google Analytics rücken als heute. Schön wäre es jedenfalls...

Wer heute schon mal reinsehen will und die Webmastertools mit dem gleichen Google-Konto wie Analytics betreibt (das ist Voraussetzung - zur Not also das Profil in Analytics für den richtigen Account freigeben), findet die Verknpüfung direkt im Dashboard der Webmastertools.

Verknüpfung herstellen

Je nach Anzahl der für dieses Konto freigeschalteten Analytics-Accounts kann die Auswahl des richtigen Kontos zur Aufgabe werden, die ohne Browser-Suchfunktion gar nicht gelöst werden kann (so sah das jedenfalls bei mir aus). In der Regel ist die Liste aber so übersichtlich wie hier dargestellt und die Auswahl des richtigen Profils kein Problem.

Profil wählen

Zum Dank erhält man dann erstens einen Link im Bericht "Links zu Ihrer Website", der direkt zum passenden Report des verbundenen Analytics-Profils führt.

Verlinkende Websites anzeigen

... und noch trivialer ist der Link oben in den Webmastertools, der stets zum Dashboard des passenden Analytics-Profils führt.

Dashboard anzeigen

Gähn. Ja sicher: Das mag praktisch sein, wenn man eine gewisse Anzahl von Sites verwaltet und daher ggf. schneller auf zwei selbst geöffneten Tabs mit beiden Informationsquellen durcheinanderkommt, wenn er diese Links in die stets passenden Profile nicht hat. Trotzdem für sich gesehen viel zu langweilig und nebensächlich, um überhaupt einen Blogbeitrag drüber zu schreiben. Wenn es denn nicht mit ein wenig Glück nur der Einstieg in eine tiefere Integration ist. Man darf ja mal träumen ;)

# 
Tuesday, 07 September 2010

Gewichtete Sortierung in Google Analytics: Einfach Wow!

Sich über einzelne neue Funktionen auszulassen lohnt sich nur dann, wenn es wirklich ein Knaller ist. Und warum auch immer: Obwohl die neue Sortierung nach Gewichtung bei Google Analytics vielleicht auf den ersten Blick unspannender erscheint als andere neue Zeitsparer der letzten Wochen und Monate*, habe ich mich schneeköniglich gefreut, als ich erstmals über das neue Feature in einem Analytics-Account gestolpert bin.

Worum geht´s?

Ganz einfach: In einem typischen Google Analytics-Profil können zwar inzwischen sehr viele sinnvolle Dinge direkt im Webinterface ermittelt werden... trotzdem kommt man bei konkreten Fragen oft nicht an Excel vorbei. Das ist zwar auch nach Einführung der gewichteten Sortierung noch so, aber man kann sich zumindest bei einigen "einfachen", aber wesentlichen Fragen den Umweg nun nicht nur sparen, sondern vielleicht sogar noch bessere Werte erhalten als mit anderen Methoden. Als Beispiel soll die Frage dienen: Welche Keywords (oder Trafficquellen, Kampagnen, tri, tra, trullalla) bringen mir zwar relativ viel Traffic, weisen aber überdurchschnittlich hohe Absprungraten (oder schlechte Conversionrates oder...) auf?

Versucht man nun, diese Frage mit einer absteigend nach Absprungrate sortierten Liste der Keywords zu beantworten, findet man i. d. R. eine ganze Menge an "Schrott", der 100% Absprünge bei minimalen Seitenaufrufen besteht. Seitenweise.

Nach Absprungrate sortierte Begriffe
Sie kamen - sahen, dass Sie hier falsch sind - und gingen. Unvermeidbar und nicht schlimm... aber definitiv nicht geeignet, um effektive Optimierungsansätze zu liefern.

Damit kann man natürlich herzlich wenig anfangen. Also müssen die Daten nach Excel exportiert und dann dort erst einmal der ganze Kleinkram gefiltert werden. Anschließend kann man z. B. über das (nach belieben mit individuellen Faktoren) gewichtete Produkt aus Seitenaufrufen und Absprungrate genommen werden, um eine "Hilfs-Kennzahl" zu generieren, nach der dann sinnvoll sortiert werden kann, um diejenigen Begriffe zu finden, für die es sich ggf. lohnt, Anpassungen an den Zielseiten zu planen, um aus dem Traffic mehr herauszuholen. Wenn die Begriffe denn irgendwas mit dem eigenen Angebot zu tun haben. Ansatzweise ;)

Aber Moment mal: Was macht die komische Checkbox da oben? Gewichtet nach Impressions und Bouncerate? Nur mit einem einfachen Klick? Genau!

Nach Absprungrate und Impressions sortiert
Das ist hilfreich: Traffic und Abschreckungsgrad im Auge: Das sind die Begriffe, für die sich die Arbeit vielleicht lohnen könnte!

Nach Aktivierung zeigen sich deutlich veränderte Top-Ten. Diese Begriffe haben einen Einfluss auf die Gesamtperformance der Site und hierüber ist dann auch (hoffentlich) viel einfacher etwas zu finden, was eine weitere Analyse lohnt: Wie sehen die Zielseiten aus und wie kann der Traffic ggf. in die richtige Richtung gelenkt werden? Man muss sollte zwar trotzdem immer noch nachdenken, ob ein Begriff wirklich relevant für das eigene Thema ist und ob 100% Absprungrate bei der konkreten Zielseite nicht einfach nur bedeutet, dass das Ziel des Besuchers bereits auf der ersten Seite erreicht wird... Aber so finden sich Chancen natürlich deutlich schneller. Ohne Export und Umwege, ohne viele Klicks - sehr cool, oder?

Wie Analytics diese Gewichtung vornimmt? Naja, die Analytics Hilfe ist hier gewohnt unkonkret. Wer es genauer wissen will, findet bei Avinash Kaushik eine gewohnt ausführliche Beschreibung, die auch auf die Vorgehensweise eingeht. Mir ist das aber ehrlich gesagt wurscht. Ich brauche auch keine Enthüllungsshows über die tollstren Tricks der Magier. Und es ist mir egal, wie genau die Pins wieder aufgestellt werden, solange es funktioniert und ich zügig weiterbowlen kann. Was zählt ist die Tatsache, dass auf diese Weise schneller sehr viel mehr aus vielen Reports herauszuholen ist. Vorausgesetzt, dass sich jemand dafür interessiert und konkrete Fragen hat, die er seiner Webanalyse stellen will...


*) Ich meine z. B. Dinge wie die Mehrfachanmeldung - schau mal in die Einstellungen des Google - Profils. Das wird für mich vielleicht der größte Effizienzschub seit Einführung des integrierten Suchanfragenberichts und der Segmentierung und Filter im AdWords-Interface, wenn es denn erst einmal durchgängig bei allen Google-Produkten funktioniert ;)

# 
Monday, 16 November 2009

AdSense mit (anderem) Google Analytics Konto verbinden

Google Analytics kann bereits seit einiger Zeit auch Daten aus einem verbundenen AdSense Konto anzeigen. Was aber, wenn man ein gentrennte Google-Konten für Analytics und AdSense verwendet? Die Lösung vorab: In diesem Fall ist es erforderlich, dem "AdSende"-Konto-Login mittels des Analytics-Nutzermanagers Administratorzugriff auf das Konto zu gewähren, in dem das betreffende Profil der Website verwaltet wird, welches künftig die AdSense-Daten erhalten soll. Der lange Weg:

AdSense-Konto mit Analytics verknüpfen

Zunächst einmal muss die Verknüpfung - am einfachsten aus AdSense heraus - aktiviert werden. Dazu dient der Link "Integrieren Sie Ihr AdSense-Konto in Google Analytics" im AdSense Dasboard:

AdSense Link zu Analytics

Der Link führt (normalerweise; nach erstmaliger Definition später dann direkt zu den Analytics-Daten) zu einer Seite, auf der gewählt werden kann, ob man sich bereits mit einem bestehenden Konto verbinden will oder ein neues Analytics-Konto eröffnet werden soll. Hat man mit dem "AdSense-Google-Konto" bereits Zugriff auf bestehende AdSense-Profile des selben oder eines anderen Kontos (durch den oben genannten Adminzugriff; zur Konfiguration siehe weiter unten), kann hier nun gewählt werden, welches Profil verwendet werden soll.

Entscheidet man sich für mehrere Profile, die mehr als eine Website betreffen, muss auf den zusätzlichen Domains ggf. ein zusätzliches Script implementiert bzw. vorhandene Scripte angepasst werden, damit die Brücke zwischen dem Profil und den AdSense-Daten funktioniert. Eine so definierte Verbindung kann übrigens nachträglich in den Profileinstellungen in Analytics wieder gelöst werden - und auch der Scriptcode ist hier (in den Profileinstellungen) nachträglich noch einmal abrufbar.

Wenn die Liste leer ist: Zugriff auf andere Analytics-Konten

Was aber tun, wenn keine Liste von Profilen eingeblendet wird oder zwar eine Liste vorhanden ist, diese aber keine Einträge zeigt? In diesem Fall ist es erforderlich, das AdSense-Konto im Nutzermanager des gewünschten Analytics-Kontos einzubinden. Nach der Anmeldung in Analytics kann der Nutzermanager über den Link am Ende der Profilliste geöffnet werden:

Nutzermanager in Analytics

Hier dann oben rechts vom Titel "Bestehender Zugriff" auf "Nutzer hinzufügen" klicken und anschließend die Anmelde-Mailadresse des AdSense-Kontos neu eintragen. Als Zugriffstyp "Kontoadministrator" wählen.

AdSense-Konto Zugriff gewähren

Nach Abschluss mit "Änderungen speichern" kann wieder zurück in das AdSense-Konto gewechselt und der obige Vorgang wiederholt werden - nun besteht Zugriff auf die Profile und per Mausklick kann das gewünschte Profil (oder mehrere; s. o.) angegeben werden, welches Daten aus AdSense enpfangen soll.

Auswerten in Analytics

Der Link im AdSense-Dashboard, mit dem eingangs die Verbindung hergestellt wurde, heißt nun "Navigieren Sie zu Ihrem Google Analytics-Konto" und führt künftig direkt zum Dashboard der Analytics-Berichte des verbundenen Kontos - leider nicht zwingend im richtigen Profil... dieses also ggf. noch aus der Auswahlliste oben auswählen. Danach findet man die AdSense-Auswertungen im Bereich "Content":

AdSense-Auswertungen in Analytics

Neben der Tatsache, dass man nun z. B. im Top-Webseiten - Bericht analyticslike weitergehend segmentieren, filtern und pivotieren kann (:-)), gibt es nun auch Ansichten, die sonst nicht so einfach herzustellen sind, wie z. B. eine Liste über besonders erfolgreiche Anzeigenziele über alle Kanäle etc...

Zum Abschluss: Die ganze Mühe lohnt sich - was bei Analytics eigentlich immer gilt - freilich nur dann, wenn man Analytics auch wirklich aktiv nutzt, um regelmäßig Fragen an die eigene Website zu stellen und die Antworten zu verwenden, um eine Optimierung voranzutreiben - sei es für AdSense-Umsätze, Shop-Bestellungen, Anfragen, Downloads, allgemeine Benutzerfreundlichkeit, Suchmaschinen oder alles zusammen...

# 
Wednesday, 04 February 2009

phpBB: Wenn Google Analytics keine Daten bekommt

Das kommt davon, wenn man nicht gleich nachsieht: Vor Wochen habe ich in ein Projekt, welches mit phpBB betrieben wird, über die Templates einen Tracking-Code für Google Analytics implementiert und wollte nun erstmals nachsehen, wie es denn mit den Besucherzahlen dort aussieht und ob bestimmte Bereiche vielleicht mehr Aufmerksamkeit benötigen. Mein erstaunen war groß, als Google Analytics mir meldete, dass der Code korrekt implementiert sei, aber dennoch keine Daten gemessen wurden. "Warte auf Daten"... und zwar seit Wochen. Die Implementierung des Trackingcodes für Google Analytics in phpBB funktionierte also offenbar nicht.

Na klar! Der Code ist irgendwie nicht richtig implementiert. Aber warum? Die Lösung: phpBB scheint "Unnützes" bei der Ausgabe zu filtern und der Trackingcode von Google Analytics hat unter diesem Filter zu leiden. Ich muss gestehen, dass ich kein ausgewiesener phpBB-Fachmann bin und nur so eben gut genug zurecht komme, um ein Forum damit aufzusetzen und einige Anpassungen am Design zu erstellen. Daher habe ich auch keine Ahnung, ob dieses Verhalten per Option steuerbar ist oder nicht. Und so musste in meinem Fall eine eher triviale Lösung her: Ich habe ein Leerzeichen an passender Stelle eingefügt, danach wurden die Daten auch korrekt an Google Analytics übertragen. Falls sich jemand mit einem ähnlichen Problem rumschlagen sollte und dank Suchmaschine auf diesen Beitrag gestoßen ist - hier die Anleitung, damit das Tracking über Google Analytics korrekt funktioniert. 

Im Template lässt sich der Code - egal ob neuer oder alter Trackingcode -, welcher gern am Ende einer Seite wohnt und so möglichst wenig den Seitenaufbau verzögert, simpel - und vor allem korrekt und vollständig - z. B. in overall_footer implementieren. Hierin ist in der letzten Zeile des Trackingscripts ein leerer Anweisungsblock zur Fehlerbehandlung vorhanden. 

Code in phpBB einbauen

Wird diese Änderung gespeichert, liefert phpBB eine "optimierte Fassung" des Codes aus, in dem der leere Anweisungsblock leider fehlt. Dies sorgt dafür, dass das ganze Script nicht korrekt arbeitet und keine Daten bei Google Analytics ankommen. Im Quelltext einer produzierten fertigen Seite sieht das dann so aus:

Defekter Code im Quelltext

Um das Problem zu beheben, kann zwischen die beiden Klammern des leeren Anweisungsblocks im Script beim Einbau in das Template einfach ein Leerzeichen eingefügt werden. Dies reicht offensichtlich, um den Block nicht als "leer und verzichtbar" zu erkennen. Eine Seite beinhaltet nach dieser Anpassung dann auch den vollständigen Code.

Funktionierender Code

Analytics ist damit zufrieden und zeigt künftig Daten an. Die Lösung ist zwar vielleicht nicht elegant, funktioniert aber. Wer weiß, warum das Script ohne diese Anpassung "kaputtoptimiert" wird und wie man dies durch eine entsprechende Einstellung oder Option im System verhindern kann, dem wäre ich für einen entsprechenden Hinweis per Kommentar höchst dankbar.

#