Dit is vir ons belangrik om te verstaan wat met ons studente gebeur tydens opleiding en hoe hierdie gebeurtenisse die resultaat beïnvloed, daarom bou ons 'n Customer Journey Map - 'n kaart van klante-ervaring. Die leerproses is immers nie iets aaneenlopend en integraal nie, dit is 'n ketting van onderling gekoppelde gebeure en handelinge van die student, en hierdie aksies kan baie tussen verskillende studente verskil. Nou het hy sy les voltooi: wat gaan hy volgende doen? Sal dit huiswerk toe gaan? Sal dit 'n mobiele toepassing bekendstel? Sal hy van koers verander, vra om onderwysers te verander? Sal jy reguit na die volgende les gaan? Of gaan hy net teleurgesteld weg? Is dit moontlik om, deur hierdie kaart te analiseer, patrone te identifiseer wat lei tot die suksesvolle voltooiing van die kursus of, omgekeerd, tot die "uitval" van die student?
Tipies word gespesialiseerde, baie duur geslotebrongereedskap gebruik om CJM te bou. Maar ons wou met iets eenvoudig vorendag kom, wat minimale moeite verg en, indien moontlik, oopbron. Die idee het dus opgekom om Markov-kettings te gebruik - en ons het daarin geslaag. Ons het 'n kaart gebou, data oor studentegedrag in die vorm van 'n grafiek geïnterpreteer, heeltemal nie-vanselfsprekende antwoorde op globale sakekwessies gesien en selfs diep versteekte foute gevind. Ons het dit alles gedoen met behulp van oopbron Python-skripoplossings. In hierdie artikel sal ek praat oor twee gevalle met daardie baie nie-vanselfsprekende resultate en die draaiboek met almal deel.
Dus, Markov-kettings toon die waarskynlikheid van oorgange tussen gebeure. Hier is 'n primitiewe voorbeeld van Wikipedia:
Hier is "E" en "A" gebeurtenisse, die pyle is oorgange tussen hulle (insluitend die oorgang van 'n gebeurtenis na dieselfde), en die gewigte van die pyle is die waarskynlikheid van oorgang ("geweegde gerigte grafiek").
Wat het jy gebruik?
Die kring is opgelei met standaard Python-funksionaliteit, wat met studenteaktiwiteitlogboeke gevoer is. Die grafiek op die resulterende matriks is deur die NetworkX-biblioteek saamgestel.
Die log lyk so:
Dit is 'n csv-lêer wat 'n tabel van drie kolomme bevat: student-ID, naam van die gebeurtenis, tyd wanneer dit plaasgevind het. Hierdie drie velde is genoeg om die kliënt se bewegings na te spoor, 'n kaart te bou en uiteindelik 'n Markov-ketting te kry.
Die biblioteek gee die gekonstrueerde grafieke terug in .dot- of .gexf-formaat. Om eersgenoemde te visualiseer, kan jy die gratis Graphviz-pakket (gvedit-instrument) gebruik, ons het met .gexf en Gephi gewerk, ook gratis.
Vervolgens wil ek twee voorbeelde gee van die gebruik van Markov-kettings, wat ons in staat gestel het om 'n nuwe blik op ons doelwitte, opvoedkundige prosesse en die Skyeng-ekosisteem self te neem. Wel, maak die foute reg.
Eerste geval: mobiele toepassing
Om mee te begin, het ons die studentereis deur ons gewildste produk – die Algemene kursus – verken. Op daardie oomblik het ek in die kinderafdeling van Skyeng gewerk en ons wou sien hoe effektief die mobiele toepassing met ons kinders se gehoor werk.
Deur die logboeke te neem en dit deur die skrif te laat loop, het ek iets soos hierdie gekry:
Die beginnodus is Begin Algemeen, en aan die onderkant is daar drie uitsetnodusse: die student het “aan die slaap geraak”, van koers verander en die kursus voltooi.
- Aan die slaap geraak, "aan die slaap geraak" - dit beteken dat hy nie meer klasse neem nie, waarskynlik het hy afgeval. Ons noem hierdie toestand optimisties "slaap", want... in teorie het hy steeds die geleentheid om sy studies voort te sit. Slegste resultaat vir ons.
- Generaal laat val, koers verander - van Generaal na iets anders oorgeskakel en verdwaal vir ons Markov-ketting.
- Kursus voltooi, kursus voltooi - ideale toestand, die persoon het 80% van die lesse voltooi (nie alle lesse word vereis nie).
Om in die suksesvolle klasnodus te kom, beteken om die les op ons platform saam met die onderwyser suksesvol te voltooi. Dit teken vordering langs die kursus en benadering tot die gewenste resultaat aan - "Het kursus voltooi." Dit is vir ons belangrik dat studente soveel as moontlik bywoon.
Om meer akkurate kwantitatiewe gevolgtrekkings vir die mobiele toepassing (toepassingsessie-nodus) te kry, het ons aparte kettings vir elk van die finale nodusse gebou en dan die randgewigte paarsgewys vergelyk:
- van die toepassingsessie terug na dit;
- van toepassingsessie tot suksesvolle klas;
- van suksesvolle klas tot appsessie.
Aan die linkerkant is studente wat die kursus voltooi het, aan die regterkant is diegene wat "aan die slaap geraak het"
Hierdie drie rande wys die verband tussen 'n student se sukses en hul gebruik van die mobiele toepassing. Ons het verwag om te sien dat studente wat die kursus voltooi het 'n sterker verbintenis met die aansoek sou hê as studente wat aan die slaap geraak het. In werklikheid het ons egter presies die teenoorgestelde resultate gekry:
- ons het seker gemaak dat verskillende groepe gebruikers verskillend met die mobiele toepassing omgaan;
- suksesvolle studente gebruik die mobiele toepassing minder intensief;
- studente wat aan die slaap raak, gebruik die mobiele toepassing meer aktief.
Dit beteken dat studente wat aan die slaap raak al hoe meer tyd in die mobiele toepassing begin spandeer en uiteindelik vir ewig daarin bly.
Ons was eers verbaas, maar nadat ons daaroor nagedink het, het ons besef dat dit 'n heeltemal natuurlike effek was. Op 'n tyd het ek Frans op my eie studeer deur twee instrumente te gebruik: 'n mobiele toepassing en grammatikalesings op YouTube. Ek het eers die tyd tussen hulle verdeel in 'n verhouding van 50 tot 50. Maar die toepassing is lekkerder, daar is gamification, alles is eenvoudig, vinnig en duidelik, maar in die lesing moet jy daarin delf, iets neerskryf , oefen in 'n notaboek. Ek het geleidelik meer tyd op my slimfoon begin spandeer, totdat sy aandeel tot 100% gegroei het: as jy drie uur daaraan spandeer, skep jy 'n valse gevoel van voltooide werk, as gevolg waarvan jy geen begeerte het om na enigiets te gaan luister nie. .
Maar hoe kan dit wees? Ons het immers spesiaal 'n mobiele toepassing geskep, , gamified dit, het dit aantreklik gemaak sodat mense tyd daarin sou spandeer, maar dit blyk dat dit net hulle aandag aflei? Trouens, die rede is dat die mobiele toepassingspan sy take te goed hanteer het, waardeur dit 'n koel, selfversorgende produk geword het en uit ons ekosisteem begin val het.
As gevolg van die navorsing het dit duidelik geword dat die mobiele toepassing op een of ander manier verander moes word sodat dit minder aandag van die hoofkursus sou wees. En beide kinders en volwassenes. Hierdie werk is tans aan die gang.
Tweede geval: aanboordfoute
Aanboord is 'n opsionele bykomende prosedure wanneer 'n nuwe student geregistreer word, wat potensiële tegniese probleme in die toekoms uitskakel. Die basiese scenario veronderstel dat 'n persoon op die bestemmingsblad geregistreer het, toegang tot sy persoonlike rekening verkry het, gekontak word en 'n inleidende les gegee word. Terselfdertyd merk ons 'n groot persentasie tegniese probleme tydens die inleidende les op: die verkeerde weergawe van die blaaier, die mikrofoon of klank werk nie, die onderwyser kan nie dadelik 'n oplossing voorstel nie, en dit alles is veral moeilik as dit kom aan kinders. Daarom het ons 'n bykomende toepassing in jou persoonlike rekening ontwikkel, waar jy vier eenvoudige stappe kan voltooi: gaan jou blaaier, kamera, mikrofoon na en bevestig dat ouers naby sal wees tydens die inleidende les (dit is immers hulle wat betaal vir hul kinders se opvoeding).
Hierdie paar aanboordbladsye het 'n tregter soos hierdie gewys:
1: beginblok met drie effens verskillende (afhangende van die kliënt) aanmeld- en wagwoordinskrywingsvorms.
2: merkblokkie stem in tot die bykomende aanboordprosedure.
2.1-2.3: Kyk vir ouerteenwoordigheid, Chrome-weergawe en klank.
3: laaste blok.
Dit lyk baie natuurlik: in die eerste twee stappe vertrek die meeste van die besoekers, besef dat daar iets is om in te vul, kyk, maar daar is nie tyd nie. As die kliënt die derde stap bereik het, sal hy byna seker die finaal haal. Daar is nie 'n enkele rede om iets op die tregter te vermoed nie.
Ons het nietemin besluit om ons aanboord nie op 'n klassieke eendimensionele tregter te ontleed nie, maar met 'n Markov-ketting. Ons het 'n bietjie meer gebeurtenisse aangeskakel, die draaiboek laat loop en dit gekry:
In hierdie chaos kan net een ding duidelik verstaan word: iets het verkeerd geloop. Die aanboordproses is lineêr, dit is inherent aan die ontwerp, daar behoort nie so 'n web van verbindings daarin te wees nie. En hier is dit dadelik duidelik dat die gebruiker tussen stappe gegooi word, waartussen daar glad nie oorgange behoort te wees nie.
Daar kan twee redes vir hierdie vreemde prentjie wees:
- skole het in die logdatabasis ingesluip;
- Daar is foute in die produk self - aanboord.
Die eerste rede is heel waarskynlik waar, maar om dit te toets is redelik arbeidsintensief, en die regstelling van die logs sal nie help om die UX te verbeter nie. Maar met die tweede een, as dit bestaan, moes iets dringend gedoen word. Daarom het ons na die nodusse gaan kyk, rande identifiseer wat nie behoort te bestaan nie, en die redes vir hul voorkoms gesoek. Ons het gesien dat sommige gebruikers vasgehaak het en in sirkels loop, ander het uit die middel geval na die begin, en ander kon in beginsel nie uit die eerste twee treë kom nie. Ons het die data na QA oorgedra - en ja, dit het geblyk dat daar genoeg foute in aanboord was: dit is so 'n neweproduk, 'n bietjie van 'n kruk, dit is nie diep genoeg getoets nie, want ... Ons het geen probleme verwag nie. Nou het die hele opnameproses verander.
Hierdie storie het ons 'n onverwagte toepassing van Markov-kettings op die gebied van QA gewys.
Probeer dit self!
Ek het myne geplaas in die publieke domein - gebruik dit vir jou gesondheid. Dokumentasie op GitHub, vrae kan hier gevra word, ek sal probeer om alles te beantwoord.
Wel, nuttige skakels: , . En hier oor Markov-kettings. Die grafieke in die artikel is gemaak met behulp van .
Bron: will.com