Ferndiagnose: Tod

App Analytics

Das Problem:

Tote Nutzer lügen nicht – 53% der Nutzer löschen eine App bei technischen Problemen wieder, meistens innerhalb der ersten zwei Tage der Nutzung. Ich sollte dem auf die Spur kommen und habe mir die verfügbaren Datenpunkte genauer angesehen. Die Deutschen installieren gern Apps. 65% der Befragten einer Online-Studie aus März 2015 (TFM Netzwerk, statista) gaben an, mehr als 10 Apps auf ihrem Smartphone zu haben. Grund genug, als Unternehmen über eine direkte Ansprache genau dieser Konsumenten nachzudenken – in 2019 selbstverständlich via App. Und wer kennt das nicht? Man öffnet die App nach mehreren Wochen oder Monaten erneut und ist sich gar nicht mehr sicher, warum man sie in erster Linie installiert hat. Noch schlimmer ist es, wenn eine neue, vielversprechende App gerade zu Beginn noch so viele Kinderkrankheiten hat, dass der Lösch-Button schnell gedrückt ist. Oft wird dabei allerdings vergessen, die persönlichen Daten, die in der App eingegeben wurden, auch zu entfernen, so häuft ein jeder Smartphone-Benutzer in seinem Leben mehrere „tote“ Benutzerkonten ein, die auf der anderen Seite der App teilweise nicht so leicht auseinanderzuhalten sind. Meine Situation beschreibt genau diese Seite – die Auswertung und Musterung der generierten Daten nach dem Entwicklungsprozess und vielen Meilensteinen. Die Situation, wenn nicht das gewünschte Engagement mit den Nutzern eintritt und man auf der Suche nach Spuren jeden möglichen Stein umdreht.

Blende. Gerichtsmedizin. Kennt man so nur aus dem Tatort. Ich begab mich gedanklich trotzdem dorthin, zog mir meine Schutzkleidung über und wühlte durch die erkalteten Körper. Ich möchte keineswegs medizinische Ursachen herausfinden, eher kriminalistisch rekonstruieren, was sich zugetragen hat. Wie im echten Leben auch erhält man von App-Nutzern nach sieben Wochen „Liegezeit“ wenig verwertbares Material. In meinem Fall hatte ich lediglich zwei Datentöpfe, die ich zu Beginn nicht einmal miteinander verknüpfen konnte.

Die App:

Kernmechanik der App ist, dass ein Nutzer ein Wochenprogramm aus Inhalten erhält und dieses innerhalb von sieben Tagen absolviert. Nach erfolgreicher Vollendung des Programms startet eine Pause von (mindestens) sieben Tagen (bis sich der Nutzer erneut einloggt), dann kommt die nächste Woche mit neuen Inhalten und Übungen. Essentiell für den Fortschritt ist also, dass ein Nutzer

  • alle Inhalte seines ersten Wochenprogramms absolviert oder
  • sieben Tage nach vollendeter letzter Übung des Wochenprogramms wiederkommt.

Diese wesentlichen Jobs wurden unterstützt durch eine tägliche Push-Mitteilung („Du hast noch offene Inhalte…“/“Komm doch zur Wiederholung deiner Übungen…“), so dass die Nummer eigentlich wasserfest sein sollte. Sollte. Denn trotz der ausgeklügelten Mechanik war es 75% der Nutzer bis heute nicht möglich, über die erste Woche (= zwei Logins) hinaus die App zu nutzen.

Das Vorgehen:

