Meille on tärkeää ymmärtää, mitä opiskelijoillemme tapahtuu koulutuksen aikana ja miten nämä tapahtumat vaikuttavat tulokseen, joten rakennamme Asiakasmatkakartan - kartan asiakaskokemuksesta. Oppimisprosessi ei loppujen lopuksi ole jotain jatkuvaa ja kiinteää, se on ketju toisiinsa liittyviä tapahtumia ja opiskelijan toimintoja, jotka voivat vaihdella suuresti eri opiskelijoiden välillä. Nyt hän on suorittanut oppituntinsa: mitä hän tekee seuraavaksi? Meneekö se läksyihin? Avaako se mobiilisovelluksen? Muuttaako hän kurssia, pyytääkö hän vaihtamaan opettajia? Menetkö suoraan seuraavalle tunnille? Vai lähteekö hän vain pettyneenä? Onko tätä karttaa analysoimalla mahdollista tunnistaa malleja, jotka johtavat kurssin onnistuneeseen suorittamiseen tai päinvastoin opiskelijan "keskeyttämiseen"?
Tyypillisesti CJM:n rakentamiseen käytetään erikoistuneita, erittäin kalliita suljetun lähdekoodin työkaluja. Halusimme kuitenkin keksiä jotain yksinkertaista, joka vaatii vain vähän vaivaa ja jos mahdollista avoimen lähdekoodin. Niinpä syntyi ajatus käyttää Markovin ketjuja - ja onnistuimme. Rakensimme kartan, tulkitsimme tietoja opiskelijoiden käyttäytymisestä kaavion muodossa, näimme täysin epäselviä vastauksia globaaleihin liiketoimintaongelmiin ja löysimme jopa syvästi piilotettuja virheitä. Teimme kaiken tämän käyttämällä avoimen lähdekoodin Python-skriptiratkaisuja. Tässä artikkelissa puhun kahdesta tapauksesta, joiden tulokset eivät ole ilmeisiä, ja jaan käsikirjoituksen kaikkien kanssa.
Joten Markovin ketjut osoittavat tapahtumien välisten siirtymien todennäköisyyden. Tässä primitiivinen esimerkki Wikipediasta:
Tässä "E" ja "A" ovat tapahtumia, nuolet ovat siirtymiä niiden välillä (mukaan lukien siirtyminen tapahtumasta samaan), ja nuolien painot ovat siirtymän todennäköisyys ("painotettu suunnattu kaavio").
Mitä käytit?
Piiri koulutettiin vakio Python-toiminnallisuudella, jota syötettiin opiskelijoiden toimintalokeilla. Tuloksena olevan matriisin kaavion rakensi NetworkX-kirjasto.
Loki näyttää tältä:
Tämä on csv-tiedosto, joka sisältää taulukon, jossa on kolme saraketta: opiskelijatunnus, tapahtuman nimi, tapahtuman aika. Nämä kolme kenttää riittää jäljittämään asiakkaan liikkeitä, rakentamaan kartan ja lopulta hankkimaan Markov-ketjun.
Kirjasto palauttaa rakennetut kaaviot .dot- tai .gexf-muodossa. Edellisen visualisoimiseksi voit käyttää ilmaista Graphviz-pakettia (gvedit-työkalu), työskentelimme .gexf:n ja Gephin kanssa, myös ilmainen.
Seuraavaksi haluaisin antaa kaksi esimerkkiä Markov-ketjujen käytöstä, joiden avulla pystyimme katsomaan uudella tavalla tavoitteitamme, koulutusprosessejamme ja itse Skyeng-ekosysteemiä. No, korjaa viat.
Ensimmäinen tapaus: mobiilisovellus
Aluksi tutkimme opiskelijan matkaa suosituimman tuotteemme – yleiskurssin – kautta. Työskentelin sillä hetkellä Skyengin lastenosastolla ja halusimme nähdä kuinka tehokkaasti mobiilisovellus toimii lapsiyleisömme kanssa.
Ottamalla lokit ja suorittamalla ne skriptin läpi, sain jotain tällaista:
Aloitussolmu on Start General, ja alareunassa on kolme lähtösolmua: opiskelija "nukahti", vaihtoi kurssia ja lopetti kurssin.
- Nukahti, "nukkui" - tämä tarkoittaa, että hän ei enää ota tunteja, todennäköisesti hän putosi. Kutsumme tätä tilaa optimistisesti "nukkuneeksi", koska... teoriassa hänellä on vielä mahdollisuus jatkaa opintojaan. Huonoin tulos meille.
- Pudonnut kenraalin, Vaihdettu kurssi - vaihtui kenraalista johonkin muuhun ja eksyi Markov-ketjullemme.
- Kurssi on valmis, kurssi suoritettu - ihanteellinen kunto, henkilö on suorittanut 80% oppituneista (kaikkia oppitunteja ei vaadita).
Onnistuneen luokan solmupisteeseen pääseminen tarkoittaa oppitunnin onnistunutta suorittamista alustallamme yhdessä opettajan kanssa. Se tallentaa edistymisen kurssin varrella ja lähestymistavan haluttuun tulokseen - "Kurssin suoritettu". Meille on tärkeää, että opiskelijat osallistuvat mahdollisimman paljon.
Saadaksemme tarkempia kvantitatiivisia johtopäätöksiä mobiilisovelluksesta (sovellusistuntosolmu), rakensimme erilliset ketjut jokaiselle lopulliselle solmulle ja vertasimme sitten reunapainoja pareittain:
- sovellusistunnosta takaisin siihen;
- sovellusistunnosta onnistuneeseen luokkaan;
- onnistuneesta luokasta sovellusistuntoon.
Vasemmalla ovat kurssin suorittaneet opiskelijat, oikealla ne, jotka "nukahtivat"
Nämä kolme reunaa osoittavat opiskelijan menestyksen ja mobiilisovelluksen käytön välisen suhteen. Odotimme, että kurssin suorittaneilla opiskelijoilla olisi vahvempi yhteys hakemukseen kuin nukahtaneilla. Todellisuudessa saimme kuitenkin täsmälleen päinvastaiset tulokset:
- varmistimme, että eri käyttäjäryhmät ovat vuorovaikutuksessa mobiilisovelluksen kanssa eri tavalla;
- menestyneet opiskelijat käyttävät mobiilisovellusta vähemmän intensiivisesti;
- nukahtavat opiskelijat käyttävät mobiilisovellusta aktiivisemmin.
Tämä tarkoittaa, että nukahtavat opiskelijat alkavat viettää yhä enemmän aikaa mobiilisovelluksessa ja pysyvät siinä lopulta ikuisesti.
Aluksi yllätyimme, mutta pohdittuamme sitä tajusimme, että tämä oli täysin luonnollinen vaikutus. Aikoinaan opiskelin ranskaa yksin kahdella työkalulla: mobiilisovelluksella ja kieliopin luennoilla YouTubessa. Aluksi jaoin ajan niiden kesken suhteessa 50:50. Mutta sovellus on hauskempaa, siellä on pelillistämistä, kaikki on yksinkertaista, nopeaa ja selkeää, mutta luennolla pitää syventyä siihen, kirjoittaa jotain ylös. , harjoittele muistikirjassa. Vähitellen aloin viettää enemmän aikaa älypuhelimellani, kunnes sen osuus kasvoi 100 prosenttiin: jos vietät siihen kolme tuntia, luot väärän tunteen tehdystä työstä, jonka vuoksi sinulla ei ole halua mennä kuuntelemaan mitään .
Mutta miten tämä voi olla? Loppujen lopuksi loimme erityisesti mobiilisovelluksen, , pelillisti sen, teki siitä houkuttelevan, jotta ihmiset viettäisivät aikaa siinä, mutta osoittautuu, että se vain häiritsee heitä? Itse asiassa syynä on se, että mobiilisovellustiimi selviytyi tehtävistään liian hyvin, minkä seurauksena siitä tuli siisti, omavarainen tuote ja alkoi pudota pois ekosysteemistään.
Tutkimuksen tuloksena kävi selväksi, että mobiilisovellusta on muutettava jotenkin niin, että se ei häiritsisi vähemmän pääkurssia. Ja niin lapset kuin aikuisetkin. Tämä työ on parhaillaan käynnissä.
Toinen tapaus: käyttöönottovirheet
Onboarding on valinnainen lisämenettely uutta opiskelijaa rekisteröitäessä, mikä eliminoi mahdolliset tekniset ongelmat tulevaisuudessa. Perusskenaariossa oletetaan, että henkilö on rekisteröitynyt aloitussivulle, päässyt henkilökohtaiseen tiliinsä, häneen ollaan yhteydessä ja hänelle annetaan johdantotunti. Samalla havaitsemme johdantotunnilla suuren osan teknisistä vaikeuksista: väärä selaimen versio, mikrofoni tai ääni ei toimi, opettaja ei voi heti ehdottaa ratkaisua, ja kaikki tämä on erityisen vaikeaa, kun se tulee lapsille. Siksi olemme kehittäneet henkilökohtaiselle tilillesi lisäsovelluksen, jossa voit suorittaa neljä yksinkertaista vaihetta: tarkistaa selaimesi, kamerasi, mikrofonisi ja varmistaa, että vanhemmat ovat lähellä esittelytunnin aikana (hehän maksavat heidän lastensa koulutus).
Näillä muutamalla aloitussivulla oli tällainen suppilo:
1: aloituslohko, jossa on kolme hieman erilaista (asiakkaasta riippuen) kirjautumis- ja salasanansyöttölomaketta.
2: valintaruutu, jossa hyväksytään ylimääräinen käyttöönottomenettely.
2.1-2.3: Tarkista vanhemman läsnäolo, Chrome-versio ja ääni.
3: viimeinen lohko.
Se näyttää hyvin luonnolliselta: kahdessa ensimmäisessä vaiheessa suurin osa vierailijoista lähtee ja huomaa, että on jotain täytettävää, tarkistettavaa, mutta aikaa ei ole. Jos asiakas on saavuttanut kolmannen vaiheen, hän saavuttaa melkein varmasti finaalin. Ei ole yhtä syytä epäillä mitään suppilossa.
Päätimme kuitenkin analysoida perehtymistämme ei klassiseen yksiulotteiseen suppiloon, vaan Markovin ketjuun. Laitoimme päälle vähän enemmän tapahtumia, suoritimme käsikirjoituksen ja saimme tämän:
Tässä kaaoksessa vain yksi asia voidaan ymmärtää selvästi: jokin meni pieleen. Käyttöönottoprosessi on lineaarinen, tämä on luonnostaan suunnittelussa, siinä ei pitäisi olla sellaista yhteyksien verkkoa. Ja tässä on heti selvää, että käyttäjä heitetään vaiheiden väliin, joiden välillä ei pitäisi olla lainkaan siirtymiä.
Tälle oudolle kuvalle voi olla kaksi syytä:
- parvet hiipivät lokitietokantaan;
- Itse tuotteessa on virheitä - onboarding.
Ensimmäinen syy on todennäköisesti totta, mutta sen testaus on melko työlästä, eikä lokien korjaaminen auta parantamaan käyttökokemusta. Mutta toisen kanssa, jos se on olemassa, jotain oli tehtävä kiireellisesti. Siksi menimme katsomaan solmuja, tunnistamaan reunat, joita ei pitäisi olla, ja etsimään syitä niiden esiintymiseen. Näimme, että osa käyttäjistä jäi jumissa ja käveli ympyröitä, toiset putosivat keskeltä alkuun ja toiset eivät periaatteessa päässeet ulos kahdesta ensimmäisestä askeleesta. Siirsimme tiedot QA:lle - ja kyllä, kävi ilmi, että onboardingissa oli tarpeeksi bugeja: tämä on sellainen sivutuote, vähän kainalosauva, sitä ei testattu tarpeeksi syvällisesti, koska... Emme odottaneet mitään ongelmia. Nyt koko tallennusprosessi on muuttunut.
Tämä tarina osoitti meille odottamattoman Markovin ketjujen sovelluksen laadunvarmistuksen alalla.
Kokeile itse!
Postasin omani julkisessa käytössä - käytä sitä terveydellesi. Dokumentaatio GitHubissa, kysymyksiä voi esittää täällä, yritän vastata kaikkeen.
No hyödyllisiä linkkejä: , . Ja täällä Markovin ketjuista. Artikkelin kaaviot on tehty käyttämällä .
Lähde: will.com