Warum ich keine Pathing Reports benutze [Update]

Von | 2. April 2013

SiteCatalyst hat eine ganze Reihe von Reports, die sich um Pathing drehen. Pathing ist letztendlich das, was früher in der Sesamstraße als „Was passiert dann?“ auftrat, es geht also um eine zeitliche Abfolge von Aktionen.

Ich habe schon öfter durchblicken lassen, daß ich Pathing Reports für unnütz halte, mit ein paar Ausnahmen, siehe weiter unten.

Heute möchte ich erklären warum.

[Update] Dank des Kommentars von Andre habe ich das jetzt doch nochmal gegengetestet. Und er hat recht! Damit sind jetzt viele Stellen in diesem Artikel falsch und ich habe sie daher durchgestrichen. Merke: niemals darauf verlassen, daß man etwas weiß. Jedenfalls nicht, wenn man nicht mehr weiß, warum und woher man es zu wissen meint. Mea culpa.

Richtig – Funnels

Grundsätzlich möchte man nicht nur wissen, wann oder daß Benutzer bestimmte Aktionen auf der Website ausgeführt haben, z.B. Dinge kaufen, Content sharen oder Newsletter abonnieren. Das tun nur vergleichsweise wenige Benutzer, daher ist es um so interessanter zu sehen, wie weit die anderen Benutzer gekommen sind, bevor sie dann die Aktionen eben nicht getan haben.

Bestes Beispiel: Bankenwebseite möchte, daß möglichst viele Besucher online ein Konto eröffnen. Dazu gibt es auf der Website einen Prozess, den Besucher durchlaufen können. Viele der Besucher brechen mittendrin ab. Die Analyse dieser Besucher kann vielleicht helfen, den Prozess zu verbessern oder gar das Angebot selber.

Dafür benutzt man am besten einen Funnel.

Bemerkenswert viele Webanalysten versuchen sich an einer Analyse per Path oder Fallout, aber:

Dafür benutzt man am besten einen Funnel.

Warum?

Ein Funnel benutzt Success Events ganz ähnlich wie ein Hochwasserstandsanzeiger: Wie hoch ist das Wasser gestiegen, als es am höchsten war? 2m? 3m? 4m? Vielleicht sogar 8m? Success Events haben hierbei die Funktion, einen bestimmten Stand zu markieren.

Auf das Beispiel mit dem Konto übertragen: Wir benutzen Events für die einzelnen Schritte des Prozesses, z.B. „Einstieg“, „Auswahl des Kontos“, „Adressabfrage“ usw. bis zu „Prozess abgeschlossen“. Im Retail wäre letzteres einfach die „Vielen Dank für Ihren Einkauf“ Seite.

So.

Genau wie bei der Hochwasserstandsanzeige ist es vollkommen egal, ob das Wasser nachdem es 4m erreicht hat erstmal wieder auf 3m fiel und dann wieder bis 3.8m stieg. Uns interessiert nur, daß es bei 4m war. Genauso im Prozess: Wir wollen wissen, wie weit unsere (Leider noch nicht-) Kunden gekommen sind, und wo wir sie vielleicht abholen müssen.

Die wichtige Grundlage hier ist: Die eigentliche zeitliche Abfolge ist irrelevant und sagt uns nicht viel über unsere Besucher oder Optimierungspotenzial unserer Site.

Gefährlich – Path und Fallout

Einer meiner Kollegen erwähnte heute den beim Testen gefürchteten „confirmation bias“, also die Tendenz jedes Testers, Argumente für das Ergebnis zu finden, dem er die besten Chancen zuspricht.

Wir kamen dann später auf Pathing zu sprechen und stellten fest, daß eine Analyse von Prozessen per Pathing genau das begünstigt: confirmation bias.

Wer sich einen Path ansieht oder einen Fallout analysiert, betrachtet per Definition nur die Besuche, die einem ganz bestimmten Pattern folgen, und zwar dem Pattern, das sich der Analyst als am wahrscheinlichsten vorstellt.

Und damit ist die Analyse in meinem Augen bereits wertlos.

Paths und Fallouts sind deswegen problematisch, weil sie einen ganz bestimmten Weg voraussetzen. Wenn es aber eine Erkenntnis gibt, die ich in den Jahren in der Webanalyse gemacht habe, dann ist es: Kein Benutzer verhält sich so wie ich mir das vorstelle!

Beispiel: Prozess mit 5 Seiten, A -> B -> C -> D -> E. Die erste Besucherin kommt in den Prozess und sieht nacheinander die Seiten A, B, C, „moment? wie war das mit den returns?“ B, C, D, „nee, mache ich später“, Exit.

Mein Funnel zeigt mir für die Besucherin jetzt die ersten 4 Events an aber natürlich nicht den letzen.

