smartmetrics

Das Universal Tag (Teil 2): Vorschläge für die Darstellung und den Transport

Im meinem Beitrag “Das Universal Tag (Teil 1): Ein erster Schritt zur Standardisierung in der Web Analytics” berichtete ich über die meiner Meinung nach inhaltlich unbedingt nötigen Fähigkeiten eines standardisierten Tags wie Seiteneigenschaften, Benutzer- oder Produktattribute sowie die frei definierbaren Metriken. Nichts von alldem ist neu - doch was fehlt, ist eine komplette Auflistung. Denn das eine Universal Tag muss alles unterstützen, was die heutigen, herstellerspezifischen Tags in Summe abbilden.

In diesem Beitrag möchte ich mich mit den Möglichkeiten auseinandersetzen, diese inhaltlichen Anforderungen in eine technische Darstellung zu überführen und die gesammelten Daten an einen Data Collection Server zu übertragen.

Was eignet sich zur Darstellung? XML, JSON und Javascript Arrays sind technisch geeignet, die inhaltlichen Anforderungen abzubilden. Heutzutage ist fast ausnahmslos Javascript im Einsatz, mit einem kunterbunten Mix aus Arrays, Objekten und globalen Variablen.

Ich würde XML für die Darstellung einsetzen. Denn XML hat die Vorteile, dass

• es ein weit verbreitetes Format ist,
• es relativ gut menschenlesbar genannt werden kann,
• es auch ausserhalb der Website viele Tools und Prozesse gibt, die mit diesen Daten etwas anfangen können,
• XML erlaubt, alle Informationen in eine einzige Variable bzw. Datei zu schreiben, die einfache, hierarchisch und listenartige Daten nebeneinander und im Verhältnis zueinander abbilden kann.

Die per Javascript ermittelbaren Daten (Browser, Betriebssystem, Plugins, Bildschirm etc.) können dort genauso einen Platz finden wie die serverseitigen, zum Beispiel aus dem CMS erzeugten Informationen zu Seiten, Gruppen von Seiten, Server und so weiter. Shop-spezifische Informationen, in der Hauptsache Warenkörbe, sind meist Listen mit Beschreibungen aus Artikelnummern, Größen, Farben, Preisen, Stückzahlen und Informationen über den Bereich, aus dem sie stammen. Auch das lässt sich hervorragend mit XML abbilden.

Daten zu Besuchern, wie die ID des benutzten Werbemittels, die Postleitzahl oder Altersgruppe können im gleichen Datensatz abgelegt werden. Die Befüllung der XML-Struktur kann teils serverseitig mit Java, Php, CMS und teils clientseitig per Javascript erfolgen.

Kurzum: Mit XML wären wir auf der sicheren Seite.

Wie steht es um die Transportmöglichkeiten eines Universal Tag? Grundsätzlich beherrschen unsere Browser zwei unterschiedliche Verfahren, Dateien aus dem Internet anzufordern und dabei zusätzliche Informationen zu übermitteln: GET und POST.

Beim GET sendet der Browser an den Server die Adresse, die hinter einem Fragezeichen eine Reihe von Name-Wert-Paaren enthält. Diese werden üblicherweise mit einem “&” voneinander getrennt, zum Beispiel: http://www.server.domain/pfad/datei.php?seite=home&user=frank&start=0

Firefox, Safari und Opera unterstützen solche Adressen mit mindestens 80.000 Zeichen Gesamtlänge, Microsofts Internet Explorer in den Versionen 5.x bis 8.x leider nur mit maximal 2.083 Zeichen. Dies führt regelmäßig zu Problemen.

Beim alternativen POST sendet der Browser die Daten im Protokoll-Header mit, sie werden nicht Bestandteil der URLs. Dieses Verfahren wird beispielsweise benutzt, um Bilder oder andere Dateien auf Server hochzuladen. Auch Formulare werden oft so übertragen. Sie erkennen diese Technik leicht daran, dass Ihr Browser bei der anschliessenden Benutzung des “Back”-Buttons fragt, ob er die Daten erneut senden soll.

