Markus Baersch

Software · Beratung · Lösungen

Suche im Blog

Sign In

Tuesday, August 23, 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, June 14, 2016

Error 522 - Timeout bei Cloudflare

Seit gestern war meine Website einige Stunden bis gerade eben offline. Untypisch. Das ist zwar immer ärgerlich - aber besonders dann, wenn man in einem Shared Hosting Paket unterwegs ist und daher eigentlich kaum etwas tun kann, um das Problem selbst zu beseitigen.

Kontakt bei meinem Lieblingshoster 2 Minus 2 ergab dann, dass auf deren Seite alles OK ist. Das war auch zu vermuten, weil andere Sites, die im gleichen Paket, aber nicht über Cloudflare laufen, keine Probleme gezeigt haben. Nach einigem Ping-Pong zwischen Hoster, Cloudflare und mir per Mail ergab sich dann eher nebenbei die Lösung: Meine IP-Adresse hatte sich von gestern auf heute geändert. Neuer Server, Umverteilung bei 1&1, was auch immer... man erfährt es eben leider nicht und es ist auch auf Nachfrage dort nicht nachvollziehbar, ob ein Umzug stattgefunden hat oder nicht. Klingt unlogisch? Ist es auch. Egal.

Update der DNS-Einstellungen bei Cloudflare erforderlich

Wer ähnliche Probleme hat, loggt sich daher einfach bei 1&1 ein, sucht in der Domainverwaltung die Adresse des Servers, auf dem man sich den Platz mit zahlreichen anderen Kunden (sxxx.online.de) teilt und schaut sich dessen IP an, z. B. per "ping s87654321.online.de" in der Kommandozeile. Passt diese IP nicht zu dem, was in Cloudflare eingetragen ist, muss die IP dort nur noch angepasst werden und schon ist die Site unmittelbar wieder erreichbar.

IP bei Cloudflare aktualisieren

Warum ich das verblogge? Weil man mir beim 1&1-Support mitgeteilt hat, dass seit gestern vermehrt solche Probleme gemeldet werden und diese alle Sites betreffen, die mit Cloudflare arbeiten. Daher gehe ich davon aus, dass dies häufiger vorkommt, ohne dass man bei 1&1 diese Information als mögliche typische Lösung anzubieten hat. Folgerichtig darf man erwarten, dass es hin und wieder periodisch Betroffene mit dem gleichen Problem geben wird. Hilft es nur einem, die bei mir heute damit verplemperte Zeit zu sparen, hat sich das schon gelohnt :)

# 
Tuesday, December 22, 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, November 23, 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, October 09, 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.


# 
Tuesday, September 15, 2015

Content ist... manchmal wirklich zu bedauern

Schon am Titel wird man es merken können: Dieser Beitrag verfolgt keinerlei Rankingziele. Er will nur meckern. Es gibt allerdings im folgenden Extremfall auch reichlich Anlass dazu, denn er zeigt, wie krank manche Websites sind. Nicht, dass es ein besonders trafficstarkes Beispiel wäre... aber es ist dafür sagenhaft miserabel.

Der Anfang allen Übels

Alles fing mit einer “ganz normalen” Websuche an. Ich habe die folgende Seite im Zuge einer Recherche in einem sehr engen und vergleichsweise "unspannenden" Keywordbereich gefunden, so dass zu Googles Entschuldigung gesagt sei, dass es ganz einfach auch nur wenig passende Inhalte gibt. Außerdem war der Inhalt selbst gar nicht so übel. Gelandet bin ich jedenfalls bei forums.codescript.in und da auf einer Seite mit dem schönen Namen how-to-fetch-top-pages-and-top-query-data-from-google-webmaster-tool-by-usi-2543.html. Warum ich nicht einfach einen Link setze? Weil ich das nicht mal mit nofollow entwertet auf einer verschlüsselten Seite machen würde, die hinter einem Login auf einem Server ohne Internetverbindung vor allen Suchmaschinen dieser Welt versteckt wäre. Deshalb!

Dabei fing alles so "harmlos" an: Schon nach 3 Minuten war die Seite augenscheinlich erstmals mit dem Laden fertig. Für die, die es wissen wollen: DOMContentLoaded nach 31,15 Sekunden. Also nichts wirklich Ungewöhnliches. Leider.

Nach 10 Minuten

Auch nicht ungewöhnlich ist es heute (ebenso leider), dass Hardcore-Monetarisierer einfach nicht mit dem Nachladen von irgendwelchem Zeugs aufhören können. Wenn die Tracker erst mal durch sind, dann halt ständig neue Werbemittel. Und zwar - natürlich - absolute Qualitätsware wie sowas hier:

Werbemittel aus der Hölle

Rein, Impression, raus, Dankeschön. In Zahlen bedeutet das, dass die Seite dann nach 10 Minuten schon über 3000 Requests abgesetzt hatte. Siehe Timeline und Statusleiste:

Ressourcenverschwendung im Browser sichtbar gemacht

Das Spiel geht natürlich immer weiter. Nach weniger als 15 Minuten sind über 4700 Requests abgesetzt und ca. 8MB an Schrott nachgeladen. Inzwischen hatten mehr als 200 Domains ihre Cookies bei mir abgeladen.

Nach 20 Minuten

... sind es schon mehr als 6000 Requests, über 10MB. Mein treuer Begleiter Ghostery zeigt mir satte 115 Tracker an, die er kennt. Es sind auch inzwischen schon 6 zum Scheitern verurteilte (Antwortcode 404 / 500) und knapp 300 failed / canceled Requests für "Werbemittel" abgesetzt worden.

Fehlerhafte Anfragen

Die Entropie wird also langsam messbar :|

Nach 30 Minuten

Hurra. Es sind nun mehr als 8700 Requests angesetzt worden und weiter wechseln die Werbemittel. Hier eine Abbildung mit gerade mal wieder angesprungener Liste von Ghostery, die alle gefundenen Tracker auflistet.

Ghostery ist voll. Aufhören bitte!

Also gut. Nach 14MB, 124 Trackern in Ghostery und grob 500 Cookies von fast ebenso zahlreichen Domains verliere ich endgültig die Lust und ziehe den Stecker. Wer mehr wissen will, kann das gern selbst probieren und länger laufen lassen.

Extremfall <> Einzelfall

Das Ergebnis liegt auf der Hand: Da stimmt was nicht. Auch wenn diese Site ein Sonderfall ist (den vermutlich auch vergleichsweise wenige zu sehen bekommen), so ist das nicht so weit von der Realität reichweitenstarker Portale aus allen möglichen Bereichen entfernt. Und natürlich überreifer Affiliateprojekte, die aus Versehen noch ranken und daher so weit ausgequetscht werden, wie es nur geht. Ich kann das zwar nachvollziehen... aber besser wird das Web davon nicht.

Da helfen dann auch keine aufgesetzten Datenschutzhinweise oder Links zu 700 verschiedenen Opt-Out-Möglichkeiten mehr. Fälle wie dieser sind für jeden Besucher, der sich dorthin verirrt, ein Loch ohne Boden, wenn es um unerwünschtes Tracking und seine kranken Verwandten geht. In solchen Momenten verstehe ich, warum Script- und Adblocker so beliebt sind. Schade um jeden auch nur ansatzweise hilfreichen Inhalt, der sich in eine so unpassende Form quetschen lassen muss!

# 
Saturday, September 12, 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, September 11, 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.

# 
Thursday, September 10, 2015

Google Search Console wird wieder in Webmaster Tools umbenannt

Jedenfalls bei mir. Ich kann mich mit dem neuen Namen nicht anfreunden. Weder in der Kommunikation mit anderen (auch wenn ich es muss), noch in Form des Anblicks bei der Verwendung der Webmaster Tools. Der Webmaster Tools. Webmaster Tools, nicht Search Console. Ich mag den Namen nicht. Hatte ich das schon erwähnt?

Name doof? Einfach umbenennen!

Ein Plugin war mir dann doch ein wenig zu übertrieben, aber da ich ohnehin gern und viel mit Greasemonkey bzw. Tampermonkey "nachbessere", habe ich zahllose schweißtreibende Stunden in eine umfangreiche Lösung investiert ;)

