Wie wir Markov-Ketten zur Entscheidungsbewertung und Fehlersuche nutzen. Mit Skript in Python

Es ist uns wichtig zu verstehen, was während des Lernens mit unseren Studierenden passiert und wie diese Ereignisse das Ergebnis beeinflussen. Deshalb erstellen wir eine Customer Journey Map — eine Karte des Kundenerlebnisses. Der Lernprozess ist nämlich kein kontinuierlicher und homogener Prozess, sondern eine Kette von miteinander verbundenen Ereignissen und Handlungen der Studierenden, die sich stark zwischen verschiedenen Teilnehmenden unterscheiden können. Hat er die Stunde absolviert: Was wird er als Nächstes tun? Wird er die Hausaufgaben machen? Wird er die mobile App starten? Wird er den Kurs wechseln oder den Lehrer wechseln wollen? Geht er sofort zur nächsten Lektion? Oder wird er einfach enttäuscht gehen? Können wir, indem wir diese Karte analysieren, Muster erkennen, die zu einem erfolgreichen Abschluss des Kurses führen oder im Gegenteil, dazu, dass der Student „ausscheidet“?

In der Regel werden für den Aufbau von CJM spezialisierte, sehr kostspielige Tools mit geschlossenem Quellcode verwendet. Wir wollten jedoch etwas Einfaches, das minimalen Aufwand erfordert und möglichst Open Source ist. So entstand die Idee, Markow-Ketten zu nutzen – und das haben wir erfolgreich umgesetzt. Wir haben eine Karte erstellt, die Daten zum Verhalten von Studierenden in Form eines Graphen interpretiert und dabei völlig unerwartete Antworten auf globale Geschäftsfragen entdeckt sowie tief versteckte Bugs gefunden. All dies haben wir mithilfe von Open-Source-Python-Skripten realisiert. In diesem Artikel werde ich zwei Fallstudien mit diesen unerwarteten Ergebnissen präsentieren und das Skript mit allen Interessierten teilen.

Markow-Ketten zeigen die Wahrscheinlichkeit von Übergängen zwischen Ereignissen. Hier ist ein einfaches Beispiel aus Wikipedia:

Hier sind „E“ und „A“ Ereignisse, die Pfeile sind Übergänge zwischen ihnen (einschließlich des Übergangs vom Ereignis zu sich selbst), und die Gewichtungen der Pfeile stehen für die Übergangswahrscheinlichkeit („gewichteter gerichteter Graph“).

Was haben wir verwendet

Die Kette wurde mit den grundlegenden Funktionen von Python trainiert, während die Protokolle der Schüleraktivität eingegeben wurden. Der Graph wurde mit der Bibliothek NetworkX auf der erhaltenen Matrix erstellt.

Das Protokoll sieht folgendermaßen aus:

Es handelt sich um eine CSV-Datei, die eine Tabelle aus drei Spalten enthält: die ID des Schülers, den Namen des Ereignisses und die Uhrzeit, zu der es stattgefunden hat. Diese drei Felder sind ausreichend, um die Bewegungen des Kunden zu verfolgen, eine Karte zu erstellen und letztlich eine Markow-Kette zu erhalten.

Die Bibliothek gibt die erstellten Grafiken im .dot- oder .gexf-Format zurück. Für die Visualisierung der ersten kann das kostenlose Paket Graphviz (das Tool gvedit) verwendet werden; wir haben mit .gexf und Gephi, ebenfalls kostenlos, gearbeitet.

Im Folgenden möchte ich zwei Beispiele für die Verwendung von Markow-Ketten anführen, die es uns ermöglicht haben, unsere Ziele, Lernprozesse und das gesamte Ökosystem von Skyeng aus einer neuen Perspektive zu betrachten und Bugs zu beheben.

Erster Fall: Mobile Anwendung

Zunächst untersuchten wir den Weg der Schüler durch unser beliebtestes Produkt – den General-Kurs. Zu diesem Zeitpunkt arbeitete ich in der Kinderabteilung von Skyeng und wir wollten herausfinden, wie effektiv die mobile App bei unserer Kinderzielgruppe funktioniert.

Nachdem ich die Logs genommen und durch das Skript laufen lassen habe, erhielt ich Folgendes:

Der Startknoten ist – Start General, und unten gibt es drei Endknoten: der Schüler „schlief ein“, wechselte den Kurs, beendete den Kurs.

• Fiel asleep, „Schlief ein“ – das bedeutet, dass er keine Kurse mehr besucht, höchstwahrscheinlich ist er abgebrochen. Wir nennen diesen Zustand optimistisch „schlief ein“, da er theoretisch die Möglichkeit hat, das Lernen fortzusetzen. Das schlechteste Ergebnis für uns.
• Dropped general, Kurs gewechselt – vom General zu etwas anderem und aus unserer Markov-Kette verloren.
• Finished course, Kurs beendet – der ideale Zustand, eine Person hat 80% der Lektionen abgeschlossen (nicht alle Lektionen sind verpflichtend).

Das Erreichen des Knotens successful class bedeutet, dass die Lektion auf unserer Plattform zusammen mit einem Lehrer erfolgreich absolviert wurde. Es zeichnet den Fortschritt im Kurs und das Näherkommen zum gewünschten Ergebnis – „Kurs beendet“ – auf. Es ist wichtig, dass die Schüler sie so oft wie möglich besuchen.

Um genauere quantitative Schlussfolgerungen für die mobile Anwendung (Node app session) zu erhalten, haben wir separate Ketten für jede der abschließenden Knoten gebaut und dann paarweise die Gewichte der Kanten verglichen:

• von app session zurück zu ihr selbst;
• von app session zu successful class;
• von successful class zu app session.

Links — Studenten, die den Kurs abgeschlossen haben, rechts — die »schlafenden«.

Diese drei Elemente zeigen die Verbindung zwischen dem Erfolg der Studenten und ihrer Nutzung der mobilen App. Wir hatten erwartet, dass die Verbindung bei den Absolventen stärker ausgeprägt ist als bei den »schlafenden«. Tatsächlich erhielten wir jedoch genau gegenteilige Ergebnisse:

• Wir haben festgestellt, dass verschiedene Nutzergruppen unterschiedlich mit der mobilen App interagieren;
• erfolgreiche Studenten nutzen die mobile App weniger intensiv;
• schlafende Studenten nutzen die mobile App aktiver.

Das bedeutet, dass die »schlafenden« Studenten immer mehr Zeit mit der mobilen App verbringen und schließlich dauerhaft darin bleiben.

Zunächst waren wir überrascht, doch nach einigem Nachdenken erkannten wir, dass dies ein ganz natürlicher Effekt ist. Ich habe früher selbst Französisch gelernt, indem ich zwei Werkzeuge verwendet habe: eine mobile App und Grammatikvorlesungen auf YouTube. Zunächst habe ich meine Zeit im Verhältnis 50 zu 50 aufgeteilt. Aber die App macht mehr Spaß; dort gibt es Gamification, die Nutzung ist einfach, schnell und klar, während man sich bei den Vorlesungen mehr konzentrieren muss, etwas aufschreiben und in einem Heft üben sollte. Im Laufe der Zeit begann ich, mehr Zeit mit meinem Smartphone zu verbringen, bis sein Anteil auf 100% angewachsen ist: Wenn man drei Stunden damit verbringt, hat man das falsche Gefühl, etwas geschafft zu haben, was einem die Lust nimmt, etwas zu hören.

Aber wie kann das sein? Schließlich haben wir die mobile App absichtlich erstellt, die Ebbinghaus-Kurve integriert,, gamifiziert, sie ansprechend gestaltet, damit die Menschen Zeit damit verbringen, und jetzt stellt sich heraus, dass sie sie nur ablenkt? Tatsächlich liegt der Grund darin, dass das Team der mobilen App seine Aufgaben zu gut erfüllt hat, wodurch sie zu einem tollen, eigenständigen Produkt geworden ist, das aus unserem Ökosystem herausfällt.

Am Ende der Untersuchung wurde klar, dass die mobile Anwendung irgendwie verändert werden muss, damit sie den Hauptlernprozess weniger stört. Dies gilt sowohl für Kinder als auch für Erwachsene. Derzeit wird an dieser Arbeit gearbeitet.

Zweiter Fall: Onboarding-Bugs

