Fontos számunkra, hogy megértsük, mi történik diákjainkkal a tanulás során, és ezek az események hogyan befolyásolják az eredményt, ezért Customer Journey Map-et — ügyfélélmény-térképet készítünk. A tanulás folyamata nem egy folyamatos és egységes valami, hanem a diákok között összefonódott események és cselekvések láncolata, amelyek jelentősen eltérhetnek a különböző diákok esetében. Tehát megtanulta az órát: mit fog tenni ezután? Elkezdi a házi feladatot? Használni fogja a mobilalkalmazást? Megváltoztatja a kurzust, vagy kérni fogja a tanárcserét? Azonnal belép a következő órába? Vagy egyszerűen csak csalódottan távozik? Lehetséges-e, hogy a térkép elemzése révén azonosítsuk azokat a mintázatokat, amelyek a kurzus sikeres befejezéséhez, vagy éppen ellenkezőleg, a diák
Általában a CJM kidolgozásához specializált, meglehetősen drága, zárt forráskódú eszközöket használnak. De mi valami egyszerűt, minimális erőfeszítést igénylőt és lehetőség szerint nyílt forrást szerettünk volna kitalálni. Így merült fel az ötlet, hogy használjunk Markov-láncokat — és sikerült. Felépítettük a térképet, a diákok viselkedéséről szóló adatokat gráf formájában értelmeztük, és olyan globális üzleti kérdésekre kaptunk egészen váratlan válaszokat, hogy még elrejtett hibákat is felfedeztünk. Mindezt nyílt forráskódú Python-szkripttel valósítottuk meg. Ebben a cikkben két esetet mutatok be az említett váratlan eredményekkel, és megosztom a szkriptemet mindenkivel, aki érdeklődik iránta.
Tehát a Markov-láncok megmutatják az események közötti átmenetek valószínűségét. Íme egy primitív példa a Wikipédiából:
Itt az "E" és az "A" — események, a nyilak — az közöttük lévő átmenetek (beleértve az esemény önálló visszautalását is), míg a nyilak súlyai — az átmenet valószínűsége ("súlyozott irányított gráf").
Mit használtunk
A lánc a Python standard funkcióival tanult, a diákok aktivitási naplóit tápláltuk be. A gráf a kapott mátrixon a NetworkX könyvtárral készült.
A napló így néz ki:
Ez egy csv fájl, amely három oszlopból áll: diák azonosító, esemény neve, és az esemény bekövetkezésének időpontja. Ezek a három mező elegendő ahhoz, hogy nyomon követhessük az ügyfél mozgását, elkészítsük a térképet, és végül megkaphassuk a Markov-láncot.
A könyvtár .dot vagy .gexf formátumban visszaadott grafikonokat. Az elsőek vizualizálásához ingyenes Graphviz csomagot (gvedit eszközt) használhatunk, mi pedig a .gexf-fel és a szintén ingyenes Gephivel dolgoztunk.
Ezután szeretnék két példát bemutatni a Markov-láncok használatára, amelyek lehetővé tették számunkra, hogy új szemszögből tekintsünk céljainkra, tanulási folyamataikra és magára a Skyeng ökoszisztémára. Valamint kijavítottuk a hibákat.
Első eset: mobilalkalmazás
Első lépésként megvizsgáltuk a hallgatók útját a legnépszerűbb termékünkön — a General kurzuson. Akkoriban a Skyeng gyermek részlegén dolgoztam, és azt akartuk megnézni, mennyire hatékonyan működik a mobilalkalmazás a gyerekközönségünkkel.
A naplók átvizsgálása után ezt kaptam:
Kezdőcsomópont — Start General, az alján pedig három kimeneti csomópont: a diák „elszundított”, váltott kurzust, befejezte a kurzust.
- Fell asleep, „Zasnął” — ez azt jelenti, hogy többé nem látogatja az órákat, valószínűleg leállt. Mi optimistán "elaludt" állapotnak hívjuk, mivel elméletben van lehetősége folytatni a tanulást. Ez számunkra a legrosszabb eredmény.
- Dropped general, Váltott kurzust — átváltott a General-tól valami másra, és elveszett a Markov-láncunk számára.
- Finished course, Befejezte a kurzust — ideális állapot, az ember 80%-át teljesítette az óráknak (nem minden óra kötelező).
A successful class csomópontba való jutás a kurzus sikeres elvégzését jelenti a platformunkon tanárral együtt. Ez rögzíti a haladást a kurzus során és a kívánt eredményhez való közeledést — „Befejezte a kurzust”. Fontos számunkra, hogy a hallgatók minél többször látogassák.
A mobilalkalmazás (app session) pontosabb kvantitatív következtetések érdekében külön láncokat építettünk ki minden végcsomópontra, majd párhuzamosan összehasonlítottuk az élek súlyát:
- az app session-ból vissza önmagába;
- az app session-ból a successful class-ba;
- a successful class-ból az app session-ba.
Balra — a kurzust befejező hallgatók, jobbra — az „elaludtak”
Ezek a három él mutatja a hallgató sikeressége és a mobilalkalmazás használata közötti kapcsolatot. Azt vártuk, hogy a kurzust befejező hallgatóknál a kapcsolat erősebb lesz az alkalmazással, mint az „elaludtak” esetében. Azonban valójában pontosan ellenkező eredményeket kaptunk:
- megbizonyosodtunk róla, hogy a felhasználói csoportok különbözően lépnek interakcióba a mobilalkalmazással;
- A sikeres hallgatók kevésbé intenzíven használják a mobilalkalmazást;
- Az elalvó hallgatók aktívabban használják a mobilalkalmazást.
Ez azt jelenti, hogy az „elalvó” hallgatók egyre több időt töltenek a mobilalkalmazásban, és végül örökre ott maradnak.
Először meglepődtünk, de aztán rájöttünk, hogy ez egy teljesen természetes hatás. Régebben én is önállóan tanultam franciául, mobilalkalmazást és YouTube-on nyelvtani órákat használva. Eleinte az időmet 50-50%-ban osztottam meg közöttük. De az alkalmazás szórakoztatóbb, ott gamifikáció történt, minden egyszerű, gyors és világos, míg az előadásokon mélyebben kell elmerülni, jegyzetelni és gyakorolni a füzetben. Fokozatosan egyre több időt töltöttem a telefonommal, amíg annak részesedése végül elérte a 100%-ot: ha három órán át benne ül az ember, hamis érzése támad a végrehajtott munkáról, ami miatt nem kíváncsi semmire a tényleges tanulás során.
De hogy lehet ez? Hiszen kifejezetten azért készítettük el a mobilalkalmazást, , gamifikáltuk, vonzóvá tettük, hogy az emberek értékes 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 végezte a dolgát, ennek következtében a termék önállóvá vált, és elkezdett kiemelkedni a mi ökoszisztémánkból.
A kutatás végére tudatosult, hogy a mobilalkalmazást valahogy meg kell változtatni, hogy kevesebbet vonjon el az alapvető tanulmányi folyamatról. Ezért a gyermekek és a felnőttek esetében is. Jelenleg ezen dolgozunk.
Második eset: az onboarding hibái
A bevezetés egy nem kötelező kiegészítő eljárás az új diákok regisztrálása során, amely megakadályozza a jövőbeli potenciális technikai problémákat. Az alapvető forgatókönyv azt jelenti, hogy a személy regisztrált a landing oldalon, hozzáférést kapott a személyes fiókjához, felveszik vele a kapcsolatot, és bevezető órát tartanak. E közben magas technikai nehézségeket tapasztaltunk a bevezető óra során: nem a megfelelő böngészőverzió, nem működik a mikrofon vagy a hang, a tanár nem tud azonnal megoldást javasolni, és mindez különösen nehéz, ha gyerekekről van szó. Ezért kifejlesztettünk egy kiegészítő alkalmazást a személyes fiókban, ahol négy egyszerű lépést lehet végrehajtani: ellenőrizni a böngészőt, a kamerát, a mikrofont és megerősíteni, hogy a szülők jelen lesznek a bevezető óra alatt (hiszen ők fizetik a gyerekek oktatását).
Ezek az onboarding oldalakon a következő tölcsér figyelhető meg:
1: kezdeti blokk három kicsit eltérő (ügyféltől függően) bejelentkezési űrlappal.
2: hozzájárulási jelölőnégyzet a kiegészítő onboarding eljáráshoz.
2.1-2.3: a szülő jelenlétének, a Chrome verziójának és a hang teljesítményének ellenőrzése.
3: végső blokk.
Nagyon természetesen néz ki: az első két lépésben a látogatók nagy része eltűnik, amikor rájön, hogy itt valamit ki kell tölteni, ellenőrizni kell, és nincs rá idő. Ha az ügyfél eljut a harmadik lépéshez, akkor szinte biztosan eljut a végső célhoz. A tölcséren nincs nyoma annak, hogy bárki gyanakodjon.
Mégis úgy döntöttünk, hogy az onboarding folyamatunkat nem a klasszikus egy dimenziós tölcsér alapján elemezzük, hanem Markov-lánc segítségével. Kicsit több eseményt vonultattunk fel, elindítottuk a szkriptet, és ezt kaptuk:
A káoszban egyértelműen csak egy dolgot lehet megérteni: valami nem jól működött. Az onboarding folyamata lineáris, ezt a dizájn is előírja, nem lehet benne ilyen szövete a kapcsolatoknak. Itt viszont azonnal látszik, hogy a felhasználót az egyes lépések között dobálja, a lépések között pedig nem lenne szabad átkapcsolásnak lennie.
Ennek a furcsa képnek két oka lehet:
- a log fájlokba hibák keveredtek;
- a termékben magában hibák találhatóak – az onboarding folyamatban.
Az első ok valószínűleg fennáll, de ennek ellenőrzése elég munkaigényes, és a naplók javítása nem segít a felhasználói élmény javításában. A második okkal viszont sürgősen foglalkozni kellett volna, ha létezik. Ezért nekiálltunk a csomópontok vizsgálatának, az eltávolítandó élek azonosításának és a kialakulásuk okainak keresésének. Láttuk, hogy egyes felhasználók ciklusba kerültek, és körbe-körbe jártak, mások pedig a közepéből a kezdetére estek vissza, míg megint mások egyszerűen nem tudtak kijutni az első két lépésből. Az adatokat átadtuk a QA-nak, és igen, kiderült, hogy a bevezetés során rengeteg hiba volt: ez egyfajta melléktermék, kicsit kényszeredett megoldás, amelyet nem teszteltek elég mélyen, mert nem számítottak problémákra. Mostanra az egész regisztrációs folyamat megváltozott.
Ez a történet váratlan alkalmazását mutatta be a Markov-láncoknak a QA területén.
Próbáld ki te is!
Kihúztam a saját nyílt hozzáférésben — használjátok egészséggel. A dokumentáció a GitHub-on található, kérdéseket itt tehetsz fel, igyekszem mindenre válaszolni.
És itt van néhány hasznos link: , . Itt pedig a Markov-láncokról. A cikkben a gráfok a .
Forrás: habr.com
