Meie jaoks on oluline mõista, mis meie õpilastega koolituse ajal toimub ja kuidas need sündmused tulemust mõjutavad, seetõttu koostame Klienditeekonna kaardi – kliendikogemuse kaardi. Õppeprotsess ei ole ju midagi pidevat ja terviklikku, see on omavahel seotud sündmuste ja õpilase tegevuste ahel ning need tegevused võivad erinevate õpilaste vahel vägagi erineda. Nüüd on tal õppetund läbi saanud: mida ta edasi teeb? Kas see läheb kodutööks? Kas see käivitab mobiilirakenduse? Kas ta muudab kurssi, palub õpetajaid vahetada? Kas lähete otse järgmisesse õppetundi? Või lahkub ta lihtsalt pettunult? Kas seda kaarti analüüsides on võimalik tuvastada mustreid, mis viivad kursuse eduka läbimiseni või, vastupidi, üliõpilase „väljalangemiseni“?
Tavaliselt kasutatakse CJM-i ehitamiseks spetsiaalseid ja väga kalleid suletud lähtekoodiga tööriistu. Kuid me tahtsime välja mõelda midagi lihtsat, mis nõuab minimaalset pingutust ja võimalusel avatud lähtekoodiga kasutamist. Nii tekkiski idee kasutada Markovi kette – ja see õnnestus. Koostasime kaardi, tõlgendasime õpilaste käitumise andmeid graafiku kujul, nägime täiesti ebaselgeid vastuseid globaalsetele äriprobleemidele ja leidsime isegi sügavalt peidetud vigu. Seda kõike tegime avatud lähtekoodiga Pythoni skriptilahenduste abil. Selles artiklis räägin kahest juhtumist, mille tulemused on väga ebaselged, ja jagan skripti kõigiga.
Niisiis näitavad Markovi ahelad sündmustevaheliste üleminekute tõenäosust. Siin on primitiivne näide Wikipediast:
Siin on “E” ja “A” sündmused, nooled on üleminekud nende vahel (kaasa arvatud üleminek sündmuselt samale) ja noolte kaalud on ülemineku tõenäosus (“kaalutud suunatud graafik”).
Mida sa kasutasid?
Ringrada treeniti standardse Pythoni funktsionaalsusega, mida toideti õpilaste tegevuste logidega. Saadud maatriksi graafik koostas NetworkX raamatukogu.
Logi näeb välja selline:
See on csv-fail, mis sisaldab kolme veeru tabelit: õpilase ID, sündmuse nimi, sündmuse toimumise aeg. Nendest kolmest väljast piisab, et jälgida kliendi liikumist, koostada kaart ja lõpuks saada Markovi kett.
Teek tagastab koostatud graafikud .dot või .gexf vormingus. Esimese visualiseerimiseks saab kasutada tasuta paketti Graphviz (tööriist gvedit), töötasime .gexf ja Gephiga, samuti tasuta.
Järgmisena tooksin kaks näidet Markovi kettide kasutamisest, mis võimaldasid heita uue pilgu nii meie eesmärkidele, haridusprotsessidele kui ka Skyengi ökosüsteemile endale. Noh, parandage vead.
Esimene juhtum: mobiilirakendus
Alustuseks uurisime õpilaste teekonda läbi meie kõige populaarsema toote – üldkursuse. Sel hetkel töötasin Skyengi lasteosakonnas ja tahtsime näha, kui tõhusalt mobiilirakendus meie lastepublikuga töötab.
Võttes logid ja käivitades need skripti kaudu, sain midagi sellist:
Algsõlm on Start General ja allosas on kolm väljundsõlme: õpilane "uinus", muutis kurssi ja lõpetas kursuse.
- Magama jäi, "Magasin" - see tähendab, et ta ei võta enam tunde, tõenäoliselt kukkus ta maha. Me nimetame seda olekut optimistlikult "uinuks", sest... teoreetiliselt on tal veel võimalus õpinguid jätkata. Meie jaoks halvim tulemus.
- Loobunud kindralist, muutnud kurssi – vahetanud kindralt millegi muu vastu ja eksinud meie Markovi keti jaoks.
- Kursuse lõpetanud, Kursuse lõpetanud - ideaalne seisund, inimene on läbinud 80% õppetundidest (kõiki tunde pole vaja).
Eduka klassi sõlme sattumine tähendab õppetunni edukat läbimist meie platvormil koos õpetajaga. See salvestab kursuse edenemise ja lähenemise soovitud tulemusele - "Kursus on läbitud". Meie jaoks on oluline, et õpilased osaleksid võimalikult palju.
Mobiilirakenduse (rakenduse seansi sõlme) kohta täpsemate kvantitatiivsete järelduste saamiseks koostasime iga lõpliku sõlme jaoks eraldi ahelad ja seejärel võrdlesime servade kaalu paarikaupa:
- rakenduse seansist tagasi selle juurde;
- rakendusesessioonist eduka klassini;
- edukast klassist rakenduse seansini.
Vasakul on kursuse läbinud õpilased, paremal need, kes "magasid"
Need kolm serva näitavad seost õpilase edukuse ja mobiilirakenduse kasutamise vahel. Ootasime, et kursuse läbinud õpilastel on rakendusega tugevam seos kui magama jäänud õpilastel. Tegelikkuses saime aga täpselt vastupidised tulemused:
- veendusime, et erinevad kasutajarühmad suhtlevad mobiilirakendusega erinevalt;
- edukad õpilased kasutavad mobiilirakendust vähem intensiivselt;
- magama jäänud õpilased kasutavad mobiilirakendust aktiivsemalt.
See tähendab, et magama jäänud õpilased hakkavad järjest rohkem aega veetma mobiilirakenduses ja jäävad lõpuks sinna igaveseks.
Alguses olime üllatunud, kuid järele mõeldes saime aru, et see on täiesti loomulik efekt. Omal ajal õppisin prantsuse keelt iseseisvalt, kasutades kahte tööriista: mobiilirakendust ja grammatika loenguid YouTube'is. Algul jagasin nende vahel aja vahekorras 50:50. Aga rakendus on lõbusam, on mängulisust, kõik on lihtne, kiire ja selge, aga loengus tuleb sellesse süveneda, midagi kirja panna , harjutage vihikus. Tasapisi hakkasin nutitelefonis rohkem aega veetma, kuni selle osakaal kasvas 100%-ni: kui kulutad sellele kolm tundi, tekib võlts tehtud töö tunne, mille tõttu ei teki soovi midagi kuulama minna. .
Aga kuidas see saab olla? Lõppude lõpuks lõime spetsiaalselt mobiilirakenduse, , muutis selle atraktiivseks, et inimesed selles aega veedaksid, kuid selgub, et see tõmbab ainult nende tähelepanu kõrvale? Tegelikult on põhjus selles, et mobiilirakenduste tiim tuli oma ülesannetega liiga hästi toime, mille tulemusel sai sellest lahe, isemajandav toode ja hakkas meie ökosüsteemist välja kukkuma.
Uurimistöö tulemusena selgus, et mobiilirakendust tuleb kuidagi muuta, et see põhiõppekursusest vähem segaks. Ja nii lapsed kui ka täiskasvanud. See töö on praegu pooleli.
Teine juhtum: sisselogimisvead
Onboarding on valikuline lisaprotseduur uue õpilase registreerimisel, mis välistab võimalikud tehnilised probleemid tulevikus. Põhistsenaarium eeldab, et inimene on maandumislehele registreerunud, saanud ligipääsu oma isiklikule kontole, temaga võetakse ühendust ja antakse talle tutvustav õppetund. Samal ajal märgime sissejuhatava tunni ajal suure osa tehnilistest raskustest: vale brauseri versioon, mikrofon või heli ei tööta, õpetaja ei saa kohe lahendust välja pakkuda ja see kõik on eriti keeruline, kui see tuleb. lastele. Seetõttu oleme teie isiklikule kontole välja töötanud lisarakenduse, kus saate teha neli lihtsat sammu: kontrollida oma brauserit, kaamerat, mikrofoni ja kinnitada, et vanemad on tutvumistunni ajal läheduses (need maksavad ju nende laste haridus).
Need mõned liitumislehed näitasid sellist lehtrit:
1: stardiplokk kolme veidi erineva (olenevalt kliendist) sisselogimise ja parooli sisestamise vormiga.
2: märkeruut, mis nõustub täiendava liitumisprotseduuriga.
2.1–2.3: kontrollige vanema kohalolekut, Chrome'i versiooni ja heli.
3: viimane plokk.
See näeb välja väga loomulik: esimese kahe sammuga lahkub suurem osa külastajatest, mõistes, et on, mida täita, kontrollida, aga aega pole. Kui klient on jõudnud kolmandale astmele, jõuab ta peaaegu kindlasti finaali. Pole ainsatki põhjust lehtris midagi kahtlustada.
Sellegipoolest otsustasime analüüsida oma liitumist mitte klassikalise ühemõõtmelise lehtri, vaid Markovi ketti kasutades. Lülitasime sisse veel veidi sündmusi, käivitasime skripti ja saime järgmise:
Selles kaoses saab selgelt aru ainult ühest: midagi läks valesti. Sisselülitusprotsess on lineaarne, see on disainile omane, selles ei tohiks sellist ühenduste võrku olla. Ja siin on kohe selge, et kasutaja visatakse sammude vahele, mille vahel ei tohiks üldse üleminekuid olla.
Sellel kummalisel pildil võib olla kaks põhjust:
- palkide andmebaasi hiilisid parved;
- Tootes endas on vigu – onboarding.
Esimene põhjus on suure tõenäosusega tõsi, kuid selle testimine on üsna töömahukas ja logide parandamine ei aita UX-i parandada. Aga teisega, kui see on olemas, tuli kiiresti midagi ette võtta. Seetõttu läksime vaatama sõlme, tuvastama servi, mida ei tohiks eksisteerida, ja otsima nende esinemise põhjuseid. Nägime, et mõned kasutajad jäid kinni ja kõndisid ringi, teised kukkusid keskelt algusesse välja ja teised ei saanud põhimõtteliselt kahest esimesest sammust välja. Andme edastasime QA-sse – ja jah, selgus, et onboardingus oli piisavalt vigu: see on selline kõrvalsaadus, natuke kark, seda ei testitud piisavalt sügavalt, sest... Me ei oodanud mingeid probleeme. Nüüd on kogu salvestusprotsess muutunud.
See lugu näitas meile Markovi kettide ootamatut rakendust kvaliteedikontrolli valdkonnas.
Proovige ise!
Postitasin oma avalikus kasutuses – kasutage seda oma tervise huvides. GitHubi dokumentatsioon, küsimusi saab esitada siin, püüan kõigele vastata.
Noh, kasulikud lingid: , . Ja siin Markovi kettide kohta. Artiklis olevad graafikud on tehtud kasutades .
Allikas: www.habr.com