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.

---