Gary Klein hat sich diesem Verhalten 2007 angenommen und eine pre-mortem Technik veröffentlicht. Quintessenz ist die Entfernung eines etwaigen perception bias, also der subjektiv unterschiedlichen Wahrnehmung von Entscheidungen oder Tatsachen. Durch die Eliminierung persönlicher Beiträge zum Erfolg oder Misserfolg, sondern einer einfachen Rückverfolgung der Handlungskette kann jeder, der sich innerhalb des Teams mit dem Projekt auseinandersetzt seine Zweifel und Fakten anbringen. Ob das im Team oder in Einzelgesprächen durchgeführt wird, spielt dabei keine Rolle. Viele wahrscheinliche Ursachen des Scheiterns des Vorhabens lassen sich ausschließen, indem die Zukunft als Gegenwart angenommen wird und der worst case zurückbeleuchtet wird. Eine solche Art der Auswirkungsanalyse (in weitaus kleinerem Umfang) verhindert, dass wie in meinem Fall im Nachgang ein großer Aufwand zur Feststellung der tatsächlichen Gründe betrieben werden muss. Denn hier gab es keineswegs ein fiktives Szenario mit Vermutungen über Hintergründe, sondern eine klare Formulierung, wie Misserfolg messbar gemacht wird – eben über KPI oder Schlüsselergebnisse. Gewappnet mit der Gewissheit, dass sich das auf zwei, vielleicht drei SQL-Abfragen (Universitätskurs IT sei dank) beschränkt, und die Zahlen entsprechende Antworten liefern. Ein altes amerikanisches Sprichwort sagt „you don’t know what you don’t know“ – das war auch hier der Fall.

Weniger Glücksspiel, mehr Kausalität – Photo by Steve Sawusch on Unsplash

Als ich mich auf diese Reise begab, war mir nicht klar wie viele Stunden die „richtige“ Abfrage zweier Datenbanken in Anspruch nimmt (als Abnehmer einer fremden Datenquelle müssen zuerst redundante, falsche oder inkonsistente Daten identifiziert werden), bevor überhaupt eine verwertbare Zahl herauspurzelt. Im Grunde war die Herangehensweise auch nicht falsch, es gab nur keinen Plan C für einen unerwartet schlechten Launch des Produkts. Und so fehlte es nicht nur an Fähigkeiten am einen Ende, sondern auch an Fokus auf relevante Punkte am anderen.





Der Durchbruch:

Alles war verbunden. Der Einstieg in eine relationale Datenbank hätte schlimmer nicht sein können. So kam es, dass ich auf einfache Fragen wie „Nenne mir alle Nutzer, die sich nur einmal eingeloggt haben“ eine Antwortkette von sieben unterschiedlichen Abfragen bauen musste, um wirklich sicherzugehen, dass es sich um eine belastbare Zahl handelte. Die Heilsbringer in Form von Statistikern und Data Analysten riefen Angebote jenseits der vertretbaren Grenzen auf, und so hieß es – wie oben sehr bildhaft beschrieben – selbst reinknien. Letztendlich half mir nur ein Eintauchen in die Welt meiner Zielpersonen. Wer waren die Menschen, die sich in meinen Zeilen stapelten, was waren die Gewohnheiten und welche Bedürfnisse gibt es am anderen Ende der Bildschirme? Die Methode war vorhersehbar, aber im Spiegel der zeitlich angespannten Situation schien es mir zuerst zu aufwändig, den Lebenszyklus eines Nutzers zu durchlaufen und mir zu notieren, an welchen Stellen die Abbrüche von meiner Person aus passiert wären. Schlussendlich kamen fünf wertvolle Kohorten auf der r²-Verteilung hervor, die wir uns in Einzelinterviews vornehmen können. Das Problem haben wir damit zwar nicht behoben, aber wenigstens konnten wir die Nutzer klar identifizieren und ihnen Symptome zuordnen. Diagnose steht aus. Rückblickend ist für mich klar, dass ein baldiger pre-mortem und damit verbunden die Festlegung der Maßnahmen im Falle abtrünniger Nutzer eine erhebliche Erleichterung darstellt und verhindert, dass Nutzungsmuster – oder auch gute Vorsätze aufgrund schlechter Erfahrungen mit Apps gebrochen werden. Darum lasst uns offen über unsere Gedanken und vor allem Vorbehalte sprechen, um uns nicht in Details zu verlieren, die sich im Voraus festlegen und damit automatisch messen lassen können. Mein Vorsatz ist jedenfalls ein datenbankstressfreies 2019.

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