Wer meine Abneigung gegen den neuen Namen teilt, kann sich also mit den o. g. Erweiterungen für den Browser seiner Wahl Abhilfe verschaffen. Sowohl in der Anwendung als auch in der Hilfe. Einfach hier klicken und das Script in Greasemonkey oder Tampermonkey installieren oder herunterladen. Schon sieht das wieder so aus:

Search Console als Webmaster Tools rerebranded

Wem es noch fehlt: Hier sind Greasemonkey für Firefox oder Tampermonkey für Chrome zu bekommen.

Happy Re-Rebranding & Webmaster-Tooling ;)


# 
Friday, May 29, 2015

OMTalk 2015 Thyborøn, Dänemark

Gähn, schon wieder ein Recap? Ja, aber aus Gründen. Weil es diesmal keine Veranstaltung mit lokalem Charakter war, sondern ein Onlinemarketing Branchentreffen mit weitem Einzugsgebiet und Teilnehmern aus allen Ecken Deutschlands... und darüber hinaus.

(K)eine Konferenz

Weil ich normalerweise nur Stammtische und Konferenzen in der Nähe besuche, war der OMTalk für mich vor allem eine Möglichkeit, auch Onliner kennenzulernen, die nicht aus dem direkten Umfeld kommen; in einem kleinen und überschaubaren Kreis. Das war auch der Grund, warum ich mich sehr kurzfristig und ohne große Gegenwehr habe überreden lassen, ein freigewordenes Ticket zu übernehmen und ohne lange Nachdenkzeit mitzufahren.

There And Back Again

Nachdem ich mich über vergangene Veranstaltungen anhand von Recaps informiert hatte, war meine Erwartung vor allem von der vielzitierten "Klassenfahrt der Onlinebranche" geprägt. Und so ging es Donnertags um 23:00 Uhr ab Köln in einer Fahrgemeinschaft für mich los mit der Klassenfahrt. Denn wenn man um die 9 Stunden gemeinsam im Auto verbringt, bleibt auch mit kurzen Schlafpausen und Fahrerwechseln noch genug Zeit, schon auf der Anreise mit dem Netzwerken zu beginnen.

Geplant war eine gemütliche Fahrt mit Frühstück im Legoland. Dumm nur, wenn man so gut durchkommt, dass der geplante Stop in Billund dermaßen früh stattfindet, dass man außer dem Haupteingang nicht viele Motive vor die Linse bekommt... das war ebenso anders geplant als die viel zu frühe Ankunft in Thyborøn.

Legoland

Um es gleich vorweg zu nehmen: Auch die Rückfahrt verlief ähnlich glatt, da wir aus Termingründen schon am Donnerstag (einen Tag vor dem eigentlichen Abreisetag, der mit dem einsetzenden Pfingstreiseverkehr nicht ideal gewählt war) zurückgefahren sind. Andere Teilnehmer hatten da deutlich mehr Gelegenheit, sich die Umgebung von Autobahnen mal in aller Ruhe anzusehen...

Thyborøn, Provinz Mordor?

Der erste Eindruck, dass wir unmittelbar nach einer Zombie-Apokalypse eingetroffen sein müssen, weil man im ganzen Ort praktisch niemanden auf der Straße antreffen konnte, wollte auch die ganze Woche über nicht wirklich verschwinden. Gehsteige sind hier nur schmückendes Beiwerk, denn man kann ungehindert stundenlang auch auf der Straße herumlaufen. Hier ein künstlich auf Minutenlänge gebrachter Beweis:

Wie sich aber später noch rausstellen sollte, ist das vermutlich aber gar nicht die beste Idee, denn von schwermetallbelastetem Wasser bis zur vogeltötenden Luft und versiegeltem Giftstrand gibt es nichts, was man hier nicht dank der ansässigen Chemiefabrik nicht schon erlebt hätte. Viel lebensbedrohlicher sollte sich aber an zwei Tagen die fischverarbeitende Fabrik erweisen, die bei ungünstigem Windstand für Luftverhältnisse um unser Haus sorgte, dass es bei StarTrek für eine Y-Klassifizierung reichen würde.

Luftkurort Thyboron

Ein Haus sie zu binden

Unterbringung, Konferenzräume, Whirlpool(s), Billard, Tischtennis und ein mitgebrachter Koch - alles unter einem Dach - machten theoretisch jeden Schritt vor die Tür überflüssig. Kurze Einkäufe oder Strandvisiten in der Mittagspause waren so für viele alles, was man in der Woche von Dänemark zu sehen bekommen hat. Und das ist auch gut so, denn auf diese Weise konnte man sich ganz dem Vortragsprogramm widmen, dass von den Teilnehmern selbst gestaltet wurde - und dem Netzwerken rund um die Vorträge, SiteClinics und vor allem bei der gemeinsamen abendlichen Restfreizeitgestaltung mit wahlfreier Alkoholunterstützung.

Seminarpause OMTalk 2015

Die Gefährten

Teilnehmer kamen nicht nur aus allen möglichen Regionen, sondern auch aus den verschiedenen Disziplinen des Onlinemarketings. Auf diese Weise war sicher für jeden etwas dabei, das neue Impulse für bestehendes Geschäft oder neue Ideen beigesteuert hat. Ich hatte den Eindruck, dass es auch (oder gerade) zwischen den Teilnehmern, die sich auf dem OMTalk zum ersten Mal begegnet sind, keinerlei Vorbehalte oder Hürden gab. Ganz im Gegenteil wurden im Nachgang von Vorträgen, die konkrete Projekte oder zumindest bestimmte Aspekte davon betroffen haben, oft schon sehr schnell ein Ideenhaufen zusammengeschmissen und erste Testballons aufgeblasen, Anpassungen erprobt oder Anregungen umgesetzt.

Über die ganze Woche lag so im Seminarraum stetig eine Mischung aus Veränderung, Neugier und (freilich nicht immer gleich starker) Aufmerksamkeit in der Luft, die mir recht gut gefallen hat und sich wohltuend von dem üblichen reinen "Konsumieren" von Vorträgen auf "echten Konferenzen" absetzen konnte.

Gruppenbildung ist zwar bei über 30 Personen auch in einer solchen Umgebung nicht zu vermeiden, aber dennoch konnte jeder, der es wollte, eine angemessene Zeit darauf verwenden, die anderen Teilnehmer und deren Hintergrund besser kennenzulernen... und das nicht nur aus beruflicher Sicht, sondern eben tatsächlich eher wie bei einer Klassenfahrt, bei der auch für Themen wie "Aufwachsen Ost vs. West", die eigene Familie oder schräge Hobbies Platz ist. Was nicht bedeutet, dass nicht auch rege über das "Not-An-Update"/Nischenwatschen/NearDC/ThinContent/Quality/Core-Update spekuliert, in Analytics-Daten gestöbert oder an PageSpeed und Wordpress-Plugins rumgeschraubt wurde ;)

Earendils Licht (AKA Fazit)

Ganz schmerzlos formuliert: Ich bin froh, überredet worden zu sein. Ich habe viel Freude daran, nach und nach auch die Gedanken der anderen Teilnehmer in Recaps (wie z. B. hier und hier) und in Kommentaren in der Facebook-Gruppe zu lesen und mich mit Leuten auszutauschen, die ich vor zwei Wochen noch nicht kannte. Und ich weiß es nun auch wieder zu schätzen, beim Einkaufen die Wahl zwischen verschiedenen Geschäften zu haben und unsere vergleichsweise saubere hiesige Luft des Gewerbegebiets zu atmen, in dem ich wohne ;)

# 
Wednesday, April 01, 2015

Metatag rettet faule Webmaster vor Rankingverlust

Wenn Google am 21.4. ernst macht und alle Websites, die nicht als mobilfreundlich eingestuft werden, bei mobilen Suchen benachteiligt (mit mehr Auswirkungen "als bei Panda und Penguin zusammen"), werden eine ganze Menge Webmaster noch nicht fertig sein mit der Umstellung auf Responsive Design oder mit anderen Mitteln.

Da dies aber vor allem auch ein paar gaaanz große Fische betrifft, hat Google genauso erstaunlich schnell einen Rettungsanker für überlastete IT-Abteilungen nachgelegt, wie zuvor mit der Nennung eines konkreten Termins überrascht. Und so geht es: Wer nicht rechtzeitig fertig wird, aber bereits angefangen hat, kann Google dies per Metatag mitteilen und so Zeit zur Fertigstellung "erbitten".