Die beiden Verfahren sind grundsätzlich geeignet, Web-Analytics-Daten zu transportieren. Dennoch wird derzeit nur GET standardmäßig von den großen Herstellern angeboten.

In Frage kommen:

1. Klassisches Javascript Tag, beschränkt im Microsoft Internet Explorer auf 2083 Byte lange URLs. Längere werden nicht übermittelt.
2. Noscript Tag (mit der gleichen Beschränkung)
3. Ajax + serverseitige Messung, ergänzt um Javascript-Automatismen zur Vergabe oder Ermittlung der Visitor ID. Diese ist in der Datenmenge praktisch nicht beschränkt, die einzigen Grenzen liegen bei den Servern, die diese Daten empfangen und verarbeiten müssen. Aber: Bei Ausfall der Infrastruktur wie der Verbindung zum Data Collection Server führt dieses Vorgehen schnell zum Stillstand der eigentlichen Applikation. Wenn man das vermeiden will, muss man sehr aufwändig entkoppeln, Pufferspeicher einbauen etc.
4. Ein direktes POST zum Data Collection Server: Um das “2083-Byte-Problem” des IE zu umgehen, wäre das in der Implementierung aus meiner Sicht sinnvoll und weniger aufwändig als die serverseitige Messung. Das ist relativ einfach zu erreichen:

• Anstelle des klassischen Image Tags wird ein FORM verwendet.
• In einem IFRAME befindet sich ein Formular mit action=”POST”, alle Variableninhalte sind INPUT TYPE=”hidden”.

Die Anforderung an den Data Collection Server ist allerdings, dass er POST-Daten empfangen kann. Omniture kann das beispielsweise nicht an der klassischen IMG-Schnittstelle, aber sehr wohl an der Schnittstelle, die für Data Insertion API ausgelegt ist. Der Schritt weg von der klassischen Image-Request-Methode zu einer ausgefeilteren Technik, die das URL-Längenproblem umgeht, ist sicher nicht für jeden notwendig.

Was jedoch passiert, wenn man nur den Markt analysiert und nach dem aktuellen Bedarf handelt, sehen wir an vielen heutigen Tools: Es entsteht eine Situation, in der die Hersteller nur das Nötige tun, um die Masse ihrer Kunden im kaufmännischen Sinne gut zu bedienen. Wirklicher Fortschritt scheint mir dabei eher eine untergeordnete Rolle zu spielen. Die (Noch-)Einzelfälle, in denen die Grenzen heutiger Implementierungen überschritten werden, nehmen in meinem Tätigkeitsbereich zu und die Workarounds sind jedesmal wieder teuer.

Ist das auch bei Ihnen der Fall? Wir sollten gemeinsam mit dem Aufräumen beginnen, um diese Kosten in Zukunft zu vermeiden.

---

Das Universal Tag (Teil 1): Ein erster Schritt zur Standardisierung in der Web Analytics

Eine traumhafte Vorstellung: Dass ein einziger universeller “Universal Tag” ausreicht, um alle  Web-Analytics-Tools einheitlich bedienen zu können. Dass man nur ein einziges Mal einen Code erstellen muss und mit diesem beliebig den Hersteller wechseln kann, ohne alle Seiten erneut anfassen zu müssen.

Für die Anwender von Web-Analytics-Tools wäre das perfekt. Die Realität sieht jedoch anders aus: Wenn man erst einmal fachlich geklärt hat, was man messen möchte, dann implementiert man häufig mit hohem Aufwand.  Wenn dann ein Wechsel des Tools ansteht, wie es für einige Sites beispielsweise beim Verschwinden von HBX notwendig war - oder weil sich herausstellt, dass das bisherige Tool neue Anforderungen nicht abdeckt -, dann hat man diese Kosten und die Mühen erneut.

