Aktivitätsanalysen für Web-Anwendungen

Bei der Entwicklung von Web-Anwendungen kann ein gut implementiertes Analytics-Rückgrat unglaublich nützliche Einsichten generieren. Dorthin zu kommen, kann für viele Unternehmen allerdings eine Herausforderung sein.

Bei einem der berühmtesten Projekte, an denen wir beteiligt waren, kam am Ende ein Mehrumsatz von 300 Millionen Dollar jährlich für eine große E-Commerce-Site heraus. Zu einem Teil hat auch das Studium der Analytics-Daten der Seite zu diesem Erfolg beigetragen. Allerdings war es nicht einfach, denn das Team hatte mehrere Fehler gemacht, zu denen es immer wieder kommt.

Es begann mit einem Muster, das aus User-Tests hervorging. Als wir Nutzern dabei zuschauten, wie sie ihre Produktauswahl beendeten und den Weg zum Checkout-System einschlugen, bemerkten wir, dass es an einer frühen Stelle im Prozess hakte, auf die niemand gekommen wäre.

Unser initialer Blick in die Analytics-Daten zeigte eine große Diskrepanz zwischen den Leuten, die Produkte in den Einkaufswagen gelegt hatten, und denjenigen, die den ersten Bildschirm des Checkouts erreichten. Das Team nahm an, viele Nutzer würden ihre Einkaufswagen einfach stehen lassen, weil sie doch keine Intention zum Kauf hätten. Wir führten unsere User-Test-Ergebnisse und die Analytics-Daten zusammen, um zu verstehen, was der tatsächliche Grund dafür sein könnte.

Dabei stellte sich heraus, dass die Kunden auf der ersten Seite des Checkout-Prozesses, der Anmelden-Seite, in Probleme gerieten. Und hier war der erste Fehler: Das Team hat die Sign-in-Page nie getrackt, sodass keine Daten für diese Seite gesammelt wurden. Darauf kamen wir erst, als wir sie in den Clickstream-Daten nicht finden konnten.

Wie sich herausstellte, waren auch die Passwort-vergessen-Seite und ihre Bestätigungsnachricht nicht integriert. Das taten wir nun und warteten ein paar Wochen ab, um valide Daten zu erhalten. Bald schon zeigte sich, dass die Anmelden-Seite nach der Homepage und dem Einkaufswagen die drittpopulärste Page war.

Leider fanden wir heraus, dass die Passwort-vergessen-Seite nun die am vierthäufigsten aufgerufene Seite war. Keine sehr gute, aber eine erhellende Nachricht.

Seitenbasierte Analytics-Tools schaffen mehr Probleme als Einsichten

Tools wie Google Analytics oder Webtrends sind sehr mächtig, wenn es um Content-Seiten geht, die User besuchen und sich dort auf weitere Seiten klicken oder die Website eben wieder verlassen. Diese Tools zeigen, welche Seiten die User aufrufen und in welcher Reihenfolge sie das tun.

Webbasierte Anwendungen sind heute allerdings komplexer. Wenn sie mit einem Ansatz wie model/view/controller implementiert sind, ist es nicht ungewöhnlich, dass eine "Page" mehr als einen einzigen Zweck hat. Eine einzelne Seite kann sich in Abhängigkeit des involvierten Views oder Models dynamisch ändern, obwohl es dieselbe Seite ist. In einem traditionellen Analytics-Tool wird diese Page ungenau ausgewertet, wir erhalten keine Einblicke in das, was tatsächlich vor sich geht.

Ebenso können diese Tools keine Non-Page-Interaktionen wie Lightboxen oder Popup-Dialoge registrieren. Für signifikante Teile der Nutzeroberfläche gäbe es keine Daten.

Im Endeffekt kann das Team den Berichten nicht trauen. Ist das Vertrauen in die Reporting-Daten einmal verloren, ist ihr Nutzen massiv geschmälert. Ein anderer Ansatz ist also nötig.

Aktivität tracken, nicht Seiten

Wir haben herausgefunden, dass die Teams, die den größten Nutzen aus ihren Analytics-Daten holen, diejenigen sind, die ihre eigenen Systeme bauen. Statt mit den HTTP-Logs des Web-Servers zu arbeiten, registrieren sie ihre eigenen Ereignisse – und zwar die, von denen sie glauben, dass es sich um die wichtigsten Aktivitäten handelt.

Der Wechsel auf ein aktivitätsbasiertes Logging-System eröffnet eine Welt voller Möglichkeiten. Nun können Sie spezifische Transaktionen und Datenabfragen tracken. Sie können festhalten, welchen Button auf der Seite die Nutzer als nächstes anklicken. Selbst für Rich-Interaction-Systeme können Sie wunderbare Ergebnisse sehen.

Dieser Ansatz lässt sich auf Multi-Device- und Mobile-Apps ausweiten. Da keine Bindung an Seiten mehr besteht, sondern an vom Team definierte diskrete Ereignisse, kann das Team sowohl die Informationen über Statusänderungen als auch die involvierten Daten sammeln.

Bei unserem E-Commerce-Team konnten wir exakt feststellen, wenn Nutzer Probleme hatten, sich an User-Namen und Passwort zu erinnern, indem wir alle Kombinationen registrierten, die sie eingaben. Obwohl sie zwischen mehreren Anmeldeversuchen die Seite nicht verließen, sahen wir, dass die meisten Nutzer, die sich nicht einloggen konnten, es mit mehreren User-Namen probierten.

