Ważne jest dla nas zrozumienie, co dzieje się z naszymi uczniami podczas szkoleń i jak te zdarzenia wpływają na wynik, dlatego budujemy Customer Journey Map – mapę doświadczeń klienta. W końcu proces uczenia się nie jest czymś ciągłym i integralnym, jest to łańcuch powiązanych ze sobą wydarzeń i działań ucznia, a działania te mogą się znacznie różnić u różnych uczniów. Teraz zakończył swoją lekcję: co będzie dalej robić? Czy pójdzie do pracy domowej? Czy uruchomi aplikację mobilną? Czy zmieni kurs, poprosi o zmianę nauczyciela? Czy przejdziesz od razu na następną lekcję? A może po prostu wyjdzie zawiedziony? Czy można, analizując tę mapę, zidentyfikować wzorce, które prowadzą do pomyślnego ukończenia kursu lub odwrotnie, do „porzucenia” kursu przez studenta?
Zwykle do budowy CJM używa się wyspecjalizowanych, bardzo drogich narzędzi o zamkniętym kodzie źródłowym. Chcieliśmy jednak wymyślić coś prostego, wymagającego minimalnego wysiłku i możliwie otwartego oprogramowania. Pojawił się więc pomysł wykorzystania łańcuchów Markowa – i udało się. Zbudowaliśmy mapę, zinterpretowaliśmy dane o zachowaniach uczniów w formie wykresu, zobaczyliśmy zupełnie nieoczywiste odpowiedzi na globalne problemy biznesowe, a nawet znaleźliśmy głęboko ukryte błędy. Wszystko to zrobiliśmy przy użyciu rozwiązań skryptowych Pythona o otwartym kodzie źródłowym. W tym artykule opowiem o dwóch przypadkach z bardzo nieoczywistymi wynikami i udostępnię wszystkim scenariusz.
Zatem łańcuchy Markowa pokazują prawdopodobieństwo przejść między zdarzeniami. Oto prymitywny przykład z Wikipedii:
Tutaj „E” i „A” to zdarzenia, strzałki to przejścia między nimi (w tym przejście od zdarzenia do tego samego), a wagi strzałek to prawdopodobieństwo przejścia („ważony wykres skierowany”).
Czego użyłeś?
Obwód został przeszkolony przy użyciu standardowej funkcjonalności Pythona, która została zasilana dziennikami aktywności uczniów. Wykres na otrzymanej macierzy został skonstruowany przez bibliotekę NetworkX.
Dziennik wygląda następująco:
Jest to plik csv zawierający tabelę składającą się z trzech kolumn: identyfikator studenta, nazwa zdarzenia, czas jego wystąpienia. Te trzy pola wystarczą, aby prześledzić ruchy klienta, zbudować mapę i ostatecznie uzyskać łańcuch Markowa.
Biblioteka zwraca skonstruowane wykresy w formacie .dot lub .gexf. Aby zwizualizować to pierwsze, możesz skorzystać z bezpłatnego pakietu Graphviz (narzędzie gvedit), pracowaliśmy z .gexf i Gephi, również bezpłatne.
Następnie chciałbym podać dwa przykłady wykorzystania łańcuchów Markowa, które pozwoliły nam na świeże spojrzenie na nasze cele, procesy edukacyjne i sam ekosystem Skyeng. Cóż, napraw błędy.
Przypadek pierwszy: aplikacja mobilna
Na początek zbadaliśmy podróż uczniów poprzez nasz najpopularniejszy produkt — kurs ogólny. W tym momencie pracowałam w dziale dziecięcym Skyeng i chcieliśmy zobaczyć, jak skutecznie aplikacja mobilna współpracuje z naszymi dziecięcymi odbiorcami.
Pobierając logi i uruchamiając je w skrypcie, otrzymałem coś takiego:
Węzeł początkowy to Start General, a na dole znajdują się trzy węzły wyjściowe: uczeń „zasnął”, zmienił kurs i ukończył kurs.
- Zasnął, „Zasnął” - to znaczy, że nie chodzi już na zajęcia, najprawdopodobniej spadł. Stan ten optymistycznie nazywamy „uśpieniem”, bo… teoretycznie ma jeszcze możliwość kontynuowania nauki. Najgorszy wynik dla nas.
- Porzuciłem generała, zmieniłem kurs - przeszedłem z generała na coś innego i zgubiłem się w naszym łańcuchu Markowa.
- Ukończony kurs, Ukończony kurs - stan idealny, osoba ukończyła 80% lekcji (nie wszystkie lekcje są wymagane).
Dostanie się do pomyślnego węzła zajęć oznacza pomyślne ukończenie lekcji na naszej platformie wraz z nauczycielem. Rejestruje postępy na kursie i podejście do pożądanego rezultatu – „Ukończono kurs”. Zależy nam na tym, aby uczniowie uczestniczyli w jak największej liczbie zajęć.
Aby uzyskać dokładniejsze wnioski ilościowe dla aplikacji mobilnej (węzeł sesji aplikacji), zbudowaliśmy osobne łańcuchy dla każdego z końcowych węzłów, a następnie porównaliśmy parami wagi krawędzi:
- z sesji aplikacji z powrotem do niej;
- od sesji aplikacji do udanych zajęć;
- od udanych zajęć do sesji aplikacji.
Po lewej stronie studenci, którzy ukończyli kurs, po prawej ci, którzy „zasnęli”
Te trzy krawędzie pokazują związek pomiędzy sukcesem ucznia a korzystaniem przez niego z aplikacji mobilnej. Spodziewaliśmy się, że studenci, którzy ukończyli kurs, będą mieli silniejsze połączenie z aplikacją niż ci, którzy zasnęli. Jednak w rzeczywistości otrzymaliśmy dokładnie odwrotne wyniki:
- zadbaliśmy o to, aby różne grupy użytkowników w różny sposób współdziałały z aplikacją mobilną;
- studenci odnoszący sukcesy rzadziej korzystają z aplikacji mobilnej;
- zasypiający uczniowie aktywniej korzystają z aplikacji mobilnej.
Oznacza to, że zasypiający uczniowie zaczynają spędzać w aplikacji mobilnej coraz więcej czasu, by ostatecznie pozostać w niej na zawsze.
Na początku byliśmy zaskoczeni, ale po namyśle doszliśmy do wniosku, że to całkowicie naturalny efekt. Swego czasu uczyłam się francuskiego samodzielnie, korzystając z dwóch narzędzi: aplikacji mobilnej i wykładów z gramatyki na YouTube. Na początku dzieliłem czas między nimi w proporcji 50 do 50. Ale aplikacja jest zabawniejsza, jest grywalizacja, wszystko jest proste, szybkie i przejrzyste, ale na wykładzie trzeba się w to zagłębić, napisać coś , poćwicz w zeszycie. Stopniowo zacząłem spędzać więcej czasu na smartfonie, aż jego udział wzrósł do 100%: spędzając na nim trzy godziny, tworzysz fałszywe poczucie zakończonej pracy, przez co nie masz ochoty iść i słuchać czegokolwiek .
Ale jak to możliwe? Przecież specjalnie stworzyliśmy aplikację mobilną, , zgamifikował, uatrakcyjnił, żeby ludzie spędzali w nim czas, ale okazuje się, że to tylko ich rozprasza? Tak naprawdę powodem jest to, że zespół aplikacji mobilnej zbyt dobrze poradził sobie ze swoimi zadaniami, w efekcie czego stała się fajnym, samowystarczalnym produktem i zaczęła wypadać z naszego ekosystemu.
W wyniku przeprowadzonych badań okazało się, że aplikację mobilną należy w jakiś sposób zmienić, aby w mniejszym stopniu odrywała od głównego kierunku studiów. I zarówno dzieci, jak i dorośli. Prace te są obecnie w toku.
Przypadek drugi: błędy onboardingowe
Onboarding to opcjonalna, dodatkowa procedura przy rejestracji nowego studenta, eliminująca potencjalne problemy techniczne w przyszłości. Podstawowy scenariusz zakłada, że osoba zarejestrowała się na stronie docelowej, uzyskała dostęp do swojego konta osobistego, skontaktowała się i udzieliła lekcji wprowadzającej. Jednocześnie odnotowujemy duży odsetek trudności technicznych podczas lekcji wprowadzającej: zła wersja przeglądarki, nie działa mikrofon lub dźwięk, nauczyciel nie może od razu zaproponować rozwiązania, a wszystko to jest szczególnie trudne, jeśli chodzi do dzieci. Dlatego też na Twoim koncie osobistym stworzyliśmy dodatkową aplikację, w której możesz wykonać cztery proste kroki: sprawdzić przeglądarkę, kamerę, mikrofon i potwierdzić, że rodzice będą w pobliżu podczas lekcji wprowadzającej (w końcu to oni płacą za edukacja ich dzieci).
Na tych kilku stronach wprowadzających pokazano lejek taki jak ten:
1: blok startowy z trzema nieco odmiennymi (w zależności od klienta) formularzami wprowadzania loginu i hasła.
2: checkbox wyrażający zgodę na dodatkową procedurę onboardingową.
2.1-2.3: Sprawdź obecność rodzica, wersję Chrome i dźwięk.
3: ostatni blok.
Wygląda to bardzo naturalnie: w pierwszych dwóch krokach większość odwiedzających wychodzi, wiedząc, że jest coś do wypełnienia, sprawdzenia, ale nie ma czasu. Jeśli klient dotarł do trzeciego kroku, prawie na pewno dotrze do finału. Nie ma powodu, aby podejrzewać cokolwiek na lejku.
Niemniej jednak postanowiliśmy analizować nasz onboarding nie na klasycznej jednowymiarowej ścieżce, a przy użyciu łańcucha Markowa. Włączyliśmy trochę więcej zdarzeń, uruchomiliśmy skrypt i otrzymaliśmy to:
W tym chaosie można zrozumieć tylko jedno: coś poszło nie tak. Proces onboardingu jest liniowy, jest to nieodłącznie związane z projektem, nie powinno w nim być takiej sieci połączeń. I tutaj od razu widać, że użytkownik jest rzucany pomiędzy krokami, pomiędzy którymi nie powinno być żadnych przejść.
Mogą być dwie przyczyny tego dziwnego obrazu:
- do bazy danych logów wkradły się ławice;
- W samym produkcie są błędy - onboarding.
Pierwszy powód jest najprawdopodobniej prawdziwy, jednak testowanie go jest dość pracochłonne, a poprawianie logów nie pomoże ulepszyć UX. Ale z tym drugim, jeśli istnieje, trzeba było pilnie coś zrobić. Dlatego poszliśmy przyjrzeć się węzłom, zidentyfikować krawędzie, które nie powinny istnieć i poszukać przyczyn ich występowania. Widzieliśmy, że niektórzy użytkownicy utknęli i chodzili w kółko, inni wypadli ze środka na początek, a jeszcze inni w zasadzie nie mogli wyjść z pierwszych dwóch stopni. Przekazaliśmy dane do QA - i tak, okazało się, że błędów w onboardingu było wystarczająco dużo: to taki produkt uboczny, taka podpórka, nie zostało wystarczająco głęboko przetestowane, bo... Nie spodziewaliśmy się żadnych problemów. Teraz zmienił się cały proces nagrywania.
Ta historia pokazała nam nieoczekiwane zastosowanie łańcuchów Markowa w dziedzinie kontroli jakości.
Spróbuj sam!
Opublikowałem swoje w domenie publicznej - wykorzystaj to dla swojego zdrowia. Dokumentacja na GitHubie, pytania można zadawać tutaj, postaram się odpowiedzieć na wszystko.
No i przydatne linki: , . I tu o łańcuchach Markowa. Wykresy w artykule zostały wykonane przy użyciu .
Źródło: www.habr.com