Je pro nás důležité chápat, co se našim studentům během vzdělávání děje, a jak tyto události ovlivňují výsledek, proto vytváříme Customer Journey Map — mapu zákaznické zkušenosti. Proces učení totiž není něco kontinuálního a celistvého, ale řetězec vzájemně propojených událostí a akcí studenta, přičemž tyto akce se mohou výrazně lišit u různých žáků. Jakmile dokončí lekci: co udělá dál? Půjde k domácímu úkolu? Spustí mobilní aplikaci? Změní kurz, požádá o změnu učitele? Hned přejde na další lekci? Nebo prostě odejde zklamaný? Může analýza této mapy odhalit vzorce, které vedou k úspěšnému zakončení kurzu či naopak k
Doposud se k vytváření CJM obvykle používají specializované, poměrně drahé nástroje se zavřeným kódem. Ale chtěli jsme vymyslet něco jednoduchého, co vyžaduje minimální úsilí a bylo by, pokud možno, open source. Tak se zrodil nápad využít Markovovy řetězce — a povedlo se nám to. Vytvořili jsme mapu, interpretovali jsme data o chování studentů ve formě grafu, viděli jsme zcela nepatrné odpovědi na globální otázky byznysu a dokonce jsme objevili hluboce skryté chyby. To vše jsme udělali s pomocí open source řešení Python skriptu. V tomto článku se podělím o dva případy s těmi nepatrnými výsledky a sdílím skript se všemi, kdo mají zájem.
Takže Markovovy řetězce ukazují pravděpodobnosti přechodů mezi událostmi. Zde je primitivní příklad z Wikipedie:
Zde „E“ a „A“ jsou události, šipky představují přechody mezi nimi (včetně přechodu z události zpět na sebe), a váhy šipek představují pravděpodobnost přechodu („vážený orientovaný graf“).
Co bylo použito
Řetězec se učil pomocí standardních funkcí Pythonu, kterému byly předkládány protokoly o aktivitě studentů. Graf na získané matici byl vytvořen pomocí knihovny NetworkX.
Protokol vypadá takto:
Je to csv soubor, který obsahuje tabulku se třemi sloupci: id studenta, název události, čas, kdy se tato událost odehrála. Těchto tří polí je dostatek k tomu, abychom sledovali pohyby zákazníka, vytvořili mapu a nakonec obdrželi Markovův řetězec.
Knihovna vrací postavené grafy ve formátu .dot nebo .gexf. Pro vizualizaci prvního můžete využít bezplatný balíček Graphviz (nástroj gvedit), pracovali jsme s .gexf a Gephi, také bezplatnou.
Dále chci uvést dva příklady použití Markovských řetězců, které nám umožnily znovu se podívat na naše cíle, vzdělávací procesy a samotný ekosystém Skyeng. A opravit chyby.
První případ: mobilní aplikace
Nejprve jsme prozkoumali cestu studenta naším nejpopulárnějším produktem — kursem General. V té době jsem pracoval v dětském oddělení Skyeng a chtěli jsme zjistit, jak efektivně funguje mobilní aplikace s naší dětskou šarží.
Vzal jsem logy a prohnal je skriptem, dostal jsem něco takového:
Počáteční uzel — Start General, a dole tři výstupní uzly: student „usnul“, změnil kurz, dokončil kurz.
- Fell asleep, „Zasnul“ — to znamená, že již nepokračuje v hodinách, pravděpodobně se odpojil. Optimisticky to nazýváme stavem „usnul“, protože teoreticky má stále možnost pokračovat v učení. Nejhorší výsledek pro nás.
- Dropped general, Změnil kurz — přešel z General na něco jiného a ztratil se pro náš Markovský řetězec.
- Finished course, Dokončil kurz — ideální stav, člověk absolvoval 80% lekcí (ne všechny lekce jsou povinné).
Dostat se do uzlu successfull class znamená úspěšné absolvování lekce na naší platformě s učitelem. Zaznamenává pokrok v kurzu a blíží se k požadovanému výsledku — „Dokončil kurz“. Je pro nás důležité, aby studenti ji navštěvovali co nejvíce.
Abychom získali přesnější kvantitativní závěry pro mobilní aplikaci (uzel app session), postavili jsme samostatné řetězce pro každou z finálních uzlů a dále jsme vzájemně porovnávali váhy hran:
- z app session zpět do ní samé;
- z app session do successful class;
- z successful class do app session.
Vlevo — studenti, kteří dokončili kurz, vpravo — „usnuvší“
Tyto tři hrany ukazují spojení mezi úspěšností studenta a jeho používáním mobilní aplikace. Očekávali jsme, že u studentů, kteří kurz dokončili, bude spojení s aplikací silnější než u „usnulých“. Ve skutečnosti jsme však získali přesně opačné výsledky:
- ujistili jsme se, že různé skupiny uživatelů interagují s mobilní aplikací různě;
- úspěšní studenti méně intenzivně používají mobilní aplikaci;
- usínající studenti aktivněji používají mobilní aplikaci.
To znamená, že "usínající" studenti začínají trávit stále více času v mobilní aplikaci a nakonec v ní zůstanou navždy.
Zpočátku jsme byli překvapeni, ale po zamyšlení jsme si uvědomili, že je to zcela logický efekt. Kdysi jsem se sám učil francouzsky pomocí dvou nástrojů: mobilní aplikace a lekcí gramatiky na YouTube. Zprvu jsem rozděloval čas mezi nimi v poměru 50 na 50. Ale aplikace je zábavnější, je tam gamifikace, všechno je jednoduché, rychlé a jasné, zatímco u lekcí se musíte soustředit, něco si zapisovat a cvičit v sešitě. Postupně jsem začal trávit více času na smartphonu, dokud jeho podíl nedosáhl 100%: když v něm strávím tři hodiny, vzniká falešný pocit vykonané práce, kvůli kterému se mi nechce jít a něco poslouchat.
Ale jak je to možné? Vždyť jsme speciálně vytvořili mobilní aplikaci, , gamifikovali jsme ji, dělali ji atraktivní, aby v ní lidé trávili čas, a ukazuje se, že je to jen odvádí pozornost? Ve skutečnosti je důvodem to, že tým mobilní aplikace příliš dobře splnil své úkoly, a výsledkem je, že se stala skvělým samostatným produktem, který začal vypadávat z našeho ekosystému.
Na konci výzkumu jsme došli k poznání, že mobilní aplikaci je třeba nějak změnit, aby méně odváděla od základního kurzu učení. A to jak pro děti, tak pro dospělé. V současné době se na tom pracuje.
Druhý případ: chyby onboarding procesu
Onboarding je nepovinný dodatečný proces při registraci nového žáka, který odstraňuje potenciální technické problémy v budoucnu. Základní scénář předpokládá, že se osoba zaregistrovala na landing page, získala přístup do osobního účtu, a je kontaktována k provedení úvodní lekce. Při tom zaznamenáváme vysoké procento technických obtíží během úvodní lekce: nesprávná verze prohlížeče, nefungující mikrofon nebo zvuk, učitel nedokáže okamžitě poskytnout řešení, a to vše je obzvlášť složité, pokud jde o děti. Proto jsme vyvinuli dodatečnou aplikaci v osobním účtu, kde lze provést čtyři jednoduché kroky: zkontrolovat prohlížeč, kameru, mikrofon a potvrdit, že rodiče budou přítomní během úvodní lekce (protože to jsou právě oni, kdo platí za vzdělávání dětí).
Tyto několik stránek onboardingu ukazovalo takový funnel:
1: startovní blok se třemi mírně odlišnými (v závislosti na klientovi) formuláři pro zadání uživatelského jména a hesla.
2: zaškrtnutí souhlasu s dodatečným onboardingovým procesem.
2.1-2.3: kontrola přítomnosti rodiče, verze Chrome a zvuku.
3: finální blok.
Vypadá to velmi přirozeně: na prvních dvou krocích se většina návštěvníků ztrácí, když zjistí, že je třeba něco vyplnit, zkontrolovat, a na to není čas. Pokud klient dosáhne třetího kroku — skoro určitě dojde k finále. V nějaké části funnelu není vidět jediný důvod, proč něco podezřívat.
I když jsme se rozhodli analyzovat náš onboarding nikoli pomocí klasického jednorozměrného funnelu, ale pomocí Markovova řetězce. Přidali jsme trochu více událostí, spustili skript a dostali toto:
V tomto chaosu lze jednoznačně pochopit pouze jedno: něco se pokazilo. Proces onboardingu je lineární, to je zakotveno v designu, nemělo by v něm být žádné takové spletité propojení. A tady je hned vidět, že uživatel je házen mezi kroky, mezi kterými vůbec nemělo být přechodů.
Důvody tak podivného obrazu mohou být dva:
- chyby se dostaly do databáze logů;
- chyby jsou přítomny v samotném produktu — onboardingu.
První důvod pravděpodobně existuje, ale ověření je dost pracné a oprava logů nijak nepomůže zlepšit UX. Co se týče druhého, pokud existuje, mělo se s ním urgentně něco dělat. Proto jsme se vydali zkoumat uzly, identifikovat hrany, které tam být neměly, a hledat příčiny jejich vzniku. Viděli jsme, že někteří uživatelé se točili v kruhu, jiní se propadali zprostředka na začátek, třetí se vůbec nemohli dostat z prvních dvou kroků. Předali jsme data QA - a ano, ukázalo se, že onboarding měl spoustu chyb: je to takový vedlejší, trochu kličkový produkt, netestovalo se to dostatečně hluboce, protože se neočekávaly žádné problémy. Nyní se celý proces registrace změnil.
Tento příběh nám ukázal nečekané využití Markovových řetězců v oblasti QA.
Vyzkoušejte to sami!
Sdílel jsem svůj ve veřejném přístupu - používejte ho ve zdraví. Dokumentace je na GitHubu, otázky můžete položit zde, pokusím se na vše odpovědět.
A tady jsou užitečné odkazy: , . A zde o Markovových řetězcích. Grafy v článku jsou vytvořeny pomocí .
Zdroj: habr.com
