Google zählt Keywords immer wieder und wieder und wieder …

Allerdings würde ich erwarten, dass mir diese anonyme Suche nur dann in den Keywords von Google Analytics gezeigt wird, wenn sie auch tatsächlich stattgefunden hat. Leider sieht Google das etwas anders. In der Liste der Keywords schlägt das sogenannte First Cookie Counting zu.

Ein und der gleiche Suchbegriff über Monate aus der gleichen Stadt und mit dem gleichen Rechner.

Wenn ein Nutzer beispielsweise im März bei Google nach “nokia analyse” gesucht hat und dabei auf qrios.de gestossen ist, erscheint diese Suche in den Keywords. Findet der Nutzer die Inhalte hier interessant und kommt im April mal wieder vorbei (weil er sich an die URL erinnert oder von seinem Browser daran erinnert wird oder noch Bookmarks verwendet) dann erscheint “nokia analyse” wiederum in der Analyse für den April.

Ein Nutzer von Google Analytics müsste jedoch annehmen, dass nur die Suchbegriffe dargestellt werden, die tatsächlich auch in dem gewählten Analysezeitraum stattgefunden haben. Insbesondere für Sites mit aktuellen Inhalten sind historische Suchanfragen extrem störend und verzerren das Bild erheblich.

Bei sehr unterschiedlich großen Sites ergibt sich bei der genaueren Analyse ein konsistentes Bild der Verzerrung der Daten. Bildet man ein Segment in dem man nur die Nutzer betrachtet, die das erste mal auf der Site waren und die von einer Suchmaschine gekommen sind bleiben nur noch ein Drittel der Einträge übrig: statt durchschnittlich ~35% sind es nun nur noch ~12% der Nutzer. Ein Wert, der übrigens deutlich näher an den Ergebnissen von alexa.com mit ~16% für den Vergleichszeitraum liegt (Werte für eine große deutsche Site mit mehr als 5Mio Visits pro Monat). Die Differenz von 12% zu 16% erklärt sich leicht durch die zu erwartende Anzahl von Usern, die (un)regelmäßig die Cookies löschen. Bei dem Panel-basierten System Alexa werden diese User dennoch gezählt.

Was hat Google davon?

Bei der Frage, warum Google Analytics diese merkwürdige Zählweise verwendet kann man nur spekulieren. Die freundliche Antwort lautet: Google Analytics verwendet das gleiche Verfahren wie es traditionell bei Kampagnenabrechnungen verwendet wird. Derjenige Advertiser, der den Nutzer ursprünglich zu der Seite geführt hat bekommt die Provision (“First-Party-Cookie”).

Die unfreundliche Antwort lautet: Google Analytics rechnet künstlich den Anteil der Nutzer hoch, die über Suchmaschinen auf eine Seite gelangen.

Disclaimer: Der Autor besitzt keine Google-Aktien. Allerdings verdient er sein Geld mit der Nutzungsanalyse von verschiedenen Sites und setzt dafür unter anderem Google Analytics ein. Allerdings nur, wenn es sich nicht vermeiden lässt, da er der Meinung ist, dass Cookie-basierte Analysesysteme evil sind.

Bei der Nutzungsanalyse einer großen Site eines Kunden wunderte ich mich diese Woche mal wieder über die verhältnismäßig wenigen Zugriffen von Android-Geräten. Google Analytics weist für den September 2011 etwas über 15000 Visits aus. Im Februar 2012 sind es knapp doppelt so viele. Eine veritable Steigerung von 100% in fünf Monaten.

Wie komme ich also zu der Einschätzung, dass es verhältnismäßig wenige Android-Zugriffen seien?

Die Zuwächse bei den Android-Geräten fallen überraschend moderat aus. Eigentlich müsste man mit einem Wachstum über dem Marktdurchschnitt rechnen.

In diesen fünf Monaten haben Android-Geräte laut aller Marktanalysen die Führung übernommen. Von einem weltweiten Marktanteil von 8,7% im Q4 2009 ist der Android-Anteil auf 32,9% im Q4 2010 gewachsen. Innerhalb eines Jahres wurde der Anteil also fast vervierfacht und inzwischen ist jedes dritte Smartphone ein Android-Gerät. Hinzu kommt der Wachstum des Marktes selbst, der sich in dieser Zeit knapp verdoppelte.