Das Problem: Die heutige Lösungen sind sehr herstellerspezifisch. Und die Anbieter von Web-Analytics-Systemen scheinen Interesse daran zu haben, dass alles so bleibt wie es ist. (Siehe auch unseren Blogbeitrag “One Tag to Rule Them All oder das Über-Tag”)

Das Entwickeln eines “Universal Tag” - hat ein solches Vorhaben überhaupt eine Chance? Gegenfrage: Warum nicht? Wenn…

• Plugins dazu führen können, dass Browserhersteller deren Funktionalität komplett übernehmen,
• es Javascript Libraries gibt, deren Funktionen ein Browser bereitstellen wird,
• sich CD, DVD und Blu ray herstellerübergreifend normieren liessen,

… dann sollte doch wohl die Normierung eines “Universal Tag” machbar sein. In einem ersten Schritt reicht es, eine Normierung zu bestimmen und festzulegen: Sobald sich dann zwei Hersteller fänden, die diese teilweise erfüllten, hätten deren Kunden einen kleinen Vorteil. Denn sie hätten eine alternative Lösung, die - mit etwas geringerem Aufwand - implementierbar wäre. Wenn ein Toolwechsel ansteht, könnte dies den Ausschlag für oder gegen eine Kaufentscheidung geben.

Nur: Irgendwer muss anfangen, sonst wird es nie Realität (wie es Ian Thomas “Whence the Universal Tag?” treffend beschreibt). Deshalb möchte ich erste Vorschläge machen, wie eine allgemeingültige, Tool unabhängige Implementierung aussehen könnte:

Die folgende Liste soll ein Superset darstellen, also die Vereinigungsmenge der bisherigen Inhalte. Sie ist unvollständig und sollte selbstverständlich und gerne diskutiert und erweitert werden. Jedes Web-Analytics-Tool unterstützt Teile folgender Spezifikation:

A. DIMENSIONEN

1. Die Websites

• Diese sollen nach verschiedensten Gesichtspunkten gruppiert und untersucht werden können (zum Beispiel Seitennamen, Navigationsbereiche, Partnerintegrationen etc.).
• Da man diese nicht von vorneherein festlegen kann, braucht man eine erweiterbare Liste von Seiteneigenschaften (Dabei ist es gleich, ob man sich für die Farben der Seiten, Templatenamen oder den Vornamen des Programmierers der Seite interessiert).
• Ob diese nun bisher Documentgroup, Channel oder prop42 hiessen, spielt keine Rolle.

2. Visitors

• Besucher haben Eigenschaften, nach denen segmentiert werden sollte. Ein Ziel kann sein, dass man herausfinden will, bei welchen Kunden man gut ankommt, bei welchen weniger.
• Auch hier gilt: Man muss jederzeit neue Eigenschaften der Besucher erfassen können. Die Eigenschaften umfassen unter anderem alle technischen Ausstattungsdetails wie Browser, Betriebssystem, Java-, Flash- etc. -Ausstattung (aber auch typischerweise abgefragte Informationen aus Formularen wie Postleitzahl, Alter, Geschlecht). Da man Visitors nicht browserübergreifend identifizieren kann, ist der Browser für mich eine Visitoreigenschaft.
• Eine wichtige Benutzereigenschaft ist das Werbemittel, das ein Besucher benutzt hat, um auf die Website zu gelangen.

3. Visits

• Ein Visit braucht keine eigenen Daten im Tag selbst.
• Visit-Start und -Ende werden nicht im Tag, sondern im Backend markiert.
• Damit werden die Visitdaten auch aus den Besucher- und Seitendaten geholt.
• Eigene Tag-Bestandteile sind nicht nötig.

4. Produkte

Dazu gehören der Inhalt eines Warenkorbs, angesehene und gekaufte Artikel für Cross-Selling-Analysen etc.

