Mums svarbu suprasti, kas vyksta su mūsų studentais mokymų metu ir kaip šie įvykiai veikia rezultatą, todėl kuriame Klientų kelionės žemėlapį – klientų patirties žemėlapį. Juk mokymosi procesas nėra kažkas nenutrūkstamo ir vientiso, tai yra tarpusavyje susijusių mokinio įvykių ir veiksmų grandinė, ir šie veiksmai tarp skirtingų mokinių gali labai skirtis. Dabar jis baigė pamoką: ką jis darys toliau? Ar tai eis į namų darbus? Ar bus paleista mobilioji programa? Ar jis pakeis kursą, prašys pakeisti mokytojus? Ar eisite tiesiai į kitą pamoką? O gal jis tiesiog išeis nusivylęs? Ar galima, analizuojant šį žemėlapį, nustatyti modelius, kurie lemia sėkmingą kurso baigimą arba, atvirkščiai, studento „iškritimą“?
Paprastai CJM kūrimui naudojami specializuoti, labai brangūs uždarojo kodo įrankiai. Tačiau norėjome sugalvoti ką nors paprasto, reikalaujančio minimalių pastangų ir, jei įmanoma, atvirojo kodo. Taip kilo mintis panaudoti Markovo grandines – ir mums pavyko. Sukūrėme žemėlapį, grafiko pavidalu interpretavome duomenis apie studentų elgesį, matėme visiškai neakivaizdžius atsakymus į globalias verslo problemas ir netgi radome giliai paslėptų klaidų. Visa tai padarėme naudodami atvirojo kodo Python scenarijų sprendimus. Šiame straipsnyje pakalbėsiu apie du atvejus, kurių rezultatai buvo labai neaiškūs, ir pasidalinsiu scenarijumi su visais.
Taigi Markovo grandinės parodo perėjimų tarp įvykių tikimybę. Štai primityvus pavyzdys iš Vikipedijos:
Čia „E“ ir „A“ yra įvykiai, rodyklės yra perėjimai tarp jų (įskaitant perėjimą nuo įvykio į tą patį), o rodyklių svoriai yra perėjimo tikimybė („svertinis nukreiptas grafikas“).
Ką naudojote?
Grandinė buvo apmokyta naudojant standartinę Python funkciją, kuri buvo maitinama studentų veiklos žurnalais. Gautos matricos grafiką sukūrė NetworkX biblioteka.
Žurnalas atrodo taip:
Tai csv failas, kuriame yra trijų stulpelių lentelė: studento pažymėjimas, įvykio pavadinimas, laikas, kada jis įvyko. Šių trijų laukų pakanka, kad būtų galima atsekti kliento judesius, sudaryti žemėlapį ir galiausiai gauti Markovo grandinę.
Biblioteka grąžina sukonstruotus grafikus .dot arba .gexf formatu. Norėdami vizualizuoti pirmąjį, galite naudoti nemokamą Graphviz paketą (gvedit įrankį), dirbome su .gexf ir Gephi, taip pat nemokamai.
Toliau norėčiau pateikti du Markovo grandinių naudojimo pavyzdžius, kurie leido naujai pažvelgti į savo tikslus, ugdymo procesus ir pačią Skyeng ekosistemą. Na, ištaisykite klaidas.
Pirmasis atvejis: mobilioji programa
Pirmiausia tyrinėjome studentų kelionę per populiariausią produktą – bendrąjį kursą. Tuo metu dirbau Skyeng vaikų skyriuje ir norėjome pamatyti, kaip efektyviai mobilioji aplikacija veikia su mūsų vaikų auditorija.
Paėmęs žurnalus ir paleisdamas juos per scenarijų, gavau kažką panašaus:
Pradinis mazgas yra Pradėti bendrą, o apačioje yra trys išvesties mazgai: studentas „užmigo“, pakeitė kursą ir baigė kursą.
- Užmigo, „Užmigo“ - tai reiškia, kad jis nebelanko pamokų, greičiausiai nukrito. Šią būseną optimistiškai vadiname „miega“, nes... teoriškai jis dar turi galimybę tęsti mokslus. Blogiausias rezultatas mums.
- Išmetė generolą, Pakeitė kursą – iš Generalinio perėjo į kažką kitą ir pasiklydo mūsų Markovo grandinei.
- Baigė kursą, Baigė kursą - ideali būklė, žmogus baigė 80% pamokų (ne visos pamokos privalomos).
Patekti į sėkmingos klasės mazgą reiškia sėkmingai užbaigti pamoką mūsų platformoje kartu su mokytoju. Jis fiksuoja eigą kurso eigoje ir artėjimą prie norimo rezultato – „Kursas baigtas“. Mums svarbu, kad studentai lankytų kuo daugiau.
Norėdami gauti tikslesnes mobiliosios programos (programos seanso mazgo) kiekybines išvadas, kiekvienam galutiniam mazgui sukūrėme atskiras grandines ir palyginome kraštų svorius poromis:
- iš programos seanso atgal į ją;
- nuo programos seanso iki sėkmingos klasės;
- nuo sėkmingos pamokos iki programos seanso.
Kairėje yra studentai, baigę kursą, dešinėje - tie, kurie „užmigo“
Šios trys briaunos parodo ryšį tarp mokinio sėkmės ir naudojimosi mobiliąja programėle. Tikėjomės, kad studentai, baigę kursą, turės stipresnį ryšį su paraiška nei studentai, kurie užmigo. Tačiau iš tikrųjų gavome visiškai priešingus rezultatus:
- įsitikinome, kad skirtingos vartotojų grupės skirtingai sąveikauja su mobiliąja aplikacija;
- sėkmingi studentai ne taip intensyviai naudojasi mobiliąja aplikacija;
- užmigusių mokinių aktyviau naudojasi mobiliąja aplikacija.
Tai reiškia, kad užmigę studentai vis daugiau laiko praleidžia mobiliojoje programėlėje ir galiausiai lieka joje amžinai.
Iš pradžių nustebome, bet pagalvoję supratome, kad tai visiškai natūralus efektas. Vienu metu prancūzų kalbos mokiausi savarankiškai, naudodamasi dviem įrankiais: mobiliąja programa ir gramatikos paskaitomis „YouTube“. Iš pradžių laiką paskirstydavau tarp jų santykiu 50 prieš 50. Bet aplikacija smagiau, yra žaidybinimas, viskas paprasta, greita ir aišku, bet paskaitoje reikia į tai įsigilinti, kažką užsirašyti. , praktika sąsiuvinyje. Palaipsniui pradėjau daugiau laiko leisti prie išmaniojo telefono, kol jo dalis išaugo iki 100%: jei tam praleidi tris valandas, sukuria klaidingą atlikto darbo jausmą, dėl kurio nebesinori nieko eiti ir klausytis. .
Bet kaip tai gali būti? Juk specialiai sukūrėme mobiliąją aplikaciją, , sužaisdavo, padarė patrauklų, kad žmonės jame praleistų laiką, bet pasirodo, kad tai tik blaško jų dėmesį? Tiesą sakant, priežastis yra ta, kad mobiliųjų programų komanda per gerai susidorojo su savo užduotimis, todėl ji tapo šauniu, savarankišku produktu ir pradėjo kristi iš mūsų ekosistemos.
Atlikus tyrimą paaiškėjo, kad reikia kažkaip pakeisti mobiliąją aplikaciją, kad ji mažiau atitrauktų dėmesį nuo pagrindinio studijų kurso. Ir vaikams, ir suaugusiems. Šis darbas šiuo metu vyksta.
Antrasis atvejis: įdiegimo klaidos
Priėmimas yra neprivaloma papildoma procedūra registruojant naują studentą, pašalinanti galimas technines problemas ateityje. Pagrindinis scenarijus daro prielaidą, kad asmuo užsiregistravo nukreipimo puslapyje, gavo prieigą prie savo asmeninės paskyros, su juo susisiekiama ir jam pravedama įvadinė pamoka. Tuo pačiu metu įvadinėje pamokoje pastebime didelį procentą techninių sunkumų: netinkama naršyklės versija, mikrofonas ar garsas neveikia, mokytojas negali iš karto pasiūlyti sprendimo, o visa tai ypač sunku. vaikams. Todėl Jūsų asmeninėje paskyroje sukūrėme papildomą aplikaciją, kurioje galėsite atlikti keturis paprastus veiksmus: pasitikrinti naršyklę, kamerą, mikrofoną ir patvirtinti, kad per įvadinę pamoką šalia bus tėvai (juk jie ir sumoka už jų vaikų išsilavinimas).
Šiuose keliuose prisijungimo puslapiuose buvo rodomas toks kanalas:
1: pradžios blokas su trimis šiek tiek skirtingomis (priklausomai nuo kliento) prisijungimo ir slaptažodžio įvedimo formomis.
2: žymimasis langelis, kuriuo sutinkama su papildoma įjungimo procedūra.
2.1–2.3: patikrinkite, ar yra tėvai, „Chrome“ versija ir garsas.
3: paskutinis blokas.
Tai atrodo labai natūraliai: pirmaisiais dviem žingsniais dauguma lankytojų išeina supratę, kad yra ką užpildyti, patikrinti, bet nėra laiko. Jei klientas pasiekė trečią žingsnį, jis beveik neabejotinai pateks į finalą. Nėra nė vienos priežasties įtarti ką nors apie piltuvą.
Nepaisant to, nusprendėme analizuoti savo įsitraukimą ne į klasikinį vienmatį piltuvą, o naudodami Markovo grandinę. Įjungėme šiek tiek daugiau įvykių, paleidome scenarijų ir gavome štai ką:
Šiame chaose aiškiai galima suprasti tik vieną dalyką: kažkas nutiko. Įdiegimo procesas yra linijinis, tai būdinga dizainui, jame neturėtų būti tokio jungčių tinklo. Ir čia iš karto aišku, kad vartotojas yra išmestas tarp žingsnių, tarp kurių neturėtų būti išvis jokių perėjimų.
Šio keisto vaizdo priežastys gali būti dvi:
- seklumos įsiskverbė į rąstų duomenų bazę;
- Pačiame gaminyje yra klaidų – įjungimas.
Pirmoji priežastis greičiausiai yra tiesa, tačiau jos testavimas yra gana daug darbo jėgos, o žurnalų taisymas nepadės pagerinti UX. Bet su antruoju, jei toks yra, reikėjo skubiai kažką daryti. Todėl nuėjome apžiūrėti mazgus, nustatyti kraštus, kurių neturėtų būti, ir ieškoti jų atsiradimo priežasčių. Matėme, kad vieni vartotojai užstrigo ir ėjo ratu, kiti iškrito iš vidurio į pradžią, o kiti iš principo negalėjo išlipti iš pirmų dviejų žingsnių. Mes perdavėme duomenis į QA – ir taip, paaiškėjo, kad įlaipinimo metu buvo pakankamai klaidų: tai toks šalutinis produktas, šiek tiek ramentas, nebuvo pakankamai nuodugniai išbandytas, nes... Nesitikėjome jokių problemų. Dabar visas įrašymo procesas pasikeitė.
Ši istorija mums parodė netikėtą Markovo grandinių pritaikymą kokybės užtikrinimo srityje.
Išbandykite patys!
Aš paskelbiau savo viešoje erdvėje – naudokite savo sveikatai. GitHub dokumentacija, klausimus galima užduoti čia, pasistengsiu į viską atsakyti.
Na, naudingos nuorodos: , . Ir čia apie Markovo grandines. Straipsnyje pateikiami grafikai sudaryti naudojant .
Šaltinis: www.habr.com