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.

Darum lösche ich keine Cookies

Aus Datenschutzgründen wird Internet-Nutzern immer wieder geraten, sie sollten doch die “gefährlichen Cookies” in ihren Browsern löschen, diese auf keinen Fall akzeptieren und überhaupt alles Erdenkliche anstellen, um diese von der Festplatte zu radieren. Das ist bestimmt gut gemeint und im Sinne einer Anonymisierung und des Schutzes der Privatsphäre auch superkorrekt!

Aber ich bekenne: Ich gehöre zu den Verweigerern dieser Ratschläge - ich lösche keine Cookies. Aktuell habe ich rund 500 Cookies auf meinem PC. Und es ist mir egal, von wem und warum die dort sind. Ich lösche sie nicht und lasse sie, wo sie sind. Im Gegenteil: Ich habe sogar meinem Virenscanner und meinem CCleaner beigebracht, Cookies nicht zu löschen.

Der Grund ist ein ganz einfacher: Ich mag es, wenn man mich auf einer Website wiedererkennt - genauso, wie ich es mag, wenn mich die  Bäckereifachverkäuferin morgens begrüßt. Ich würde nicht auf die Idee kommen, solche Läden mit Verkleidung zu betreten, jeden Morgen mit einer anderen, damit ich um Gottes willen nicht wiedererkannt werde. Kurzum: Ein bisschen Eitelkeit darf sein, deshalb lösche ich meine Cookies nicht.

Zugegeben, das klingt etwas pathetisch, aber es ist einfach an der Zeit, mal etwas Gutes über Cookies zu sagen. Es sind kleine Helfer, die viele Dinge im Internet einfacher und bequemer machen:

• Man wird automatisch auf Websites eingeloggt.
• Websites speichern individuelle Einstellungen in Cookies und ich muss nicht jedesmal neu konfigurieren.
• Shops wissen, was ich mag und bieten mir interessante Dinge an.
• Ich genieße Einkaufsvorteile, weil ich einen Cookie besitze und der Shop mich als Stammkunden wiedererkennt.
• Websites tauschen untereinander Daten aus und Social-Media-Applikationen “sprechen” untereinander, weil ich deren Cookies akzeptiere.

Cookies wurden weder von der CIA, noch von der NSA und schon gar nicht vom BND erfunden, sondern von Site-Betreibern und Webserver-Programmierern, die einfach wissen wollen, wer da virtuell vor ihnen steht. Diese erfahren auch nichts “von mir”, sondern lediglich über mein Internet-Benutzungsverhalten, also einen recht schmalen und einseitigen Ausschnitt meiner “Persönlichkeit”.

Für wesentlich “gefährlicher” halte ich Rabattkartensysteme, weil sie in der Lage sind, mein gesamtes Offline-Verhalten lückenlos nachzuvollziehen. Damit habe ich tatsächlich ein Problem, und darum besitze ich keine einzige dieser Karten.

Also, liebe Rabattkarten-Besitzer: Macht bitte nicht so viel Getöse um die angebliche Schädlichkeit von Cookies, diese haben aus meiner Sicht einen berechtigten Daseinszweck.

Im Übrigen kennt die oben erwähnte Bäckereifachverkäuferin die Größe meiner Familie, deren Essgewohnheiten, die Anzahl Autos und deren Marken sowie die Zahl unserer Fahrräder. Und sie weiß, wie viele Kreditkarten ich besitze. Sie weiß auch, dass ich selten Kekse kaufe. Und das alles ganz ohne Browser-Cookies.

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.

Regelmäßiges Vertster Webinar - Mehr Erfolg durch Marketingeffizienz

Wer Online-Erfolgskontrolle heute professionell betreibt, kommt um das Thema Testen nicht mehr herum. Als exklusiver Partner von Vertster in D/A/CH möchten wir Sie einladen, die Vorteile von Vertster kennen zu lernen.

Erster Termin: Webinar 1: Donnerstag, 3. Dezember 2009, 16:00 bis 16:45 Uhr

Regelmässiges Vertster Webinar - jeweils letzter Donnerstag im Monat ab 16:00 Uhr:

• Webinar 1: Was ist Vertster, was sind A/B Tests - Beispiel A/B Test
• Webinar 2: Was ist Vertster, Auswertung eines A/B Tests
• Webinar 3: Was ist Vertster, was sind MV-Tests, Beispiel MV-Test
• Webinar 4: Was ist Vertster, Auswertung eines MV Tests mit Vertster

Nächstes Webinar: Donnerstag, 28. Januar 2010; 16:00 bis 16:45 Uhr

Zugangsdaten zum Webinar:

Laden Sie sich die Präsentationssoftware von nachfolgendem Link herunter, speichern sie diese und starten sie den Präsentations-Client

Geben Sie dann im Eingangsdialog die folgenden Zugangsdaten ein:

Sitzungsnummer:   761830

Sitzungspasswort: vertster

An der parallel stattfindenden Telefonkonferenz nehmen Sie teil, indem sie eine der nachfolgenden Nummern anwählen

Deutschland: 01805-007644 (14 ct/min)

Österreich: 0820-40001578 (12 ct/min)

Schweiz: 0848-560198 (12 Rp./min)

contentmetrics - Service und Software aus einer Hand

Nutzen Sie die Vorteile der Testing-Software Vertster und unsere Erfahrung: einfache Handhabung - flexible Vertragslaufzeiten - einfaches Abrechnungsmodell nach Testteilnehmer sowie die Unterstützung durch das contentmetrics-Team, erhöhen Ihren Erfolg im Marketing nachweislich!

Wir freuen uns auf Sie!

Einfache A/B und multivariate Tests - contentmetrics übernimmt exklusive Vermarktung von Vertster

Ab sofort ist contentmetrics exklusiver Vermarkter von Vertster, einem Tool für A/B und multivariate Tests des US-Unternehmens U-Pro, in Deutschland, Österreich und der Schweiz. Zudem unterstützt contentmetrics die Anwender des Produkts im D/A/CH-Gebiet durch Consulting und Support-Dienstleistungen.

Wir sind sehr stolz auf die Zusammenarbeit mit U-Pro, denn Vertster ist eine extrem leistungsstarke SaaS-Lösung (Software As A Service, ASP), mit der Websites optimiert und die Marketingeffizienz erhöht werden kann. Daher stellen wir Vertster in diesem Blogbeitrag näher vor:

Vertster bietet standardmäßig folgende Testvarianten an:

• Baseline Testing
• URL Split-Testing
• A/B Split-Testing
• Multivariates Testing mit und ohne Taguchi Methodik

Vertster lässt sich ohne kompliziertes Programmieren leicht in Websites integrieren. Somit können Online-Marketing und Product-Management selbstständig - also unabhängig von IT-Ressourcen und Website-Deployments - Kampagnen steuern und beliebige Website-Inhalte und Rezepte austauschen.

Vertster ist mandantenfähig und eignet sich daher für Agenturen, die im Auftrag ihrer Kunden mehr Effizienz im Marketing erreichen wollen. Zudem können Agenturen das User Interface von Vertster ihrem Corporate Design anpassen.

Die Abrechnung erfolgt auf Basis der Testteilnehmer (Unique Visitors) - und nicht wie bei vergleichbaren Produkten nach Anzahl der ausgelieferten Rezeptseiten (Pageviews) und Werbemittel. Anwender, Betreiber und Marketiers können dadurch im voraus wesentlich genauer kalkulieren.

Für alle Interessenten, die Vertster kennenlernen möchten, bietet contentmetrics Leistungspakete für kurze Zeiträume und kleine Volumina in kalkulierbaren Modellen an. Erste Produktinformationen sind verfügbar über www.vertster.eu oder treten Sie direkt mit uns in Kontakt.

Übrigens: Der Name “Vertster” setzt sich zusammen aus den Begriffen “conVERT und teSTER“.

contentmetrics führt REQB-System für methodisches Anforderungsmanagement ein

Website-Betreiber sind ständig gefordert: Ununterbrochen müssen sie ihre Online-Angebote den geänderten Bedingungen des Marktes und dem Verhalten der Besucher und Nutzer anpassen. Das Gleiche gilt für Web-Analytics-Lösungen - auch diese müssen jederzeit den neuen Anforderungen und Veränderungen entsprechen. Die dazu nötige Wachsamkeit ist eine sehr anspruchsvolle Aufgabe, die viele Unternehmen allein nicht meistern können.

Um unsere Kunden dabei zu unterstützen, haben wir nun das Anforderungs- und Change-Management-System “Contour” eingeführt - ein System zur software-gestützten Erfassung und Speicherung von betriebswirtschaftlichen, technischen und nicht-funktionalen Anforderungen. Hierbei setzt contentmetrics REQB-Methoden (des “Requirements Engineering Qualifications Board”) ein. Diese gewährleisten hohe Qualität bei gleichzeitiger Transparenz und Nachverfolgbarkeit - insbesondere diese ist in Web-Analytics-Projekten von entscheidender Bedeutung. Unsere Berater wurden dazu in methodischem Requirements Engineering und Management geschult und zertifiziert (REQB® Certfied Requierements Engineer).

Die Vorteile des REQB-Verfahrens und “Contour”:

• Langfristig garantiert diese methoden- und toolgestützte Vorgehensweise über einen langen Zeitraum den Support der von uns entworfenen Lösungen sowie das Change Management .

• Durch den direkten Web-Zugang wird eine direkte Kollaboration aller Projektbeteiligten in einem zentralen Repository auch von unterschiedlichen Standorten aus möglich. Eine Systemprotokollierung und reversible Versionierung aller Elemente sorgt für eine lückenlose Nachvollziehbarkeit.

• Neben einer Erhöhung der Effizienz aller Projektbeteiligten wird bei der Erarbeitung der Anforderung und der Erstellung der notwendigen Konzepte eine qualitative Verbesserung der Projektergebnisse erreicht.

• Ein Problem der Web Analytics - die langfristige Nachvollziehbarkeit von Änderungen und Anpassungen - kann direkt gelöst werden. So ist es nicht erforderlich, dass Kunden über eigene Excel-Listen ihre betriebswirtschaftlichen und technischen Anforderungen aktuell halten. Stattdessen werden die Anforderungen und deren Änderungen - auch losgelöst von uns - direkt ins Repository eingepflegt und können in austauschbaren Formaten (MS Office, PDF) kommuniziert werden.

Unsere Kunden könnten sich direkt auf unserer Website anmelden. Wer noch keinen Zugang hat oder das Passwort vergessen hat, kann sich gerne direkt an seinen Projektleiter bei contentmetrics wenden.

Neues Referrer-Tracking in der Google Suche

Wie in einigen Blogs gepostet, beginnt Google mit dem Roll Out einer technischen Änderung bei den Referrern der geklickten Suchergebnisse. Der Referrer erhält in Zukunft die Ziel-URL sowie die Position des geklickten Suchergebnisses als Parameter. Darüber hinaus kann jeder anhand der Referrer URL erkennen, ob es sich um ein gesponsorten Link (Adword) oder um ein “natürliches Ergebnis” der Suche handelt.

Beispiel für die Referrer-URLs von Google:

Bisherige Referrer-URL:

http://www.google.com/search
hl=en
q=flowers
btnG=Google+Search

Neue Referrer-URL:

http://www.google.com/url
sa=t
source=web
ct=res
cd=7
url=http%3A%2F%2Fwww.example.com%2Fmypage.htm
ei=0SjdSa-1N5O8M_qW8dQN
rct=j
q=flowers
usg=AFQjCNHJXSUh7Vw7oubPaO3tZOzz-F-u_w
sig2=X8uCFh6IoPtnwmvGMULQfw

Dies hat insofern Auswirkungen auf die Web Analytics Tools, als dass diese normalerweise die Referrer Informationen dazu benutzen, Statistiken über Suchwörter je Suchmaschine zu erstellen. Dazu muss der URL-String analysiert und ausgewertet werden. Sofern Annahmen an das derzeitige Format gemacht werden, kann es bei diesen Tools zu Problemen kommen, die sich ein einem vermeintlichen Abfall der Zugriffszahlen über natürliche Suche bemerkbar machen.

Da Google den Roll Out über seine dezentrale Infrastruktur durchführt, kann es in einer Übergangszeit dazu kommen, dass sowohl altes als auch neues Format bei einer Website auftreten werden und zu diesem Effekt führen, wenn das Web Analytics Tool darauf nicht vorbereitet ist. Wer jedoch Google Analytics nutzt, braucht sich darüber keine Gedanken machen. Die neuen Referrer-URLs werden auf die GA-Reportings keine Auswirkung haben.