Metatag mobileready to the rescue!

Dazu wird in den Quelltext der betroffenen Seite (i. d. R. also vermutlich einfach alle) ein Metatag in den head-Bereich eingebracht, mit dem Google mitgeteilt wird, dass die Umstellung bereits in Arbeit ist.

<meta name="mobileready" content="soon">

Der hier abgebildete Wert "soon" bedeutet für Google, dass man davon ausgeht, spätestens innerhalb von 14 Tagen mit der Umstellung fertig zu sein. Wenn Google im Mobile Friendly Test auf diese Anweisung stößt, wird auch eine entsprechende Meldung ausgegeben, die einen erneuten Crawl der Seite in zwei Wochen in Aussicht stellt.

Mobile Ready: Soon

Als weitere Option ist die Angabe "pending", mit der angekündigt wird, dass die Umsetzung zwar erfolgt, aber noch längere Zeit in Anspruch nimmt. Die Crawlpause fällt in diesem Fall doppelt so groß aus, so dass man vier volle Wochen Zeit bekommt, um die Mobil-Hausaufgaben nachzureichen.

<meta name="mobileready" content="pending">

Große Website? Kein Problem: Auch in den Webmaster Tools wird es in Kürze (lt. Blogpost spätestens bis zum 19.4.) eine Funktion geben, um die "Entdeckung" per Metatag zu forcieren, ohne dass man explizit für jede einzelne Seite den obigen Test durchführen muss. Man merkt der Lösung aber nicht nur daran an, dass sie mit der heißen Nadel gestrickt wurde.

Vorsicht bei tagesaktuellen Inhalten!

Da die obige Angabe z. B. dazu führt, dass die betreffende Seite tatsächlich eine Crawlpause erhält und Google erst zum "vereinbarten" Termin zurückkehrt, um sich von der Mobilfreundlichkeit der Seite zu überzeugen, entgehen der Suchmaschine in der Zwischenzeit alle Updates am Inhalt der Seite. Wer also seine Blogstartseite damit ausstattet, kann sich auch eine Publikationspause gönnen, wenn der Hauptkanal für Traffic die Suche ist. Ein Workaround für dieses Problem ist nicht bekannt... aber solche Lücken entstehen eben, wenn ein plötzlich notwendig gewordener Notbehelf aus nichts als einer Kugelschreibermine und einem Einmachgummi gebastelt werden muss.

Sonderfunktion für gesperrte Ressourcen

Auch ein anderes Problem kann mit der neuen Wunderwaffe behandelt werden: Google beachtet Verbote in der robots.txt. Hier wurde und wird gern aber eine ganze Menge an internen Ressourcen wie CSS- und JavaScript-Dateien für Google & Co. gesperrt. Außerdem sind unauffällige Ordner wie website.de/css oder website.de/js seit jeher ja ein beliebter Ablageort für Firmengeheimnisse, unverschlüsselte Nutzerdaten und Online Banking Passwörter der Geschäftsleitung. Wo sonst könnte man auch sensible Daten auf einem online zugänglichen Ort ablegen, ohne dass sich Suchmaschinen und andere Bots darüber hermachen? Naja, vielleicht erfindet ja jetzt jemand Dropbox oder so. Sperren per robots.txt ist nun jedenfalls definitv out. Was früher heimlich der Sicherheit interner Daten sowie vorgeblich der Schonung der Ressourcen von Crawler und dem eigenen Server gedacht war, geht nun also nach hinten los, denn wenn Google keinen Blick auf das Design werfen kann, dann kann auch nicht bestimmt werden, ob eine Website mobilfreundlich ist oder nicht.

Für diesen Fall gibt es eine dritte Möglichkeit, mobileready mit einem Wert zu bestücken:

<meta name="mobileready" content="yes">

Versieht man die oben dargestellte Seite mit gesperrtem Design mit dieser Angabe, beteuert Google das Vertrauen in die Angabe des Webmasters:

Mobile Ready: Yes

Hierbei wird auch keine Pause vereinbart o. Ä - vielmehr scheint Google tatsächlich den Angaben des Webmasters zu vertrauen. Wie lange das aber gut gehen wird - und ob dies wirklich eine Rettung für Rankings bei mobil ausgeführten Suchanfragen bedeutet -, muss abgewartet werden, bis der nach dem 21.4. geänderte Zustand eine zuverlässige Bewertung erlaubt.

Einfach einbauen?

Daher sollten Webmaster mobileready nicht einfach implementieren, ohne zuvor auch alle denkbaren Konsequenzen bedacht zu haben. Neben der Crawlpause gibt man Google mit dem Einbau auch ein Versprechen, dass es einzuhalten gilt. Daher lautet die Empfehlung: Lieber "pending" statt "soon", wenn es denn schon eingebaut werden muss. So ist dann wenigstens sichergestellt, dass unerwartete Probleme bei der Umsetzung noch einen etwas größeren Puffer bekommen, als bei einer Zwei-Wochen-Frist.

Wie lange hält so ein Pflaster denn?

Keine Ahnung. Google hat nichts dazu geschrieben, was passiert, wenn man die Angaben einfach im head drin läßt und das Versprechen der Umsetzung nicht einlöst. Sicher wird es aber spätestens nach mehrfachem Verstreichen der Frist ohne erkennbare Verbesserungen der Mobiltauglichkeit dann auch an die Rankings gehen. Auch unklar bleibt, wie es nach dem ersten verpassten Termin mit der Crawlfrequenz aussieht... oder was passiert, wenn man eigentlich schon mobilfreundlich geworden ist und nur vergisst, das Ding wieder auszubauen - Also Vorsicht ;)



# 
Sunday, March 29, 2015

Mobile Search steigt auf in die erste Liga

Am 21. April ist #MobileDay. Wer bis dahin nicht (endlich) seine Hausaufgaben gemacht und seine Website auf Mobilfreundlichkeit abgeklopft hat, wird bei Suchanfragen, die auf Mobilgeräten stattfinden (Wachstum: schnell und unaufhaltsam), nicht mehr gefunden, weil die "mobilen Rankings" deutlich abfallen werden.

Eine Überraschung? Nein.

Nach all dem freundlichen "Du, mobile ist echt wichtig, Du - mach da doch mal gelegentlich was, ja?", das seit 2010 immer wiederholt, aber meistenteils unbeachtet blieb, hat uns Google zuerst in seit Mitte 2014 rasant steigender Schlagzahl massenweise Infos und Werkzeuge an die Hand gegeben, dann per Webmaster Tools tonnenweise Warnungen per Mail versendet und schlussendlich mit dem konkreten Termin 21.4.2015 die Pistole auf die Brust gesetzt. Wer jetzt nicht aufwacht und die bestehenden Probleme aller Besucher mit Smartphones weiterhin missachtet, wird dort konsequenterweise bald auch nicht mehr angezeigt; darüber habe ich bereits an anderer Stelle geschrieben.

Der Mai ist gekommen - die Rankings schlagen aus?

Spätestens Anfang Mai wird man mit dem Ausrollen nach eigenen Aussagen bei Google fertig sein. Mobile Rankingverluste drohen. Das muss kein Problem sein... jedenfalls nicht sofort: Wer jetzt noch keinen nennenswerten Anteil an organischen Besuchern per Smartphone verzeichnet, mag sich auch noch Zeit lassen dürfen. Alle anderen müssen aber handeln, wenn der Anteil nicht rapide sinken soll.

Vorher noch fertig werden? Möglich...

Aus der Erfahrung von inzwischen über 25 (teilweise zugegebenermaßen auch nur "notdürftig") in den letzten Monaten auf Responsive Design umgestellter Websites, die zumindest erst einmal den Mobilfreundlichkeitstest bei Google mit "grün" bestehen, kann ich behaupten, dass es für viele, aber sicher nicht alle Websites i. d. R. eine praktikable, wenngleich sicher nicht perfekte Lösung gibt, deren Vorbereitungs- und Umsetzungsaufwand in Stunden und nicht in Tagen berechnet werden kann. Jedenfalls bis uns auch Mobile Page Speed und der Rest einholt und der Erhalt der Rankings mehr erfordert als nur Änderungen am Design oder ein paar Templates.

Ja oder Nein: Google Mobile Friendly Test

