Es ist wichtig fĂŒr uns zu verstehen, was mit unseren Studenten wĂ€hrend des Lernens passiert und wie diese Ereignisse das Ergebnis beeinflussen. Daher erstellen wir eine Customer Journey Map â eine Karte des Kundenerlebnisses. Denn der Lernprozess ist kein kontinuierlicher und einheitlicher Prozess, sondern eine Kette von miteinander verbundenen Ereignissen und Aktionen des Studenten, wobei diese Aktionen bei verschiedenen SchĂŒlern stark variieren können. Er hat also Unterricht gehabt: Was macht er als NĂ€chstes? Macht er die Hausaufgaben? Startet er die mobile Anwendung? Ăndert er den Kurs oder bittet um einen Lehrerwechsel? Geht er sofort zur nĂ€chsten Lektion? Oder verlĂ€sst er einfach enttĂ€uscht? Kann man durch die Analyse dieser Karte Muster identifizieren, die zum erfolgreichen Abschluss des Kurses fĂŒhren oder im Gegenteil dazu, dass der Student âaufgibtâ?
Normalerweise werden fĂŒr den Aufbau von CJMs spezialisierte, ziemlich teure Werkzeuge mit geschlossener Software verwendet. Aber wir wollten etwas Einfaches entwickeln, das minimale Anstrengungen erfordert und nach Möglichkeit Open Source ist. So entstand die Idee, Markov-Ketten zu verwenden â und wir hatten Erfolg. Wir haben eine Karte erstellt, die Daten ĂŒber das Verhalten von Studenten in Form eines Graphen interpretiert, und dabei ganz unerwartete Antworten auf globale GeschĂ€ftsfragen gefunden und sogar tief versteckte Bugs entdeckt. All dies haben wir mit Hilfe von Open Source-Lösungen eines Python-Skripts realisiert. In diesem Artikel werde ich zwei FĂ€lle mit diesen unerwarteten Ergebnissen erlĂ€utern und das Skript mit allen Interessierten teilen.
Markov-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 von einem Ereignis zu sich selbst), und die Gewichte der Pfeile sind die Ăbergangswahrscheinlichkeiten (âgewichteter gerichteter Graphâ).
Was wir verwendet haben
Die Kette wurde mit der StandardfunktionalitÀt von Python trainiert, die die Protokolldaten der AktivitÀten der Studenten verarbeitet hat. Der Graph wurde mit der Bibliothek NetworkX aus der erhaltenen Matrix erstellt.
Das Protokoll sieht so aus:
Es handelt sich um eine CSV-Datei, die eine Tabelle mit drei Spalten enthĂ€lt: die ID des Studenten, die Bezeichnung des Ereignisses und die Zeit, zu der es aufgetreten ist. Diese drei Felder sind ausreichend, um die Bewegungen des Kunden nachzuvollziehen, eine Karte zu erstellen und schlieĂlich eine Markov-Kette zu erhalten.
Die Bibliothek gibt die erstellten Graphen im .dot- oder .gexf-Format zurĂŒck. Zum Visualisieren der ersten kann man das kostenlose Paket Graphviz (Werkzeug gvedit) verwenden, wir haben mit .gexf und Gephi, ebenfalls kostenlos, gearbeitet.
Als nĂ€chstes möchte ich zwei Beispiele fĂŒr die Nutzung von Markow-Ketten vorstellen, die es uns ermöglicht haben, unsere Ziele, Bildungsprozesse und das gesamte Skyeng-Ăkosystem neu zu betrachten. Und einige Fehler zu beheben.
Erster Fall: mobile Anwendung
ZunĂ€chst haben wir den Weg des SchĂŒlers durch unser beliebtestes Produkt - den General-Kurs - untersucht. Zu diesem Zeitpunkt arbeitete ich in der Kinderabteilung von Skyeng und wir wollten herausfinden, wie effektiv die mobile App mit unserem Kinderpublikum arbeitet.
Nachdem ich die Protokolle genommen und sie durch ein Skript gejagt habe, erhielt ich Folgendes:
Startknoten - Start General, und unten drei Ausgangsnodes: SchĂŒler 'ist eingeschlafen', hat den Kurs gewechselt, hat den Kurs beendet.
- 'Ist eingeschlafen' bedeutet, dass er die Lektionen nicht mehr besucht, wahrscheinlich hat er aufgegeben. Wir nennen diesen Zustand optimistisch 'eingeschlafen', da er theoretisch die Möglichkeit hat, das Lernen fortzusetzen. Das schlechteste Ergebnis fĂŒr uns.
- 'Kurs gewechselt' - er ist von General zu etwas anderem gewechselt und ist aus unserer Markow-Kette verschwunden.
- 'Kurs beendet' - idealer Zustand, die Person hat 80 % der Lektionen besucht (nicht alle Lektionen sind verpflichtend).
Das Erreichen des Knotens 'successful class' bedeutet, dass die Lektion auf unserer Plattform zusammen mit dem Lehrer erfolgreich absolviert wurde. Es dokumentiert den Fortschritt im Kurs und das NĂ€herkommen zum gewĂŒnschten Ergebnis - 'Kurs beendet'. Es ist uns wichtig, dass die SchĂŒler ihn so oft wie möglich besuchen.
Um genauere quantitative Schlussfolgerungen fĂŒr die mobile Anwendung (Knoten 'app session') zu erhalten, haben wir separate Ketten fĂŒr jeden der Endknoten erstellt und anschlieĂend paarweise die Gewichte der Kanten verglichen:
- von der app session zurĂŒck zu ihr selbst;
- von der app session zur successful class;
- von der successful class zur app session.
Links - SchĂŒler, die den Kurs beendet haben, rechts - 'eingeschlafene'
Diese drei Kanten zeigen die Verbindung zwischen dem Erfolg des SchĂŒlers und der Nutzung der mobilen Anwendung. Wir erwarteten, dass die Verbindung mit der App bei den SchĂŒlern, die den Kurs abgeschlossen haben, stĂ€rker ist als bei den 'eingeschlafenen'. In Wirklichkeit haben wir jedoch genau gegenteilige Ergebnisse erhalten:
- Wir haben festgestellt, dass verschiedene Benutzergruppen unterschiedlich mit der mobilen Anwendung 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 in der mobilen App verbringen und letztendlich fĂŒr immer darin bleiben.
ZunĂ€chst waren wir ĂŒberrascht, aber nach eingehender Ăberlegung erkannten wir, dass dies ein ganz natĂŒrlicher Effekt ist. Ich habe in der Vergangenheit eigenstĂ€ndig Französisch gelernt, indem ich zwei Werkzeuge genutzt habe: die mobile App und Grammatikvorlesungen auf YouTube. Anfangs habe ich die Zeit zwischen den beiden im VerhĂ€ltnis 50 zu 50 aufgeteilt. Aber die App macht mehr SpaĂ, es gibt Gamification, alles ist einfach, schnell und verstĂ€ndlich, wĂ€hrend man sich in die Vorlesungen vertiefen, etwas aufschreiben und in einem Heft ĂŒben muss. AllmĂ€hlich habe ich immer mehr Zeit mit meinem Smartphone verbracht, bis der Anteil auf 100% angestiegen ist: Wenn man drei Stunden darin verbringt, entsteht ein falsches GefĂŒhl der erledigten Arbeit, weshalb man keine Lust hat, etwas zu hören oder zu lernen.
Aber wie kann das sein? SchlieĂlich haben wir die mobile App extra entwickelt, , gamifiziert und sie ansprechend gestaltet, damit die Leute Zeit darin verbringen, und jetzt stellt sich heraus, dass sie nur ablenkt? TatsĂ€chlich liegt der Grund darin, dass das Team der mobilen App seine Aufgaben zu gut gelöst hat, wodurch sie ein groĂartiges, eigenstĂ€ndiges Produkt geschaffen haben, das aus unserem Ăkosystem herausfĂ€llt.
Am Ende der Forschung kam das VerstĂ€ndnis zustande, dass die mobile App irgendwie verĂ€ndert werden muss, damit sie weniger vom Kern des Lernens ablenkt. Und zwar sowohl fĂŒr Kinder als auch fĂŒr Erwachsene. Diese Arbeit wird derzeit durchgefĂŒhrt.
Zweiter Fall: Bugs im Onboarding
Onboarding ist ein optionales zusĂ€tzliches Verfahren bei der Registrierung eines neuen SchĂŒlers, das potenzielle technische Probleme in der Zukunft vermeidet. Das Basisszenario sieht vor, dass sich eine Person auf der Landingpage registriert, Zugang zum persönlichen Bereich erhĂ€lt, kontaktiert wird und eine EinfĂŒhrungsstunde erhĂ€lt. Dabei stellen wir einen hohen Anteil an technischen Schwierigkeiten wĂ€hrend der EinfĂŒhrungsstunde fest: falsche Browser-Version, Mikrofon oder Ton funktionieren nicht, der Lehrer kann nicht sofort eine Lösung anbieten, und das alles ist besonders schwierig, wenn es um Kinder geht. Deshalb haben wir eine zusĂ€tzliche Anwendung im persönlichen Bereich entwickelt, in der vier einfache Schritte durchgefĂŒhrt werden können: den Browser, die Kamera, das Mikrofon prĂŒfen und bestĂ€tigen, dass die Eltern wĂ€hrend der EinfĂŒhrungsstunde anwesend sein werden (schlieĂlich zahlen sie fĂŒr die Ausbildung der Kinder).
Diese wenigen Seiten des Onboardings zeigten folgendes Trichterdiagramm:
1: Ein Einstiegsblock mit drei leicht unterschiedlichen (je nach Kunde) Login-Passwort Eingabeformularen.
2: HĂ€kchen fĂŒr die Zustimmung zum zusĂ€tzlichen Onboarding-Verfahren.
2.1-2.3: ĂberprĂŒfung der Anwesenheit des Elternteils, der Chrome-Version und des Tons.
3: Schlussblock.
Es sieht sehr natĂŒrlich aus: In den ersten beiden Schritten scheitert ein GroĂteil der Besucher, weil sie erkennen, dass sie etwas ausfĂŒllen und ĂŒberprĂŒfen mĂŒssen, und keine Zeit haben. Wenn der Kunde bis zur dritten Stufe gelangt ist, wird er mit Sicherheit auch das Ende erreichen. Im Trichter sind keinerlei GrĂŒnde zu erkennen, um an etwas zu zweifeln.
Dennoch haben wir uns entschieden, unser Onboarding nicht anhand des klassischen eindimensionalen Trichters, sondern mithilfe einer Markov-Kette zu analysieren. Wir haben etwas mehr Ereignisse einbezogen, ein Skript gestartet und Folgendes erhalten:
Man kann in diesem Chaos eindeutig nur eines verstehen: Etwas ist schiefgelaufen. Der Onboarding-Prozess ist linear, das ist im Design vorgesehen, und es sollte dort definitiv kein so komplexes Geflecht von Verbindungen geben. Und hier ist sofort ersichtlich, dass der Benutzer 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önnten zwei sein:
- Fehler haben sich in die Log-Datenbank eingeschlichen;
- Fehler sind im Produkt selbst vorhanden â im Onboarding.
Der erste Grund ist wahrscheinlich vorhanden, aber es ist zeitaufwendig, ihn zu ĂŒberprĂŒfen, und das Korrigieren von Protokollen wird das Benutzererlebnis nicht verbessern. Bei dem zweiten Grund, falls er existiert, musste dringend etwas unternommen werden. Daher haben wir uns auf die Suche nach Knoten begeben, fehlerhafte Verbindungen identifiziert und die Ursachen fĂŒr deren Entstehung gesucht. Wir haben festgestellt, dass einige Benutzer sich in einer Schleife gefangen haben, andere aus der Mitte zum Anfang zurĂŒckfielen, und Dritte im Grunde genommen nicht ĂŒber die ersten beiden Schritte hinauskommen konnten. Wir haben die Daten an QA ĂŒbergeben â und ja, es stellte sich heraus, dass es im Onboarding viele Bugs gab: es ist ein eher nebensĂ€chliches, etwas improvisiertes Produkt, das nicht ausreichend getestet wurde, da man keine Probleme erwartete. Jetzt hat sich der gesamte Registrierungsprozess geĂ€ndert.
Diese Geschichte hat uns eine unerwartete Anwendung von Markow-Ketten im Bereich QA gezeigt.
Probiert es selbst aus!
Ich habe mein öffentlich zugĂ€nglich gemacht â viel SpaĂ damit. Die Dokumentation befindet sich auf GitHub, Fragen können hier gestellt werden, ich werde versuchen, alles zu beantworten.
Und hier sind nĂŒtzliche Links: , . Und hier gibt es ĂŒber Markow-Ketten. Die Grafiken im Artikel wurden mit Hilfe von .
Quelle: habr.com
