3 Beiträge kategorisiert in "Ziele"

11. Juni 11

Den "Website Performance Index" messen

In zwei vorausgegangenen Posts hatte ich bereits das Konzept des Website Performance Index in Analogie zu einem Börsenindex vorgestellt und dessen Berechnung und Herleitung der Metrik-Gewichtung beschrieben. Im dritten und letzten Teil geht es nun noch darum, wie sich ein solcher Index in einem Web Analytics System abbilden und fortwährend nutzen lässt.

Nutzung des Formel-Editors im Web Analytics Tool
Voraussetzung für die Hinterlegung einer relativ kompliziert berechneter Formel wie ein Performance Index ist ein Formel-Editor im Web Analytics System. Manche Systeme bieten solche Formeleditoren von Haus aus an, dann handelt es sich um eine relativ einfache Geschichte: Die bei der Berechnung definierten Ziele werden mit Ihrer Gewichtung im Formel-Editor hinterlegt - wie in unten stehender Abbildung im Beispiel von Webtrekk.

PerformanceIndex_1

Im Ergebnis lassen sich dann für den aktuellen Peformance Index zum Beispiel Graphen wie der folgende anzeigen, sobald diese noch mit Schwellwerten für die Zielerreichung (z.B. ab 50% im gelben Bereich, ab 75% im grünen Bereich) versehen werden.

PerformanceIndex_2

Für Google Analytics im Speziellen
Bei Google Analytics als das wohl meist eingesetzte Web Analytics Tool fehlt allerdings zur Zeit ein solcher Formel-Editor. Ein Performance Index lässt sich daher nicht in Google Analytics selbst abbilden, sondern muss in einem Drittsystem gehalten werden. Eine einfache Möglichkeit dazu ist Excel. Nutzt man ein Excel-Plugin wie Excellent Analytics lassen sich aktuelle Google Analytics Daten über das API auslesen und in Excel darstellen. Die Hinterlegung einer Formel ist dann nur noch einfache Excel-Handarbeit. Insbesondere wenn man Reports und Dashboard intern ohnehin per Excel aufbereitet und dann versendet, ist dies eine sehr handliche Möglichkeit. Auch schöne Gauge-Diagramme lassen sich mit etwas Excel-Tweaking gestalten wie unten stehendes Beispiel eines Excel-Reportings zeigt (andere Indizes):

PerformanceIndex_3

Wer den Website Performance Index lieber tagesaktuell und überall dabei haben möchte (was ja eigentlich auch die Idee eines solchen Indexes ist) und über ein iPhone verfügt, dem sei die kürzlich vorgestellte iPhone App "Dashboard pro for Google Analytics" nahe gelegt. Auch darin lassen sich die hinterlegten Google Analytics Ziele gewichten, danach wird der Performance Index automatisch und tagesaktuell berechnet.

IPhone_view_pro

28. April 09

Bedienbarkeit der Navigation mit Web Analytics auswerten

Besucher, die auf eine Website gelangen, können typischerweise zwei unterschiedliche Verhaltensmuster für die Informationsauffindung aufweisen: Sie nutzen die eingebaute Suchfunktion (Site Search), oder versuchen sich durch die hierarchische Navigation zum gewünschten Inhalt durchzuklicken. Die Qualität von Suche und Navigation kann daher stark ausschlaggebend sein, ob ein Besucher erfolgreich sein Ziel erreicht bzw. seine Aufgabe auf der Website erledigen kann - oder eben nicht.

Insbesondere auf eine verständliche und begrifflich trennscharfe Navigation wird daher bei der Website-Konzeption ein starker Fokus gelegt. Website-Konzeptionen, welche konsequent den User Centered Design-Ansatz verfolgen, testen solchen Navigationen sogar ausführlich in Usability-Labors mit Testnutzern. So stellt man zum Beispiel einem Tester die Aufgabe, einen bestimmten Inhalt zu finden und beobachtet dann sein Verhalten, wie direkt oder indirekt er über die Navigationseinträge zu einer entsprechenden Seite gelangt.

Während bei einem Website-Relaunch die Inhaltsstruktur noch optimal auf die Erkenntnisse aus den Usability-Tests angepasst ist, kann sich dies im Verlaufe der Zeit ändern: Neue Inhaltsseiten und Bereiche werden von Autoren auf der Website dazu gefügt, andere fallen weg. So kann schon wenige Monate nach dem Launch eine ursprünglich nutzerzentriert gestaltete Navigation überhaupt nicht mehr intuitiv bedienbar sein und Besucher können ihre Ziele nicht mehr erreichen. All paar Monate einen neuen Labor-Test zu machen kann sich auf der anderen Seite aber auch kaum ein Unternehmen leisten.