Wer nicht 100% aller Seiten umstellen kann, hat außerdem die Option, sich den wichtigsten (Traffic bringenden) Inhalten zu widmen - das sind oft nur die Startseite und eine Handvoll weiterer Seiten, die i. d. R. auch alle mit dem gleichen Template erstellt und dem gleichen Design versehen werden. Denn das Thema „Mobilfreundlichkeit“ ist bei Google (aktuell) nicht nur an eine überschaubare Anzahl von Anforderungen geknüpft, sondern wird auch seitenweise beachtet, nicht „domainweit“.

Google hat bzgl. einer bevorzugten Methode selbst klargestellt, dass Responsive Design keine Vorteile ggü. anderen Lösungen haben wird. So ist also selbst eine separate m.meinedomain.de mit vollkommen unabhängigen Inhalten für Mobilgeräte ein ebenso probater Notbehelf wie die keinerlei Anpassungen am eigenen System (abgesehen von ein paar DNS-Einstellungen) erfordernde dynamische Generierung mobiler Fassungen durch das System eines Dienstleisters, von denen es inzwischen einige gibt – als Service oder „selbstgehostet“.

... aber mitunter nicht sehr wahrscheinlich

Weil der Termin erst Ende Februar bekannt geworden ist, kann gerade die Umstellung größerer Websites - oder kleinerer, dafür komplexer Webauftritte - kaum rechtzeitig fertig werden, wenn man erst im März oder später startet. Zu vollgestopft sind die IT-Roadmaps des Mittelstands. Aus beharrlicher Ignoranz plötzlich agile und effiziente Aktivität an den Tag zu legen oder einen Plan B wie die "Mobilmachung" der wichtigsten Seiten zu schmieden, beschließen und auch noch umzusetzen, bis der 21. April auf dem Kalender steht, ist selten noch drin.

Unterschiede gibt es schon heute

Es bleibt spannend zu beobachten, wie sich die Unterschiede zwischen Desktop- und mobilen Rankings weiter verändern werden... und bei wem die Ausschläge nach unten - oder durch Verdrängung des unvorbereiteten Wettbewerbs ja vielleicht auch nach oben? - besonders groß ausfallen. Ab dem 22. April wird es von den SEO-Toolanbietern dazu vermutlich reichlich Daten geben. Wer nicht bis dahin warten will, kann sich beim SISTRIX Smartphone-Sichtbarkeitsindex informieren, inwiefern sich schon auf Basis der Daten vom Februar Unterschiede feststellen lassen.

STSTRIX Smartphone Sichtbarkeit

Da hier "nur noch" die Aktualisierung der Datenbasis erforderlich ist, sollte sich auch ein zweiter und dritter Besuch lohnen, wenn erst einmal der #MobileDay gekommen ist ;)

Nächster Halt: Mobile PageSpeed

Damit ist die Reise natürlich nicht zu Ende. Ein so digitaler Faktor wie "mobilfreundlich" oder "mobilmist", wie er derzeit nicht nur in Form des oben angesprochenen Tests implementiert ist, sondern in gleicher Form auch in den Webmaster Tools lebt - und vermutlich aktuell im angekündigten Algoupdate, das uns so nett nebst konkretem Termin in Aussicht gestellt wurde -, ist noch nicht das, was wir von Google gewohnt sind.

Die Tatsache, dass ein Klick zum Recheck einer in den Problemen genannten Seiten des Berichts zur "Benutzerfreundlichkeit auf Mobilgeräten" in den WMT früher nicht zu dieser "hopp oder top"-Evaluierung, sondern zu den mobilen PageSpeed Insights geführt hat, wo man weitaus strenger mit den Probanden verfährt, zeugt von einer gewissen Rücksicht seitens Google...

Streng: PageSpeed Insights

...aber zeigt auch in eine klare Richtung. Genau wie die in der Branche nicht unbemerkt gebliebenen Tests mit als "Slow" gekennzeichneten Seiten.

Der "Mobile Split" kommt

Es ist bereits angekündigt, dass Google in Zukunft die Unterschiede zwischen Desktop, Tablet und Smartphone ernster nehmen will. Man wird dazu einen eigenen, vom "Desktop-Index" getrennten Index für mobile Suchergebnisse betreiben... und mittelfristig bestimmt auch einen separaten Satz an Rankingfaktoren und deren Gewichtung, um sensibler mit den sehr unterschiedlich ausfallenden Nutzersignalen aus verschiedenen Gerätewelten umgehen zu können. Die gleiche Maßnahme wäre selbstredend auch für Tablets denkbar, für Wearables... oder was auch immer übermorgen das dominierende Gerät sein wird. Desktop und Laptop aber ganz sicher nicht. Insofern ist dieser Schritt nicht nur logisch, sondern auch (überlebens-) notwendig für Google. Und deren Wettbewerber. Genau wie die entsprechende Reaktion aller Websitebetreiber, die sich um organischen Traffic scheren.

Damit: Happy Mobilmaching ;)

# 
Monday, November 10, 2014

10+1 Argumente gegen eine (unvorbereitete) SSL-Umstellung

Gleich vorab: Ich bin kein Gegener von SSL. Überhaupt nicht. Aber es scheint mir, als würden derzeit zahlreiche Websites aus völlig falschen Gründen auf den SSL-Zug aufspringen... um sich dabei nicht selten derb selbst ins Knie zu schießen. Daher sollen hier nicht die zahlreichen Argumente für einen Umstieg auf https statt http aufgezählt werden, die ich gar nicht anzweifeln will, sondern ein paar m. E. wichtige Punkte zur Sprache kommen, die vor einer Umstellung bedacht, abgewägt und vor allem vorher geprüft werden sollten. Und wenn es nur ein paar böse Überraschungen vermeiden hilft ;)

Umstellung aus den falschen Gründen?

Der Grund für das stark angestiegene Interesse liegt oft in der Hoffnung auf bessere Rankings bei Google. Wie diese Hoffnung aufgekommen ist, soll hier nicht interessieren (und ist den meisten der wenigen Leser dieses Blogs ohnehin bestens bekannt), aber es gibt m. E. für 99,99% der Webmaster, die sich gerade aus SEO-Gründen mit SSL befassen, mindestens 100 andere Baustellen, an denen mit dem gleichen Aufwand viel mehr Effekt zu erzielen ist, wenn es um Rankings geht.

Nur weil das Thema gerade durch die SEO-Blogs geht und die großen Hoster ihre Kunden zusätzlich mit Dingen wie "Umstellung mit wenigen Klicks" - natürlich erst einmal auch noch kostenlos - locken, ist das noch lange kein Anlass zum Handeln, ohne sich zuvor über Gegenargumente bzw. potentielle Probleme Gedanken gemacht zu haben.

SSL Werbung bei 1und1
Beispiel 1&1: "Wenige Klicks". Jaja. Und dann geht der Spaß los...

Viele der Hindernisse sind technischer Natur. Das ist nicht für jeden Webmaster gleich abschreckend, bedeutet aber auf jeden Fall, dass diese gelöst werden müssen, wenn die Site nach einer Umstellung noch genau so funktionieren soll wie vorher. Hier sind ein paar Denkanstöße:

