Meile on oluline mõista, mis meie tudengitega õppeprotsessi jooksul juhtub ja kuidas need sündmused tulemust mõjutavad, seetõttu loome Customer Journey Map'i — kliendikogemuse kaardi. Õppeprotsess ei ole midagi pidevat ja ühtekuuluvat, see on seotud omavaheliste sündmuste ja tudengi tegevustega, mille eripärad võivad erinevates õpilastes oluliselt varieeruda. Ta läbis tunni: mida ta teeb edasi? Tõuseb kodutööd tegema? Käivitab mobiilirakenduse? Muudab kursust, palub õpetajat vahetada? Asub otse järgmist tundi? Või tõesti lahkub pettunult? Kas selle kaardi analüüsimise kaudu on võimalik tuvastada mustreid, mis viivad kursuse edukalt lõpetamiseni või vastupidi, tudengi „lahkumiseni“?
Tavaliselt kasutatakse CJM-i ülesehitamiseks spetsialiseeritud, väga kalliseid suletud koodiga tööriistu. Kuid soovisime välja mõelda midagi lihtsat, mis nõuaks minimaalset pingutust ja oleks võimalusel avatud lähtekoodiga. Nii tekkis idee kasutada Markovi ahelaid - ja meil õnnestus see. Oleme koostanud kaardi, tõlgendanud üliõpilaste käitumisandmeid graafina, näinud täiesti ilmselgeid vastuseid globaalsele äri küsimustele ja isegi leidnud sügavale varjatud vigu. Kõike seda tegime avatud lähtekoodi lahenduste Python-skripti abil. Selles artiklis räägin kahest juhtumist, kus saavutati need mitte-ilmsed tulemused, ja jagan skripti kõigiga, kes soovivad.
Nii näitavad Markovi ahelad üleminekute tõenäosust sündmuste vahel. Siin on primitiivne näide Vikipeediast:
Siin on «E» ja «A» - sündmused, noolikesed - üleminekud nende vahel (sealhulgas üleminek sündmusest endasse) ja noolte kaalud - ülemineku tõenäosus («kaalutud suunatud graaf»).
Mida kasutati
Jõu võrgu kontseptsioon õppis Python'i tavaliste funktsioonide abil, millele anti üliõpilaste aktiivsuse logid. Graaf sellel saadud maatriksil ehitati kasutades NetworkX'i teeki.
Logi näeb välja selline:
See on csv-fail, mis sisaldab kolme veergu: üliõpilase ID, sündmuse nimetus ja aeg, mil see toimus. Need kolm välja on piisavad, et jälgida kliendi liikumisi, koostada kaardi ja lõpuks saada Markovi ahel.
Teek tagastab genereeritud graafid .dot või .gexf formaadis. Esimeste visuaalsuseks saab kasutada tasuta paketti Graphviz (tööriist gvedit), meie töötasime .gexf ja Gephi'ga, mis on samuti tasuta.
Edasi tahan tuua kaks näidet Markovi ahelate kasutamisest, mis võimaldasid meil uue pilguga vaadata meie eesmärke, õppimisprotsesse ja Skyengi ökosüsteemi. Ja ka mõningate vigade parandamine.
Esimene juhtum: mobiilirakendus
Alguses uurisime üliõpilase teekonda meie kõige populaarsemas tootes — General kursuses. Sel ajal töötasin Skyengi lasteosakonnas ja soovisime näha, kui tõhusalt mobiilirakendus meie laste sihtrühmas toimib.
Logid kokku kogudes ja neid skripti kaudu käies sain midagi sellist:
Algusmärk on Start General, all on kolm väljundnode: õpilane "magas ära", vahetas kursust, lõpetas kursuse.
- "Magas ära" - see tähendab, et ta ei osale enam tundides, tõenäoliselt on ta kadunud. Me optimistlikult nimetame seda seisundit "magas ära", kuna teoorias on tal veel võimalus õppimist jätkata. Meie jaoks halvim tulemus.
- Vahetas kursust - läks Generalilt üle millelegi muule ja kadus meie Markovi ahelast.
- "Lõpetas kursuse" - ideaalne seisund, inimene on läbinud 80% õppetundidest (kõik õppetunnid ei ole kohustuslikud).
Jõudmine noodi successful class tähendab, et õpilane on edukalt läbinud õppetunni meie platvormil koos õpetajaga. See fikseerib edusammud kursusel ja lähenemise soovitud tulemusele - "Lõpetas kursuse". Meie jaoks on oluline, et õpilased osaleksid võimalikult palju.
Kuna saime mobiilirakenduse (noda app session) jaoks täpsemaid kvantitatiivseid järeldusi, koostasime iga lõppmoodulite jaoks eraldi ahelad ja võrreldes siis paarikaupa servade kaalu:
- app sessionist tagasi sinna;
- app sessionist successful classi;
- successful classist app sessionisse.
Vasakul — kursuse lõpetanud tudengid, paremal — «magavad»
Need kolm ribasid näitavad seost tudengi edusammude ja mobiilirakenduse kasutamise vahel. Ootasime näha, et kursuse lõpetanute seos rakendusega on tugevam kui «magajate» seas. Kuid tegelikult saime vastupidised tulemused:
- oleme veendunud, et erinevad kasutajagruppid suhtlevad mobiilirakendusega erinevalt;
- edukad tudengid kasutavad mobiilirakendust vähem intensiivselt;
- magavad tudengid kasutavad mobiilirakendust aktiivsemalt.
See tähendab, et «magavad» tudengid hakkavad veetma üha rohkem aega mobiilirakenduses ja lõpuks jäävad nad sinna igaveseks.
Alguses olime üllatunud, kuid mõeldes mõistsime, et see on täiesti loogiline mõju. Aegade jooksul õppisin ma iseseisvalt prantsuse keelt, kasutades kahte tööriista: mobiilirakendust ja grammatika loenguid YouTube'is. Alguses jagasin aega nende kahe vahel 50-50, kuid rakendus oli lõbusam, seal oli mängustamine, kõik oli lihtne, kiire ja arusaadav, samas kui loengutes tuli süveneda, midagi üles kirjutada ja harjutada vihikus. Aja jooksul hakkasin ma rohkem aega veetma nutitelefonis, kuni selle osa kasvas 100%-ni: kui veeta seal kolm tundi, tekib vale tunne tehtud töö kohta, mille tõttu pole mingit soovi minna ja midagi kuulata.
Aga kuidas see võimalik on? Me ju spetsiaalselt lõime mobiilirakenduse, , mängustasime selle, tegime sellest atraktiivse, et inimesed veedaksid seal aega, aga selgub, et see lihtsalt häirib neid? Tegelikult on põhjus selles, et mobiilirakenduse meeskond tegi oma ülesandeid liiga hästi, mille tulemuseks oli, et see muutus ägedaks iseseisvaks tooteks ja hakkas meie ökosüsteemist välja kukkuma.
Uuringu tulemusena jõuti arusaamale, et mobiilirakendust tuleb teatud viisil muuta, et see vähem häiriks põhijoonest õppimist. See kehtib nii laste kui ka täiskasvanute jaoks. Praegu käivitatakse seda tööd.
Teine juhtum: onboardimise vead
Onboardimine on valikuline täiendav protseduur uue õpilase registreerimisel, mis aitab vältida võimalikke tehnilisi probleeme tulevikus. Põhistsenaarium tähendab, et inimene on registreerunud maandumislehel, saanud juurdepääsu isiklikule kontole, temaga võetakse ühendust ja korraldatakse sissejuhatav tund. Sellega seoses oleme märganud suurt protsenti tehnilistest raskustest sissejuhatava tunni ajal: vale brauseri versioon, mikrofoni või heli probleemid, õpetaja ei suuda kohe lahendust pakkuda, ja see on kõik eriti keeruline, kui tegemist on lastes. Seetõttu oleme arendanud täiendava rakenduse isiklikus kontos, kus saab läbi viia neli lihtsat sammu: kontrollida brauserit, kaamerat, mikrofoni ja kinnitada, et vanemad on sissejuhatava tunni ajal lähedal (sest just nemad maksavad laste õppimise eest).
Need paar lehte onboardimist demonstreerisid sellist müügivihikut:
1: alustav plokk, kus on kolm veidi erinevat (sõltuvalt kliendist) sisselogimise ja parooli vormi.
2: nõusoleku märkeruut täiendava onboardingu protseduuri jaoks.
2.1-2.3: vanema, Chrome'i versiooni ja heli kontrollimine.
3: lõpetav plokk.
See näeb väga loomulik välja: esimesel kahel sammul sulab suurem osa külastajatest kokku, mõistes, et siin on vaja midagi täita ja kontrollida, aga aeg on piiratud. Kui klient jõuab kolmandasse sammu, siis on ta peaaegu kindlasti lõpuni jõudmas. Voolikus ei ole ühtegi põhjust midagi kahtlustada.
Otsustasime siiski analüüsida meie onboardimist mitte klassikalise ühemõõtmelise vooliku kaudu, vaid Markovi ahela abil. Lisame veidi rohkem sündmusi, käivitame skripti ja saame sellise tulemuse:
Selles kaoses on selgelt aru saada ainult ühte: midagi on valesti. Onboarding-protsess on lineaarne, see on disainiga sisse ehitatud, seal ei tohiks olla sellist ühenduste võrku. Siin on kohe näha, et kasutajat visatakse sammude vahel edasi-tagasi, mille vahel ei peaks olema üleminekuid.
Sellise kummalise pildi põhjuseid võib olla kaks:
- vead on sattunud logide andmebaasi;
- tootedel on vigu — onboardimisprotsessis.
Esimene põhjus on tõenäoliselt olemas, kuid selle kontrollimine on piisavalt töömahukas ja logide parandamine ei aita kasutajakogemust parandada. Teise, kui see on olemas, puhul pidi midagi kiirelt ette võtma. Seega läksime sõlmede uurimisele, et tuvastada servade olemasolu, mida ei peaks olema, ja uurida nende ilmumise põhjuseid. Nägime, et mõned kasutajad jäid loopidesse kinni, teised langesid algusse keskel, kolmandad aga ei suutnud mingil juhul esimestest kahest sammust välja pääseda. Edastasime andmed QA-le — ja jah, selgus, et onboardimisprotsessis oli laias laastus vigu: see on selline kõrvaline, pisut ajutine toode, mida ei testitud piisavalt sügavalt, kuna probleeme ei oodatud. Praegu on kogu salvestusprotsess muutunud.
See lugu näitas meile Markovi ahelate ootamatut kasutamist QA valdkonnas.
Proovige ise!
Olen avaldanud oma avatud juurdepääsuga — kasutage julgelt. Dokumentatsioon on GitHubis, küsimusi võib esitada siin, püüan kõigile vastata.
Ja mõned kasulikud lingid: , . Siin on Markovi ahelitest. Artikli graafid on loodud kasutades .
Allikas: habr.com