Broswer-Overlay und Klickpfade helfen nur bedingt

Als weitaus kosteneffizientere Massnahme als Labor-Tests mit Endnutzern würde sich hingegen Web Analytics anbieten, sofern es denn ein passendes Verfahren gäbe um die Bedienbarkeit einer Navigation zu messen. Web Analytics Systeme sehen für solche Fälle typischerweise zwei Instrumente vor:

  • Browser-Overlay
  • Klickpfade durch die Website

Omniture_BrowserClickchart

Das Browser-Overlay (im Bild ein Beispiel von Omniture) zeigt auf, auf welchen Navigationseintrag welcher Anteil an Benutzer geklickt hat. Etwas interessanter wird die Aussage, wenn zugleich noch eine Segmentierung der Nutzer vorgenommen wird: Wo klicken Nutzer, welche über eine Suchmaschine mit dem Keyword "XY" auf die Website gelangt sind, wo jene mit dem Keyword "YZ"? So lassen sich die typischen Navigationspfade von einzelnen Segmenten mittels Browser-Overlay nachvollziehen bzw. "nachklicken", das Verständnis wie die Nutzer denken und funktionieren wächst etwas. Die Klickpfade auf einer Website (zweiter Screen, ebenfalls Omniture) zeigen analog dazu eine aggregierte Ansicht solcher Pfade durch die Website.

Allerdings ist für die Fragestellung der Bedienbarkeit einer Navigation aus meiner Erfahrung weder das eine noch das andere wirklich praktikabel (für andere Fragestellungen schon). Das Grundproblem ist nämlich, dass man bei diesen Auswertungen nie weiss, ob der Besucher sein Ziel nun wirklich erreicht hat - oder ob er zwar den üblichen Pfad auf der Website eingeschlagen hat, vielleicht aber dann in ein paar Schlaufen über verschiedene Seiten umhergeirrt ist und anschliessend frustriert die Website verlassen hat. Genau dafür müsste es jedoch einen Indikator geben um zu entscheiden, ob die Navigation ihren Zweck erfüllt oder nicht.

Neuer Ansatz mit Funnels, Zielseiten und Events

Mein Ansatz nun, um genau dafür eine Antwort zu erhalten, ist ein anderer - und der benötigt weder Browser-Overlay noch Klickpfad-Auswertungen sondern die drei Komponenten Funnels, Zielseiten und Event-Tracking. Im Folgenden sei dieser Ansatz kurz vorgestellt und anhand eines Praxisversuches erläutert.

Als erstes versuche ich ein Verhaltensmuster von Benutzern zu identifizieren, welche die Navigation als primäres Instrument für die Auffindung von Information nutzen und schlussendlich ihre Website-Aufgabe erfolgreich abschliessen. Zur Vereinfachung reduziere ich die Betrachtungen einmal lediglich auf jene Besucher, welche von der Homepage aus starten - also ohne solche, welche über Suchmaschinen direkt auf ein hierarchisch in der Tiefe liegenden Seite einstiegen. Startet ein Besucher seinen Besuch also auf der Homepage und klickt er auf einen Navigationseintrag, gehe ich davon aus, dass er seine Aufgabe versucht über die Navigation zu lösen.

Der nächste und zugegebenermassen schwierigste Schritt ist es nun herauszufinden, ob ein solcher Besucher sein Website-Ziel erreichen konnte oder nicht. Ganz sicher herausfinden könnte man dies eigentlich nur, wenn man jeden Benutzer befragen würde - bei Web Analytics aber keine praktikable Vorgehensweise. Etwas Abhilfe schaffen da hingegen Feedback-Möglichkeiten wie im letzten Post zur Feedbackintegration vorgestellt: Bewertet ein Besucher einen Inhalt (z.B. eine FAQ-Antwort) als positiv, dann ist dies ein relativ klares Indiz dafür, dass er seine Aufgabe erfolgreich abschliessen konnte. Das Problem ist jedoch, dass wiederum nur ein marginaler Teil der Besucher überhaupt ein solches Feedback gibt - der grosse Besucheranteil bliebe dann eine Blackbox.

