It is wichtich foar ús om te begripen wat der bart mei ús studinten tidens training en hoe't dizze eveneminten it resultaat beynfloedzje, dus bouwe wy in Customer Journey Map - in kaart fan klantûnderfining. It learproses is ommers net wat kontinu en yntegraal, it is in keatling fan inoar ferbûn eveneminten en aksjes fan 'e studint, en dizze aksjes kinne sterk ferskille tusken ferskate studinten. No hat er syn les ôfmakke: wat sil er dan dwaan? Sil it nei húswurk gean? Sil it in mobile applikaasje lansearje? Sil hy fan kursus feroarje, freegje om leararen te feroarjen? Sille jo direkt nei de folgjende les gean? Of sil er gewoan teloarsteld fuortgean? Is it mooglik, troch dizze kaart te analysearjen, patroanen te identifisearjen dy't liede ta it suksesfolle foltôgjen fan 'e kursus of, oarsom, ta de "dropout" fan 'e studint?
Typysk wurde spesjalisearre, heul djoere sletten boarne-ark brûkt om CJM te bouwen. Mar wy woenen mei wat ienfâldichs komme, dat minimale ynspanning freget en, as it mooglik is, iepen boarne. Dat it idee kaam op om Markov-keatlingen te brûken - en wy binne slagge. Wy bouden in kaart, ynterpretearre gegevens oer studintgedrach yn 'e foarm fan in grafyk, seagen folslein net-foar de hân lizzende antwurden op wrâldwide saaklike problemen, en fûnen sels djip ferburgen bugs. Wy diene dit alles mei iepen boarne Python-skriptoplossingen. Yn dit artikel sil ik prate oer twa gefallen mei dy heul net-foar de hân lizzende resultaten en it skript mei elkenien diele.
Dus, Markov-keatlingen litte de kâns fan transysjes tusken eveneminten sjen. Hjir is in primityf foarbyld fan Wikipedia:
Hjir binne "E" en "A" eveneminten, de pylken binne oergongen tusken har (ynklusyf de oergong fan in evenemint nei itselde), en de gewichten fan 'e pylken binne de kâns op oergong ("gewogen rjochte grafyk").
Wat hast brûkt?
It circuit waard oplaat mei standert Python-funksjonaliteit, dy't waard fiede mei studintaktiviteitslogs. De grafyk op 'e resultearjende matrix waard konstruearre troch de NetworkX-bibleteek.
It logboek sjocht der sa út:
Dit is in csv-bestân mei in tabel fan trije kolommen: studinte-id, namme fan it evenemint, tiid doe't it barde. Dizze trije fjilden binne genôch om de bewegingen fan 'e kliïnt op te spoaren, in kaart te bouwen en úteinlik in Markov-ketting te krijen.
De bibleteek jout de konstruearre grafiken werom yn .dot- of .gexf-formaat. Om it eardere te visualisearjen, kinne jo it fergese Graphviz-pakket (gvedit-ark) brûke, wy wurken mei .gexf en Gephi, ek fergees.
Folgjende wol ik twa foarbylden jaan fan it brûken fan Markov-keatlingen, wêrtroch't wy in frisse blik op ús doelen, edukative prosessen en it Skyeng-ekosysteem sels kinne nimme. No, reparearje de bugs.
Earste gefal: mobile applikaasje
Om te begjinnen hawwe wy de studintereis ûndersocht troch ús populêrste produkt - de Algemiene kursus. Op dat stuit wurke ik yn 'e berne-ôfdieling fan Skyeng en wy woene sjen hoe effektyf de mobile applikaasje wurke mei it publyk fan ús bern.
Troch de logs te nimmen en se troch it skript te rinnen, krige ik sa'n ding:
De startknooppunt is Start Algemien, en oan 'e ûnderkant binne d'r trije útfierknooppunten: de studint "foel yn 'e sliep", feroare kursus en foltôge de kursus.
- Sliep yn 'e sliep, "Sliep yn sliep" - dit betsjut dat hy gjin lessen mear nimt, wierskynlik foel hy ôf. Wy neame dizze steat optimistysk "sliepe", om't ... yn teory hat er noch de kâns om syn stúdzje troch te gean. Slimste resultaat foar ús.
- Algemien falle, koers feroare - oerskeakele fan Algemien nei wat oars en ferlern gien foar ús Markov-ketting.
- Kursus foltôge, kursus foltôge - ideale steat, de persoan hat 80% fan 'e lessen foltôge (net alle lessen binne ferplicht).
Yn it suksesfolle klasseknooppunt komme betsjut dat jo de les op ús platfoarm mei de learaar mei súkses foltôgje. It registrearret foarútgong lâns de kursus en oanpak fan it winske resultaat - "De kursus foltôge." It is foar ús wichtich dat learlingen safolle mooglik bywenje.
Om krekter kwantitative konklúzjes te krijen foar de mobile applikaasje (app-sesjeknooppunt), bouden wy aparte keatlingen foar elk fan 'e definitive knopen en fergelike dan de rânegewichten pearswiis:
- fan 'e app-sesje werom nei it;
- fan app-sesje oant suksesfolle klasse;
- fan suksesfolle klasse oant app-sesje.
Links binne studinten dy't de kursus foltôge hawwe, rjochts dejingen dy't "yn sliep foelen"
Dizze trije rânen litte de relaasje sjen tusken it sukses fan in studint en har gebrûk fan 'e mobile app. Wy ferwachten te sjen dat studinten dy't de kursus foltôge in sterkere ferbining soene hawwe mei de applikaasje dan studinten dy't yn 'e sliep foelen. Yn werklikheid krigen wy lykwols krekt de tsjinoerstelde resultaten:
- wy hawwe derfoar soarge dat ferskate groepen brûkers ferskillend ynteraksje mei de mobile applikaasje;
- suksesfolle studinten brûke de mobile applikaasje minder yntinsyf;
- studinten dy't yn 'e sliep falle brûke de mobile applikaasje aktyfer.
Dit betsjut dat studinten dy't yn sliep falle mear en mear tiid begjinne te besteegjen oan 'e mobile applikaasje en, op it lêst, foar altyd yn bliuwe.
Earst wiene wy ferrast, mar nei it neitinken, realisearren wy dat dit in folslein natuerlik effekt wie. Op in stuit studearre ik sels Frânsk mei twa ark: in mobile applikaasje en grammatikalêzingen op YouTube. Earst haw ik de tiid tusken har ferdield yn in ferhâlding fan 50 oant 50. Mar de applikaasje is leuker, der is gamifikaasje, alles is ienfâldich, fluch en dúdlik, mar yn 'e lêzing moatte jo deryn dûke, wat opskriuwe , oefenje yn in notebook. Stadichoan begon ik mear tiid te besteegjen oan myn smartphone, oant har oandiel groeide nei 100%: as jo der trije oeren oan besteegje, meitsje jo in falsk gefoel fan foltôge wurk, wêrtroch't jo gjin winsk hawwe om nei alles te harkjen .
Mar hoe kin dit? Wy hawwe ommers spesjaal in mobile applikaasje makke, , gamified it, makke it oantreklik sadat minsken soene besteegje tiid yn it, mar it docht bliken dat it allinnich ôfliedt harren? Yn feite is de reden dat it mobile applikaasjeteam har taken te goed omgie, wêrtroch't it in koel, selsfoarsjennend produkt waard en út ús ekosysteem begon te fallen.
As gefolch fan it ûndersyk waard dúdlik dat de mobile applikaasje op ien of oare manier feroare wurde moast, sadat it minder ôfliede soe fan 'e haadkursus. En sawol bern as folwoeksenen. Dit wurk is op it stuit dwaande.
Twadde gefal: onboarding bugs
Onboarding is in opsjonele ekstra proseduere by it registrearjen fan in nije studint, wêrtroch potensjele technyske problemen yn 'e takomst eliminearje. It basissenario giet derfan út dat in persoan hat registrearre op 'e lâningsside, tagong krigen ta syn persoanlike akkount, kontakt opnommen wurdt en in ynliedende les jûn wurdt. Tagelyk konstatearje wy in grut persintaazje technyske swierrichheden tidens de ynliedende les: de ferkearde ferzje fan 'e browser, de mikrofoan of lûd wurket net, de learaar kin net fuortendaliks in oplossing foarstelle, en dit alles is benammen lestich as it giet oan bern. Dêrom hawwe wy in ekstra applikaasje ûntwikkele yn jo persoanlike akkount, wêr't jo fjouwer ienfâldige stappen kinne foltôgje: kontrolearje jo blêder, kamera, mikrofoan en befestigje dat âlders yn 'e buert sille wêze tidens de ynliedende les (it binne ommers dejingen dy't betelje foar ûnderwiis fan har bern).
Dizze pear onboarding-siden lieten in trechter sa sjen:
1: startblok mei trije wat ferskillende (ôfhinklik fan de kliïnt) oanmeld- en wachtwurdynfierformulieren.
2: karfakje akkoard mei de ekstra onboardingproseduere.
2.1-2.3: Kontrolearje foar oanwêzigens fan âlders, Chrome-ferzje en lûd.
3: lêste blok.
It sjocht der hiel natuerlik út: yn de earste twa stappen, de measte besikers ferlitte, realisearje dat der wat te foljen, kontrolearje, mar der is gjin tiid. As de klant de tredde stap berikt hat, dan komt hy hast wis yn de finale. D'r is gjin inkelde reden om wat op 'e trechter te fermoedzjen.
Dochs hawwe wy besletten om ús onboarding te analysearjen net mei in klassike iendimensjonale trechter, mar mei in Markov-ketting. Wy draaiden in bytsje mear eveneminten oan, rûnen it skript en krigen dit:
Yn dizze gaos is mar ien ding dúdlik te begripen: der gie wat mis. It onboardingproses is lineêr, dit is inherent oan it ûntwerp, d'r moat net sa'n web fan ferbiningen yn wêze. En hjir is it daliks dúdlik dat de brûker tusken stappen smiten wurdt, dêr't hielendal gjin oergongen tusken komme moatte.
D'r kinne twa redenen wêze foar dizze frjemde foto:
- skoalen krûpen yn 'e logdatabase;
- D'r binne flaters yn it produkt sels - onboarding.
De earste reden is nei alle gedachten wier, mar it testen is frij arbeidsintensyf, en it korrigearjen fan de logs sil net helpe om de UX te ferbetterjen. Mar mei de twadde, as dy bestiet, moast der driuwend wat dien wurde. Dêrom gongen wy nei de knopen te sjen, rânen te identifisearjen dy't net moatte bestean, en sykje nei de redenen foar har foarkommen. Wy seagen dat guon brûkers stiene fêst en rûnen yn sirkels, oaren foelen út it midden nei it begjin, en oaren koene yn prinsipe net út 'e earste twa stappen komme. Wy hawwe de gegevens oerbrocht nei QA - en ja, it die bliken dat d'r genôch bugs wiene yn onboarding: dit is sa'n byprodukt, in bytsje in kruk, it waard net djip genôch hifke, om't ... Wy hiene gjin problemen ferwachte. No is it hiele opnameproses feroare.
Dit ferhaal liet ús in ûnferwachte tapassing fan Markov-keatlingen op it mêd fan QA sjen.
Besykje it sels!
Ik pleatste myn yn it publike domein - brûk it foar jo sûnens. Dokumintaasje op GitHub, fragen kinne hjir steld wurde, ik sil besykje alles te beantwurdzjen.
No, brûkbere keppelings: , . En hjir oer Markov keatlingen. De grafiken yn it artikel binne makke mei .
Boarne: www.habr.com