Det er vigtigt for os at forstå, hvad der sker med vores studerende under deres uddannelse, og hvordan disse begivenheder påvirker resultatet. Derfor bygger vi en Customer Journey Map - en kortlægning af kundeoplevelsen. Uddannelsesprocessen er ikke en kontinuerlig og ensartet proces, men en kæde af relaterede events og handlinger fra den studerende, hvor disse handlinger kan variere meget fra elev til elev. Han har gennemført lektionen: hvad gør han så? Går han videre til lektierne? Starter han mobilappen? Ændrer han kurset, beder om at skifte lærer? Går han straks til næste lektion? Eller forlader han bare skuffet? Er det muligt, ved at analysere dette kort, at identificere mønstre, der fører til en vellykket afslutning af kurset eller tværtimod til at ”falde fra” for den studerende?
Normalt anvendes der specialiserede, meget dyre værktøjer med lukket kildekode til at opbygge CJM. Men vi ønskede at finde på noget simpelt, der krævede minimumsindsats og som helst skulle være open source. Så ideen om at bruge Markov-kæder opstod - og det lykkedes os. Vi byggede et kort, fortolkede data om studerendes adfærd i form af en graf, så nogle helt uventede svar på overordnede forretningsspørgsmål og fandt endda dybt skjulte bugs. Alt dette gjorde vi ved hjælp af open source-løsninger med Python-script. I denne artikel vil jeg fortælle om to cases med de samme uventede resultater og dele scriptet med alle interesserede.
Så Markov-kæder viser sandsynligheder for overgange mellem begivenheder. Her er et primitivt eksempel fra Wikipedia:
Her er «E» og «A» begivenheder, pile angiver overgange mellem dem (inklusive overgangen fra en begivenhed til sig selv), og vægtene på pilene angiver sandsynligheden for overgangen (»vægte orienterede grafer«).
Hvad der blev brugt
Kæden blev trænet med standardfunktionaliteten i Python, hvor logfiler over studerendes aktivitet blev indlæst. Grafen i den modtagne matrix blev bygget med bibliotekerne NetworkX.
Loggen ser sådan ud:
Det er en csv-fil, der indeholder en tabel med tre kolonner: studerendes id, betegnelse for begivenheden, tidspunktet hvor den fandt sted. Disse tre felter er tilstrækkelige til at følge kundens bevægelser, opbygge kortet og i sidste ende få en Markov-kæde.
Biblioteket returnerer de konstruerede grafer i .dot eller .gexf format. For visualisering af de første kan man bruge det gratis Graphviz-pakke (værktøjet gvedit). Vi har arbejdet med .gexf og Gephi, som også er gratis.
Jeg vil nu give to eksempler på brugen af Markov-kæder, som har givet os et nyt perspektiv på vores mål, læringsprocesser og selve Skyeng-økosystemet. Og også rette nogle fejl.
Det første tilfælde: mobilapplikationen
Vi undersøgte først studentens rejse gennem vores mest populære produkt — General-kurset. På det tidspunkt arbejdede jeg i Skyengs børneafdeling, og vi ville se, hvor effektivt mobilapplikationen fungerede for vores børnepublikum.
Ved at tage logfilerne og køre dem gennem et script, fik jeg noget som dette:
Startknuden — Start General, og nedenunder tre udgående noder: eleven "faldt i søvn", skiftede kursus, afsluttede kurset.
- Fell asleep, "Faldt i søvn" — betyder, at han ikke længere deltager i undervisningen; sandsynligvis er han ikke længere aktiv. Vi kalder dette optimistisk for "faldt i søvn", da han i teorien stadig har mulighed for at fortsætte sin uddannelse. Det værste resultat for os.
- Dropped general, Skiftede kursus — gik fra General til noget andet og er blevet væk fra vores Markov-kæde.
- Finished course, Afsluttede kurset — en ideel tilstand; personen har gennemført 80% af lektionerne (ikke alle lektioner er obligatoriske).
Indtræden i noden successful class betyder, at lektionen blev gennemført succesfuldt på vores platform med læreren. Den registrerer fremdriften i kurset og nærmere sig ønsket resultat — "Afsluttede kurset". Det er vigtigt for os, at eleverne deltager i den så meget som muligt.
For at få mere præcise kvantitative konklusioner for mobilapplikationen (noden app session) byggede vi separate kæder for hver af de afsluttende noder og sammenlignede derefter parvis vægtene af kanterne:
- fra app session tilbage til den samme;
- fra app session til successful class;
- fra successful class til app session.
Til venstre — studerende, der har afsluttet kurset; til højre — "faldet i søvn".
Disse tre kanter viser forbindelsen mellem studentens succes og brugen af mobilapplikationen. Vi forventede at se, at de studerende, der har afsluttet kurset, ville have en stærkere forbindelse til applikationen end de "faldet i søvn". Men i realiteten fik vi præcist de modsatte resultater:
- Vi blev overbevist om, at forskellige brugergrupper interagerer forskelligt med mobilapplikationen.
- Succesful studerende bruger mindre intensivt mobilapplikationen;
- Sovende studerende bruger mere aktivt mobilapplikationen.
Det betyder, at 'sovende' studerende begynder at tilbringe mere og mere tid i mobilapplikationen og i sidste ende forbliver der for altid.
Først blev vi overraskede, men efter at have tænkt over det, indså vi, at det er en helt naturlig effekt. I sin tid studerede jeg fransk for egen hånd ved at bruge to værktøjer: mobilapplikationen og grammatikforelæsninger på YouTube. I starten delte jeg tiden mellem dem i forholdet 50 til 50. Men applikationen er sjovere, der er gamification, alt er simpelt, hurtigt og tydeligt, mens man i forelæsningerne skal forstå, skrive noget ned og øve sig i notebogen. Med tiden begyndte jeg at tilbringe mere tid på min smartphone, indtil andelen nåede op på 100%: hvis man bruger tre timer i den, skabes der en falsk følelse af gennemført arbejde, hvilket gør, at man ikke har nogen lyst til at gå ud og lytte til noget.
Men hvordan kan det være? For vi skabte jo netop mobilapplikationen, , gamificerede den, gjorde den attraktiv, så folk bruger tid i den, men det viser sig, at den kun distraherer dem? Den reelle årsag er, at teamet bag mobilapplikationen har klaret deres opgaver så godt, at den er blevet et fantastisk selvstændigt produkt og er begyndt at falde ud af vores økosystem.
Som et resultat af undersøgelsen kom vi til forståelse for, at mobilapplikationen skal ændres på en måde, så den mindre afleder fra det primære læringsforløb. Dette gælder både for børn og voksne. Dette arbejde er i gang.
Andet tilfælde: onboarding-bugs
Onboarding er en valgfri supplerende procedure ved registrering af nye elever, som fjerner potentielle tekniske problemer i fremtiden. Det grundlæggende scenario indebærer, at personen registrerer sig på landing-siden, får adgang til deres personlige konto, bliver kontaktet og får en introduktionslektion. Vi bemærker dog en stor procentdel af tekniske vanskeligheder under introduktionslektionen: forkert version af browseren, mikrofon eller lyd fungerer ikke, læreren kan ikke straks give en løsning, og alt dette er særligt udfordrende, når det drejer sig om børn. Derfor har vi udviklet en supplerende applikation i den personlige konto, hvor man kan udføre fire enkle trin: kontrollere browseren, kameraet, mikrofonen og bekræfte, at forældrene vil være til stede under introduktionslektionen (for det er dem, der betaler for børns uddannelse).
Disse få sider om onboarding viste følgende tragt:
1: startblok med tre lidt forskellige (afhængig af kunden) login-password formularer.
2: afkrydsningsfelt for accept af den supplerende onboarding-procedure.
2.1-2.3: kontrol af forældres tilstedeværelse, version af Chrome og lyd.
3: den afsluttende blok.
Det ser meget naturligt ud: i de første to trin falder størstedelen af besøgende fra, når de indser, at de skal udfylde noget, kontrollere, og at der ikke er tid. Hvis kunden når til tredje trin — så er de næsten garanteret til at nå til slutningen. I tragten ses ikke nogen årsager til at mistænke noget.
Vi besluttede alligevel at analysere vores onboarding ikke på den klassiske endimensionale tragt, men ved hjælp af Markov-kæden. Vi inkluderede lidt flere begivenheder, kørte scriptet og opnåede følgende:
Man kan kun forstå én ting i dette kaos: at noget gik galt. Onboarding-processen er lineær, det er indbygget i designet, og der bør ikke være et sådant netværk af forbindelser. Her ses det straks, at brugeren kastes mellem trin, hvor der slet ikke bør være overgange.
Der kan være to årsager til dette mærkelige billede:
- fejl er sneget ind i logdatabasen;
- fejl findes i selve produktet — onboarding-processen.
Den første årsag er sandsynligvis til stede, men det er ret arbejdsintensivt at kontrollere, og reparation af logs vil ikke forbedre UX. Men hvad angår den anden, hvis den findes, skulle vi hurtigt have gjort noget. Derfor gik vi i gang med at undersøge noderne, identificere kanter, der ikke burde være der, og finde årsagerne til deres forekomst. Vi så, at nogle brugere stod fast og gik i cirkler, andre røg ud fra midten tilbage til starten, mens tredje gruppe generelt ikke kunne komme væk fra de første to trin. Vi sendte dataene til QA — og ja, det viste sig, at der var mange fejl i onboarding-processen: det var et biprodukt, lidt klodset, og det var ikke blevet testet grundigt, da vi ikke forventede problemer. Nu er hele tilmeldingsprocessen ændret.
Denne historie viste os en uventet anvendelse af Markov-kæder inden for QA.
Prøv selv!
Jeg har lagt min tilgængeligt — brug det gerne. Dokumentationen findes på GitHub, spørgsmål kan stilles her, jeg vil forsøge at besvare dem alle.
Og nogle nyttige links: , . Og her om Markov-kæder. Grafene i artiklen er lavet med .
Kilde: habr.com