Die "Miesmacherliste" zur SSL-Umstellung

  1. Anpassung der Inhalte: Alle Verweise auf Bilder, Videos, Ressourcen in iFrames (bis hin zur eingebundenen Werbung etc.) müssen ggf. angepasst werden, wenn diese direkt auf eine http-Variante auf der eigenen Domain zugreifen. Oder eben auch auf einer anderen Domain... hoffentlich gibt es dort dann auch SSL. Ohne eine Anpassung drohen je nach Browser fehlende Bilder bzw. Ressourcen (was durchaus auch die Bedienbarkeit der Site beeinträchtigen kann!) oder zumindest unterschiedlich aufdringliche Warnhinweise beim Verschlüsselungssymbol bzw. sogar Warndialoge. Wer das in seinem Browser nach der Umstellung nicht sieht, mag sich sicher fühlen... ist es aber nicht! Beispiele gefällig?
    SSL Probleme
    Die nachträgliche Anpassung von Content ist also zwingend erforderlich, aber nicht immer einfach. Je nach Umfang mag sich der Aufwand in Grenzen halten oder ist vielleicht mit ein wenig "Suchen und Erstzen" erledigt. Komplexere / umfangreichere Websites und deren Content Management Systeme erfordern hier aber deutlich mehr als nur den einen Klick, den man beim Hoster zu erledigen hat! Wo Inhalte in einer Datenbank umgestellt werden müssen, braucht es nicht nur die erforderlichen Möglichkeiten zum Zugriff und entsprechendes Spezialwissen - es muss auch Backups und vernünftige Tests vor einer Umstellung im Livebetrieb geben. Hier steckt folgerichtig oft der größte Brocken an Arbeit. Wer diese erst beim Erwachen nach der Umstellung angeht, wird es mit Hektik kaum sorgfältig genug hinbekommen, auf Backups verzichten und sich ernsthafte Probleme einhandeln. Externe Kosten sind hier für viele Websitebetreiber nicht nur unvermeidbar, sondern im Vorfeld auch schlecht anzuschätzen.
  2. Ressourcen: Wie sieht es mit im CSS referenzierten Hintergrundbildern aus... oder @import-Anweisungen? Wenn CSS kein Problem ist, folgen spätestens bei internen - und vor allem externen - JavaScript-Dateien schnell ernsthafte Hürden für Webmaster, die nicht zufällig die entsprechenden Kenntnisse zur Analyse und Korrektur selbst mitbringen. Siehe oben: weitere Kosten drohen.
  3. Content Management System: Idealerweise geht alles einfach glatt. Das wird bei gängigen Systemen auch der Fall sein und höchstens ein paar Anpassungen in der Konfiguration erfordern, die sich sogar für "Laienadmins" ergoogeln lassen. Bei alten Systemen oder Exoten (ich betreibe mit meinem Blog selbst so ein Urvieh) sind Verweise im System inkl. "http://" statt nur "//" aber mitunter "sehr sehr hart" codiert. Kann man dann wirklich alles ändern (wieder: Die Kenntnisse und den Zugriff vorausgesetzt)? Was ist denn, wenn die Problemstellen nicht im Quelltext vorliegen, sondern in einer .NET oder ISAPI DLL oder noch gruseligeren Dingen auf dem Server vorliegen? Und überhaupt: Was ist bei einer Anpassung in Eigenregie, wenn es dann doch irgendwann Updates des Systems gibt?
  4. Templates: Je nach System kann die erforderliche Anpassung in den Themes bzw. Templates des CMS selbst HTML-feste Webmaster überfordern. PHP, Smarty oder gar proprietäre Lösungen mögen für "Nichtkenner" zu kryptisch für Selbsthife ausfallen. Schwupps, wieder Geld an den nächsten Profi ausgegeben, der das passende Spezialwissen mitbringt.
  5. Fremdcode / Erweiterungen: Weil fast alle Systeme mit AddOns, PlugIns, Modulen oder unter anderen abstrusen Bezeichnungen erweiterbar sind, ist das einen eigenen Punkt auf der Checkliste wert. Denn diese stammen oft aus fremder Feder und entziehen sich vielleicht sogar einer Analyse (und ggf. erforderlicher Korrektur). Auf jeden Fall erfordern solche Kandidaten einen Testlauf, der wieder mal Aufwand und / oder Kosten mit sich bringt.
  6. Rankings werden vermutlich nicht steigen: Alle vermuteten Rankingvorteile sind derzeit eher "hypothetisch" und wie oben beschrieben gibt es meistens Besseres zu tun. Selbst John Mu sagt, dass er sich den ganzen Kram selbst nicht antun würde... wenn das primäre Ziel nicht Sicherheit ist, sondern damit bessere Rankings erreicht werden sollen.
  7. Rankings können sogar leiden: Es sind sogar Rankingverluste statt einer Steigerung möglich - oder zumindest unnötige Probleme für Google & Co. Diese können durch Doubletten entstehen, die auf fehlende oder falsche Weiterleitungen auf die https-Variante zurückzuführen sind. Mit korrekten Weiterleitungen bleibt immer noch zu bedenken, dass eingehende Links i. d. R. nicht auf die https-Variante gehen. Man mag fragen: Wie viel geht ggf. durch die 301-Weiterleitungen auf https-Fassungen verloren und macht das zunichte, was mit dem angeblichen Rankingboost(chen) gewonnen wird? Auch steckt ein gewisses Risiko in vergessenen "Kleinigkeiten" wie Weiterleitungen auf nicht-SSL-Varianten in der eigenen .htaccess oder im System. Oder in auf einmal giftigen Canonicals mit http statt https. Und so weiter ;)
  8. Kosten des Zertifikats: Auch wenn in anderen Punkten schon reichlich Kosten angesprochen wurden, sind auch die Kosten einzurechnen, die das Zertifikat betreffen. Ein "ordentliches" (AKA eigenes und vertrauenswürdiges) Zertifikat kostet Geld. Was ist, wenn billige Wildcard-Zertifikate oder kostenlose Zertifikate von CloudFlare & Co. übermorgen einen Rankingnachteil statt eines Rankingboosts bedeuten? Vielleicht sind Billigzertifikate die Artikelverzeichnisse von morgen... wer weiß das schon?
  9. Nicht jede Site braucht SSL: Oft ist die Umstellung schlichtweg unnötig. Auf vielen Sites gibt es streng genommen außer dem Besucherverhalten, das ohnehin über zahlreiche Systeme aufgezeichnet wird (s.u.) und der IP nichts an potentiell schützenswerten Informationen, die bei der Benutzung der Site anfallen und auf dem Transportweg gefährdet sind. Selbst in Shops ist jenseits des Checkouts - heute noch - ein Verzicht auf SSL nicht unüblich. Außerdem werden Informationen wie Verhalten und IP durch SSL nicht wirklich "sicherer", solange diese durch eingebundene "Mithörer" wie SocialMedia-Plugins, Webanalysesysteme u. Ä. gespeichert und ggf. vom Systemanbieter oder auch Dritten aktiv genutzt werden.
  10. Falsche Sicherheit: Wer im einem Shop, Portal oder der Landingpage mit neugierigem Formular die Eingaben seiner Besucher und deren Übertragung zum eigenen Server schützen will, ist mit SSL gut beraten. Spätestens seit Firesheep ist das auch beim "informierten Verbraucher" angekommen. Außerdem mag sich der Hinweis auf verschlüsselte Übertragung sogar positiv auf die Abschlussrate auswirken (muss es aber nicht unbedingt, nur weil das in CaseStudies so steht!). Dass mit SSL aber die gespeicherten Daten noch lange nicht sicher sind, scheint nicht allen klar zu sein und so sind oft dahinter immer noch hochgradig unsichere Backendsysteme im Einsatz. So wird SSL zum Tropfen auf den heißen Stein und verhindert in keiner Weise automatisierte oder gar gezielte Versuche, an die sensiblen Daten zu gelangen. Wer seinen Shop wirklich sicher machen will, darf nicht beim SSL-Zertifikat aufhören, sondern muss sich um Verringerung der Angriffsfläche des Servers sowie Aktualität und Absicherung des Backends einschließlich der Datenbank kümmern.
  11. Performance: PageSpeed ist längst ein "akzeptierter" Rankingfaktor. Spätestens auf dem Umweg der Nutzersignale wird sich heute jeder SEO Gedanken um die Optimierung von Ladezeiten machen. Selbst wenn es für Suchmaschinen egal wäre: Besucher nehmen je nach Site selbst geringe Veränderungen wahr, was an veränderten Konversionsraten sogar in Experimenten nachweisbar ist. Durch SSL wird die Ladezeit aber messbar größer. Dazu gibt es hier einen kleinen "Videobeweis" ;)

SSL vs. Non-SSL im Ladezeitenvergleich

Ich habe mir den Spaß gegönnt und anhand meiner eigenen und sehr überschaubaren Website die Umstellung auf SSL durchgespielt. Da ich dies aber hauptsächlich deshalb angegangen bin, um Erfahrungen für größere Projekte zu sammeln und meine Website m. E. kein SSL braucht, habe ich diese Variante wieder deaktiviert. Nicht zuletzt wegen der unvermeidlichen Einbußen in den Ladezeiten.

Das "Test-Setup"

