Dass man mit Cookies die Wege eines Nutzers nachbildbar machen kann, ist spätestens seit dem Boom von Tablets und Smartphones Wunschdenken. Auf dem Weg zum Conversionziel liegen heute die verschiedensten Geräte, mit denen der Nutzer nacheinander, abwechselnd oder mehrfach auf eine oder mehrere Websites zugreift. Hier entstand in der Vergangenheit ein Problem, das man mit der klassischen Webanalyse nicht nachbilden konnte. Bis jetzt.
Vergleicht man die verschiedenen Disziplinen des Online-Marketings miteinander, war die Webanalyse schon immer eher etwas ruhiger und ohne vergleichbare Partys, wie dies z. B. bei den Affiliates oder in der SEO-Szene üblich ist. Und so ist es auch nicht verwunderlich, dass die kleine Revolution, die sich derzeit in der Webanalyse abzeichnet, weitgehend unbeachtet blieb ist und noch unter dem Radar der meisten Online-Marketer läuft.
Ende des Jahres 2012 veröffentlichte Google Version 2 seiner Mobile-Tracking-Lösungen – für iOS und Android – und ließ den einen oder anderen Webanalysten verwundert stehen. Waren doch die bisher bekannten benutzerdefinierten Variablen, eine Möglichkeit Daten auch sessionübergreifend mit einem Nutzer zu verbinden, weggefallen. Stattdessen konnten benutzerdefinierte Dimensionen und Metriken angelegt werden. Irgendetwas war hier anders, nur keiner wusste so recht, wieso.
Die Antwort auf dieses „Wieso?“ sollte erst ein wenig später auf der Partnerkonferenz von Google Analytics (GACP-Summit) kommen, als Google Universal Analytics und mit ihm das Measurement-Protokoll veröffentlichte. Dieses Protokoll ermöglicht es Nutzern, unter anderem eigene Daten auf Google Analytics in eigene Metriken und Dimensionen hochzuladen.
Was im ersten Moment nicht nach besonders viel klingt, hat immense Tragkraft.
Aber immer der Reihe nach.
Schaut man sich den Status quo der Webanalyse an, so haben alle bekannten Tools auf dem Markt einen kleinen Javascript-Code, den man mal mehr, mal weniger einfach auf der eigenen Website platziert. Dieser wird mit verschiedenen Optionen aufgerufen und überträgt je nach Wunsch eine Page-Impression, ein Ereignis oder eine E-Commerce-Transaktion an den Tracking-Server. So weit, so gut, aber hier hört der Spaß eben auch schon auf.
Ist kein Javascript im Browser aktiviert, funktioniert das Tracking in den meisten Fällen überhaupt nicht. Sind Cookies deaktiviert, ist das Tracking oft nicht mehr zuverlässig. Besonders problematisch wird es, wenn etwas gemessen werden soll, das außerhalb der Website oder lange nach dem Besuch des Nutzers passiert. Eine Warenrücksendung lässt sich kaum noch mit den bereits im Webanalyse-Tool erfassten E-Commerce-Daten kombinieren.
Und genau hier zeigt das Measurement-Protokoll seine Stärken. Es definiert nur eine Schnittstelle und die Kommunikation mit dieser Schnittstelle. Der Rest bleibt dem Anwender überlassen.
Natürlich bietet Google auch für sein neues Protokoll ein eigenes Tracking-Snippet an. Es wird wie bisher auf der Website eingebunden, um Daten an den Tracking-Server zu übertragen. Und es ist sehr wahrscheinlich, dass Google in absehbarer Zeit noch weitere dieser Implementierungen für serverseitige Sprachen wie Python, Java oder PHP folgen lässt. Es ist aber auch problemlos möglich, in einer völlig anderen Programmiersprache Tracking-Daten an Google Analytics zu übergeben. Wenn die Daten wie im Protokoll definiert übertragen werden, werden sie von Universal Analytics akzeptiert und verarbeitet.
Der große Unterschied zum bisherigen Google Analytics ist, dass zu jeder Zeit und von jedem Gerät Daten übertragen werden können – egal, ob das Gerät ein Computer, ein Smartphone oder ein Webserver ist. Oder ein Kassensystem, das einen im Internet gedruckten Coupon registriert. Oder das Inhouse-CRM-System. Oder ein Sensor in der eigenen Filiale, der die Anzahl von Smartphones in der Umgebung misst (z. B. Euclid Analytics – euclidanalytics.com/). Woher die Daten auch kommen, sie landen alle in einem Tool mit dem „bescheidenen” Namen Universal Analytics.
Dabei sollte natürlich nicht vergessen werden, dass Google Analytics mit Universal Analytics auch in Zukunft seinen Fokus auf Daten aus dem Web legen wird. Alle bisherigen Reports bleiben so, wie man sie kennt. Sie können jetzt jedoch mit Daten von überallher erweitert und angereichert werden. Den eigenen Ideen sind keine Grenzen mehr gesetzt.
Die wohl entscheidendste Änderung, die dies jedoch mit sich bringt und die das größte Diskussionspotenzial hat, ist eine ganz andere.
Als bisherige Grundlage der Reports diente der Besuch, Besucher als solche standen nicht im Fokus. Häufig waren es sehr viele Besuche und jeder einzelne Besuch eines Besuchers ging in der Datenmasse unter.
Wenn es jetzt möglich ist, Daten aus dem eigenen CRM-System oder anderen (Offline-)Kanälen einfließen zu lassen, können Daten nicht mehr auf Besuchsebene betrachtet werden. Der gemeinsame Nenner, der bleibt, ist die Person, die die Daten erzeugt. Und so ist es auch mit dem Measurement-Protokoll und Universal Analytics.
Ich wiederhole es noch einmal, weil es die wichtigste Aussage dieses Artikels ist: Mit Universal Analytics ändert sich die komplette Betrachtungsweise der Daten: Weg vom Besuch. Hin zum Besucher. Hin zur Person.
Natürlich kann man argumentieren, dass der reine Besuchsbezug in Google Analytics bisher nicht in jedem Report gegeben ist. So gibt es einen Multi-Channel-Funnel, der es ermöglicht, die verschiedenen Berührungspunkte eines Besuchers zu betrachten, auch benutzerdefinierte Variablen können besuchsübergreifend gesetzt und ausgewertet werden.
Diese beschränken sich jedoch auf die Idee, das ein Tracking-Cookie einen Besucher widerspiegelt. Spätestens auf einem Familienrechner funktioniert auch das nicht mehr, hier ist ein Besucher nicht mehr der Bruchteil einer einzelnen Person, sondern ganz vieler. Wäre eine Suchmaschine ein Psychologe und müsste ein Profil für eine Person anhand des Suchverhaltens an einem solchen Rechner erstellen, sie müsste sich selbst einweisen.
Jedes Gerät, sogar jeder Browser, arbeitet also mit seinen eigenen Cookies und somit ist ein Besucher auf jedem Gerät und in jedem Browser mindestens eine neue Person.
Laut Google wird mittlerweile von über 90 % aller Nutzer mehr als ein Gerät genutzt, um sich über Produkte zu informieren und zu einer Kaufentscheidung zu finden. Die Aktienkurse und Umsatzzahlen von Apple und Samsung verraten auch dem Letzten, dass Tablets und Smartphones allgegenwärtig werden und nur noch die wenigstens von uns arbeiten in Kohleminen oder an der frischen Luft, sondern vielmehr hart an ihrem ersten oder nächsten Bandscheibenvorfall – auf einem Stuhl vor einem Arbeitsrechner.
Bedenkt man, dass nicht alle Länder – ich setze kurz die rosa Marketingbrille auf – so paranoid sind wie die Deutschen, ist der Schritt zum Besucherbezug also nur verständlich.
Die Umsetzung ist denkbar einfach. Wird ein Nutzer auf der eigenen Website wiedererkannt, kann eine für diesen Nutzer einmalige ID an den Tracking-Server mit übertragen werden. Der Tracking-Server prüft, ob die ID bereits bekannt ist, und weist die neuen Daten - Page-Impression, Ereignis, Transaktion, etc. … – dem Nutzer zu.
Der bisherige Identifikation, die Tracking-Cookies, verlieren ihre ehemals so wichtige Funktion. Entsprechend verwundert es nicht, dass die bisher in Google Analytics benutzten vier bis fünf Cookies mit dem neuen Javascript-Code unter Universal Analytics auf einen einzigen zusammenschrumpfen. Dieser Cookie besteht aus zwei mit einem Punkt verknüpften Zufallszahlen und Google „warnt”, ein Löschen dieses Cookies müsse nicht dazu führen, dass man nicht sofort wiedererkannt wird (http://support.google.com/analytics/bin/answer.py?hl=de&answer=2838718&topic=2790009&ctx=topic).
So erstaunlich und faszinierend all das klingen mag, nicht nur der Datenschutz, sondern vor allem Google setzt hier Grenzen. Zwar dient die ID dazu, einen Nutzer wiederzuerkennen, dies ist jedoch nicht zu verwechseln mit Daten, die eine Person als solche identifizierbar machen. Letzteres ist ausdrücklich verboten! So sollte als ID ein kryptischer Wert und nicht etwa die Kreditkarten-Nummer oder die E-Mail-Adresse des Besuchers genutzt werden.
Diese neue Art zu tracken hat noch einen ganz anderen, sehr positiven Nebeneffekt. So verlor der Tracker nicht nur einen Großteil seiner Cookies, sondern auch seiner Logik. Jedem Webanalysten dürfte die Qual mit Self-Referrern (die eigene Website wird als Verweis angezeigt) bekannt sein – und die damit verbundenen unzähligen Methoden, wie man dies verhindern soll. Eine einzige falsch oder nicht vertaggte Seite reicht schon, um sämtliche Mühen zunichtezumachen, und ist im schlimmsten Fall nur mit großem Aufwand zu finden.
Das fällt weg. Elendiges Ärgern mit domainübergreifendem Tracking? Fällt auch weg. Probleme mit Sessionlaufzeiten? Fallen weg. Alles, was der Tracker im Frontend der Seite noch macht, ist, Daten an den Server schicken. Das war’s.
Im Backend kann jetzt eingestellt werden, welche Referrer als Referrer zählen und welche zu eigenen Domains gehören. Selbiges gilt für organischen Traffic, das Hinzufügen von neuen Suchmaschinen dauert nicht mehr Wochen bis zum nächsten Website-Deploy, sondern eine Minute, um sie im Backend zu ergänzen. Sessionlaufzeiten? Im Backend einstellbar. Keywords, die als direkter Traffic zählen sollen? Im Backend.
Eine von vielen lang ersehnten Funktionen ist dadurch ebenfalls verfügbar, der Import von Kostendaten. So können nicht mehr nur Adwords und Google-Dienste in Analytics verglichen werden, sondern der Traffic von allen Quellen kann mit konkreten Kostenblöcken versehen und gewichtet werden. Dies hilft nicht nur, sich ein besseres Gesamtbild über die eigenen Ausgaben zu verschaffen, sondern unterstützt auch dabei, die Wechselwirkungen zwischen verschiedenen Kanälen zu erkennen und so zu deren Optimierung beizutragen – der eigentliche Sinn und Zweck der Webanalyse.
Und trotzdem, ein kleiner fader Beigeschmack dürfte bleiben, sobald man die Marketingbrille abnimmt. Dem Website-Boosting-Leser dürfte nicht erst seit Beginn dieses Jahres bekannt sein, welche Daten aus Facebook-Applikationen gezogen werden können, und dass es mit deren Hilfe möglich ist, einen Nutzer quer durchs Netz und unabhängig vom Gerät zu identifizieren.
War dies bisher nur Facebook vorbehalten, kann dies jetzt von jedem Webanalysten genutzt werden, um eigene Bewegungsprofile von Nutzern geräteübergreifend zu erstellen.
Auch Websites, die ihren Nutzern Log-ins anbieten oder eventuell sogar erfordern, haben ähnliche Möglichkeiten, eine Geräteunabhängigkeit zu erreichen. Personalisierte Werbung und Angebote dürften, genauso wie die Diskussionen um Datenschutz, völlig neue Dimensionen erreichen.
Und doch ist genau diese „Überallidentifizierbarkeit“ die größte Schwäche der Idee, denn diese Umsetzung der Wiedererkennung bleibt jedem selbst überlassen. Google bietet mit Universal Analytics lediglich ein Tool, das dies unterstützt. Ohne ein solches Log-in, das eine Wiedererkennung ermöglicht, bleibt das Ganze ein schöner Traum. Und auch dieses Log-in würde nur das Internet abdecken. Ob das Smartphone, das unser Sensor im Laden erkannt hat, jemals vernünftig mit dem vorhergehenden Besuch auf der Website im Internet verknüpft werden kann, bleibt fraglich. Die großen Möglichkeiten werden wegen des hohen Aufwands wahrscheinlich nur finanzkräftigen Unternehmen vorbehalten bleiben.
So sehr die Möglichkeiten dieser neuen Funktion also locken und so hilfreich sie schon jetzt in großen Teilen sein werden – es wird noch viel Zeit ins Land gehen, bis es technisch überhaupt möglich ist, den vollen Umfang effektiv zu nutzen, um aussagekräftige Analysen und Handlungsempfehlungen zu treffen.
Wenn dann mit dem in Onlinedingen üblichen Zeitverzug von zwei bis drei Jahren die Juristen und Datenschützer sich dieses Themas annehmen, wird die Handhabung sicherlich nicht unbedingt einfacher.