Unter der Annahme, dass die untersuchte Site mit mehreren millionen Usern im Monat für Android-User genauso interessant ist, wie für jeden Anderen, hätte der Anteil der Android-Geräte in dem Beobachtungszeitraum erheblich stärker steigen müssen als dargestellt. Insbesondere vor dem Hintergrund, dass sich der Anteil der Mobil-Nutzer insgesamt auf der Site von Q4/2009 auf Q4/2010 fast verzehnfacht hat.

Stutzig wurde ich in einem Gespräch mit meinem Kollegen Ramon, der mir berichtete, dass der Standard-Browser seines HTC-Desire über eine Einstellung verfügt, die die Seiten in der klassischen (Desktop-)Variante darzustellen. Viele Web-Sites liefern für Handys angepasste Darstellungen. Deutlich zu sehen bei Wikipedia oder bei WordPress-Blogs. Und viele Android-Nutzer (und auch iOS-User wie mich) nervt diese Darstellung. Denn sie bedeutet, dass man sich mit einer anderen (häufig reduzierten) Funktionsweise beschäftigen muss.

Nicht jedermanns Sache: mobiles Interface für Wikipedia

Ein Test ergab, dass bei Änderung dieser Einstellung der User-Agent-String des Browsers geändert wird. Statt:

Mozilla/5.0 (Linux; U; Android 2.2.1; de-de; HTC_DesireZ_A7272 Build/FRG83D) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

wird bei Aktivierung der Einstellung:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.22+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4

im Header des Requests an den Server gesendet. Für den Server sieht es damit so aus, als ob ein ganz normaler Mac die Seite aufruft. Ebenfalls geändert werden die Properties im navigator-Objekt des Browsers unter JavaScript. Dem Server wird ein komplett anderer Browser vorgegaukelt damit die Seite möglichst so aussieht, wie der Nutzer es auf einem Notebook erwarten würde.

Da es sich bei dem Standard-Browser (und den meisten Alternativen auch) unter Android um einen WebKit-Browser handelt ist die Verwendung der Safari-Kennung naheliegend. Eventuelle Anpassungen dürften sich weitgehend gleich verhalten.

Nur eine Umfrage könnte tatsächlich ermitteln wie viele Android-User diese Einstellung vornehmen. Häufige Fragen in Nutzerforen, wie die mobile Darstellung abgeschaltet werden kann deutet allerdings darauf hin, dass dies nicht so selten geschieht.

Interessant am Rande ist darüber hinaus, dass selbst Google Analytics (wie alle anderen WebAnalytics-Anbieter auch) nach wie vor keine vernünftige Lösung für Ermittlung des Browsers bieten. Der normale User-Agent-String des genannten HTCs wird nicht – wie es korrekt wäre – als WebKit ausgezeichnet, sondern taucht als “HTC_DesireZ_A7272″. Bei Samsung und LG verhält es sich ähnlich.

Als Gegencheck habe ich mir die Entwicklung der Nutzungszahlen von Safari unter MacOSX angesehen. Vom September bis einschliesslich Februar wuchs die Zahl der Nutzer überdurchschnittlich um fast 40% von 250.000 Besuchen auf 350.000. Hochgerechnet auf ein Jahr ergäbe sich eine Verdopplung. Zwar wachsen die Verkaufszahlen laut Marktforschern aber sie verdoppeln sich nicht. Ausserdem verwendet ein wachsender Teil der User auch auf dem Mac einen anderen Browser als Safari (z.B. Firefox oder Chrome).

Ein weiteres Indiz für die fehlerhafte Erkennung der Android-Geräte ist die merkwürdige Häufung ungewöhnlicher Bildschirmgrößen bei den Safari-Nutzern unter Mac OSX. Eigentlich sollte man davon ausgehen, dass gerade die Apple-Rechner mit wenigen bekannten Auflösungen – 1280 x 800 beim MacBook Pro 13″ oder 1366 x 768 beim MacBook Air 11″ – daher kommen müssten. Es sind stattdessen jedoch signifikant viele Geräte mit “unrunden” Auflösungen zu verzeichnen.

