Je pre nás dôležité, aby sme pochopili, čo sa deje s našimi študentmi počas školenia a ako tieto udalosti ovplyvňujú výsledok, preto zostavujeme mapu zákazníckej cesty – mapu zákazníckej skúsenosti. Koniec koncov, proces učenia nie je niečo nepretržité a integrálne, je to reťazec vzájomne prepojených udalostí a akcií študenta a tieto akcie sa môžu medzi rôznymi študentmi značne líšiť. Teraz dokončil svoju lekciu: čo bude robiť ďalej? Pôjde to na domácu úlohu? Spustí mobilnú aplikáciu? Zmení kurz, požiada o zmenu učiteľa? Pôjdete rovno na ďalšiu lekciu? Alebo odíde len sklamaný? Je možné pomocou analýzy tejto mapy identifikovať vzorce, ktoré vedú k úspešnému ukončeniu kurzu alebo naopak k „vypadnutiu“ študenta?
Na vytvorenie CJM sa zvyčajne používajú špecializované, veľmi drahé nástroje s uzavretým zdrojom. Chceli sme však prísť s niečím jednoduchým, vyžadujúcim minimálne úsilie a pokiaľ možno open source. Tak prišiel nápad použiť Markovove reťaze – a podarilo sa. Vytvorili sme mapu, interpretovali údaje o správaní študentov vo forme grafu, videli sme úplne neočividné odpovede na globálne obchodné problémy a dokonca sme našli hlboko skryté chyby. To všetko sme urobili pomocou open source riešení skriptov Python. V tomto článku budem hovoriť o dvoch prípadoch s týmito veľmi nezrejmými výsledkami a zdieľať scenár so všetkými.
Markovove reťazce teda ukazujú pravdepodobnosť prechodov medzi udalosťami. Tu je primitívny príklad z Wikipédie:
Tu sú „E“ a „A“ udalosti, šípky sú prechody medzi nimi (vrátane prechodu z udalosti na rovnakú) a váhy šípok predstavujú pravdepodobnosť prechodu („vážený orientovaný graf“).
čo si použil?
Okruh bol trénovaný so štandardnou funkcionalitou Pythonu, ktorá bola napájaná protokolmi aktivít študentov. Graf na výslednej matici bol skonštruovaný knižnicou NetworkX.
Log vyzerá takto:
Toto je súbor csv obsahujúci tabuľku troch stĺpcov: ID študenta, názov udalosti, čas, kedy k nej došlo. Tieto tri polia stačia na sledovanie pohybu klienta, zostavenie mapy a nakoniec na získanie Markovovej reťaze.
Knižnica vracia vytvorené grafy vo formáte .dot alebo .gexf. Na vizualizáciu prvého môžete použiť bezplatný balík Graphviz (nástroj gvedit), pracovali sme s .gexf a Gephi, tiež zadarmo.
Ďalej by som rád uviedol dva príklady používania Markovových reťazcov, ktoré nám umožnili nový pohľad na naše ciele, vzdelávacie procesy a samotný ekosystém Skyeng. No opravte chyby.
Prvý prípad: mobilná aplikácia
Na začiatok sme preskúmali cestu študentov cez náš najobľúbenejší produkt – všeobecný kurz. V tom momente som pracoval na detskom oddelení Skyeng a chceli sme vidieť, ako efektívne funguje mobilná aplikácia s našim detským publikom.
Keď som vzal denníky a prebehol ich cez skript, dostal som niečo takéto:
Počiatočný uzol je Start General a v spodnej časti sú tri výstupné uzly: študent „zaspal“, zmenil kurz a dokončil kurz.
- Zaspal, „Zaspal“ - to znamená, že už nechodí na hodiny, pravdepodobne spadol. Tento stav optimisticky nazývame „spiaci“, pretože... teoreticky má ešte možnosť pokračovať v štúdiu. Najhorší výsledok pre nás.
- Generál vypadol, zmenil sa kurz – zmenil sa z generála na niečo iné a stratil sa pre náš reťazec Markov.
- Ukončený kurz, Ukončený kurz - ideálny stav, človek absolvoval 80% lekcií (nie všetky lekcie sú povinné).
Dostať sa do úspešného uzla triedy znamená úspešne dokončiť lekciu na našej platforme spolu s učiteľom. Zaznamenáva pokrok na trati a priblíženie sa k požadovanému výsledku – „Dokončil som kurz“. Záleží nám na tom, aby študenti chodili čo najviac.
Aby sme získali presnejšie kvantitatívne závery pre mobilnú aplikáciu (uzol relácie aplikácie), vytvorili sme samostatné reťazce pre každý z konečných uzlov a potom sme párovo porovnali váhy hrán:
- z relácie aplikácie späť do nej;
- od relácie aplikácie po úspešnú triedu;
- od úspešnej triedy po reláciu aplikácie.
Vľavo sú študenti, ktorí ukončili kurz, vpravo tí, ktorí „zaspali“
Tieto tri hrany ukazujú vzťah medzi úspechom študenta a jeho používaním mobilnej aplikácie. Očakávali sme, že študenti, ktorí kurz absolvovali, budú mať k aplikácii silnejšie spojenie ako študenti, ktorí zaspali. V skutočnosti sme však dostali presne opačné výsledky:
- zabezpečili sme, že rôzne skupiny používateľov interagujú s mobilnou aplikáciou odlišne;
- úspešní študenti využívajú mobilnú aplikáciu menej intenzívne;
- študenti, ktorí zaspávajú, aktívnejšie využívajú mobilnú aplikáciu.
To znamená, že študenti, ktorí zaspia, začnú tráviť čoraz viac času v mobilnej aplikácii a nakoniec v nej zostanú navždy.
Najprv sme boli prekvapení, ale po premýšľaní sme si uvedomili, že ide o úplne prirodzený efekt. Svojho času som študoval francúzštinu sám pomocou dvoch nástrojov: mobilnej aplikácie a prednášok gramatiky na YouTube. Najprv som medzi nich rozdelil čas v pomere 50 ku 50. Aplikácia je ale zábavnejšia, je tam gamifikácia, všetko je jednoduché, rýchle a prehľadné, no na prednáške sa do toho treba zahĺbiť, niečo si zapísať , cvičenie v zošite. Postupne som začal tráviť viac času na svojom smartfóne, až jeho podiel narástol na 100%: ak na ňom strávite tri hodiny, vytvárate falošný pocit dokončenej práce, kvôli ktorému nemáte chuť ísť čokoľvek počúvať. .
Ale ako to môže byť? Koniec koncov, vytvorili sme špeciálne mobilnú aplikáciu, , gamifikoval, zatraktívnil, aby v ňom ľudia trávili čas, no ukázalo sa, že ich to len rozptyľuje? Dôvodom je v skutočnosti to, že tím mobilnej aplikácie si so svojimi úlohami poradil až príliš dobre, v dôsledku čoho sa z neho stal chladný, sebestačný produkt a začal vypadávať z nášho ekosystému.
Výsledkom výskumu bolo jasné, že mobilnú aplikáciu treba nejako zmeniť, aby menej odvádzala pozornosť od hlavného štúdia. A to ako deti, tak aj dospelí. Táto práca momentálne prebieha.
Druhý prípad: palubné chyby
Onboarding je voliteľný dodatočný postup pri registrácii nového študenta, ktorý eliminuje prípadné technické problémy v budúcnosti. Základný scenár predpokladá, že osoba sa zaregistrovala na vstupnej stránke, získala prístup k svojmu osobnému účtu, bude kontaktovaná a dostane úvodnú lekciu. Zároveň sme zaznamenali veľké percento technických ťažkostí počas úvodnej hodiny: nesprávna verzia prehliadača, mikrofón alebo zvuk nefunguje, učiteľ nemôže okamžite navrhnúť riešenie, a to všetko je obzvlášť ťažké, keď príde deťom. Preto sme vo vašom osobnom účte vyvinuli doplnkovú aplikáciu, v ktorej môžete vykonať štyri jednoduché kroky: skontrolovať prehliadač, kameru, mikrofón a potvrdiť, že na úvodnej hodine budú rodičia nablízku (napokon sú to tí, ktorí platia za vzdelanie ich detí).
Týchto niekoľko vstupných stránok ukázalo zúženie, ako je toto:
1: štartovací blok s tromi mierne odlišnými (v závislosti od klienta) formulármi na zadanie prihlasovacieho mena a hesla.
2: začiarkavacie políčko súhlasu s dodatočným postupom registrácie.
2.1-2.3: Skontrolujte prítomnosť rodiča, verziu prehliadača Chrome a zvuk.
3: záverečný blok.
Vyzerá to veľmi prirodzene: v prvých dvoch krokoch väčšina návštevníkov odchádza, uvedomujúc si, že je čo vypĺňať, kontrolovať, ale nie je čas. Ak klient dosiahol tretí krok, potom sa takmer určite dostane do finále. Neexistuje jediný dôvod na podozrenie na niečo na lieviku.
Napriek tomu sme sa rozhodli analyzovať náš onboarding nie na klasickom jednorozmernom lieviku, ale pomocou Markovho reťazca. Zapli sme trochu viac udalostí, spustili skript a dostali sme toto:
V tomto chaose možno jasne pochopiť iba jednu vec: niečo sa pokazilo. Proces onboardingu je lineárny, to je vlastné dizajnu, nemala by v ňom byť taká sieť spojení. A tu je okamžite jasné, že používateľ je vrhnutý medzi krokmi, medzi ktorými by nemali byť žiadne prechody.
Tento zvláštny obrázok môže mať dva dôvody:
- do databázy denníkov sa vkradli húfy;
- V samotnom produkte – onboardingu sú chyby.
Prvý dôvod je s najväčšou pravdepodobnosťou pravdivý, ale jeho testovanie je dosť náročné na prácu a oprava protokolov nepomôže zlepšiť UX. Ale s tým druhým, ak existuje, bolo treba niečo urgentne urobiť. Išli sme sa preto pozrieť na uzly, identifikovať hrany, ktoré by nemali existovať a hľadať príčiny ich výskytu. Videli sme, že niektorí používatelia sa zasekli a chodili v kruhoch, iní vypadli zo stredu na začiatok a iní sa v zásade nevedeli dostať z prvých dvoch krokov. Údaje sme preniesli do QA – a áno, ukázalo sa, že v onboardingu bolo dosť chýb: toto je taký vedľajší produkt, tak trochu barlička, nebolo to dostatočne hlboko testované, pretože... Nečakali sme žiadne problémy. Teraz sa celý proces nahrávania zmenil.
Tento príbeh nám ukázal nečakané uplatnenie Markovových reťazcov v oblasti QA.
Vyskúšajte sami!
Zverejnil som svoje vo verejnej sfére - používajte to pre svoje zdravie. Dokumentácia na GitHub, otázky možno klásť tu, pokúsim sa na všetko odpovedať.
No, užitočné odkazy: , . A tu o Markovových reťazcoch. Grafy v článku sú vytvorené pomocou .
Zdroj: hab.com