Im Weiteren ist es spannend zu beobachten, wann die ersten Hersteller ihre Produkte dahingehend angepasst haben, dass die jetzt zusätzlichen Informationen (Position, Art des Ergebnisses, in der Beispiel URL oben fett markiert) auch in den Statistiken verwendet werden.

>> Google Analytics Blog
>> Callmetrics Blog

Virtuelle Besucher: Die Geister, die Safari rief

Nicht jeder Besuch einer Website ist erwünscht. Schließlich verfolgen Sie mit Ihrer Website immer auch einen Zweck. Entweder Sie verdienen als Verlag Geld mit Online-Anzeigen oder Sie stellen Ihre Produkte oder Dienstleistungen dar und versuchen, über Ihre Inhalte Kunden anzusprechen. Doch was machen Sie, wenn Browser Geisterbesuche initiieren? Eine Webanalyse sollte eigentlich deutlich machen, wie erfolgreich Ihre Conversion Rate ist. Einen digitalen Strich durch Rechnung macht Ihnen hierbei jedoch der Browser Safari 4, der “virtual Visits” von Websites verursacht. Durch die neue Funktionalität einer “CoverFlow” - artigen Darstellung von Seiten aktualisiert der Safari-Browser automatisiert im Hintergrund die Seiten, die der Onliner kürzlich besucht hat.

Um die für den Safari-Nutzer durchaus praktischen Voransichten der Seiten zu aktualisieren, “besucht” Safari 4 die Webseiten immer mal wieder in unregelmäßigen Abständen, mindestens aber,  wenn die CoverFlow-Ansicht der Bookmarks geöffnet wird.

Dies führt zu einer Erhöhung der Bounce Rate und einer Senkung der Conversion Rate. Leider gibt es derzeit keinen vernünftigen Weg, die “Geisterbesuche” des Safari 4 in irgendeiner Weise übersichtlich darzustellen.

Inwieweit dies tatsächlich einen entscheidenden Einfluss auf die Statistik hat, ist angesichts eines Browseranteils von derzeit hierzulande gerade einmal 2 - 3 Prozent Safari-Nutzer noch zu beobachten. Da wiederum nur ein (noch) geringerer Teil auf die neue Version 4 entfällt, ist der Effekt sicherlich  vernachlässigbar, sollte aber beobachtet werden.

>> The Data Driving Blog: Safari 4 Beta distorts Web Analytics
>> Formatur: Web-Analytikers Albtraum: Safari 4 Beta

Schrödinger und Heisenberg in der Web Analytics

In vielen Kundenprojekten kommt mitunter der Punkt, an dem ein Vertreter des Kunden sinngemäß folgende Frage stellt: “Beeinflusst die Instrumentierung der Seite mit einem Zählmechanismus die Ladezeiten und damit die Usability - und wäre es deshalb nicht besser, darauf zu verzichten?”

Ich fühle mich angesichts dieser Frage immer in meine Abiturzeit zurückversetzt, als wir Heisenbergs Unschärferelation und das wohl umstrittenste Gedankenexperiment der Elementarphysik - Schrödingers Katze - durchnahmen. Denn die vom Kunden gestellte Frage folgt der gleichen “Logik”.

Fangen wir von ganz vorne an, um die Gemeinsamkeit zu zeigen:

1. Ein Betreiber hat eine Website, die er nicht misst. Er hat deswegen keine Erkenntnis über Reichweite, Performance oder Conversion Rates.

2. Es werden Programmzeilen hinzugefügt, damit sie Auswirkungen haben. Der Einbau solcher Messfunktionen wird das Verhalten der Site modifizieren. In welcher Form, ist zunächst nicht relevant.

3. Als Folge erhält der Website-Betreiber nun die in Punkt 1. erwähnten Erkenntnisse etwa zu Reichweite, Performance und Conversion Rates.

Interessant ist hierbei nun die Behauptung, dass eine solche Messung nicht genau sei und das eigentliche - unbekannte - Messergebnis ohne Messung immer besser sei. (Zu diesem Schluss kommt im Übrigen auch die hier im Blog vorgestellte CMS Watch Studie.)

