Fontos számunkra, hogy megértsük, mi történik hallgatóinkkal a képzés során, és ezek az események hogyan befolyásolják az eredményt, ezért készítünk egy Ügyfélúttérképet - az ügyfélélmény térképét. Hiszen a tanulási folyamat nem valami folytonos és integrált dolog, hanem a tanuló egymáshoz kapcsolódó események és cselekvéseinek láncolata, és ezek a cselekvések nagyon eltérőek lehetnek a különböző tanulók között. Most befejezte a leckét: mit fog tenni ezután? Házi feladatra fog menni? Elindít mobilalkalmazást? Változtat-e irányt, kérni fog-e tanárváltást? Egyenesen a következő leckére megy? Vagy csak csalódottan távozik? Lehetséges-e ennek a térképnek az elemzésével azonosítani azokat a mintákat, amelyek a kurzus sikeres elvégzéséhez, vagy éppen ellenkezőleg, a hallgató „lemorzsolásához” vezetnek?
A CJM felépítéséhez általában speciális, nagyon drága, zárt forráskódú eszközöket használnak. De valami egyszerűt akartunk kitalálni, minimális erőfeszítést, és ha lehetséges, nyílt forráskódot igényel. Így jött az ötlet, hogy Markov-láncokat használjunk – és sikerült is. Építettünk egy térképet, grafikon formájában értelmeztük a tanulók viselkedésére vonatkozó adatokat, láttunk teljesen nem nyilvánvaló válaszokat a globális üzleti problémákra, és még mélyen rejtett hibákat is találtunk. Mindezt nyílt forráskódú Python szkriptmegoldások segítségével tettük. Ebben a cikkben két olyan esetről fogok beszélni, amelyek nagyon nem nyilvánvaló eredménnyel járnak, és mindenkivel megosztom a forgatókönyvet.
Tehát a Markov-láncok az események közötti átmenetek valószínűségét mutatják. Íme egy primitív példa a Wikipédiából:
Itt az „E” és „A” események, a nyilak a köztük lévő átmenetek (beleértve az eseményről az azonosra való átmenetet is), a nyilak súlya pedig az átmenet valószínűsége („súlyozott irányított gráf”).
mit használtál?
Az áramkört szabványos Python-funkcióval képezték ki, amely a tanulói tevékenységnaplókkal volt táplálva. A kapott mátrixon a grafikont a NetworkX könyvtár készítette.
A napló így néz ki:
Ez egy csv fájl, amely három oszlopból álló táblázatot tartalmaz: diákigazolvány, az esemény neve, az esemény időpontja. Ez a három mező elegendő az ügyfél mozgásának nyomon követéséhez, térkép készítéséhez, és végül Markov-lánchoz.
A könyvtár az összeállított gráfokat .dot vagy .gexf formátumban adja vissza. Előbbi megjelenítéséhez használhatjuk az ingyenes Graphviz csomagot (gvedit eszköz), dolgoztunk a szintén ingyenes .gexf-el és Gephi-vel.
A következőkben két példát szeretnék hozni a Markov-láncok használatára, amelyek lehetővé tették számunkra, hogy új pillantást vethessünk céljainkra, oktatási folyamatainkra és magára a Skyeng ökoszisztémára. Nos, javítsd ki a hibákat.
Első eset: mobil alkalmazás
Kezdetben a hallgatók utazását fedeztük fel legnépszerűbb termékünkön – az Általános tanfolyamon – keresztül. Abban a pillanatban a Skyeng gyermekosztályán dolgoztam, és látni akartuk, hogy a mobilalkalmazás mennyire hatékonyan működik gyermekközönségünkkel.
A naplókat átvéve és a szkripten keresztül futtatva valami ilyesmit kaptam:
A kezdő csomópont a Start General, alul pedig három kimeneti csomópont található: a hallgató „elaludt”, irányt váltott és befejezte a kurzust.
- Elaludt, „Elaludt” - ez azt jelenti, hogy már nem vesz részt az órákon, valószínűleg leesett. Ezt az állapotot optimistán „alvónak” nevezzük, mert... elméletileg még van lehetősége tanulmányait folytatni. A legrosszabb eredmény számunkra.
- Elhagyott tábornok, irányt váltott - tábornokról valami másra váltott, és eltévedt a Markov-láncunkhoz.
- Befejezett tanfolyam, Befejezett tanfolyam - ideális állapot, a személy a leckék 80%-át teljesítette (nem minden leckét kötelező).
A sikeres osztálycsomópontba kerülni azt jelenti, hogy a tanárral együtt sikeresen teljesítjük a leckét platformunkon. Rögzíti a haladást a pálya mentén és a kívánt eredmény elérését – „A tanfolyam befejezve”. Fontos számunkra, hogy a tanulók minél többet jelenjenek meg.
Annak érdekében, hogy pontosabb kvantitatív következtetéseket vonjunk le a mobilalkalmazásra (alkalmazás-munkamenet-csomópontra), külön láncokat építettünk az egyes végső csomópontokhoz, majd páronként összehasonlítottuk az élsúlyokat:
- az alkalmazás-munkamenetből vissza oda;
- az alkalmazásmenettől a sikeres osztályig;
- a sikeres kurzustól az alkalmazásmenetig.
A bal oldalon a kurzust végzett hallgatók, a jobb oldalon azok, akik „elaludtak”
Ez a három él mutatja a kapcsolatot a tanuló sikere és a mobilalkalmazás használata között. Arra számítottunk, hogy a kurzust elvégző hallgatók erősebben kapcsolódnak a pályázathoz, mint az elaludt hallgatók. A valóságban azonban pont az ellenkező eredményt kaptuk:
- gondoskodtunk arról, hogy a felhasználók különböző csoportjai eltérően lépjenek kapcsolatba a mobilalkalmazással;
- a sikeres hallgatók kevésbé intenzíven használják a mobilalkalmazást;
- az elaludt tanulók aktívabban használják a mobilalkalmazást.
Ez azt jelenti, hogy az elaludt diákok egyre több időt töltenek a mobilalkalmazásban, és végül örökre benne maradnak.
Először meglepődtünk, de utánagondolva rájöttünk, hogy ez teljesen természetes hatás. Egy időben egyedül tanultam franciául két eszköz segítségével: mobilalkalmazással és nyelvtani előadásokkal a YouTube-on. Eleinte 50-50 arányban osztottam el az időt közöttük. De az alkalmazás szórakoztatóbb, van gamification, minden egyszerű, gyors és világos, de az előadáson bele kell elmélyedni, le kell írni valamit. , gyakorlat jegyzetfüzetben. Fokozatosan elkezdtem több időt tölteni az okostelefonomon, mígnem az aránya 100%-ra nőtt: ha három órát töltesz vele, hamis kész munka érzést keltesz, ami miatt nincs kedved elmenni és hallgatni semmit. .
De hogy lehet ez? Végül is speciálisan készítettünk egy mobil alkalmazást, , eljátszott, vonzóvá tette, hogy az emberek időt töltsenek benne, de kiderül, hogy csak elvonja a figyelmüket? Valójában az az oka, hogy a mobilalkalmazás csapata túl jól megbirkózott a feladataival, aminek eredményeként menő, önellátó termék lett, és kezdett kiesni ökoszisztémánkból.
A kutatás eredményeként világossá vált, hogy a mobilalkalmazáson valahogy változtatni kell, hogy kevésbé vonja el a figyelmet a főtanfolyamról. És gyerekeknek és felnőtteknek egyaránt. Ez a munka jelenleg folyamatban van.
Második eset: bevezető hibák
A beiskolázás egy opcionális kiegészítő eljárás új hallgató regisztrálásakor, kiküszöbölve az esetleges technikai problémákat a jövőben. Az alapforgatókönyv feltételezi, hogy egy személy regisztrált a céloldalon, hozzáfért személyes fiókjához, felveszik vele a kapcsolatot, és bevezető leckét kapnak. Ugyanakkor a bevezető órán a technikai nehézségek nagy százalékát észleljük: nem működik a rossz böngészőverzió, a mikrofon vagy a hang, a tanár nem tud azonnal megoldást javasolni, és mindez különösen nehéz, ha jön. gyerekeknek. Ezért kifejlesztettünk egy további alkalmazást a személyes fiókjában, ahol négy egyszerű lépést hajthat végre: ellenőrizze a böngészőt, a kamerát, a mikrofont, és győződjön meg arról, hogy a szülők a közelben lesznek a bevezető órán (végül is ők fizetnek gyermekeik oktatása).
Ez a néhány bevezető oldal egy ehhez hasonló tölcsért mutatott:
1: kezdőblokk három kissé eltérő (klienstől függően) bejelentkezési és jelszóbeviteli űrlappal.
2: jelölőnégyzet, amely beleegyezik a további felvételi eljárásba.
2.1–2.3: Ellenőrizze a szülők jelenlétét, a Chrome verzióját és a hangot.
3: utolsó blokk.
Nagyon természetesnek tűnik: az első két lépésben a legtöbb látogató elmegy, rájön, hogy van mit kitölteni, ellenőrizni, de nincs idő. Ha az ügyfél elérte a harmadik lépést, akkor szinte biztos, hogy bejut a döntőbe. Nincs egyetlen ok arra, hogy bármit is gyanítsunk a tölcséren.
Ennek ellenére úgy döntöttünk, hogy nem egy klasszikus egydimenziós tölcséren, hanem egy Markov-lánc segítségével elemezzük beépítésünket. Bekapcsoltunk még egy kis eseményt, lefuttattuk a forgatókönyvet, és ezt kaptuk:
Ebben a káoszban csak egy dolgot lehet világosan megérteni: valami elromlott. A beépítési folyamat lineáris, ez a dizájn velejárója, ne legyen benne ilyen kapcsolatháló. És itt azonnal látható, hogy a felhasználót olyan lépések közé dobják, amelyek között egyáltalán nem szabad átmenetnek lennie.
Ennek a furcsa képnek két oka lehet:
- rajok kúsztak be a napló adatbázisába;
- Hibák vannak magában a termékben – a beépítésben.
Az első ok valószínűleg igaz, de a tesztelése meglehetősen munkaigényes, és a naplók javítása nem segít az UX javításában. De a másodikkal, ha létezik, sürgősen tenni kellett valamit. Ezért elmentünk megnézni a csomópontokat, azonosítani azokat az éleket, amelyeknek nem kellene létezniük, és megkeresni az előfordulásuk okát. Azt láttuk, hogy egyes felhasználók elakadtak és körbe jártak, mások a közepéről estek ki az elejére, mások pedig elvileg nem tudtak kijönni az első két lépésből. Átvittük az adatokat a QA-nak - és igen, kiderült, hogy az onboardingban van elég bug: ez akkora melléktermék, kicsit mankó, nem volt elég mélyen tesztelve, mert... Problémára nem számítottunk. Most az egész felvételi folyamat megváltozott.
Ez a történet megmutatta nekünk a Markov-láncok váratlan alkalmazását a minőségbiztosítás területén.
Próbáld ki magad!
közzétettem az enyémet közkinccsé – használja egészsége érdekében. Dokumentáció a GitHubon, itt lehet kérdéseket feltenni, igyekszem mindenre válaszolni.
Nos, hasznos linkek: , . És itt Markov-láncokról. A cikkben szereplő grafikonok felhasználásával készültek .
Forrás: will.com