• Eigenschaften dieser Artikel wie Farben, Größen und das Sortiment, zu dem es in meinem Shop gehört.
• Diese Eigenschaften sind wie die Besucher- und die Seiteneigenschaften nicht statisch, sondern müssen flexibel erweiterbar sein.
• Vielleicht will ich ja morgen einen Partner in meinen Shop integrieren und brauche dann eine Partner-ID am Produkt? Das Geschäft kann dann nicht auf die Web-Analytics-Lösung warten.

B) METRIKEN

• Alles, was ich irgendwie zahlenmäßig erfassen will, benötigt einen Zähler.
• Auch hier gilt: Beliebig erweiterbare Arrays mit Namen und Werten erscheinen geeignet.
• Informationen über die numerischen Datentypen und deren einzelnen Felder sollten im Backend hinterlegt sein und gehören nicht in ein Tag.

Grundsätzlich sollte man zwei Gruppen von Metriken unterscheiden:

1. Besuchermetriken: Wenn der Besucher zählbare Dinge tut, die nicht direkt mit Warenkorbinhalten zu tun haben, zum Beispiel Newsletterregistrierungen oder Klicks auf bestimmte Links, die zählenswert erscheinen. Sogar eine PageImpression oder ein Werbemittel-Clickthrough kann dazu gehören. Aber auch die Eindringtiefe in Conversion Funnels und Szenario-Analysen beliebiger Art sind damit möglich. Die Einstellungen zu den Szenarios gehört meines Erachtens ins Backend. Der Klarheit halber sollten sie im Visitor-Array mit untergebracht werden.

2. Produktmetriken: Hier werden Bestellungen, Stückzahlen, Preise einzelner Produkte im Warenkorb zugeordnet. Selbstverständlich scheint mir, dass sie an den entsprechenden Warenkorb-Positionen hängen sollten.

Fazit: Das eine Tag muss alles unterstützen, was die heutigen, herstellerspezifischen Tags in Summe abbilden. Ich bitte um eifrige Beteiligung, um die Liste abzurunden.

In einem weiteren Artikel werde ich mich mit den Themen Darstellung und Transport eines Universal Tags beschäftigen.

---

“One Tag to Rule them All” oder das Über-Tag

Wenn wir als Webanalyse-Unternehmen einen Wunsch frei hätten, dann wäre es doch ein faszinierender Gedanke, wenn man mit einem einzigen universellen Tag alle Tools der Web-Analytics Welt einheitlich bedienen könnte. Man müsste nur ein einziges Mal den Code erstellen und könnte beliebig die Hersteller wechseln, ohne erneut alle Seiten wieder anfassen zu müssen. Kunden fragen uns in der Tat immer mal wieder nach einer solchen Technologie. Allerdings haben die Hersteller leider aus technischen und lizenzrechtlichen Gründen einiges dagegen einzuwenden und wehren sich dagegen, dass alles simpel austauschbar wird. Im Blogbeaks Blog werden alle Argumente einer solchen Idee ausgetauscht.

Meiner Meinung nach besteht ein Weg zu diesem Ziel in der Erstellung eines Wrappers oder einer generischen API, der bzw. die die Spezifka der Hersteller-Scripts kapselt und diese an einer “neutralen” Schnittstelle anbietet. Bislang sind die Tools jedoch noch sehr unterschiedlich, was die Art des Taggings sowie Zahl und Form der Parameter betrifft. Darüber hinaus werden spezifische Codesnippets bereitgestellt, die allen möglichen Sinn und Unsinn im Client veranstalten, um Informationen zu generieren und zu speichern. Immerhin hat Stephane Hamel ein Tool namens WASP entwickelt, welches schon einmal über 70 Trackingtools in Websites erkennen und anzeigen kann.

Ich würde mir ein solches Tool als Open-Source-Software wünschen, damit eine unabhängige Lösung ermöglicht wird. Vielleicht sollten wir dazu pragmatischerweise ein Projekt in Sourceforge (oder freshmeat, savannah, gna!, google code, …) aufmachen und schauen, wer sich (mit uns) an eine solche Entwicklung herantraut. Wer macht den Anfang?

---