Este important pentru noi să înțelegem ce se întâmplă cu studenții noștri pe parcursul învățării și cum aceste evenimente influențează rezultatul, așa că construim o Hartă a Călătoriei Clientului — o hartă a experienței clientului. Procesul de învățare nu este un lucru continuu și unitar, ci o succesiune de evenimente și acțiuni interconectate ale studentului, iar aceste acțiuni pot diferi semnificativ între diferiți elevi. Iată, a absolvit o lecție: ce va face în continuare? Va merge la tema pentru acasă? Va lansa aplicația mobilă? Va schimba cursul, va cere să schimbe profesorul? Va intra imediat în lecția următoare? Sau va pleca pur și simplu dezamăgit? Este posibil să identificăm, analizând această hartă, tipare care conduc la finalizarea cu succes a cursului sau, dimpotrivă, la „abandonarea” studentului?
De obicei, pentru a construi CJM se folosesc instrumente specializate, foarte scumpe, cu cod închis. Dar ne-am dorit să venim cu ceva simplu, care necesită eforturi minime și, pe cât posibil, să fie open source. Așa a apărut ideea de a folosi lanțurile Markov — și am reușit. Am construit o hartă, am interpretat datele despre comportamentul studenților sub forma unei grafice, am descoperit răspunsuri complet neobișnuite la întrebările majore de afaceri și am găsit chiar bug-uri bine ascunse. Am realizat toate acestea cu ajutorul soluțiilor open source dintr-un script Python. În acest articol, voi vorbi despre două cazuri cu acele rezultate neobișnuite și voi împărtăși scriptul cu toți cei interesați.
Așadar, lanțurile Markov arată probabilitatea tranzițiilor între evenimente. Iată un exemplu primitiv din Wikipedia:
Aici, „E” și „A” sunt evenimente, iar săgețile indică tranzițiile între ele (inclusiv tranziția dintr-un eveniment în el însuși), iar greutățile săgeților reprezintă probabilitatea tranziției („grafic orientat ponderat”).
Ce am folosit
Lanțul a fost antrenat cu funcționalitatea standard a Python, care a primit jurnalele de activitate ale studenților. Graficul pe matricea obținută a fost construit cu biblioteca NetworkX.
Jurnalul arată astfel:
Este un fișier csv, care conține un tabel cu trei coloane: id-ul studentului, numele evenimentului și timpul când a avut loc. Aceste trei câmpuri sunt suficiente pentru a urmări mișcările clientului, a construi harta și, în cele din urmă, a obține un lanț Markov.
Biblioteca returnează grafurile construite în format .dot sau .gexf. Pentru vizualizarea primelor, se poate folosi pachetul gratuit Graphviz (instrumentul gvedit); noi am lucrat cu .gexf și Gephi, de asemenea gratuit.
Mai departe vreau să prezint două exemple de utilizare a lanțurilor Markov, care ne-au permis să privim dintr-o nouă perspectivă asupra obiectivelor noastre, proceselor de învățare și a ecosistemului Skyeng. De asemenea, am corectat unele erori.
Primul caz: aplicația mobilă
La început, am studiat parcursul studentului prin cel mai popular produs al nostru — cursul General. În acel moment, lucram în departamentul pentru copii Skyeng și voiam să vedem cât de eficient este mobilul nostru aplicație cu publicul nostru tânăr.
După ce am luat fișierele de log și le-am procesat printr-un script, am obținut ceva de genul:
Nodul de start — Start General, iar în jos sunt trei noduri finale: studentul „a adormit”, a schimbat cursul, a terminat cursul.
- A adormit, „Zasnul” — înseamnă că nu mai urmează lecții, cel mai probabil s-a retras. Noi numim optimist acest stadiu „a adormit” deoarece, în teorie, el are în continuare posibilitatea de a continua studiile. Cel mai rău rezultat pentru noi.
- A schimbat cursul, a trecut de la General la altceva și s-a pierdut pentru lanțul nostru Markov.
- A terminat cursul — un stadiu ideal, persoana a parcurs 80% din lecții (nu toate lecțiile sunt obligatorii).
Intrarea în nodul lecție reușită semnifică finalizarea cu succes a lecției pe platforma noastră împreună cu profesorul. Aceasta fixează progresul pe curs și apropierea de rezultatul dorit — „A terminat cursul”. Este important pentru noi ca studenții să o viziteze cât mai mult.
Pentru a obține concluzii cantitative mai precise pentru aplicația mobilă (nodul sesiune app), am construit lanțuri separate pentru fiecare din nodurile finale și apoi am comparat perechea greutățile muchiilor:
- din sesiunea app înapoi în ea însuși;
- din sesiunea app în lecție reușită;
- din lecție reușită în sesiunea app.
La stânga — studenți care au terminat cursul, la dreapta — „a adormit”
Aceste trei muchii arată legătura dintre succesul studentului și utilizarea aplicației mobile. Ne așteptam să vedem că studenții care au terminat cursul au o legătură mai puternică cu aplicația decât „aduce-l la somn”. Cu toate acestea, în realitate, am obținut rezultate exact opuse:
- ne-am convins că diferitele grupuri de utilizatori interacționează diferit cu aplicația mobilă;
- studenții de succes folosesc aplicația mobilă mai puțin intensiv;
- studenții care adorm folosesc mai activ aplicația mobilă.
Aceasta înseamnă că studenții «care adorm» încep să petreacă din ce în ce mai mult timp în aplicația mobilă și, în cele din urmă, rămân în ea pentru totdeauna.
La început am fost surprinși, dar, după ce ne-am gândit, am realizat că este un efect destul de firesc. Cândva, am învățat singur franceza folosind două instrumente: aplicația mobilă și lecțiile de gramatică de pe YouTube. La început, îmi împărțeam timpul între ele în proporție de 50 la 50. Dar aplicația era mai distractivă, exista gamificare, totul era simplu, rapid și clar, în timp ce lecțiile necesitau implicare, notarea unor lucruri și practică în caiet. Treptat, am început să petrec mai mult timp pe smartphone, până când ponderea acestuia a ajuns la 100%: dacă rămâi în el timp de trei ore, se creează o iluzie falsă a muncii realizate, din cauza căreia nu mai există dorința de a pleca și de a asculta ceva.
Dar cum așa? Noi am creat special aplicația mobilă, am gamificat-o, am făcut-o atrăgătoare, pentru ca oamenii să petreacă timp în ea, iar se pare că ea doar îi distrage? De fapt, cauza este că echipa aplicației mobile a făcut prea bine treaba, rezultând într-un produs grozav, auto-suficient, care a început să iasă din ecosistemul nostru.
În urma cercetării, s-a ajuns la înțelegerea că aplicația mobilă trebuie să fie schimbată pentru a distrage mai puțin de la cursul principal de învățare. Și pentru copii, și pentru adulți. Acum, această muncă este în desfășurare.
Al doilea caz: bug-uri în procesul de onboarding.
Îndrumarea este o procedură opțională suplimentară la înregistrarea unui nou student, care elimină potențialele probleme tehnice în viitor. Scenariul de bază presupune că persoana s-a înregistrat pe pagina de destinație, a obținut acces la contul personal, este contactată și participă la o lecție introductivă. În acest context, observăm un procent mare de dificultăți tehnice în timpul lecției introductive: versiunea greșită a browser-ului, microfonul sau sonorul care nu funcționează, iar profesorul nu poate oferi imediat o soluție, iar toate acestea sunt cu atât mai complicate când este vorba despre copii. De aceea, am dezvoltat o aplicație suplimentară în contul personal, unde pot fi efectuați patru pași simpli: verificarea browser-ului, camerei, microfonului și confirmarea că părinții vor fi lângă copii în timpul lecției introductive (deoarece ei sunt cei care plătesc pentru educația copiilor).
Aceste câteva pagini de îndrumare au demonstrat un astfel de funnel:
1: un bloc de start cu trei formulare de login-parola ușor diferite (în funcție de client).
2: o bifă de consimțământ pentru procedura suplimentară de îndrumare.
2.1-2.3: verificarea prezenței părintelui, versiunea Chrome și sunetul.
3: blocul final.
Arată foarte natural: în primele două etape, cea mai mare parte a vizitatorilor se pierde, realizând că trebuie să completeze ceva, să verifice, iar timpul este limitat. Dacă clientul a ajuns la pasul trei, atunci este aproape sigur că va ajunge la final. În funnel nu se observă niciun motiv pentru a suspecta ceva.
Cu toate acestea, am decis să analizăm îndrumarea noastră nu pe un funnel clasic unidimensional, ci printr-un model Markov. Am inclus puțin mai multe evenimente, am rulat scriptul și am obținut următorul rezultat:
Din acest haos se poate înțelege un singur lucru: ceva nu a mers bine. Procesul de îndrumare este liniar, acest lucru este încorporat în design, nu ar trebui să existe o astfel de rețea de legături. Dar aici este clar că utilizatorul este aruncat între pași, între care nu ar trebui să existe tranziții.
Cauzele acestei imagini ciudate pot fi două:
- erori au fost introduse în baza de loguri;
- erorile sunt prezente în produsul în sine – îndrumare.
Primul motiv, cel mai probabil, este valid, dar verificarea acestuia este destul de complicată, iar corectarea logurilor nu va ajuta la îmbunătățirea experienței utilizatorului. În ceea ce privește al doilea motiv, dacă acesta există, trebuia să se acționeze rapid. Așadar, ne-am îndreptat spre examinarea nodurilor, identificarea muchiilor care nu ar trebui să existe și căutarea cauzelor apariției acestora. Am observat că unii utilizatori se blocau și circulau în cerc, alții erau aruncați din mijloc în început, iar alții pur și simplu nu puteau scăpa din primele două pași. Am transmis datele către QA — și da, s-a dovedit că onboarding-ul avea suficient de multe buguri: acesta era un produs secundar, puțin improvizat, care nu a fost testat suficient de bine, deoarece nu se așteptau probleme. Acum întregul proces de înregistrare s-a schimbat.
Această poveste ne-a arătat o aplicare neașteptată a lanțurilor Markov în domeniul QA.
Încercați și voi!
Am postat scriptul meu în acces deschis — folosiți-l cu plăcere. Documentația este pe GitHub, întrebările pot fi adresate aici, voi încerca să răspund la toate.
Și iată câteva linkuri utile: , . Iar aici despre lanțurile Markov. Graficele din articol sunt realizate cu ajutorul .
Sursa: habr.com