Wir haben außerdem gesehen, dass viele User versuchten, sich mit ihren E-Mail-Adresssen anzumelden, obwohl das System diese als Account-Namen nicht unterstützte. Kurz: Wir kamen zu Einsichten, die mit einem seitenbasierten Analytics-Tool nicht möglich gewesen wären.

Die Fehler erfassen

Zu den wichtigsten zu trackenden Ereignissen gehören Fehlermeldungen, die die User erhalten. Client-seitige Validierung und asynchrone Kommunikation bedeuten, dass Natur und Frequenz eines jeden Fehlers für das Team rätselhaft sind.

Wenn wir aber jeden Fehler und die entsprechenden Daten, die ihn ausgelöst haben, registrieren, ist das sehr aufschlussreich. Wissen wir, welche Fehler am häufigsten auftreten, kann dies dem Team helfen, Problemquellen wie schlechtes Labeling oder ungenaue Erklärungen aufzudecken. Kommt es bei einer bestimmten Fehlermeldung zu einem plötzlichen Anstieg, könnte das bedeuten, dass eine jüngste Änderung eine wichtige Interaktion kaputt gemacht hat.

Die Transitionen einer Inventur unterziehen

Unlängst fragte uns ein Team, das eine Software für Systemadministratoren entwickelt, nach dem besten Weg zur Strukturierung der Menüs. Sie erzählten uns, dass ihre User – Sys-Admins – direkten Zugriff auf die über 750 Funktionen des Systems haben wollen. Einige ihrer Menüs waren zur Frustration der Nutzer sechs Ebenen tief. Die Frage lautete also: "Wie strukturieren wir die Menüs, wenn jeder augenblicklich überall hin will?"

Um ein Problem wie dieses zu lösen, muss das Team zwei Schlüsselfragen beantworten: “Was tun die User heute?” und "Was versuchen die Nutzer zu tun?" Eine gut implementierte Analytics-Lösung kann auch helfen zu identifizieren, was die Anwender wirklich mit der Applikation anstellen, und bringt Klarheit darüber, ob das, was die Nutzer sagen, überhaupt zutrifft.

Das Tracking aller Bewegungen durch die gesamte Applikation führte bald zu Resultaten. Das Team zeichnete jeden Weg eines jeden Nutzers zu einer Funktion auf und beobachtete zudem genau, welche Funktionen ausgelassen wurden. Im Endeffekt wurden sämtliche Pfade durch die Website getrackt.

Das Ergebnis war eine gigantische Transitions-Matrix mit allen Startbildschirmen oben und allen Zielfunktionen unten links. Das Team konnte sehen, wie häufig welche Funktionen von welchen Bildschirmen aus angesteuert werden.

Obwohl die User angegeben hatten, von überall auf jede andere Funktion zugreifen zu wollen, zeigten die Daten klar, dass die Nutzer das in der Realität gar nicht tun. Eine kleine Gruppe von Startbildschirmen war weitaus populärer als der Rest, und tatsächlich ergaben die in den ersten Wochen gesammelten Daten, dass mehr als 20% der Funktionen nie auch nur von einem einzigen User genutzt wurden, woraufhin das Team sich natürlich fragte, ob diese Features überhaupt noch nötig sind.

Die Analyse der wenigen sehr beliebten Startbildschirme ergab, dass die User von hier aus regelmäßig spezifische Funktionen ansteuern. Durch das Studium der populärsten Transitionen konnte das Team diejenigen Features identifizieren, für die es sinnvoll wäre, große und strahlende Buttons zu integrieren statt sie im Menü zu begraben. In einigen Fällen erwies es sich zudem als nützlich, die Funktionen zweier Bildschirme zu einer zu verschmelzen, weil die meisten Nutzer sie kombiniert ausführten.

Investitionen in Aktivitätsanalysen

Dies sind nur einige Beispiele für den Nutzen einer Investition in ein Analytics-System für kritische Aktivitäten in der Anwendung. Da Lösungen von der Stange natürlich nicht auf die spezifischen Arten von Interaktionen in einer individuellen Applikation zugeschnitten sind, muss das Team sich auf die Entwicklung eines eigenen Tools verständigen.

Es ist richtig, dass der beste Ansatz darin besteht, die Analytics-Plattform von Beginn an zu implementieren. Doch auch ein nachträglich eingepasstes System für spezifische Funktionalitäten ist den Aufwand wert.

Zusätzlich zur Programmierung muss das Team ein Data Warehouse aufbauen, um die Ergebnisse zu speichern, und eine Reporting-Lösung entwickeln, die die Daten extrahiert. Hier können wiederum Business-Intelligence-Werkzeuge von der Stange nützlich sein. (Sie werden die Pivot-Tabellen von Excel lieben lernen, ganz sicher!)

Am Ende führen die Ergebnisse, die das Team auf dem Tisch hat, zu dramatischen Verbesserungen der Applikation. Und das lohnt sich allemal.

Dieser Artikel wurde im Original am 15. November 2012 unter dem Titel Activity Analytics for Web Apps von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar