Het is belangrijk voor ons om te begrijpen wat er met onze studenten gebeurt tijdens hun opleiding en hoe deze gebeurtenissen invloed hebben op het resultaat. Daarom bouwen we een Customer Journey Map - een kaart van de klantbeleving. Het onderwijsproces is immers niet iets doorlopends en eenduidigs; het is een keten van onderling verbonden gebeurtenissen en acties van de student, en deze acties kunnen sterk verschillen tussen verschillende leerlingen. Wat gebeurt er nadat hij een les heeft gehad? Gaat hij het huiswerk maken? Start hij de mobiele app? Verandert hij van cursus, vraagt hij om een andere docent? Logt hij meteen in voor de volgende les? Of gaat hij gewoon teleurgesteld weg? Kunnen we door deze kaart te analyseren patronen ontdekken die leiden tot een succesvolle afronding van de cursus of juist tot het 'uitvallen' van de student?
Gewoonlijk worden voor het opstellen van een CJM gespecialiseerde, behoorlijk dure tools met gesloten code gebruikt. Maar we wilden iets eenvoudigs bedenken dat minimale inspanning vereiste en bij voorkeur opensource was. Zo ontstond het idee om Markov-ketens te gebruiken - en dat is gelukt. We hebben een kaart gebouwd, de gegevens over het gedrag van studenten geĆÆnterpreteerd in de vorm van een grafiek, en hebben helemaal niet voor de hand liggende antwoorden op wereldwijde bedrijfsvragen gevonden, en zelfs diep verborgen bugs ontdekt. Dit hebben we allemaal gedaan met behulp van opensource-oplossingen van een Python-script. In dit artikel zal ik twee casestudy's vertellen met diezelfde onopvallende resultaten en het script delen met alle geĆÆnteresseerden.
Dus, Markov-ketens laten de waarschijnlijkheid van overgangen tussen gebeurtenissen zien. Hier is een primitief voorbeeld uit Wikipedia:
Hier zijn 'E' en 'A' - gebeurtenissen, de pijlen - overgangen daartussen (inclusief overgang van een gebeurtenis naar zichzelf), en de gewichten van de pijlen - de waarschijnlijkheid van de overgang ('gewogen gerichte grafiek').
Wat we hebben gebruikt
De keten werd getraind met de standaardfunctionaliteit van Python, waarbij de logboeken van de activiteiten van studenten werden ingevoerd. De grafiek op de verkregen matrix werd gebouwd met de NetworkX-bibliotheek.
De log ziet er als volgt uit:
Dit is een csv-bestand dat een tabel bevat met drie kolommen: id van de student, naam van de gebeurtenis, tijd waarop deze plaatsvond. Deze drie velden zijn voldoende om de bewegingen van de klant te volgen, een kaart op te stellen en uiteindelijk een Markov-keten te verkrijgen.
De bibliotheek retourneert de opgebouwde grafen in .dot of .gexf formaat. Voor de visualisatie van de eerste kan de gratis Graphviz-pakket (hulpmiddel gvedit) worden gebruikt, wij hebben gewerkt met .gexf en Gephi, ook gratis.
Vervolgens wil ik twee voorbeelden geven van het gebruik van Markov-ketens, die ons in staat hebben gesteld om onze doelstellingen, leerprocessen en het ecosysteem van Skyeng vanuit een nieuw perspectief te bekijken. En om bugs bij te werken.
Eerste geval: mobiele applicatie
Om te beginnen hebben we de route van de student onderzocht via ons populairste product ā de General-cursus. Op dat moment werkte ik in de kinderafdeling van Skyeng en wilden we bekijken hoe effectief de mobiele applicatie werkt bij ons jongere publiek.
Door de logs te nemen en deze door een script te draaien, kreeg ik het volgende:
De startknop ā Start General, en onderaan drie uitvoernodes: de leerling 'viel in slaap', wisselde van cursus, voltooide de cursus.
- Fell asleep, 'Viel in slaap' ā betekent dat er geen lessen meer worden gevolgd, waarschijnlijk is hij afgehaakt. We noemen deze toestand optimistisch 'viel in slaap', omdat hij theoretisch nog de mogelijkheid heeft om het leren voort te zetten. Het slechtste resultaat voor ons.
- Dropped general, Wisselde van cursus ā ging van General naar iets anders en verdween uit onze Markov-keten.
- Finished course, Voltooide de cursus ā ideale toestand, de persoon heeft 80% van de lessen gevolgd (niet alle lessen zijn verplicht).
Toegang tot de node successful class betekent dat de les op ons platform samen met de docent succesvol is afgerond. Het registreert de voortgang door de cursus en de voortgang naar het gewenste resultaat ā 'Voltooide cursus'. Het is belangrijk voor ons dat studenten deze zo veel mogelijk bezoeken.
Om nauwkeurigere kwantitatieve conclusies voor de mobiele applicatie (node app session) te krijgen, hebben we aparte ketens gebouwd voor elke eindnode en vervolgens de gewichten van de randjes paargewijs vergeleken:
- van app session terug naar zichzelf;
- van app session naar successful class;
- van successful class naar app session.
Links ā studenten die de cursus hebben afgerond, rechts ā 'gevallen in slaap'
Deze drie randen tonen de relatie aan tussen het succes van de student en het gebruik van de mobiele applicatie. We verwachtten te zien dat studenten die de cursus hadden afgerond een sterkere verbinding met de applicatie zouden hebben dan de 'gevallen in slaap'. Echter, in werkelijkheid kregen we precies het tegenovergestelde resultaat:
- we hebben vastgesteld dat verschillende groepen gebruikers verschillend omgaan met de mobiele applicatie;
- succesvolle studenten gebruiken de mobiele app minder intensief;
- slapende studenten gebruiken de mobiele app actiever.
Dit betekent dat 'slapende' studenten steeds meer tijd in de mobiele app doorbrengen en uiteindelijk permanent in de app blijven.
Aanvankelijk waren we verrast, maar na erover nagedacht te hebben, realiseerden we ons dat dit een volkomen logisch effect is. In mijn tijd studeerde ik Frans op eigen houtje met behulp van twee hulpmiddelen: een mobiele app en grammaticale lessen op YouTube. In het begin verdeelde ik mijn tijd tussen hen in een verhouding van 50-50. Maar de app is leuker, er is gamificatie, alles is eenvoudig, snel en duidelijk, terwijl je bij de lessen echt moet invoelen, aantekeningen moet maken en in een schrift moet oefenen. Geleidelijk bracht ik meer tijd door op mijn smartphone, totdat het aandeel 100% bereikte: als je er drie uur in zit, krijg je een vals gevoel van volbrachte taken, waardoor je geen zin hebt om naar iets anders te gaan of naar een les te luisteren.
Maar hoe kan dat? We hebben de mobiele app toch speciaal gemaakt, we hebben het gamified, aantrekkelijk gemaakt, zodat mensen er tijd in doorbrengen, en toch blijkt het alleen maar af te leiden? De reden is eigenlijk dat het team van de mobiele app zijn taken te goed heeft uitgevoerd, waardoor het een geweldig autonoom product is geworden dat uit ons ecosysteem begint te vallen.
Uiteindelijk kwam het inzicht dat de mobiele app op de een of andere manier moet worden veranderd, zodat deze minder afleidt van de hoofdopleiding. Zowel voor kinderen als volwassenen. Dit werk is momenteel aan de gang.
Tweede geval: onboarding bugs
Onboarding is an optional additional procedure during the registration of a new student, designed to eliminate potential technical issues in the future. The basic scenario involves a person registering on the landing page, gaining access to their personal account, being contacted, and participating in an introductory lesson. We note a high percentage of technical difficulties during this introductory lesson: using the wrong browser version, microphone or audio issues, and the teacher not being able to provide immediate solutions, which is especially challenging when working with children. Therefore, we developed an additional application in the personal account where four simple steps can be completed: check the browser, camera, microphone, and confirm that parents will be present during the introductory lesson (as they are the ones paying for their children's education).
These few onboarding pages demonstrated the following funnel:
1: a starting block with three slightly different (depending on the client) login-password input forms.
2: a checkbox for consent to the additional onboarding procedure.
2.1-2.3: checking for the presence of a parent, the version of Chrome, and sound.
3: the final block.
It looks very natural: at the first two steps, most visitors drop off, realizing that they need to fill something out, check something, and there isnāt enough time. If a client reaches the third step, they are almost guaranteed to reach the end. There is no visible reason in the funnel to suspect anything.
Still, we decided to analyze our onboarding not using a classic one-dimensional funnel, but rather through a Markov chain. We included a bit more events, launched the script, and got this:
One can only conclude one thing amid this chaos: something went wrong. The onboarding process is linear, as intended by the design, and there should not be such a web of connections. Here, it is immediately evident that users are being thrown between steps with transitions that should not exist.
The reasons for such a strange picture could be two:
- issues crept into the log database;
- issues are present in the product itself ā the onboarding.
De eerste oorzaak is waarschijnlijk aanwezig, maar het verifiƫren ervan is behoorlijk arbeidsintensief, en het corrigeren van de logboeken zal de UX niet verbeteren. Maar over het tweede probleem, als dat er is, moesten we dringend actie ondernemen. Dus gingen we knooppunten bekijken, ontdekken welke verbindingen er niet zouden moeten zijn en de oorzaken daarvan zoeken. We zagen dat sommige gebruikers vastliepen en in cirkels rondgingen, anderen vielen ergens halverwege terug naar het begin, en weer anderen konden in principe niet ontsnappen uit de eerste twee stappen. We hebben de gegevens doorgegeven aan QA - en ja, het bleek dat er genoeg bugs in de onboarding zaten: het is een soort bijproduct, iets improviserends, dat niet diep genoeg is getest omdat er geen problemen verwacht werden. Inmiddels is het hele registratieproces veranderd.
Dit verhaal toonde ons een onverwachte toepassing van Markov-ketens op het gebied van QA.
Probeer het zelf!
Ik heb mijn openbare toegang gegeven - maak er gebruik van. De documentatie is op GitHub, je kunt hier vragen stellen, ik zal proberen alles te beantwoorden.
En hier zijn nuttige links: , . En hier over Markov-ketens. De grafieken in het artikel zijn gemaakt met .
Bron: habr.com