Onboarding ist ein optionales zusätzliches Verfahren bei der Registrierung neuer Schüler, das zukünftige potenzielle technische Probleme vermeiden soll. Das Basisszenario sieht vor, dass sich eine Person auf der Landingpage registriert, Zugang zum persönlichen Bereich erhält, kontaktiert wird und eine Einführungseinheit erhält. Dabei stellen wir fest, dass es während der Einführungseinheit zu einer hohen Anzahl technischer Schwierigkeiten kommt: falsche Browser-Version, Mikrofon oder Ton funktionieren nicht, der Lehrer kann nicht sofort eine Lösung vorschlagen, und das alles ist besonders schwierig, wenn es um Kinder geht. Daher haben wir eine zusätzliche Anwendung im persönlichen Bereich entwickelt, in der man vier einfache Schritte ausführen kann: den Browser, die Kamera und das Mikrofon überprüfen und bestätigen, dass die Eltern während der Einführungseinheit anwesend sein werden (denn sie sind es, die für die Ausbildung der Kinder zahlen).

Diese einigen Seiten des Onboardings zeigten eine solche Trichterstruktur:

1: Ein Einstieg mit drei leicht unterschiedlichen (je nach Kunde) Formularen zur Eingabe von Benutzernamen und Passwort.
2: Zustimmung zur zusätzlichen Onboarding-Prozedur.
2.1-2.3: Überprüfung der Anwesenheit eines Elternteils, der Chrome-Version und des Sounds.
3: Der finale Block.

Es sieht sehr natürlich aus: In den ersten beiden Schritten scheiden die meisten Besucher aus, als sie erkennen, dass sie etwas ausfüllen und überprüfen müssen, während die Zeit knapp ist. Wenn der Kunde bis zum dritten Schritt kommt, ist die Wahrscheinlichkeit hoch, dass er auch bis zum Ende weitergeht. In der Trichterdarstellung gibt es keinen Anhaltspunkt, um etwas zu misstrauen.

Dennoch haben wir uns entschieden, unser Onboarding nicht in einem klassischen eindimensionalen Trichter zu analysieren, sondern mithilfe einer Markov-Kette. Wir haben ein paar mehr Ereignisse einbezogen, ein Skript ausgeführt und folgendes erhalten:

Eindeutig lässt sich in diesem Chaos nur eines erkennen: Etwas läuft falsch. Der Onboarding-Prozess ist linear, das ist im Design vorgesehen, und es sollte keine derartigen Verknüpfungen geben. Hier wird sofort deutlich, dass der Nutzer zwischen den Schritten hin und her geworfen wird, zwischen denen es eigentlich keine Übergänge geben sollte.

Die Gründe für dieses merkwürdige Bild können zwei sein:

• Fehler in der Log-Datenbank sind aufgetreten;
• Es gibt Mängel im Produkt selbst – im Onboarding.

Die erste Ursache könnte tatsächlich vorliegen, aber ihre Überprüfung ist ziemlich aufwendig, und die Korrektur der Protokolle wird das Nutzererlebnis nicht verbessern. Bei der zweiten, sofern vorhanden, musste dringend gehandelt werden. Deshalb haben wir uns auf die Suche nach Knoten gemacht, um überflüssige Kanten zu identifizieren und die Ursachen ihres Auftretens zu finden. Wir haben festgestellt, dass einige Nutzer in einer Schleife gefangen waren, andere vom Mittelteil zum Anfang zurückkamen, während dritte im Allgemeinen nicht über die ersten beiden Schritte hinaus kamen. Wir haben die Daten an die QA weitergegeben – und ja, es stellte sich heraus, dass es im Onboarding zahlreiche Bugs gab: Es handelt sich um ein sekundäres, etwas provisorisches Produkt, das nicht ausreichend gründlich getestet wurde, da keine Probleme erwartet wurden. Der gesamte Aufnahmeprozess wurde inzwischen geändert.

Diese Geschichte hat uns eine unerwartete Anwendung von Markow-Ketten im QA-Bereich gezeigt.

Probieren Sie es selbst aus!

Ich habe mein Python-Skript zur Schulung von Markow-Ketten öffentlich zugänglich gemacht – nutzen Sie es gern. Die Dokumentation ist auf GitHub, Fragen können hier gestellt werden, ich werde versuchen, alles zu beantworten.

Und hier einige nützliche Links: Bibliothek NetworkX, Graphviz-Visualisierer. Und hier ist ein Artikel auf Habr über Markov-Ketten. Die Grafiken im Artikel wurden mit Hilfe von Gephi.

Quelle: habr.com