Beim Selbsversuch sind mir auch dank meines Blogs ein paar der o. a. eher exotischen Hindernisse in den Sinn (und in den Weg) gekommen. Zumindest für den Rest der Domain war die Umstellung aber mit vertretbarem Aufwand in ein paar Stunden erledigt. Das Zertifikat stammt von CloudFlare; ist also nicht auf meinem eigenen Server installiert. Das dürfte aber allein schon dank der Tatsache, dass CloudFlare als CDN genutzt wird und der Content so aus der gleichen Quelle wie das Zertifikat stammt, kaum störend ins Gewicht fallen.

Ergebnisse

Tests habe ich mit verschiedenen Services wie pingdom.com, pagespeed.de, gtmetrix.com und ein paar anderen gemacht und (bedingt durch die unterschiedlichen Standorte) eine relativ breite Streuung in den Ladezeiten gesehen. In allen Fällen aber waren die https-Fassungen der Seiten (ich habe nicht nur die Startseite getestet, sondern auch "ressourcenreichere" Inhalte) langsamer als die Versionen mit http. Mal mehr, mal weniger - aber stets langsamer.

Natürlich kann man diesen "Test" mit nur einem Kandidaten an einem einzelnen Tag und mit zufällig (bzw. vom jeweiligen Tool abhängigen) Rahmenbedinungen belächeln bzw. zumindest zurecht dessen Signifikanz anzweifeln. Totzdem finde ich das folgende Video der Ergebnisse von WebPageTest.org sehr anschaulich. Deshalb mag ich diese Präsentationsform auch viel lieber als alle Diagramme ;) Datanerds mögen sich nun aber Tabellen und Wasserfalldiagramme wünschen - z. B. hier finden sich welche.

Um zu zeigen, dass die reinen Zahlen egal sind, im Ergebnis aber mit SSL stets langsamer ist als ohne, habe ich den Test dort einfach noch einmal wiederholt und dabei beide Varianten zweimal eingetragen, so dass vier - recht unterschiedliche - Ladezeiten herauskommen. Es bleibt aber dabei, dass https immer langsamer ist als http.



Fazit? Empfehlung?

Eine Umstellung ist angesichts dieser Punkte für viele Betreiber möglicherweise wirtschaftlich betrachtet tatsächlich unsinnig. Oder zumindest unnötig. Der Eingriff geht jedenfalls im Regelfall sehr viel tiefer, als es zunächst klingen mag. Daher sollte man sich erstens aus gutem Grund (SEO als Hauptargument lasse ich nach aktuellem Stand nicht gelten) und zweitens entsprechend vorbereitet damit auseinandersetzen. Zu einer guten Vorbereitung ist umfängliches testen unabdingbar; vorher und nachher. Wer noch einen Plan B bei sich zeigenden Einbußen in Sichtbarkeit und Traffic zur Hand hat, sollte sich aber nicht aufhalten lassen. Viel Spaß ;)

# 
Friday, November 07, 2014

SEO Day 2014 Recap in 333 Worten

Am 30. Oktober war es wieder soweit: SEO Day 2014 im Rheinenergie-Stadion zu Köln. Und obwohl ich aus rein privaten Gründen ungern in dieses Stadion reise, habe ich mich nach einem Jahr „SEO-Day-Pause“ sehr kurzfristig entschieden, dieses Mal doch wieder dabei zu sein. Sicher war auch ich primär am ExpertDay interessiert, die Tickets dafür waren aber wie immer sehr schnell ausverkauft. Schade...

Aber auch der SEO-Day selbst muss sich mit deutlich über 600 Besuchern nicht verstecken. Wer primär zum beliebten „Netzwerken“ angereist war, konnte sich in zahlreichen Ecken des Stadions auch ohne Störung des Vortragsbetriebs schon vor der Party austauschen… und das wurde auch genutzt. Die Location ist ohnehin (ich gebe es ungern zu) prima für solche Events geeignet.

Achja, und es gab natürlich reichlich Vorträge, was auf einer Konferenz ja nicht ganz unüblich ist. Die Speaker es m. E. dieses Mal noch besser geschafft, die sehr knapp bemessenen Sessions von größtenteils nur 20 Minuten mit Inhalten zu füllen, bei denen sich potentiell jeder etwas mitnehmen konnte.

SEO Day 2014 - Christian Tembrink und Hendrik Unger

Wer nicht da war und sich selbst ein Bild machen will, findet bei Andreas Graap ausgesuchte Sessions als Aufzeichnung. Praktischerweise überschneidet sich diese Liste nur an zwei Stellen mit den Vorträgen, die ich selbst besucht habe ;)

Den Abschluss im Stadion machte wie immer das „Superpanel“, bei dem es neben den in den anderen Recaps reichlich besprochenen Preisverleihungen vor allem eine relativ chaotische Site-Klinik für vorher ausgewählte Websites gab. Dazu nur eins: Ein Sonderpreis für brutale Ehrlichkeit wurde leider nicht vergeben, sonst hätte Jens Fauldrath den locker in der Tasche gehabt ;)

Was die Party angeht, muss ich ebenso auf andere Recaps verweisen, denn als ich einmal im Auto saß, hat es mich dann doch (mehr oder minder ungeplant) nach Hause gezogen. Bin halt alt. Es dürfte aber wieder eine Menge an Alkohol und Insidertipps im Spiel gewesen sein – so wie immer. Strich drunter: Es war ein gut investierter Tag – Danke an Fabian Rossbacher, die Speaker und alle, die dazu ihren Teil beigetragen haben. Gerne wieder!

# 
Tuesday, September 30, 2014

Nachrichten aus Google Webmaster Tools für bereits entfernte Websites

Seit Monaten bekomme ich regelmäßig Nachrichten aus den Google Webmaster Tools für die Domain eines ehemaligen Kunden. Und ich werde sie einfach nicht los. Obschon ich die Domain schon aus meinen Webmaster Tools gelöscht habe. Dass ich damit nicht allein bin, mehrkt man schnell, wenn man sich mit passenden Suchbegriffen bei Google um Abhilfe bemüht: Alle paar Monate wird ein neuer Eintrag in einem der mal mehr und mal weniger passenden Google Produktforen gepostet.

Ein Tipp, den man häufig liest, ist "einfach die Mails ignorieren". Das würde ich auch gern, aber nun haben die Nachrichten eine neue Dimension erreicht. Nachdem es zunächst nur Meldungen gab, dass der Googlebot keinen Zugriff auf die Seite hat, dass sich die Fehler häufen und ähnlicher Kram, den man sich zuammenreimen kann, weil die Domain vom ehemaligen Betreiber zwischenzeitlich abgestoßen wurde, hatte ich kürzlich dieses Schätzchen im Posteingang:

Spammeldung

Da hat sich offenbar jemand die Domain geschnappt und betreibt nun reichlich Unsinn damit. In diesem speziellen Fall ist es ein Fake-Shop, mit dem der Betreiber sicher nichts Gutes im Schilde führt. Sonst hätte er sicher auch keine Phantasieadresse bei der Registrierung verwendet. Ich mag ja etwas überempfindlich sein, aber so eine Domain möchte ich einfach nicht in den Webmaster Tools haben. Oder gar für den Eigentümer gehalten werden... Also muss diese Domain irgendwie in den Webmaster Tools nachhaltig zum Schweigen gebracht werden können, oder?

So geht es... eigentlich

Während sich für die meisten Geplagten eine Lösung findet, kann ich leider nichts tun und werde wohl weiterhin ein ungewolltes Auge auf die Domain werfen. Der Grund: Wer vollen Zugriff auf die Domain hat, kann sich erst "deverifizieren" und erst dann die Domain löschen.

Das ist eigentlich recht einfach:

  1. Die Domain wieder in den Webmaster Tools hinzufügen, falls man sie schon gelöscht hat und dann
  2. unter "Website verwalten - Nutzer hinzufügen oder entfernen" auf den Link "Website Inhaber verwalten".
  3. Dort beim eigenen Eintrag auf "Bestätigung aufheben" klicken.
  4. Nun die Website wieder aus den WMT löschen - und schon herrscht Ruhe.

...aber wehe, Du bist gar kein Eigentümer!

Mein Problem ist aber, dass ich nicht (mehr) als Eigentümer mit vollem Zugriff ausgestattet bin, sondern nur einen eingeschränkten Zugriff auf die Domain habe. Das äußert sich nach der Wiederanmeldung der Site in den Webmaster Tools so:

