Ważne jest, aby zrozumieć, co dzieje się z naszymi studentami podczas nauki i jak te wydarzenia wpływają na wyniki, dlatego tworzymy Customer Journey Map — mapę doświadczeń klientów. Proces nauki nie jest czymś ciągłym i jednolitym, jest to ciąg powiązanych wydarzeń i działań studenta, a te działania mogą się znacznie różnić w zależności od ucznia. Oto przeszedł lekcję: co zrobi dalej? Przejdzie do zadania domowego? Uruchomi aplikację mobilną? Zmieni kierunek, poprosi o zmianę nauczyciela? Od razu wejdzie na następną lekcję? A może po prostu odejdzie rozczarowany? Czy analizując tę mapę, można zidentyfikować wzorce prowadzące do pomyślnego ukończenia kursu lub, przeciwnie, „odpadnięcia” studenta?
Zazwyczaj do budowania CJM używa się wyspecjalizowanych, bardzo drobnych narzędzi z zamkniętym kodem. Ale chcieliśmy wymyślić coś prostego, wymagającego minimalnych wysiłków i w miarę możliwości open source. Tak powstał pomysł wykorzystania łańcuchów Markowa — i udało nam się to. Zbudowaliśmy mapę, zinterpretowaliśmy dane o zachowaniu studentów w formie grafu, dostrzegliśmy zupełnie nieoczywiste odpowiedzi na globalne pytania biznesowe i nawet znaleźliśmy głęboko ukryte błędy. Wszystko to zrobiliśmy przy pomocy rozwiązań open source w skrypcie Pythona. W tym artykule opowiem o dwóch przypadkach z tymi samymi nieoczywistymi wynikami i podzielę się skryptem z wszystkimi zainteresowanymi.
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 z wydarzenia do tego samego wydarzenia), a wagi strzałek to prawdopodobieństwo przejścia («ważony graf skierowany»).
Co użyto
Łańcuch uczył się standardową funkcjonalnością Pythona, której dostarczano logi aktywności studentów. Graf na otrzymanej macierzy zbudowano przy pomocy biblioteki NetworkX.
Log wygląda tak:
Jest to plik csv zawierający tabelę z trzema kolumnami: id studenta, nazwa zdarzenia, czas, kiedy ono wystąpiło. Te trzy pola są wystarczające, aby śledzić ruchy klienta, zbudować mapę i ostatecznie uzyskać łańcuch Markowa.
Biblioteka zwraca zbudowane grafy w formacie .dot lub .gexf. Do wizualizacji pierwszych można wykorzystać darmowy pakiet Graphviz (narzędzie gvedit), pracowaliśmy z .gexf i Gephi, również darmowym.
Następnie chciałbym przedstawić dwa przykłady zastosowania łańcuchów Markowa, które pozwoliły nam spojrzeć na nasze cele, procesy edukacyjne i samą ekosystem Skyeng w nowy sposób. No i poprawić błędy.
Pierwszy przypadek: aplikacja mobilna
Na początek zbadaliśmy ścieżkę studenta w naszym najpopularniejszym produkcie — kursie General. W tamtym czasie pracowałem w dziecięcym dziale Skyeng i chcieliśmy zobaczyć, jak efektywnie działa aplikacja mobilna wśród naszej dziecięcej publiczności.
Pobrałem logi i przeszedłem je przez skrypt, otrzymałem coś takiego:
Węzeł startowy — Start General, a na dole trzy węzły wyjściowe: uczeń "zasnął", zmienił kurs, zakończył kurs.
- Fell asleep, "Zasnął" — oznacza to, że przestał uczestniczyć w zajęciach, prawdopodobnie się wycofał. Optymistycznie nazywamy ten stan "zasnął", ponieważ teoretycznie ma jeszcze szansę kontynuować naukę. Najgorszy wynik dla nas.
- Dropped general, Zmienił kurs — przeszedł z General na coś innego i zaginął w naszym łańcuchu Markowa.
- Finished course, Zakończył kurs — idealny stan, osoba ukończyła 80% lekcji (nie wszystkie lekcje są obowiązkowe).
Dostanie się do węzła successful class oznacza pomyślne zakończenie lekcji na naszej platformie z nauczycielem. Rejestruje postęp w kursie i zbliżenie do pożądanego wyniku — "Zakończył kurs". Ważne jest dla nas, aby studenci odwiedzali go jak najczęściej.
Aby uzyskać dokładniejsze ilościowe wnioski dotyczące aplikacji mobilnej (węzeł app session), 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 app session z powrotem do niej samej;
- z app session do successful class;
- z successful class do app session.
Po lewej — studenci, którzy zakończyli kurs, po prawej — „zasnąwszy”
Te trzy krawędzie pokazują związek między sukcesem studenta a korzystaniem z aplikacji mobilnej. Spodziewaliśmy się zobaczyć, że u studentów, którzy ukończyli kurs, związek z aplikacją będzie silniejszy niż u „zasnąwszy”. Jednak w rzeczywistości uzyskaliśmy dokładnie odwrotne wyniki:
- przekonaliśmy się, że różne grupy użytkowników różnie oddziałują z aplikacją mobilną;
- bardziej udani studenci rzadziej korzystają z aplikacji mobilnej;
- uczniowie przychodzący do siebie używają aplikacji mobilnej bardziej aktywnie.
To oznacza, że „uczniowie przychodzący do siebie” zaczynają coraz więcej czasu spędzać w aplikacji mobilnej i ostatecznie pozostają w niej na zawsze.
Na początku byliśmy zaskoczeni, ale po namyśle zrozumieliśmy, że to jest w pełni uzasadniony efekt. Kiedyś samodzielnie uczyłem się francuskiego, korzystając z dwóch narzędzi: aplikacji mobilnej oraz wykładów z gramatyki na YouTube. Początkowo dzieliłem czas między nimi w proporcji 50 do 50. Ale aplikacja była bardziej interesująca, miała gamifikację, wszystko było proste, szybkie i jasne, a wykłady wymagały zaangażowania, zapisywania i ćwiczenia w zeszycie. Z biegiem czasu zacząłem spędzać więcej czasu na smartfonie, aż jego udział wzrósł do 100%: jeśli spędzę na nim trzy godziny, tworzę fałszywe poczucie wykonanej pracy, przez co nie mam żadnej chęci, aby pójść i czegoś posłuchać.
Ale jak to możliwe? Przecież specjalnie stworzyliśmy aplikację mobilną, , zrobiliśmy ją atrakcyjną, aby ludzie spędzali w niej czas, a to okazuje się, że jedynie ich rozprasza? W rzeczywistości przyczyna tkwi w tym, że zespół aplikacji mobilnej zbyt dobrze poradził sobie ze swoimi zadaniami, w efekcie czego stała się ona świetnym, samodzielnym produktem i zaczęła wypadać z naszego ekosystemu.
W wyniku badań doszliśmy do wniosku, że aplikację mobilną trzeba jakoś zmienić, aby mniej odciągała od głównego kursu nauczania. Dotyczy to zarówno dzieci, jak i dorosłych. Aktualnie prace w tym kierunku są prowadzone.
Drugi przypadek: błędy w onboarding.
Onboarding to opcjonalna dodatkowa procedura przy rejestracji nowego ucznia, która eliminuje potencjalne problemy techniczne w przyszłości. Podstawowy scenariusz zakłada, że osoba zarejestrowała się na stronie, uzyskała dostęp do swojego konta, kontaktuje się z nią i przeprowadza wprowadzenie. Przy tym zauważamy wysoki procent trudności technicznych podczas wprowadzenia: niewłaściwa wersja przeglądarki, nie działa mikrofon lub dźwięk, nauczyciel nie może od razu podać rozwiązania, a wszystko to jest szczególnie trudne, jeśli chodzi o dzieci. Dlatego opracowaliśmy dodatkową aplikację w osobistym koncie, gdzie można wykonać cztery proste kroki: sprawdzić przeglądarkę, kamerę, mikrofon i potwierdzić, że rodzice będą obok podczas lekcji wprowadzającej (w końcu to oni płacą za edukację dzieci).
Te kilka stron onboardingu pokazuje taką lejek:
1: blok startowy z trzema nieco różnymi (w zależności od klienta) formularzami logowania.
2: zaznaczenie zgody na dodatkową procedurę onboardingu.
2.1-2.3: sprawdzenie obecności rodzica, wersji Chrome i dźwięku.
3: blok końcowy.
Wygląda to bardzo naturalnie: na pierwszych dwóch krokach większa część odwiedzających odpada, zdając sobie sprawę, że muszą coś wypełniać, sprawdzać, a nie mają na to czasu. Jeśli klient dotrze do trzeciego kroku — dalej prawie na pewno dotrze do końca. W lejek nie widać żadnej przyczyny, aby coś podejrzewać.
Mimo to postanowiliśmy przeanalizować nasz onboarding nie na klasycznym jednoznacznym lejku, ale za pomocą łańcucha Markowa. Włączyliśmy trochę więcej wydarzeń, uruchomiliśmy skrypt i uzyskaliśmy coś takiego:
Jedno jest pewne w tym chaosie: coś poszło nie tak. Proces onboardingu jest liniowy, to jest zaprojektowane, nie powinno być takiej sieci połączeń. A tutaj od razu widać, że użytkownik jest miotany pomiędzy krokami, pomiędzy którymi w ogóle nie powinno być przejść.
Przyczyny tak dziwnego obrazu mogą być dwie:
- błędy mogły wkręcić się w bazę logów;
- błędy istnieją w samym produkcie — onboardingu.
Pierwszy powód najprawdopodobniej ma miejsce, ale sprawdzenie go jest dość pracochłonne, a poprawa logów w żaden sposób nie wpłynie na poprawę UX. Natomiast w przypadku drugiego, jeśli rzeczywiście istnieje, należało natychmiast coś zrobić. Dlatego przystąpiliśmy do analizy węzłów, identyfikacji krawędzi, których być nie powinno, oraz poszukiwania przyczyn ich pojawiania się. Zauważyliśmy, że niektórzy użytkownicy zapętleni błądzili w kółko, inni wypadali z środka na początek, a jeszcze inni w ogóle nie mogli wydostać się z pierwszych dwóch kroków. Przekazaliśmy dane do QA — i tak, okazało się, że w onboardingu było sporo błędów: to taki uboczny, nieco prowizoryczny produkt, który nie był wystarczająco testowany, ponieważ nie spodziewano się żadnych problemów. Teraz cały proces rejestracji został zmieniony.
Ta historia pokazała nam niespodziewane zastosowanie łańcuchów Markowa w dziedzinie QA.
Spróbuj sam!
Opublikowałem mój w otwartym dostępie — korzystaj na zdrowie. Dokumentacja na GitHubie, pytania można zadawać tutaj, postaram się na wszystkie odpowiedzieć.
No i przydatne linki: , . A tutaj o łańcuchach Markowa. Grafiki w artykule zostały stworzone za pomocą .
Źródło: habr.com