Und im Fallout? Dort wird die Benutzerin als „ist nach C abgesprungen“ gewertet, obwohl sie bis D gekommen ist. Weil eben nach C B kam und nicht D.

Es gibt im Internet zu viele Möglichkeiten, seiner Individualität beim Browsen Ausdruck zu verleihen – Browser, Tabs, Klicks und Rechtsklicks, Copy und Paste, Instant Messenger, Mobilgeräte, Suchmaschinen, … – unsere Benutzer verhalten sich manchmal geradezu abenteuerlich!

Wenn ich einen Path als Maßstab anlege, fallen alle diese absonderlichen Fälle automatisch heraus!

Und das ist nicht nur eine theoretische Überlegung!

Ein Retailer hier im UK, der vor ein paar Monaten auf responsive design umgestiegen war, bemerkte nach etwa 4 Stunden, daß das neue Overlayfenster für das shopping cart nicht funktionierte. Man konnte nichts darin klicken und wegmachen konnte man es auch nicht. Es war quasi unmöglich, etwas zu kaufen. Und dennoch schafften es nicht wenige Besucher! Hunderte, um genau zu sein.

So viel zu „Naja, die meisten Besucher klicken doch aber einfach nur …“. Das ist manchmal einfach nicht so. Funnels ist das wie oben erwähnt auch vollkommen egal. Paths und Fallouts aber eben nicht. Und daher ziehe ich erstere vor.

Update!

So, wie oben schon angedeutet habe ich mich geirrt.

Ich habe einen Test gemacht mit zwei Visitors, die die Strecke „Step1“ bis „Step4“ durchlaufen. Einer der Benutzer machte dabei eine Schleife:

[Screenshot]

Full Path Report meines Tests

Im Fallout Report sehen die zwei so aus:

[Screenshot]

Fallout Report meines Tests

Das ist ein klares Ergebnis: Auch der Fallout Report arbeitet wie ein Wasserstandsanzeiger, und damit ist mein Mißtrauen nicht angebracht.

Ich benutze dennoch lieber Events, weil ich dabei mit beliebigen eVars kombinieren kann.

Ausnahmen

Ausnahmen bestätigen bekanntlich die Regel. Ein paar der Reports aus dem Umfeld „Pathing“ finde ich durchaus sinnvoll.

Next Page Flow / Previous Page Flow

Für einen groben Überblick darüber, was ein Großteil der Besucher nach oder vor einer bestimmten Seite oder Aktion getan hat, sind die Naxt Page Flow und Previous Page Flow Reports geeignet.

Trotz aller Beschränkungen dürfte man hier ablesen können, ob Besucher von „Landing Page XYZ“ mehrheitlich zum „Produkt ABC“ weiterklicken oder nicht. Wo kommen meine Besucher her, wenn sie die Homepage ansehen (Tip: Neubesucher versus Wiederholungsbesucher segmentieren!)? Was war die meistbesuchte Seite vor dem Einstieg in den Checkout? Shopping Cart? Oder eine Produktseite?

Entries / Exits

Hier findet man schnell, wo die meisten Benutzer landen und wo sie wieder abspringen. Das liefert Hinweise für’s Testen.

Event Pathing

Der Artikel zum Event Pathing ist in der Pipeline und sollte in 2 Wochen oder Anfang nächsten Monats fertig sein. Ich füge dann hier einen Link ein. Wer sich das jetzt schon ansehen will, kann das bei Adam Greco tun. Natürlich auf Englisch: Success Event Pathing

6 Gedanken zu „Warum ich keine Pathing Reports benutze [Update]

  1. Andre

    Hmm, die Kritik an dem Fallout Report verstehe ich nicht so ganz. Wenn ich den Report auf Seitenbasis anlege, also bei Aufruf den nächsten Schrittes eine PageView Server Call absetzte, dann kommt mein Nutzer auch bis D. Ob und wo es Probleme mit dem Formular gibt, würde ich separat betrachten.

    Antworten
    1. jexner

      Korrekt. Siehe Korrektur im Artikel.

      Ich komme nach D, klar, aber der nächste Schritt nach C war B, womit der Fallout das als Abbruch zählt. Je nach Konfiguration meines Fallouts müssen die Schritte _exakt_ passen, und das gibt es meiner Erfahrung nach im Web nur selten.

      Dem Funnel hingegen ist die Abfolge absolut egal und das macht ihn flexibler.

      Antworten
  2. Andre

    Das würde bedeuten, dass die Benutzerin als Sie bei D ankommt nicht mehr im Fallout Report berücksichtigt wird, obwohl es derselbe Visit ist? Ich bin davon ausgegangen, das dass für den Visit egal wäre. Da habe ich so noch gar nicht drüber nachgedacht.

    Antworten
  3. Pingback: Alles neu macht der Mai! | Webanalyse auf Deutsch

  4. Pingback: Cookies seit H.25.4 | Webanalyse auf Deutsch

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.