Geht man nun aber mal davon aus, dass es beim typischen Usertask darum geht, dass der Besucher eine bestimmte Information sucht, lässt sich auch schon die Betrachtungsdauer als Indikator für die erfolgreiche Auffindung einer Information herbeiziehen und damit folgende These aufstellen: Ein Besucher, der die Navigation über mehrere Klicks nutzt und irgendwann eine Seite über einen längeren Zeitraum betrachtet (d.h. wahrscheinlich liest), hat mit grosser Wahrscheinlichkeit über die Navigation sein Informationsbedürfnis erfolgreich befriedigen können. Ein Besucher, der hingegen nach mehrere Klicks in der Navigation die Website verlässt, ohne eine Information detaillierter zu lesen, hat wahrscheinlich sein Informationsbedürfnis nicht befriedigen können - die Navigation oder Website hat damit ihre Aufgabe schlecht erfüllt.  Alternativ zur Betrachtungsdauer könnten natürlich auch bestimmte Website-Ziele, z.B. die Kontaktaufnahme, der Download von Dokumenten usw. als Indikator für einen erfolgreichen Abschluss des Nutzerziels gewertet werden.

Messmethode für erfolgreiche Navigation

Glaubt man, dass solche Verhaltenmuster eine Aussage über die Qualität der Navigation machen - und das ist meine Überzeugung - , dann sind wir in einem Bereich, wo das Messen mittels Web Analytics-Methoden möglich wird. Mittels dem Einsatz sogenannter Events - welche im Web 2.0 den PageView verdrängen - lässt sich nämlich das genannte Verhaltensmuster wie folgt abbilden:

  • Besucher, welche auf der Homepage einsteigen und auf die Navigation klicken, lösen einen ersten Event "Navigationsnutzer ab Homepage" aus. Den Klick auf die Navigation kann man mittels einem kleinen JavaScript-Code abfangen. Beim Einsatz von Google Analytics schickt man ihn anschliessend mittels pageTracker._trackEvent('Navigation', 'Nutzung ab Homepage'); zu Google.
  • Derart klassifizierte Besucher, welche nun mindestens zwei oder drei Mal in der Navigation klicken, kann nun als "Informationssucher via Navigation" klassifizieren. Die Mehrfachklicks findet man wiederum heraus, indem man die Klicks auf die Navigation mittels eines kleinen JavaScripts überwacht und die Klickzahl in einem Cookie speichert. Nach zwei oder drei Navigationsklicks erfolgt die Übergabe an das Tracking-System, z.B. in Google Anlytics mittels pageTracker._trackEvent('Navigation', '2 Clicks');
  • Wenn nun solche User eine Inhaltsseite während z.B. mindestens 45 Sekunden betrachten, wird ein weiterer Event ausgelöst, z.B. via pageTracker._trackEvent('Navigation', 'Erfolgreich abgeschlossen'); . Wie man dies genau messen kann würde erst kürzlich hier im Post "Tod dem Page View" erläutert.

Der gesamte JavaScript-Code, wie so etwas mit Google Analytics aussehen kann, findet sich hier. Natürlich muss man den Code etwas auf seine Website bzw. Navigation adaptieren, damit er die betreffenden Klicks trackt, grundsätzlich ist er aber sehr generisch gehalten.

Auswertungen zur Navigation richtig interpretieren

Soweit die Theorie, und nun zu dem was uns die Auswertungen in einem Praxisbeispiel zeigen: Die Auswertung der Events mittels Balkengrafik gibt uns so etwas wie ein Funnel für die Nutzung der Navigation und zeigt uns den anteilmässigen Ausstieg der Nutzer während der Navigationsbedienung an.

NavigationEvents

In Google Analytics wird das Bild noch etwas deutlicher, wenn man zu den Events hinzu noch PageViews trackt, so dass sich ein echter Goal-Funnel abbilden lässt:

NavigationFunnel

Im Beispiel lässt sich so herauslesen, dass offenbar nur etwas mehr als ein Drittel der Nutzer - welche die Navigation als primäres Informationsfindungsinstrument nutzen - schlussendlich auch erfolgreich die Information über die Navigation finden. Rund zwei Drittel der User hingegen brechen ab, ohne ihren Task erfolgreich abzuschliessen.

Benchmarking und Slicing&Dicing