Genau das besagt die Heisenbergsche Unschärferelation: Vereinfacht ausgedrückt, verändert die Messung das Experiment (3. Theorem). Andererseits: Ohne Messung erhält man gar keine Aussage - das ist wiederum die Logik aus Schrödingers Katze, die gleichzeitig tot und lebendig ist.

Ein Dilemma der Web Analytics - gibt es eine pragmatische Lösung?

Natürlich ist das Nicht-Messen keine Alternative zum Messen. Man muss jedoch die “Nebenwirkungen” durch sorgfältige Programmierung überschaubar klein halten und sich über die Tatsache im Klaren sein, dass es tatsächlich zwischen Messung und Realität Abweichungen gibt. Diese Abweichungen können im Übrigen in der Praxis recht gut eingegrenzt und beziffert werden.

Zudem ist nach der Implementierung eines Tools eine Phase notwendig, die wir “Eichung” oder “Validierung” nennen. Dabei konzentriert man sich auf einfache Metriken (z.B. PIs, Visits, Visitors) und versucht diese anhand anderer Messsysteme (Ad Server, …) oder den Backends zu plausibilisieren. Dabei hat sich die Faustregel als hilfreich erwiesen, dass alles unter einer 10%-Abweichung für statistische Aussagen und Bewertungen irrelevant ist. Oder wie Avinash Kaushik in einem seiner Vorträge einmal gesagt hat:

Reporting = the art of finding 3 errors in a thousand rows
Analysis = the art of knowing 3 errors in a thousand are irrelevant
Or: the evolution of Reporting Squirrels into Analysis Ninjas

Bleibt die Frage: Reporten Sie noch oder analysieren Sie schon?

Methodengestütztes Web Analytics Enabling

Die Einführung von Web Analytics Lösungen in Unternehmen ist eine interdisziplinäre Aufgabe zwischen Marketing/Vertrieb, IT Abteilung und Web Verantwortlichen. Die Vielzahl der Projekte, deren Komplexitätsgrad sowie die Änderungshäufigkeit zwingen dabei immer zu methodengestützten Arbeiten bei der Erfassung und Strukturierung der Anforderungen an ein Web Analytics System.  Damit wir Sie erfolgreich dabei unterstützen können, haben wir unsere Berater in methodischem Requirements Engineering und Management geschult und zertifizieren lassen (REQB® Certfied Requierements Engineer), damit Sie gewohnte Qualität von uns erhalten.

Demnächst werden wir ein System zur Software-gestützten Erfassung von Anforderungen aufsetzen und einführen. Dadurch können Sie die betriebswirtschaftlichen, technischen und nicht-funktionalen Anforderungen systematisch erfassen und nachvollziehbar speichern. Langfristig garantiert diese methoden- und toolgestützte Vorgehensweise den Support der von uns entworfenen Lösungen ebenso wie das Change Management über einen langen Zeitraum.

Unseren Kunden und Partnern ermöglichen wir künftig den Web-Zugang zu dem System, sodass eine direkte Kollaboration aller Projektbeteiligten innerhalb eines zentralen Repositories auch von unterschiedlichen Standorten aus möglich wird. Dass hierbei auch eine Systemprotokollierung und reversible Versionierung aller Elemente für eine lückenlose Nachvollziehbarkeit gegeben ist, ist fast schon selbstverständlich.

Neben einer Erhöhung der Effizienz aller Projektbeteiligten wird durch diese Vorgehensweise bei der Erarbeitung der Anforderung und der Erstellung der notwendigen Konzepte eine sichtbare qualitative Verbesserung der Projektergebnisse erreicht. Eines der Probleme von Web Analytics Lösungen - die langfristige Nachvollziehbarkeit von Änderungen und Anpassungen - kann auf diese Weise ebenfalls für unsere Kunden direkt gelöst werden. So ist es nicht erforderlich, dass Kunden versuchen über eigene Excel - Listen ihre betriebswirtschaftlichen und technischen Anforderungen aktuell zu halten. Statt dessen werden die Anforderungen und deren Änderungen - auch losgelöst von uns - direkt ins Kundenrepository eingepflegt und können in austauschbaren Formaten (MS Office, PDF) weiter kommuniziert werden.