Det er viktig for oss å forstå hva som skjer med elevene våre under opplæring og hvordan disse hendelsene påvirker resultatet, så vi bygger et Customer Journey Map – et kart over kundeopplevelsen. Tross alt er ikke læringsprosessen noe kontinuerlig og integrert, det er en kjede av sammenkoblede hendelser og handlinger til eleven, og disse handlingene kan variere sterkt mellom ulike elever. Nå har han fullført leksjonen: hva skal han gjøre videre? Vil det gå til lekser? Vil det lansere en mobilapplikasjon? Vil han endre kurs, be om å få bytte lærer? Vil du gå rett til neste leksjon? Eller vil han bare gå skuffet? Er det mulig, ved å analysere dette kartet, å identifisere mønstre som fører til vellykket gjennomføring av kurset eller, omvendt, til "frafall" av studenten?
Vanligvis brukes spesialiserte, veldig kostbare verktøy med lukket kildekode for å bygge CJM. Men vi ønsket å finne på noe enkelt, som krever minimal innsats og om mulig åpen kildekode. Så ideen kom opp om å bruke Markov-kjeder – og vi lyktes. Vi bygde et kart, tolket data om elevatferd i form av en graf, så helt uopplagte svar på globale forretningsproblemer, og fant til og med dypt skjulte feil. Vi gjorde alt dette ved å bruke åpen kildekode Python-skriptløsninger. I denne artikkelen vil jeg snakke om to tilfeller med de svært ikke-åpenbare resultatene og dele manuset med alle.
Så Markov-kjeder viser sannsynligheten for overganger mellom hendelser. Her er et primitivt eksempel fra Wikipedia:
Her er "E" og "A" hendelser, pilene er overganger mellom dem (inkludert overgangen fra en hendelse til den samme), og vektene til pilene er sannsynligheten for overgang ("vektet rettet graf").
Hva brukte du?
Kretsen ble trent med standard Python-funksjonalitet, som ble matet med elevaktivitetslogger. Grafen på den resulterende matrisen ble konstruert av NetworkX-biblioteket.
Loggen ser slik ut:
Dette er en csv-fil som inneholder en tabell med tre kolonner: student-ID, navn på hendelsen, tidspunkt da den skjedde. Disse tre feltene er nok til å spore klientens bevegelser, bygge et kart og til slutt få en Markov-kjede.
Biblioteket returnerer de konstruerte grafene i .dot- eller .gexf-format. For å visualisere førstnevnte kan du bruke den gratis Graphviz-pakken (gvedit-verktøyet), vi jobbet med .gexf og Gephi, også gratis.
Deretter vil jeg gi to eksempler på bruk av Markov-kjeder, som tillot oss å ta en ny titt på målene våre, utdanningsprosessene og selve Skyeng-økosystemet. Vel, fiks feilene.
Første tilfelle: mobilapplikasjon
Til å begynne med utforsket vi studentreisen gjennom vårt mest populære produkt – det generelle kurset. I det øyeblikket jobbet jeg i barneavdelingen til Skyeng, og vi ønsket å se hvor effektivt mobilapplikasjonen fungerte med barnas publikum.
Ved å ta loggene og kjøre dem gjennom skriptet, fikk jeg noe sånt som dette:
Startnoden er Start Generelt, og nederst er det tre utgangsnoder: studenten «sovet», endret kurs og fullførte kurset.
- Sovnet, "Sovnet" - dette betyr at han ikke lenger tar klasser, mest sannsynlig falt han av. Vi kaller optimistisk denne tilstanden "sovende", fordi... i teorien har han fortsatt muligheten til å fortsette studiene. Dårligste resultat for oss.
- Droppet general, endret kurs - byttet fra general til noe annet og gikk seg vill for vår Markov-kjede.
- Ferdig med kurs, Ferdig med kurs - ideell tilstand, personen har fullført 80 % av timene (ikke alle leksjoner er påkrevd).
Å komme inn i den vellykkede klassenoden betyr å fullføre leksjonen på plattformen vår sammen med læreren. Den registrerer fremgang langs kurset og tilnærming til ønsket resultat - "Fullførte kurset." Det er viktig for oss at studentene møter så mye som mulig.
For å få mer nøyaktige kvantitative konklusjoner for mobilapplikasjonen (app-øktnoden), bygde vi separate kjeder for hver av de endelige nodene og sammenlignet deretter kantvektene parvis:
- fra app-økten tilbake til den;
- fra app-økt til vellykket klasse;
- fra vellykket klasse til appøkt.
Til venstre er studenter som fullførte kurset, til høyre er de som "sov"
Disse tre kantene viser forholdet mellom en elevs suksess og deres bruk av mobilappen. Vi forventet å se at studenter som fullførte kurset ville ha en sterkere tilknytning til søknaden enn studenter som sovnet. Imidlertid fikk vi i virkeligheten nøyaktig motsatte resultater:
- vi sørget for at ulike grupper brukere samhandler med mobilapplikasjonen forskjellig;
- suksessrike studenter bruker mobilapplikasjonen mindre intensivt;
- elever som sovner bruker mobilapplikasjonen mer aktivt.
Dette betyr at elever som sovner begynner å bruke mer og mer tid i mobilapplikasjonen og til slutt forblir i den for alltid.
Først ble vi overrasket, men etter å ha tenkt oss om, skjønte vi at dette var en helt naturlig effekt. På en gang studerte jeg fransk på egen hånd ved å bruke to verktøy: en mobilapplikasjon og grammatikkforelesninger på YouTube. Først delte jeg tiden mellom dem i forholdet 50 til 50. Men applikasjonen er morsommere, det er gamification, alt er enkelt, raskt og oversiktlig, men i forelesningen må du fordype deg i det, skrive ned noe , øv i en notatbok. Gradvis begynte jeg å bruke mer tid på smarttelefonen min, til dens andel vokste til 100%: hvis du bruker tre timer på den, skaper du en falsk følelse av fullført arbeid, på grunn av hvilket du ikke har noe ønske om å gå og høre på noe .
Men hvordan kan dette være? Vi har tross alt laget en mobilapplikasjon, , gamifiserte det, gjorde det attraktivt slik at folk ville bruke tid på det, men det viser seg at det bare distraherer dem? Faktisk er årsaken at mobilapplikasjonsteamet taklet oppgavene sine for godt, som et resultat av at det ble et kult, selvforsynt produkt og begynte å falle ut av økosystemet vårt.
Som et resultat av forskningen ble det klart at mobilapplikasjonen måtte endres på en eller annen måte slik at den ville være mindre distraherende fra hovedstudiet. Og både barn og voksne. Dette arbeidet pågår for tiden.
Andre tilfelle: onboarding bugs
Onboarding er en valgfri tilleggsprosedyre når du registrerer en ny student, og eliminerer potensielle tekniske problemer i fremtiden. Grunnscenarioet forutsetter at en person har registrert seg på landingssiden, fått tilgang til sin personlige konto, blir kontaktet og gitt en introduksjonsleksjon. Samtidig noterer vi oss en stor prosentandel av tekniske problemer i løpet av introduksjonsleksjonen: feil versjon av nettleseren, mikrofonen eller lyden fungerer ikke, læreren kan ikke umiddelbart foreslå en løsning, og alt dette er spesielt vanskelig når det gjelder til barn. Derfor har vi utviklet en tilleggsapplikasjon på din personlige konto, der du kan fullføre fire enkle trinn: sjekk nettleseren, kameraet, mikrofonen og bekreft at foreldrene vil være i nærheten under introduksjonstimen (det er tross alt de som betaler for barnas utdanning).
Disse få innføringssidene viste en trakt som denne:
1: startblokk med tre litt forskjellige (avhengig av klient) innloggings- og passordskjemaer.
2: avmerkingsboks godtar den ekstra onboarding-prosedyren.
2.1–2.3: Se etter foreldrenes tilstedeværelse, Chrome-versjon og lyd.
3: siste blokk.
Det ser veldig naturlig ut: i de to første trinnene forlater de fleste besøkende, innser at det er noe å fylle ut, sjekke, men det er ikke tid. Hvis klienten har nådd det tredje trinnet, vil han nesten helt sikkert nå finalen. Det er ikke en eneste grunn til å mistenke noe på trakten.
Likevel bestemte vi oss for å analysere onboardingen vår ikke på en klassisk endimensjonal trakt, men ved å bruke en Markov-kjede. Vi satte på litt flere hendelser, kjørte manuset og fikk dette:
I dette kaoset kan bare én ting forstås klart: noe gikk galt. Onboarding-prosessen er lineær, dette er iboende i designet, det skal ikke være et slikt nett av forbindelser i det. Og her er det umiddelbart klart at brukeren kastes mellom trinnene, mellom hvilke det ikke skal være noen overganger i det hele tatt.
Det kan være to grunner til dette merkelige bildet:
- stimer snek seg inn i loggdatabasen;
- Det er feil i selve produktet – onboarding.
Den første grunnen er mest sannsynlig sann, men å teste den er ganske arbeidskrevende, og korrigering av loggene vil ikke bidra til å forbedre brukeropplevelsen. Men med den andre, hvis den eksisterer, måtte noe raskt gjøres. Derfor gikk vi for å se på nodene, identifisere kanter som ikke skulle eksistere, og se etter årsakene til at de oppsto. Vi så at noen brukere ble sittende fast og gikk i sirkler, andre falt ut av midten til begynnelsen, og andre kunne i prinsippet ikke komme seg ut av de to første trinnene. Vi overførte dataene til QA - og ja, det viste seg at det var nok feil i onboarding: dette er et slikt biprodukt, litt av en krykke, det ble ikke testet dypt nok, fordi... Vi forventet ingen problemer. Nå er hele innspillingsprosessen endret.
Denne historien viste oss en uventet anvendelse av Markov-kjeder innen QA.
Prøv det selv!
Jeg la ut min i det offentlige domene - bruk det for helsen din. Dokumentasjon på GitHub, spørsmål kan stilles her, jeg skal prøve å svare på alt.
Vel, nyttige linker: , . Og her om Markov-kjeder. Grafene i artikkelen er laget vha .
Kilde: www.habr.com