Solche Zahlen sind nun wohl ein relativ alarmierendes Signal für die Qualität einer Navigation. Allerdings, bevor man nun in Panik ausbricht bei solchen Auswertungen, sollte man zuerst noch einen Benchmark zu Rate ziehen, um ein Gefühl dafür zu bekommen was denn nun gut, mässig oder ein schlechter Wert für so eine Auswertung ist. Und da es diese bei solch neuen Ansätzen noch nicht gibt, hilft nur das Benchmarking gegen sich selbst: Im Idealfall schaut man zurück, wie dieses Verhältnis gleich nach dem Website-Launch ausgeschaut hatte, als die Struktur der Site noch der im Usability-Labor getesteten entsprach. Diesen Wert kann man dann als optimale Zielgrösse nehmen und versuchen über die Zeit zu halten oder gar zu verbessern. Damit lassen sich auch kleine Anpassungen an der Navigationsstruktur vornehmen und gleich in den Analytics-Auswertungen verifizieren, ohne dass man einen kompletten und teuren Labor-Test fahren muss.

Stellt man anhand so eines eigenen Benchmarks fest, dass tatsächlich eine Verschlechterung eingetroffen ist, folgt das übliche Nachforschen in den Web Analytics Tiefen: Besteht irgendein Muster, nach welchen die Navigationsbedienung häufig abgebrochen wird? Vielleicht lässt sich so dann erahnen, nach was für Informationen ein Besucher gesucht haben könnte, bevor er das Unterfangen abbrach. Und wenn auch das nichts mehr hilft, dann muss halt trotz allem auf die User Centered Design Methodiken zurückgreifen: Den Besucher direkt mit Umfragen oder im Test befragen. Ich bin aber überzeugt, dass man mit dem eben vorgestellten Ansatz sehr viel auch schon rein aus dem Analytics-System herauslesen kann und auf ein allzu häufiges Testen im Labor verzichten und einiges an Geld einsparen kann.

23. März 09

Tod dem PageView: Gelesene Seiten statt Seitenaufrufe messen!

Nachdem die "Hits" schon lange den Web Analytics Tod gestorben sind, ist nun auch der PageView langsam aber sicher am Ende seines Lebens angelangt. Heutige Anwendungen wie Bewegtbild, Kartenanwendungen, Rich Internet Applications können mit dem PageView-Modell schlichtweg nicht mehr sinnvoll gemessen werden. Aber auch sonst gibt es kaum noch ein Anwendungsfall, wo die PageView-Messung zielführend wäre - mit Ausnahme vielleicht von Portalseiten, welche noch Banner auf PageView-Basis verkaufen können.

Was bei einer zielorientierten Nutzung von Web Analytics mehr interessiert, ist ob die gesteckten Ziele erreicht wurden bzw. Conversions erfolgt sind. Je nach dem Website-Ziel, das man sich gesteckt hat, kann eine Conversion auch sein, dem Besucher bestimmte Werte vermittelt zu haben. Angenommen ein Unternehmen verfolgt mit der Website hauptsächlich ein Branding- oder Kommunikations-Ziel - was beim Grossteil der Grossunternehmen der Fall sein dürfte - dann kann es zweckmässig sein, das Lesen bestimmter Inhalte als Conversion zu definieren. Liest ein Besucher wirklich einen Unternehmensbeschrieb, Key Figures oder das Interview mit dem CEO, dann kann man durchaus sagen, das dadurch bestimmte Werte vermittelt und ein Stück weit das Ziel der Website erreicht wurde. Nur, der PageView sagt relativ wenig darüber aus, ob eine Seite nun wirklich gelesen und somit die Message rübergebracht wurde - oder ob die Seite lediglich kurz angeklickt und überflogen, oder direkt wieder verlassen wurde.

Abhilfe schaffen hier sogenannte "Events", die designierten Nachfolger und Ablöser des PageViews. Ein Event ist ein Ereignis, das in einer bestimmten Situation eintritt, z.B. wenn der Benutzer auf einen Link klickt, einen Film startet oder in eine Kartenanwendung hinein- oder herauszoomt. Genau so wie sich Rich Internet Applications und Movies damit messen lassen, können Events auch für die feinere Messung von anderen Website-Zielen eingesetzt werden. Im konkreten Fall eines Kommunikations- und Branding-Ziel ist es mein Vorschlag, das Lesen einer Seite dadurch zu messen, ob eine Seite ausreichend lange betrachtet wurde. Braucht man zum schnellen Lesen des CEO-Statements zum Beispiel 45 Sekunden, dann sollte man einen Event definieren, der sich nach dieser Zeit automatisch auslöst. Um die Messung nicht zu verfälschen, darf die Stoppuhr natürlich nur laufen, solange sich die Seite auch wirklich auf dem Bildschirm befindet und nicht durch irgendwelche andere Fenster überdeckt wird.

