Det er vigtigt for os at forstå, hvad der sker med vores elever under træningen, og hvordan disse begivenheder påvirker resultatet, så vi bygger et Customer Journey Map - et kort over kundeoplevelsen. Læringsprocessen er jo ikke noget kontinuerligt og integreret, det er en kæde af indbyrdes forbundne begivenheder og handlinger hos eleven, og disse handlinger kan variere meget mellem forskellige elever. Nu har han afsluttet sin lektion: hvad vil han gøre nu? Vil det gå til lektier? Vil det lancere en mobilapplikation? Vil han ændre kurs, bede om at skifte lærer? Vil du gå direkte til næste lektion? Eller vil han bare gå skuffet? Er det muligt ved at analysere dette kort at identificere mønstre, der fører til en vellykket gennemførelse af kurset eller omvendt til "frafald" af den studerende?
Typisk bruges specialiserede, meget dyre lukkede kildeværktøjer til at bygge CJM. Men vi ønskede at finde på noget simpelt, der kræver minimal indsats og om muligt open source. Så ideen opstod om at bruge Markov-kæder – og det lykkedes. Vi byggede et kort, fortolkede data om elevernes adfærd i form af en graf, så helt uoplagte svar på globale forretningsproblemer og fandt endda dybt skjulte fejl. Vi gjorde alt dette ved hjælp af open source Python-scriptløsninger. I denne artikel vil jeg tale om to tilfælde med de meget ikke-indlysende resultater og dele manuskriptet med alle.
Så Markov-kæder viser sandsynligheden for overgange mellem begivenheder. Her er et primitivt eksempel fra Wikipedia:
Her er "E" og "A" begivenheder, pilene er overgange mellem dem (inklusive overgangen fra en begivenhed til den samme), og pilenes vægt er sandsynligheden for overgang ("vægtet rettet graf").
Hvad brugte du?
Kredsløbet blev trænet med standard Python-funktionalitet, som blev fodret med elevaktivitetslogs. Grafen på den resulterende matrix blev konstrueret af NetworkX-biblioteket.
Loggen ser sådan ud:
Dette er en csv-fil, der indeholder en tabel med tre kolonner: elev-id, navn på begivenheden, tidspunkt, hvor den fandt sted. Disse tre felter er nok til at spore klientens bevægelser, bygge et kort og i sidste ende få en Markov-kæde.
Biblioteket returnerer de konstruerede grafer i .dot- eller .gexf-format. For at visualisere førstnævnte kan du bruge den gratis Graphviz-pakke (gvedit-værktøj), vi arbejdede med .gexf og Gephi, også gratis.
Dernæst vil jeg gerne give to eksempler på brug af Markov-kæder, som gjorde det muligt for os at tage et nyt kig på vores mål, uddannelsesprocesser og selve Skyeng-økosystemet. Nå, ret fejlene.
Første tilfælde: mobilapplikation
Til at begynde med udforskede vi elevernes rejse gennem vores mest populære produkt – det generelle kursus. På det tidspunkt arbejdede jeg i børneafdelingen i Skyeng, og vi ville se, hvor effektivt mobilapplikationen arbejdede med vores børns publikum.
Da jeg tog logfilerne og kørte dem gennem scriptet, fik jeg noget som dette:
Startknudepunktet er Start Generelt, og i bunden er der tre udgangsnoder: eleven "faldt i søvn", skiftede kursus og afsluttede kurset.
- Faldt i søvn, "Fallede i søvn" - det betyder, at han ikke længere tager undervisning, sandsynligvis faldt han fra. Vi kalder optimistisk denne tilstand "sovende", fordi... i teorien har han stadig mulighed for at fortsætte sine studier. Værste resultat for os.
- Droppede general, Ændrede kurs - skiftede fra General til noget andet og gik vild for vores Markov-kæde.
- Afsluttet kursus, Afsluttet kursus - ideel stand, personen har gennemført 80% af lektionerne (ikke alle timer er påkrævet).
At komme ind i den vellykkede klasseknude betyder at gennemføre lektionen på vores platform med succes sammen med læreren. Den registrerer fremskridt langs kurset og tilgang til det ønskede resultat - "Fuldførte kurset." Det er vigtigt for os, at eleverne deltager så meget som muligt.
For at få mere nøjagtige kvantitative konklusioner for mobilapplikationen (appsessionsknudepunkt), byggede vi separate kæder for hver af de endelige knudepunkter og sammenlignede derefter kantvægtene parvis:
- fra app-sessionen tilbage til det;
- fra app-session til vellykket undervisning;
- fra vellykket klasse til app-session.
Til venstre er elever, der gennemførte kurset, til højre er dem, der "faldt i søvn"
Disse tre kanter viser forholdet mellem en elevs succes og deres brug af mobilappen. Vi forventede at se, at studerende, der gennemførte kurset, ville have en stærkere tilknytning til ansøgningen end studerende, der faldt i søvn. Men i virkeligheden fik vi præcis de modsatte resultater:
- vi sørgede for, at forskellige grupper af brugere interagerer forskelligt med mobilapplikationen;
- succesrige studerende bruger mobilapplikationen mindre intensivt;
- studerende, der falder i søvn, bruger mobilapplikationen mere aktivt.
Det betyder, at elever, der falder i søvn, begynder at bruge mere og mere tid i mobilapplikationen og i sidste ende forbliver i den for evigt.
Først blev vi overraskede, men efter at have tænkt over det, indså vi, at dette var en helt naturlig effekt. På et tidspunkt studerede jeg fransk på egen hånd ved hjælp af to værktøjer: en mobilapplikation og grammatikforelæsninger på YouTube. Først delte jeg tiden mellem dem i forholdet 50 til 50. Men applikationen er sjovere, der er gamification, alt er enkelt, hurtigt og overskueligt, men i foredraget skal du dykke ned i det, skrive noget ned , øv dig i en notesbog. Efterhånden begyndte jeg at bruge mere tid på min smartphone, indtil dens andel voksede til 100%: hvis du bruger tre timer på den, skaber du en falsk følelse af færdigt arbejde, på grund af hvilket du ikke har lyst til at gå og lytte til noget .
Men hvordan kan dette være? Vi har jo lavet specielt en mobilapplikation, , gamificerede det, gjorde det attraktivt, så folk ville bruge tid i det, men det viser sig, at det kun distraherer dem? Faktisk er årsagen, at mobilapplikationsteamet klarede sine opgaver for godt, hvilket resulterede i, at det blev et sejt, selvforsynende produkt og begyndte at falde ud af vores økosystem.
Som et resultat af forskningen blev det klart, at mobilapplikationen skulle ændres på en eller anden måde, så den ville være mindre distraherende fra hovedforløbet. Og både børn og voksne. Dette arbejde er i gang i øjeblikket.
Andet tilfælde: onboarding-fejl
Onboarding er en valgfri yderligere procedure, når du registrerer en ny studerende, hvilket eliminerer potentielle tekniske problemer i fremtiden. Grundscenariet forudsætter, at en person har registreret sig på landingssiden, fået adgang til sin personlige konto, bliver kontaktet og givet en introduktionslektion. Samtidig noterer vi en stor procentdel af tekniske vanskeligheder under den indledende lektion: den forkerte version af browseren, mikrofonen eller lyden virker ikke, læreren kan ikke umiddelbart foreslå en løsning, og alt dette er især svært, når det kommer til børn. Derfor har vi udviklet en ekstra applikation på din personlige konto, hvor du kan gennemføre fire enkle trin: Tjek din browser, kamera, mikrofon og bekræft, at forældre vil være i nærheden under introduktionstimen (det er trods alt dem, der betaler for deres børns uddannelse).
Disse få onboarding-sider viste en tragt som denne:
1: startblok med tre lidt forskellige (afhængigt af klienten) login- og adgangskodeindtastningsformularer.
2: afkrydsningsfelt accepterer den yderligere onboarding-procedure.
2.1-2.3: Tjek for forældres tilstedeværelse, Chrome-version og lyd.
3: sidste blok.
Det ser meget naturligt ud: i de første to trin forlader de fleste besøgende, idet de indser, at der er noget at udfylde, tjekke, men der er ingen tid. Hvis klienten har nået det tredje trin, vil han næsten helt sikkert nå finalen. Der er ikke en eneste grund til at mistænke noget på tragten.
Ikke desto mindre besluttede vi at analysere vores onboarding ikke på en klassisk endimensionel tragt, men ved hjælp af en Markov-kæde. Vi tændte for lidt flere begivenheder, kørte scriptet og fik dette:
I dette kaos kan kun én ting tydeligt forstås: noget gik galt. Onboarding-processen er lineær, dette er iboende i designet, der bør ikke være et sådant net af forbindelser i det. Og her er det med det samme tydeligt, at brugeren kastes mellem trin, som der slet ikke skal være overgange imellem.
Der kan være to grunde til dette mærkelige billede:
- stimer sneg sig ind i logdatabasen;
- Der er fejl i selve produktet - onboarding.
Den første grund er højst sandsynligt sand, men at teste den er ret arbejdskrævende, og korrigering af logfilerne vil ikke hjælpe med at forbedre UX. Men med den anden, hvis den eksisterer, skulle der gøres noget akut. Derfor gik vi for at se på noderne, identificere kanter, der ikke burde eksistere, og kigge efter årsagerne til deres forekomst. Vi så, at nogle brugere satte sig fast og gik i cirkler, andre faldt ud af midten til begyndelsen, og andre kunne i princippet ikke komme ud af de to første trin. Vi overførte dataene til QA - og ja, det viste sig, at der var nok fejl i onboarding: dette er sådan et biprodukt, lidt af en krykke, det blev ikke testet dybt nok, fordi... Vi forventede ingen problemer. Nu er hele optagelsesprocessen ændret.
Denne historie viste os en uventet anvendelse af Markov-kæder inden for QA.
Prøv det selv!
Jeg postede min i det offentlige domæne - brug det for dit helbred. Dokumentation på GitHub, spørgsmål kan stilles her, jeg vil forsøge at svare på alt.
Nå, nyttige links: , . Og her om Markov-kæder. Graferne i artiklen er lavet vha .
Kilde: www.habr.com