Eingeschränktes Menü

Nix mit Beenden der "Eigentümerschaft". Und löschen allein läßt die Mails nicht verstummen. Nach allem, was ich so zum Thema gefunden habe, sitze ich also mit einer großen Ar...-Karte vor dem Rechner und es scheint keinen Auswweg zu geben, der nicht auf die Löschung des kompletten Google-Accounts hinausläuft.

Oder kennt jemand eine andere Lösung? Dann würde ich mich über einen Kommentar sehr freuen ;)

# 
Saturday, September 20, 2014

Optimierbar: Online einkaufen bei IKEA

Normalerweise mag ich solche individuellen Erfahrungsberichte mit einem Shop o. Ä. nicht so gern... zu schnell landet man damit in der "Meckerecke". Was ich aber gestern bei / mit IKEA erlebt habe, zeigt vor allem beim Shop so viele Dinge auf, die man offensichtlich besser machen kann (und sollte), dass es ich mich nach 5 Jahren dann doch noch mal dazu hinreißen lasse.

Vorab: Ja, IKEA ist trotzdem cool. Und innovativ: Tolle elektronische Blätterkataloge, aktuell sogar gut funktionierende virale Kampagnen, AR im eigenen Wohnzimmer beim Möbelrücken per App und und und. Umso trauriger ist es, dass es im Onlineshop (alles andere, was später noch folgt, ist wirklich nur Kleinkram) so viele Stellen gibt, an denen potentiell nicht nur ich "hängen bleibe", sondern vermutlich auch eine ganze Menge anderer Besucher in ähnlichen Situationen und mit vergleichbaren Bedürfnissen.

Testcase: Bürostuhl kaufen

Klingt eigentlich ganz einfach. Zumal ich schon auf dem gewünschten Möbel bei IKEA in Kaarst gesessen habe und daher genau wusste, was ich will. Genau 3 Mal, in unterschiedlichen Farben (blau, grün, orange).

Auf der unspektakulären, aber problemlos bedienbaren Produktdetailseite zum Bürostuhl "Markus" (für den Namen kann ich nix, er hat auch die Kaufentscheidung bestimmt nur minimal und bestenfalls unterbewusst beeinflusst; versprochen!) lege ich also alle drei Varianten je einmal in den Warenkorb, wobei mir IKEA per Layer direkt in Buttonnähe anbietet, den Warenkorb zu öffnen. Soweit, so gut. Exkurs: Wer direkt aus einer Übersicht oder Suchergebnissen heraus auf einen "Online kaufen"-Schalter klickt, muss schon genau hinsehen, dass oben links nun ein Artikel im Warenkorb angekommen ist, denn in dem Fall erfolgt ansonsten keinerlei Hinweis. Aber zurück zum Bürostuhlkauf: Klick auf den Warenkorb.

Hürdenlauf im Warenkorb

Die Bilder wirken hier zwar unnötig klein und die Angebote oberhalb der für mich gerade viel wichtigeren Produktübersicht sind nur schwer zu lesen,...


Angebote, Angebote, lies zuerst die Angebote

... aber das eigentliche Problem ist alles, was unter der Produktliste folgt.


Akute Buttonitis, gruselige Benutzerführung

Hier gibt es gleich so viele Dinge, die man klarer gestalten kann, dass jeder CRO-Rookie aus dem Stand so viele vierversprechende Hypothesen aufstellen kann, dass diese einen Testplan bis Ende 2016 füllen würden. Oder noch besser: Man macht es gleich radikal anders; nach unten ist sowieso nicht mehr viel Luft. Ein paar Ansatzpunkte jenseits der Klassiker wie Coupon-Code, SSL, fehlende Warenwertsumme unter der Tabelle u. v. m., das sicher schon alles bereits getestet wurde, gell?):

  • Eine nennenswerte Anzahl von Benutzern wird vermutlich (wie ich) spätestens beim zweiten Besuch des Warenkorbs, in dem dann die zuvor schon einmal eingegebene PLZ noch zu sehen ist, den Hinweis Bitte berechne zunächst die Versandkosten durch Eingabe deiner Postleitzahl, bevor du das Feld "ZUR BESTELLUNG" auswählst. übersehen. Obwohl er so schön klein geschrieben ist...
  • Wenn man einen Button wirklich einfach finden sollte, dann ist es der "zur Kasse"-Schalter, der hier zwar "ZUR BESTELLUNG" brüllt, aber dennoch alles andere als auffällig ist.
  • Außerdem kann ich ihn ja ohnehin noch nicht nutzen, ohne vorher (nennen wir es mal "in Schritt 1") die Versandkosten berechnet zu haben. Wie einfach wäre das, wenn der dazu passende Schalter farbig markiert und der Abschnitt darunter (nennen wir es doch "Schritt 2", OK?) ausgegraut wäre, bis der Schritt davor abgearbeitet ist?
  • Sich nicht mal die Mühe zu machen, den fitzeligen Hinweis nach einem Klick auf "Zur Bestellung" wenigstens farbig hervorzuheben oder eine der anderen 1001 Optionen zu wählen, um diese Notwendigkeit freundlich zu unterstreichen, ist das Online-Pendant zu "Du Idiot". Bei jedem Klick. "Warum funktioniert das nicht?" fragt sich der eine, "Habe ich vielleicht JavaScript deaktiviert oder bin ich mal wieder im falschen Browser unterwegs?" der andere. Oder auch "Whäää? Dann halt nicht, nächster Shop"...

Transparenz beim Liefertermin: Fehlanzeige

Wer den Knopf gefunden und geklickt hat, erhält Auskunft über die Kosten (sehr klein, nicht bündig und gaaanz weit weg von den Preisen in der Tabelle und frei von Währungssymbol) und einen für den hiesigen Markt eher unüblich formatierten vorauss. (Platz zum Ausschreiben wäre freilich da) Termin:


Bei dem Preis würde ich auch gaaanz klein schreiben

Und auch der Schalter, der mich hier weiter bringt, ist nun in einer anderen Farbe, hurra. Freilich aber immer noch mit unnötig wenig innenabstand und daher nicht wirklich optisch gefällig. Ich will jetzt nicht von "klick mich ja nicht an, ich mach mich mal klein" anfangen, aber ... der Punkt ist klar denke ich, oder?

Exkurs: Versandkosten sparen. Wer wie ich knapp 70,-- brutto für drei Bürostühle zu teuer findet, sollte einfach alle drei separat bestellen, denn einen Stuhl bekommt man offenbar für 6,90 geliefert. Klingt blöd? Ist es auch.

Lieferzeit und Verfügbarkeit

Warum aber muss ich so lange warten? Zurück auf der Produktdetailseite kann man zwar die Verfügbarkeit in einem beliebigen IKEA Haus kontrollieren, aber eine "Online-Verfügbarkeit" gibt es nicht und so mag man (ich bin es) auf die Idee kommen, dass es schneller geht, wenn man einzelne Artikel aus dem Warenkorb löscht, um so herauszufinden, was das Problem ist. An dieser Stelle setzt also je nach Bestückung des Warenkorbs eine Menge ein- und auspacken an. Mit entsprechendem Frust, wenn das Ergebnis ausfällt wie bei mir: Es dauert immer so lange. Egal wie viele oder welche Farbe. Warum? Keine Ahnung.

Kundenkonto. Oder auch nicht.

Resignation, ich will weiter kommen. Also Klick auf den erblauten Button. Hier gibt es nun zwei Szenarien: Wer das Ganze zum ersten Mal durchspielt, hat die Wahl zwischen einem Login oder dem Einkauf ohne Anmeldung. Wie jetzt? Ich kann ohne Anmeldung kaufen oder mich anmelden, wenn ich ein Konto habe? Wie komme ich denn an ein Konto, wenn es gar keine Option zum Einkauf als Neukunde mit Anmeldung gibt? Naja, das wird schon alles richtig sein. Also ohne Anmeldung.


Hast Du noch kein Konto oder ärgerst Du Dich schon?

Wer hingegen (wie ich) den Einkauf vor dem Abschluss abgebrochen hat, steht hier ggf. schon wieder vor einer Hürde: Da der Einkauf "ohne Anmeldung" offenbar technisch nicht wirklich frei von einer Anmeldung ist, muss sich hier also entweder an sein Passwort erinnern (nach dem ich nicht gefragt wurde) oder den Browser von Cookies befreien bzw. gleich ganz wechseln, denn hier hat man nur noch die Wahl zwischen der Anmeldung (da man freundlicherweise abgemeldet wurde, wie der rote Hinweis erklärt) oder der Lüge, man sei ein neuer Kunde. Und das Passwort, an dessen Eingabe ich mich nicht erinnern kann (vielleicht weil ich den Vorgang auch gar nicht abgeschlossen habe?), muss ich offenbar auch ändern:


Wehe, Du warst schon mal hier!

Als simulierter Erstbesucher gelangt man nach der Entscheidung für den Einkauf "ohne Anmeldung" (die Anführungsstriche sind ja nun nachweislich wohl verdient) gleich zur nächsten Hürde:


Hast Du keine BusinessCard guckst Du nur...

Ich bin in diesem Moment keine Privatperson, habe aber auch keine IKEA BusinessCard. Meine Option fehlt also. Weil ich aber eine Firmenanschrift eingeben und die Rechnung nicht aus der eigenen Tasche zahlen will, wähle ich notgedrungen die zweite Option... in der Hoffnung, dass mir das Fehlen einer solchen Karte nicht noch zum unüberwindbaren Verhängnis wird. Meine Daten aus dem ersten Einkaufsversuch gebe ich hier auch notgedrungen nochmal ein. Wenn sich also jemand fragt, wie die ganzen Doubletten in der Kundendatenbank herkommen: Hier.

Liefertermin. Oder auch nicht.

Bei meinem ersten Versuch wurde ich noch mit der Auswahl eines Wunsch-Liefertermins konfrontiert. Dabei gibt es jeweils die Wahl zwischen zwei Zeitfenstern, die beide unsinnig sind, wenn man ein Büro beliefern will: 7:00 bis 14:00 Uhr oder 14:00 bis 21: Uhr. Aber auch diese Kröte habe ich bei der ersten und fast abgeschlossenen Bestellung gefressen.

Komischerweise aber erfolgt diese Auswahl bei meinem zweiten Einkaufsversuch mit neu eingegebenen Daten nicht. Ein Glück, dass ich das jetzt nur noch deshalb mache, um Screenshots zu erstellen ;)

Zahlungsweise und (fast) Kaufabschluss

Als ich dann endlich auf der letzten Seite vor dem finalen Klick angekommen bin, gibt man mir einen weiteren Grund, mir das Ganze noch mal zu überlegen, denn als Nicht-Business-Karteninhaber kann ich nun noch zwischen Bar und - vielleicht - EC beim Spediteur wählen. Wenn es nicht dann doch per DHL kommt.


Ich bin dann mal weg

Von Online zu Offline...

Bargeld bereitlegen, um die Stühle zu bezahlen? "Ach Nein..." denke ich mir und entscheide mich dann doch für einen kurzen Ausflug zum nächsten IKEA Standort ein paar-zehn Kilometer entfernt. Nach all dem Unsinn im Shop will ich also nun nur noch eins wissen: Wie groß sind die Packstücke? Oder anders: Bekomme ich drei dieser Stühle in zerlegter Form ins Auto?

Die Antwort erhoffe ich mir auf der Produktdetailseite. Und tatsächlich gibt es dort einen Block, der Maße und Gewicht des Packstücks verspricht:


Finde den Fehler

Wie bitte? Artikelnummer ja, Maße nein? Was soll das denn? Bleibt wohl nur das Telefon. Ich versuche es erst zwar noch mit "Frag Anna", aber darüber breite ich mal lieber den Mantel des Schweigens... hatte aber auch nichts anderes erwartet. Also bleibt nur eine Nummer mit gaaaanz vielen Neunen am Ende, die ich nach ein paar Klicks auch finde.

Verzweiflung am Telefon

Angesichts der bereits erreichten unangemessenen Länge des Beitrags mache ich es kurz: Es gibt kaum sinnvolle Optionen im IKEA-werbeakzentschwangeren Sprachmenü. Freundlich aber nervig, träge und trotz mehrfacher Rückkehr zum Hauptmenü bei meiner speziellen Frage nicht zu gebrauchen. Leider fragt mich auch keiner, ob ich lieber mit einem Menschen statt einem Sprachmenü reden will, also muss ich mich so lange durchkämpfen, bis ich eine Option gefunden habe, die mich zu einer Hotline bringt. Vielleicht...

"Sie sind mehr als 30 cm über dem Boden"

Wenn man aus einem Flugzeug stürzt und wissen will, wann es Zeit ist, den Fallschirm zu öffnen, für den wäre diese Information sicher nicht hilfreich. Genauso geht es mir, nachdem ich über fünf Minuten lang erfahre, dass "mehr als 30 andere arme Schweine vor mir" dran sind. In anderen Worten, aber mit dem gleichen Informationsgehalt für mich. Sind es 31 oder 310? Wie viele Leute sitzen wohl im Callcenter, um die Zahl zu minimieren? Wie sieht es mit meiner voraussichtlichen Wartezeit aus? Ich weiß es nicht - und lege irgendwann genervt auf, ohne eine Ahnung zu haben, ob zwischenzeitlich vielleicht schon 280 vor mir wartende Personen abgearbeitet wurden. Wer weiß das schon? Kontext ist immer gut, wenn man Zahlen bewerten soll. Das stimmt nicht nur in der Webanalyse, sondern auch in einer Warteschlange.

"Wenden Sie sich an einen Mitarbeiter"

Schnitt. Neue Szene: Angekommen in Kaarst, schnell zu den Bürostühlen und die Regalnummer gesucht. Die gibt es aber nicht, denn das Ding muss an der Warenausgabe abgeholt werden. Man soll sich an einen Mitarbeiter wenden. Ich kenne das Spiel, reihe mich in die Schlange ein und erlange tatsächlich irgendwann einen Passierschein A38, mit dem ich via Kasse zur Ausgabe marschieren bzw. fahren kann.

Auf dem Parkplatz der Warenausgabe angekommen mache ich den gleichen Fehler wie immer: Ich nehme einen Wagen mit rein. Es mag sein, dass da irgendwo steht, dass das nicht erforderlich ist. Drinnen steht es jedenfalls und es fällt mir auch auf dem Weg wieder ein, also lasse ich den Wagen mit dem festen Vorhaben stehen, ihn gleich wieder zurückzubringen. Bin auch nicht der einzige, dem das in der nächsten knappen halben Stunde passiert, wie ich noch feststellen darf.

Neu (für mich) sind die Nummern auf dem Ausgabezettel, die auf mehreren Monitoren entweder wiederzufinden sind oder eben nicht. Also gehe ich erst mal (wie bei meinem letzen Besuch noch üblich) zur Theke, wo mich ein Mitarbeiter freundlich darauf aufmerksam macht, wie das jetzt funktioniert und dass ich zu warten habe, bis meine Nummer elektronisch per Monitor "aufgerufen" wird. Auch das passiert während der folgenden Wartezeit noch mit mehreren anderen Kunden.

Warum es 2014 satte 25 Minuten (plus Gang zur Kasse, Zahlvorgang, Fahrzeit vom Parkplatz bis Warenausgabe) dauert, bis meine Nummer sich endlich auf dem Display findet und die Bürostühle eingeladen werden können, will ich gar nicht wissen. Warum aber sagt nicht einfach derjenige, der einem Kunden den Wisch in die Hand drückt sowas wie "Diese Nummer hier finden Sie in der Warenausgabe auf einem der Monitore, sobald Ihre Ware bereitsteht; setzen Sie sich ruhig solange hin. Einen Wagen brauchen Sie nicht mit reinzunehmen, die Kartons stehen schon auf einem Wagen, wenn Sie sie bekommen"? Genau so wäre sichergestellt, dass es wahrgenommen wird. Alles andere, was an Schildern & Co. angebracht sein mag, ist nicht so wirksam. Weil wir nun mal so ticken, wie wir ticken.

Wie auch immer: Die Nummer am Telefon und der Kleinkram bei der Abholung sind meines Erachtens echte Peanuts gegen das, was im Shop potentiell liegengelassen wird. Oder zumindest der ganze vermeidbare Frust, der dort in meinem und ähnlichen Usecases entsteht. Also: einfach mal mit der Optimierung anfangen. Bitte.

#