Je pro nás důležité porozumět tomu, co se s našimi studenty během školení děje a jak tyto události ovlivňují výsledek, proto vytváříme mapu zákaznických cest – mapu zákaznických zkušeností. Koneckonců, proces učení není něco nepřetržitého a integrálního, je to řetězec vzájemně propojených událostí a akcí studenta a tyto akce se mohou mezi různými studenty velmi lišit. Nyní dokončil svou lekci: co bude dělat dál? Půjde to k domácímu úkolu? Spustí mobilní aplikaci? Změní kurz, požádá o změnu učitele? Půjdete rovnou na další lekci? Nebo prostě odejde zklamaný? Je možné analýzou této mapy identifikovat vzorce, které vedou k úspěšnému absolvování kurzu nebo naopak k „odpadnutí“ studenta?
K vytváření CJM se obvykle používají specializované, velmi drahé nástroje s uzavřeným zdrojovým kódem. Chtěli jsme ale přijít s něčím jednoduchým, vyžadujícím minimální úsilí a pokud možno open source. Tak vznikl nápad použít Markovské řetězy – a uspěli jsme. Vytvořili jsme mapu, interpretovali data o chování studentů ve formě grafu, viděli jsme zcela nesrozumitelné odpovědi na globální obchodní problémy a dokonce jsme našli hluboce skryté chyby. To vše jsme provedli pomocí open source řešení skriptů Python. V tomto článku budu mluvit o dvou případech s těmito velmi nezřejmými výsledky a sdílet scénář se všemi.
Markovovy řetězce tedy ukazují pravděpodobnost přechodů mezi událostmi. Zde je primitivní příklad z Wikipedie:
Zde jsou „E“ a „A“ události, šipky jsou přechody mezi nimi (včetně přechodu z události na stejnou) a váhy šipek představují pravděpodobnost přechodu („vážený orientovaný graf“).
co jsi použil?
Okruh byl trénován se standardní funkčností Pythonu, která byla napájena protokoly aktivit studentů. Graf na výsledné matici byl zkonstruován knihovnou NetworkX.
Protokol vypadá takto:
Toto je soubor csv obsahující tabulku se třemi sloupci: ID studenta, název události, čas, kdy k ní došlo. Tato tři pole stačí ke sledování pohybů klienta, sestavení mapy a nakonec k získání Markovova řetězce.
Knihovna vrací vytvořené grafy ve formátu .dot nebo .gexf. Pro vizualizaci prvního můžete použít bezplatný balíček Graphviz (nástroj gvedit), pracovali jsme s .gexf a Gephi, také zdarma.
Dále bych rád uvedl dva příklady použití Markovových řetězců, které nám umožnily nový pohled na naše cíle, vzdělávací procesy a samotný ekosystém Skyeng. Dobře, opravte chyby.
První případ: mobilní aplikace
Nejprve jsme prozkoumali cestu studentů naším nejoblíbenějším produktem – kurzem Obecné. V tu chvíli jsem pracoval na dětském oddělení Skyeng a chtěli jsme vidět, jak efektivně mobilní aplikace pracuje s naším dětským publikem.
Vzal jsem protokoly a prošel je skriptem a dostal jsem něco takového:
Počátečním uzlem je Start General a ve spodní části jsou tři výstupní uzly: student „usnul“, změnil kurz a dokončil kurz.
- Usnul, „usnul“ - to znamená, že již nechodí na hodiny, pravděpodobně spadl. Tento stav optimisticky nazýváme „spící“, protože... teoreticky má stále možnost pokračovat ve studiu. Pro nás nejhorší výsledek.
- Vypadl generál, změnil kurz - přešel z generála na něco jiného a ztratil se pro náš Markovův řetěz.
- Ukončený kurz, Ukončený kurz - ideální stav, člověk absolvoval 80 % lekcí (ne všechny lekce jsou povinné).
Dostat se do úspěšného uzlu třídy znamená úspěšně dokončit lekci na naší platformě společně s učitelem. Zaznamenává pokrok na trati a přiblížení se k požadovanému výsledku – „Dokončeno“. Je pro nás důležité, aby studenti chodili co nejvíce.
Abychom získali přesnější kvantitativní závěry pro mobilní aplikaci (uzel relace aplikace), vytvořili jsme samostatné řetězce pro každý z konečných uzlů a poté jsme párově porovnali váhy hran:
- z relace aplikace zpět do ní;
- od relace aplikace po úspěšnou třídu;
- od úspěšného kurzu k aplikaci.
Vlevo jsou studenti, kteří kurz dokončili, vpravo ti, kteří „usnuli“
Tyto tři hrany ukazují vztah mezi úspěchem studenta a jeho používáním mobilní aplikace. Očekávali jsme, že studenti, kteří kurz dokončili, budou mít k aplikaci silnější spojení než studenti, kteří usnuli. Ve skutečnosti jsme však dostali přesně opačné výsledky:
- zajistili jsme, aby různé skupiny uživatelů interagovaly s mobilní aplikací odlišně;
- úspěšní studenti využívají mobilní aplikaci méně intenzivně;
- studenti, kteří usínají, využívají mobilní aplikaci aktivněji.
To znamená, že studenti, kteří usnou, začnou trávit stále více času v mobilní aplikaci a nakonec v ní zůstanou navždy.
Nejprve jsme byli překvapeni, ale po přemýšlení jsme zjistili, že jde o zcela přirozený efekt. Svého času jsem se francouzsky učil sám pomocí dvou nástrojů: mobilní aplikace a přednášek gramatiky na YouTube. Nejprve jsem mezi ně rozdělil čas v poměru 50 ku 50. Aplikace je ale zábavnější, je tam gamifikace, vše je jednoduché, rychlé a přehledné, ale na přednášce se do toho musíte ponořit, něco si zapsat , cvičení v sešitě. Postupně jsem začal trávit více času na svém smartphonu, až jeho podíl narostl na 100%: když na něm strávíte tři hodiny, vytváříte falešný pocit dokončené práce, kvůli kterému nemáte chuť chodit a cokoliv poslouchat .
Ale jak to může být? Koneckonců jsme speciálně vytvořili mobilní aplikaci, , gamifikoval, zatraktivnil, aby v něm lidé trávili čas, ale ukázalo se, že je to jen rozptyluje? Důvodem je ve skutečnosti to, že tým mobilních aplikací si se svými úkoly poradil až příliš dobře, v důsledku čehož se z něj stal cool, soběstačný produkt a začal vypadávat z našeho ekosystému.
Výsledkem výzkumu se ukázalo, že je potřeba mobilní aplikaci nějak změnit, aby méně rušila hlavní průběh studia. A to jak děti, tak dospělí. Tato práce právě probíhá.
Druhý případ: onboarding bugs
Onboarding je volitelný doplňkový postup při registraci nového studenta, eliminující případné technické problémy v budoucnu. Základní scénář předpokládá, že se člověk zaregistroval na vstupní stránce, získal přístup ke svému osobnímu účtu, je kontaktován a dostane úvodní lekci. Zároveň zaznamenáváme velké procento technických potíží během úvodní lekce: špatná verze prohlížeče, nefunguje mikrofon nebo zvuk, učitel nemůže okamžitě navrhnout řešení a to vše je obzvláště obtížné, když přijde dětem. Vyvinuli jsme proto doplňkovou aplikaci ve vašem osobním účtu, kde můžete provést čtyři jednoduché kroky: zkontrolovat prohlížeč, kameru, mikrofon a potvrdit, že během úvodní lekce budou rodiče nablízku (koneckonců jsou to oni, kdo platí za vzdělání jejich dětí).
Těchto několik vstupních stránek ukazovalo cestu takto:
1: počáteční blok se třemi mírně odlišnými (v závislosti na klientovi) formuláři pro zadání přihlašovacích údajů a hesla.
2: zaškrtávací políčko, které souhlasí s dodatečným postupem registrace.
2.1-2.3: Zkontrolujte přítomnost rodiče, verzi Chromu a zvuk.
3: závěrečný blok.
Vypadá to velmi přirozeně: v prvních dvou krocích většina návštěvníků odchází s tím, že je co vyplňovat, kontrolovat, ale není čas. Pokud klient dosáhl třetího kroku, pak se téměř jistě dostane do finále. Na trychtýři není jediný důvod něco podezřívat.
Přesto jsme se rozhodli náš onboarding analyzovat nikoli na klasickém jednorozměrném trychtýři, ale pomocí Markovova řetězce. Zapnuli jsme trochu více událostí, spustili skript a dostali jsme toto:
V tomto chaosu lze jasně pochopit pouze jednu věc: něco se pokazilo. Proces onboardingu je lineární, to je vlastní designu, neměla by v něm být žádná taková pavučina spojení. A zde je hned jasné, že uživatel je vržen mezi kroky, mezi kterými by neměly být vůbec žádné přechody.
Tento podivný obrázek může mít dva důvody:
- hejna se vkradla do databáze logů;
- Chyby jsou v samotném produktu – onboardingu.
První důvod je s největší pravděpodobností pravdivý, ale jeho testování je poměrně pracné a oprava protokolů nepomůže zlepšit UX. Ale s tím druhým, pokud existuje, se muselo něco urychleně udělat. Šli jsme se proto podívat na uzly, identifikovat hrany, které by neměly existovat, a hledat důvody jejich výskytu. Viděli jsme, že někteří uživatelé uvízli a chodili v kruzích, jiní vypadli ze středu na začátek a další se v zásadě nemohli dostat z prvních dvou kroků. Data jsme přenesli do QA – a ano, ukázalo se, že v onboardingu bylo dost chyb: tohle je takový vedlejší produkt, trochu berlička, nebylo to dostatečně hluboce testováno, protože... Nečekali jsme žádné problémy. Nyní se celý proces nahrávání změnil.
Tento příběh nám ukázal nečekané uplatnění Markovových řetězců v oblasti QA.
Zkus to sám!
Zveřejnil jsem svůj ve veřejné doméně - použijte to pro své zdraví. Dokumentace na GitHubu, dotazy lze klást zde, pokusím se na vše odpovědět.
No, užitečné odkazy: , . A tady o Markovových řetězech. Grafy v článku jsou vytvořeny pomocí .
Zdroj: www.habr.com