Lean Startup: Zählen Sie Ihre Nutzer nicht wie Schafe (Teil 1)

In den letzten Posts habe ich die Idee eingeführt, wie sich ein Standard-Messprozess für Ihre Produkte mithilfe einer handvoll Markro-Metriken (versus Mikro-Metriken) etablieren lässt, die in Batches oder Gruppen aufgebrochen sind.

Makro-Metriken sind nützlich fürs Lernen, während Mikro-Metriken bei der Optimierung und Problemlösung helfen.

Das Problem mit Mikro-Metriken besteht darin, dass man immer noch durch sehr viele von ihnen waten muss. Heute möchte ich einen Ansatz dahingehend teilen, wie man durch diese Daten navigieren kann, ohne in einem Zahlenmeer zu ertrinken.

Der traditionelle Ansatz: Deklarative Sub-Trichter

Der traditionelle Ansatz ist der, die Mikro-Metriken in einen oder mehrere Sub-Trichter zu organisieren. Die Grundidee dahinter ist, dass die User eine Reihe von Schritten ausführen, um ein bestimmtes Ziel (oder ein Call to Action) zu erreichen. Und durch die Visualisierung der Einbußen zwischen den Schritten lassen sich die löchrigen Gefäße im Trichter festnageln.

Während das scheinbar logisch ist, beruht all das auf der Annahme, dass sich zwischen Startpunkt A und Ziel B eine Reihe von Schritten klar definieren lässt.

In den frühen Tagen der Analytics-Software mussten diese Sub-Trichter-Schritte vorab explizit deklariert und entsprechend programmiert werden. Selbst bei der geringsten Änderung des Flows musste neuer Code re-deployt werden – ein (Re-)Konfigurations-Alptraum.

Neue Analytics-Produkte lösen dieses Problem, indem sie es ermöglichen, Sub-Trichter “on the fly” zu definieren, was eine große Verbesserung darstellt. Doch man muss immer noch auf diverse Beschränkungen achten, die es nahezu unmöglich machen, jeden Nutzer im Trichter akkurat zu messen.

Limitierung #1: Nutzer müssen den Trichter von Anfang an durchlaufen, sonst werden sie nicht gezählt

Das ist normalerweise kein Problem, wenn man sicherstellen kann, dass jeder am selben Startpunkt anfängt. Aber die echte Welt ist voller Annahmen. Und Annahmen werden nicht gezählt.

Sehen wir uns ein paar einfache Beispiele an:

1. Auf einer Marketing-Website könnte die Landing-Page explizit von der Pricing-Seite getrennt sein, sodass beide als separate Schritte getrackt werden können, wie ich selbst es oft tue. Doch trotz aller Bemühungen, die User diesen Pfad entlang zu führen, starten sie nicht immer auf der Landing-Page – dank Google und geteilten Links.

2. Mit einer Web-App kann vielleicht ein Wizard gebaut werden, um die Nutzer einen bestimmten Pfad entlang zu zwingen. Doch erstens ist das aus Usability-Perspektive nicht so sehr im Trend. Und zweitens kann so ein nicht-linearer Trichter entstehen, in dem es keine präskriptive Reihe von Schritten gibt, die für jeden passt (wie beim Ausfüllen eines Lean Canvas’).

3. Selbst wenn man sich für einen Wizard entschieden hat – Was passiert jenseits des Aktivierungs-Flows, wenn User in der Applikation wirklich machen können, was sie wollen? Wie soll hier der Trichter definiert werden?

Limitierung #2: Sie können keine optionalen Schritte haben

Einige der besten bahnbrechenden Ideen kamen beim Begehen der Trampelpfade heraus. Man sollte es fördern und tracken und nicht behindern, dass User herumwandern und experimentieren.

Limitierung #3: User müssen den Trichter innerhalb eines gesetzten Zeitfensters durchqueren

Viele der neueren Tools lassen uns hängen, wenn der Trichter über 30 Tage hinausgeht. Deklarative Trichter funktionieren bei klar definierten kurzfristigen Zielen wie Konversionen von einer Landing-Page aus. Doch man muss ebenso in der Lage sein, diese kurzfristigen Sub-Trichter in eine Makro-Ebene (z.B. Umsätze) zu übertragen. Hier kann es um mehrere Wochen oder Monate gehen.

Ein Beispiel: Wenn man auf der Marketing-Website keine Preise nennt, kann das kurzfristige Ziele wie Sign-ups unterstützen (Yeah!), aber zulasten der bezahlten Konversionen am Ende des Monats gehen (Buh!).

Wir müssen das gesamte System von vorne bis hinten messen, um nicht in die Falle der Mikro-Optimierung (oder lokaler Maxima) zu tappen.

Das fundamentale Problem mit deklarativen Trichtern besteht darin, dass sie voraussetzen, dass wir Trichter im Vorfeld definieren und unsere User wie Schafe führen können, was in der Praxis nicht zutrifft.

Im folgenden zweiten Artikel wird Ash Maurya als Alternative emergente Trichter einführen.

Dieser Artikel wurde im Original am 4. Juni 2013 unter dem Titel Don't Count Your Users Like Sheep von Ash Maurya veröffentlicht. Ash Maurya gehört zu den führenden Köpfen der internationalen Gründerszene und ist einer der renommiertesten Experten für Lean Startup und Customer Development. Seinen Weblog finden Sie unter www.ashmaurya.com. Die Website seines Unternehmens Spark59 erreichen Sie unter http://spark59.com. Mehr Fachartikel bietet unser Lean-Special.