Diese Tatsache ist damit zu erklären, dass bei Android ebenso wie bei iOS die Größe des Bildschirms nicht festgelegt ist, da der Browser die Seiten skaliert. Die tatsächliche Größe steht erst fest, wenn der Browser die Elemente tatsächlich kennt und darstellen kann. Wenn die Seite meint, dass sie nur 600 Pixel breit ist, wird in den meisten Fällen der Browser auch behaupten, dass der Screen 600 Pixel breit ist.

Nach diesen Betrachtungen ergibt sich, dass ein signifikanter Teil der Android-User in den Tracking-Tools schlicht als Mac-User gezählt werden. Fussend auf den Auffälligkeiten bei den Zahlen zur Safari-Nutzung schätze ich, dass mindestens ein Drittel aller Android-Geräte falsch gemessen werden.

Ein ähnliches Problem ergab sich übrigens schon vor 15 Jahren für den legendären Browser Omniweb unter NeXTSTEP. Auch dieser verfügte über einen Mimikry-Modus damit der User nicht immer nur die Seiten mit dem Hinweis auf den Netscape Navigator sahen (mein Artikel dazu bei Heise, leider kostenpflichtig …).

Per Default ausgeschaltet: Google Instant

Mit Google Chrome 9 wurde jetzt eine Funktion eingeführt, die erheblichen Einfluss auf das Verhalten der Nutzer haben könnte. Schaltet man in den Einstellungen “Google Instant” ein wird bereits während der URL-Eingabe die jeweils wahrscheinlichste Seite geladen. Je nach Historie des Surfens wird also bei ‘sp’ entweder spiegel.de oder spreeblick.com geladen.

Mir ist momentan nicht klar, ob eine solche Funktion aus User-Sicht wirklich sinnvoll ist, da ich insgesamt den Eindruck habe, dass viele neue Funktionen zu einer immer kürzer werdenden Aufmerksamkeitsspanne führen.

Auswirkungen hat diese Funktion jedoch auf die Webanalyse und damit auch auf den Betrieb einer Site. Denn in Zukunft werden mehr Seiten aufgerufen und direkt danach wieder verlassen. Die bisher schon sehr schwierig zu beurteilende Bounce Rate wird also steigen. Solange diese Funktion nicht von den anderen Browsern übernommen wird, kann man deren Bounce Rate benutzen, um den Chrome-Faktor zu berechnen. Leichter wird Webanalyse dadurch sicher nicht. Aber es fließen bestimmt noch mehr interessante Daten zu Google.

Wenn ein Gesetz und Strafandrohung bei Anbietern nicht dazu führen, dass IP-Nummern nicht gespeichert werden, wie bitte sollte ein http-Header mit der Aussage ‘do not track me’ dazu führen, dass Werbetreibende kein Targeting durchführen.

“Do not Track” soll in Zukunft im http-Header übermitteln, dass der User vor diesem Browser nicht wünscht, analysiert zu werden. Sozusagen eine Tarnkappe mit dem Hinweis “Falls Sie mich doch sehen, ignorieren Sie mich doch bitte!“.

Nun könnte man natürlich vermuten, dass Firmen wie Doubleclick sich in Zukunft hüten werden, Cookies an den Browser zu schicken. Natürlich werden sie das tun. Aber das hindert sie nicht daran, trotzdem profilierte Werbung auszuliefern. In Zukunft wird ein Retailer von seinen Werbenetzwerken einfach verpflichtet (respektive Preisnachlässe erhalten), Cookies verschiedener Partner durchzureichen. Dieses Durchreichen geschieht schon heute. Denn die Anbieter sind schon heute nicht unabhängig. Netzwerk X arbeitet bezüglich Branche Y mit Netzwerk Z zusammen.

Wenn ein User dann bei Shop A (wg. der Funktionen des Shops, zwinker, zwinker …) gezwungen wird, Cookies zu akzeptieren, werden diese an das Netzwerk durchgereicht. Wenn es nicht anders geht mit Hilfe von Mengenabfragen à la History-Hijacking.

Aber selbst dieses recht komplizierte Szenario muss eigentlich nicht bemüht werden. Denn mit dem Browser-Fingerprint gibt es eine funktionierende Methode der Wiedererkennung eines Systems an Hand von Browser- und Systemumgebung, ohne eine ID auf dem/vom Rechner des Users zu speichern/abzufragen.

Schlussendlich gibt es aber niemanden (am wenigsten einen Richter), der in der Lage wäre, zu unterscheiden, ob die technischen Umgebungsvariablen so sind wie sie sind, weil jemand wollte, dass sie so sind wie sie sind oder weil eine Standardkonfiguration meinte, dass es eine gute Idee wäre, dass sie so seien, wie sie sind.

Und – ganz ehrlich – glaubt irgendwer im Raum, dass facebook seine Like-It-Funktion disabled, wenn ein User die DNT-Funktion eingeschaltet hat? Mit jedem Recht kann facebook behaupten, dass diese Funktion nicht dem Tracking dient sondern der Kommunikation. Wenn diese Argumentation funktioniert, werden in Zukunft auch lauter Googles, Zanoxes und andere eine Community aufbauen. Haben sie schon versucht? In Zukunft werden sie wissen, warum es sich lohnt, selbst wenn sie NULL User haben …

“Ich hab’s Ihnen ja gesagt” (1996, vor kurzem) trifft es nicht so ganz (2004) …

Alle großen Anbieter (Omniture, At Internet, Nedstat) bieten dabei XML als Ausgabeformat an. Toll denkt man sich da. Als jemand der seit Jahren mit XML arbeitet und schon etliche Mashup-Projekte gemacht hat träumt man dann schon von tollen neuen Charts und großen Monitoren im Entrée unserer Kunden.

Und dann bekommt man von den Anbietern XML-Beispieldateien. Und plötzlich fallen all die Träume wie ein Kartenhaus zusammen. Von einem Schema oder einer Definition ist weit und breit nichts zu sehen. Weder DTD, noch XSD oder Relax NG ist bei den WebAnalytics-Anbietern in Gebrauch. Mir ist schleierhaft, wie man eine API entwickeln kann, die XML generieren soll, ohne eine Beschreibung der Struktur und der Typen zu verwenden.

Entsprechend katastrophal ist dann auch die Struktur der XML-Dateien. Bei allen Anbietern sieht man mit einem Blick, dass es sich eigentlich nur um gewrappte CSV-Dateien handelt. Typisch ist sowas hier:

<Col>
<Row>Veränderung in %</Row>
<Row>-5,4</Row>
<Row>0,45555555</Row>
<Row>10,3</Row>
</Col>

Und das sieht zumindest – aus Sicht der Formatierung – noch gut aus. Zu finden ist jedoch auch sowas hier:

<Col
/><Row
/>

Womit eigentlich sofort klar wird, dass die Programme mit denen diese Ausgaben generiert werden, noch nie einen XML-Parser gesehen haben, denn einen solchen zu solcherlei Formatierung zu bringen, bedarf es schon einiger Handstände.

Wenn aber die Programme mit denen diese Ausgaben generiert werden, noch nie einen Parser gesehen haben wird früher oder später folgendes passieren: Die Daten, die ausgegeben werden sollen enthalten irgendwelche Zeichen oder eine Struktur, die besonders behandelt werden müsste, damit das ausgegebene XML überhaupt noch wohlgeformt ist.

Und so erhält man dann tatsächlich – sogar als Beispieldatei zugesandt – eine XML-Datei über die jeder Parser stolpern wird:

<?xml version=”1.0″ encoding=”utf-16″?>
<Export>
…
<Metric265>Temps passé par page (chargement)</Metric265>
…

Etliche Versuche mit verschiedenen Programmen, die alle meinten, dass es sich um chinesische Zeichen handeln würde, scheitern. Xmllint meldet dann auch, dass die Daten – entgegen der XML-Deklaration –  nicht in UTF-16 vorliegen sondern in UTF-8 geschrieben sind. Jedes vernünftige System zur Verarbeitung von XML (also z.B. Saxon) wird sofort den Dienst einstellen.

Wäre die Ausgabe mit einem echten XSLT-Prozessor generiert worden, könnte sowas nicht passieren. Dieser hätte die Daten entweder tatsächlich als UTF-16 codiert oder den Dienst verweigert und man hätte eine vernünftige Fehlermeldung ausgeben können.

Aber was soll man auch von Firmen erwarten, die mehr Leute im Verkauf haben als im Support plus Entwicklung?