Na Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« kuptojmĂ« se çfarĂ« ndodh me studentĂ«t tanĂ« gjatĂ« mĂ«simit dhe si kĂ«to ngjarje ndikojnĂ« nĂ« rezultat, prandaj ne krijojmĂ« Customer Journey Map â hartĂ«n e pĂ«rvojĂ«s sĂ« klientit. Sepse procesi i mĂ«simit nuk Ă«shtĂ« njĂ« diçka e vazhdueshme dhe e tĂ«rĂ«, Ă«shtĂ« njĂ« zinxhir ngjarjesh dhe veprimesh tĂ« lidhura me studentin, ku kĂ«to veprime mund tĂ« duken shumĂ« tĂ« ndryshme pĂ«r nxĂ«nĂ«s tĂ« ndryshĂ«m. Ai kaloi njĂ« mĂ«sim: çfarĂ« do tĂ« bĂ«jĂ« mĂ« pas? Do tĂ« fillojĂ« detyrĂ«n e shtĂ«pisĂ«? Do tĂ« nisĂ« aplikacionin celular? Do tĂ« ndryshojĂ« kursin, do tĂ« kĂ«rkojĂ« tĂ« ndryshojĂ« mĂ«suesin? Do tĂ« hyjĂ« menjĂ«herĂ« nĂ« mĂ«simin tjetĂ«r? Apo do tĂ« largohet i zhgĂ«njyer? A Ă«shtĂ« e mundur tĂ« identifikojmĂ«, duke analizuar kĂ«tĂ« hartĂ«, rregulla qĂ« çojnĂ« nĂ« pĂ«rfundimin e suksesshĂ«m tĂ« kursit apo nga ana tjetĂ«r, âlargiminâ e studentit?
Zakonisht pĂ«r ndĂ«rtimin e CJM pĂ«rdoren mjete tĂ« specializuara, shpeshherĂ« shumĂ« tĂ« shtrenjta me kod tĂ« mbyllur. Por ne doja tĂ« shpikim diçka tĂ« thjeshtĂ«, qĂ« tĂ« kĂ«rkonte pĂ«rpjekje minimale dhe tĂ« ishte sa mĂ« shumĂ« open-source. KĂ«shtu ndĂ«rtojmĂ« idenĂ« pĂ«r tĂ« pĂ«rdorur zinxhirĂ«t Markov â dhe ia dolĂ«m. Krijuam njĂ« hartĂ«, interpretuam tĂ« dhĂ«nat mbi sjelljen e studentĂ«ve nĂ« formĂ«n e njĂ« grafiku, dhe pamĂ« pĂ«rgjigje krejt tĂ« papritura pĂ«r pyetje globale tĂ« biznesit dhe madje gjetĂ«m defekte tĂ« thella tĂ« fshehura. TĂ« gjitha kĂ«to i bĂ«mĂ« me ndihmĂ«n e zgjidhjeve open-source tĂ« skenarĂ«ve Python. NĂ« kĂ«tĂ« artikull do tĂ« flas pĂ«r dy raste me kĂ«to rezultate krejt tĂ« papritura dhe do tĂ« ndaj skenarin me tĂ« gjithĂ« ata qĂ« janĂ« tĂ« interesuar.
Kështu, zinxhirët Markov tregojnë probabilitetin e kalimeve midis ngjarjeve. Ja një shembull primitiv nga Wikipedia:
Këtu "E" dhe "A" janë ngjarje, shigjetat janë kalimet midis tyre (përfshirë kalimin nga një ngjarje në vetvete), dhe peshat e shigjetave janë probabiliteti i kalimit ("grafik i orientuar me pesha").
ĂfarĂ« pĂ«rdorĂ«m
Zinxhiri u stërvit me funksionalitetin standard të Python, të cilit iu dhanë loget e aktivitetit të studentëve. Grafiku në matricën e marrë u ndërtua me bibliotekën NetworkX.
Logu duket kështu:
Ky është një skedar csv që përmban një tabelë me tre kolona: id e studentit, emri i ngjarjes, koha kur ndodhi ajo. Këto tri fusha janë të mjaftueshme për të ndjekur lëvizjet e klientit, për të ndërtuar hartën dhe në fund për të marrë zinxhirin Markov.
Biblioteka kthen grafet e ndërtuara në formatin .dot ose .gexf. Për vizualizimin e të parëve mund të përdorim paketën falas Graphviz (instrumenti gvedit), ne kemi punuar me .gexf dhe Gephi, gjithashtu falas.
Tani do të sjell dy shembuj të përdorimit të zinxhirëve Markov, të cilat na ndihmuan të shohim ndryshe qëllimet tona, proceset e të mësuarit dhe vetë ekosistemin Skyeng. Po ashtu, rregulluam disa gabime.
Shembulli i parë: aplikacioni mobil
Fillimisht, ne hulumtuam rrugĂ«n e studentit nĂ« produktin tonĂ« mĂ« tĂ« njohur â kursin General. NĂ« atĂ« kohĂ« unĂ« punoja nĂ« departamentin e fĂ«mijĂ«ve tĂ« Skyeng dhe dĂ«shironim tĂ« shihnim sa efektivisht funksionon aplikacioni mobil me audiencĂ«n tonĂ« fĂ«minore.
Merrni logjet dhe kaloni ato përmes skriptit, kam marrë diçka të tillë:
NodĂ«n fillestare â Start General, dhe mĂ« poshtĂ« tre nodet e daljes: studenti «ka fjetur», ndryshoi kursin, pĂ«rfundoi kursin.
- Ka fjetur, «Zasnul» â do tĂ« thotĂ«, nuk kalon mĂ« mĂ«sime, me shumĂ« se ka rĂ«nĂ«. Ne e quajmĂ« optimist kĂ«tĂ« gjendje «ka fjetur», pasi teorikisht ka ende mundĂ«sinĂ« tĂ« vazhdojĂ« mĂ«simin. Rezultati mĂ« i keq pĂ«r ne.
- Ndryshoi kursin, kaloi nga General në diçka tjetër dhe u humb nga zinxhiri ynë i Markov.
- PĂ«rfundoi kursin â gjendja ideale, personi ka kaluar 80% tĂ« mĂ«simeve (jo tĂ« gjitha mĂ«simet janĂ« tĂ« obligueshme).
TĂ« ecuri nĂ« nodĂ«n successful class do tĂ« thotĂ« tĂ« kalosh me sukses mĂ«simin nĂ« platformĂ«n tonĂ« sĂ« bashku me mĂ«suesin. Kjo regjistron avancimin nĂ« kurs dhe afrim ndaj rezultatit tĂ« dĂ«shiruar â «PĂ«rfundoi kursin». ĂshtĂ« e rĂ«ndĂ«sishme pĂ«r ne qĂ« studentĂ«t ta vizitojnĂ« sa mĂ« shumĂ«.
Për të marrë konkluzione më të sakta sasiore për aplikacionin mobil (noda app session), ne ndërtuam zinxhirë të veçantë për çdo nod të fundit dhe pastaj krahasuam peshat e skelave në çifte:
- nga app session mbrapsht në të njëjtën;
- nga app session në successful class;
- nga successful class në app session.
Majtas â studentĂ«t qĂ« pĂ«rfunduan kursin, djathtas â «kanĂ« fjetur»
Këto tri skela tregojnë lidhjen midis suksesit të studentit dhe përdorimit të aplikacionit mobil. Ne prisnim të shihnim se lidhja për studentët që përfunduan kursin do të ishte më e fortë sesa për ata që «kanë fjetur». Megjithatë, në realitet morëm pikërisht rezultate të kundërta:
- ne u sigurua se grupet e ndryshme të përdoruesve ndërveprojnë ndryshe me aplikacionin mobil;
- studentët e suksesshëm përdorin më pak intensivisht aplikacionin mobil;
- studentët që bien në gjumë e përdorin më aktivisht aplikacionin mobil.
Kjo do të thotë se studentët "që bien në gjumë" fillojnë të kalojnë gjithnjë e më shumë kohë në aplikacionin mobil dhe në fund mbesin aty përherë.
Fillimisht u befasuam, por duke menduar e kuptuam se ishte një efekt mjaft logjik. Në kohën time, unë mësoja frëngjishten vetë duke përdorur dy mjete: aplikacionin mobil dhe leksionet mbi gramatikën në YouTube. Nga fillimi, unë e ndaja kohën midis tyre në një raport 50 me 50. Por aplikacioni është më argëtues, ka gamifikim, është i thjeshtë, i shpejtë dhe i kuptueshëm, ndërsa në leksionet duhet të përqendrohesh, të shkruash diçka dhe të praktikosh në fletore. Gradualisht, fillova të kaloj më shumë kohë në smartphone, derisa pjesa e tij u rrit në 100%: nëse kaloj tri orë atje, krijohet një ndjesi e rreme e përfundimit të punës, për shkak të së cilës nuk ndihem aspak i motivuar të shkoj dhe të dëgjoj diçka.
Por si është e mundur? Sepse ne e krijuam veçanërisht aplikacionin mobil, , e gamifikuam, e bëmë tërheqëse, që njerëzit të gjithashtu kalonin kohë aty, dhe rezulton se ai vetëm i shpërqendron? Në të vërtetë, arsyeja është se ekipi i aplikacionit mobil e përfundoi detyrën e tij kaq mirë, saqë u bë një produkt fantastik dhe filloi të dalë jashtë ekosistemit tonë.
Si rezultat i hulumtimit, kuptuam se aplikacioni mobil duhet ndonjëherë të ndryshohet, në mënyrë që të mos shpenzojë shumë kohë nga kursi kryesor i mësimit. Kjo përfshin si fëmijët ashtu edhe të rriturit. Tani, ky punim është në zhvillim.
Rasti i dytë: gabimet e onboarding
Onboarding është një procedurë jo e detyrueshme suplementare gjatë regjistrimit të një nxënësi të ri, e cila do të shmangë probleme të mundshme teknike në të ardhmen. Skenari bazë nënkupton se individi ka marrë një regjistrim në landin, ka marrë qasje në llogarinë personale, e kontaktojnë dhe i bëjnë një mësim hyrës. Gjatë këtij procesi, ne vërejmë një përqindje të lartë të vështirësive teknike gjatë mësimit hyrës: versioni i gabuar të shfletuesit, mikrofoni ose zëri nuk funksionon, mësuesi nuk mund t'i japë menjëherë një zgjidhje, dhe gjithçka është veçanërisht e komplikuar kur bëhet fjalë për fëmijë. Prandaj ne zhvilluam një aplikacion të rëndësishëm në llogarinë personale, ku mund të përfundoni katër hapa të thjeshtë: të kontrolloni shfletuesin, kamerën, mikrofonin dhe të konfirmoni se prindërit do të jenë pranë gjatë mësimit hyrës (sepse ata janë ata që paguajnë për arsimimin e fëmijëve).
Këto disa faqe onboarding demonstruan një funnel të tillë:
1: blloku fillestar me tre forma të ndryshme (sipër faqes) për të futur emrin dhe fjalëkalimin.
2: një shenjë pëlqimi për procedurën shtesë të onboarding.
2.1-2.3: kontrollimi i pranisë së prindit, versionit të Chrome dhe zërit.
3: blloku përfundimtar.
Ajo duket shumĂ« natyrshme: nĂ« dy hapat e parĂ«, shumica e vizitorĂ«ve shkurtohen, duke kuptuar se kĂ«tu duhen plotĂ«suar disa gjĂ«ra, tĂ« kontrollohet diçka dhe nuk ka kohĂ« pĂ«r kĂ«tĂ«. NĂ«se klienti arrin nĂ« hapat e tretĂ« â ai do tĂ« vijojĂ« gati me siguri deri nĂ« pĂ«rfundim. NĂ« funnel nuk duket asnjĂ« arsye pĂ«r tĂ« dyshuar ndonjĂ« gjĂ«.
Megjithatë, ne vendosëm ta analizojmë onboarding-un tonë jo në një funnel klasik një-dimensional, por me anë të zinxhirit Markov. Përcaktuam pak më shumë ngjarje, e startuam skenarin dhe morëm këtë rezultat:
E vetmja gjë që mund të kuptohet në këtë kaos është se diçka ka shkuar keq. Procesi i onboarding-ut është linear, kjo është e injektuar në dizajn, nuk duhet të ketë një zgjidhje njohurish. Dhe këtu është e qartë se përdoruesi hidhet mes hapave, midis të cilëve nuk duhet të ketë kalime.
Shkaktarët e kësaj pamjeje të çuditshme mund të jenë dy:
- gabime të futur në bazën e logjeve;
- gabime ekzistojnĂ« nĂ« produktin vetĂ« â onboarding.
Arsyeja e parë, me sa duket, ekziston, por kontrollimi i saj është mjaft punë intensive, dhe korrigjimi i logëve nuk ndihmon fare për të përmirësuar UX. Ndërsa për arsye të dytë, nëse ekziston, duhej bërë diçka urgjente. Prandaj, ne shkuam për të shqyrtuar nyjet, për të zbuluar brinjët që nuk duhet të ishin, dhe për të kërkuar arsyet e shfaqjes së tyre. Vëmë re se disa përdorues po ngelen në cikël dhe shkonin në rreth, të tjerë dalin nga mes në fillim, ndërsa të tretët në principe nuk mund të dilnin nga dy hapat e parë. I dhamë të dhënat QA - dhe po, doli se onboarding kishte shumë bugs: ky është një produkt anësor, disi i dobët, nuk ishte testuar mjaft thellë, pasi nuk pritej asnjë problem. Tani, që të gjithë procesi i regjistrimit është ndryshuar.
Kjo histori na tregoi një aplikim të papritur të zinxhirëve të Markovit në fushën e QA.
Provojeni vetë!
Unë kam publikuar në dispozitë të hapur - përdorni me shëndet. Dokumentacioni është në GitHub, pyetjet mund të bëhen këtu, do të përpiqem të përgjigjem për të gjitha.
E po ashtu edhe lidhje të dobishme: , . Dhe këtu për zinxhirët e Markovit. Grafët në artikull janë bërë me .
Burimi: habr.com