Zu kompliziert für ein einfaches Web Analytics System? Nein. Folgendes kleine Script (jetzt wirds etwas technisch) zeigt, wie man dies in Google Analytics lösen kann:

Im <body>-Tag der betreffenden Seite folgendes unterbringen:

<body onunload="calculateViewDuration()" onblur="stoppingTime()" onfocus="startingTime()">

Dies ist die eigentliche Stoppuhr, welche läuft, solange sich die Seite im Vordergrund des Bildschirms befindet.

Im <head>-Bereich der gleichen Seite folgendes Skript unterbringen:

<script type="text/javascript"> 
 
var start;
var startTime;
var eventFired = 0;
var eventTracked = 0;
var duration = 0;
var diffTime;

startingTime();

function startingTime() {
 start = new Date();
 startTime = start.getTime();
 eventFired = 0;
}

function stoppingTime() {
 var end = new Date();
 var endTime = end.getTime();

 diffTime = Math.floor((endTime - startTime) / 1000);
 
duration +=  diffTime;
}

function calculateViewDuration () {
 stoppingTime();
 if (eventFired == 0)
 {
   eventFired = 1;
   if (duration > 44 && eventTracked == 0)
   {
     eventTracked = 1;
     pageTracker._trackPageview('/events/View45Sekunden');
   }
  } 
}

</script>

Die Funktion calculateViewDuration() wird ausgelöst, sobald der Benutzer das Browserfenster schliesst oder auf eine andere Seite surft. In dem Moment wird der Event ausgelöst, falls dies Seite mindestens 45 Sekunden betrachtet wurde. Im obigem Fall wird mittels pageTracker._trackPageview('/events/View45Sekunden');ein virtueller Seitenaufruf an Google Analytics gesendet. In der Auswertung sieht das dann wie folgt aus:

PageView_Tracking 

Hinterlegt man den Seitenaufruf als Ziel in der Analytics-Konfiguration, dann lassen sich auch Conversions damit abbilden:

Goal_Tracking

Zugegebenermassen ist dies noch etwas eine Krücke, da ein Event somit trotzdem als eigentlicher Seitenaufruf im Analytics System endet, wenngleich es sich um einen Event und keinen Seitenaufruf handelt. Empfehlenswert ist daher, diese virtuellen Seitenaufrufe in einem ebenfalls virtuellen Verzeichnis "/events/" abzulegen, wie im obigen Beispiel gezeigt. Somit lassen sich sich einfacher in den Auswertungen finden und anschliessend auswerten. Google hat scheinbar auch gemerkt dass das nicht ganz so intelligent ist für die Event-Messung und führt deshalb in Kürze einen eigenen Abschnitt in der Content-Auswertung ein, welcher für Events reserviert ist (momentan nur als Beta und auf Antrag in Google Anlytics verfügbar). Damit lassen sich dann Events wie der obige über folgenden Aufruf tracken: pageTracker._trackEvent('Seitenbetrachtung', 'CEO Statement', '45 Sekunden'); In der Auswertung wird dies dann wesentlich eleganter und wie folgt aussehen:

Event_Tracking

Wer ein solchen Event-Tracking im Einsatz sehen möchte: Ganz einfach den Quellcode dieser Seite anschauen. Denn auch für Blogs ist eine solche Messung wesentlich zielführender als der sterbende PageView!


Über das Blog | Impressum | Nutzungsbedingungen | Ihren Besuch aufzeichnen [?]


Web Analyticson


Das Buch zum Blog:

  • Buch
    Details zum Buch Buch bei Amazon.de bestellen

Die App zum Blog:

  • iPhone App
    Download

Über den Autor

  • Marco Hassler ist Business Unit Manager und Partner beim IT- und Web-Dienstleister Namics.

    marco.hassler (at) gmail.com

Ethik Code

  • Web Analytics Association Code of Ethics

Twitter Updates

    Web Analytics Fotos

    Web Analytics Association

    • Web Analytics Association