Важно е да разберем какво се случва с нашите студенти по време на обучението и как тези събития влияят на резултата, затова изграждаме Карта на потребителското изживяване. Процесът на обучение не е нещо непрекъснато и цялостно, а верига от свързани събития и действия на студента, които могат да се различават значително между различните ученици. Той е преминал урок: какво ще направи след това? Ще премине ли към домашното? Ще отиде ли в мобилното приложение? Ще смени ли курса, ще поиска ли смяна на учителя? Ще се впусне ли в следващия урок веднага? Или просто ще си тръгне разочарован? Може ли да се анализира тази карта, за да се идентифицират закономерности, водещи до успешно завършване на курса или обратно, до „отпадане“ на студента?
Обикновено за изграждането на CJM се използват специализирани, доста скъпи инструменти с затворен код. Но ние искахме да измислим нещо просто, изискващо минимални усилия и по възможност отворено. Така се роди идеята да използваме Маркови вериги — и успяхме. Създадохме карта, интерпретирахме данните за поведението на студентите под формата на граф, видяхме напълно неочевидни отговори на глобални бизнес въпроси и дори открихме дълбоко скрити бъгове. Всичко това направихме с помощта на отворени решения на Python скрипт. В тази статия ще споделя два случая с тези едва ли неочевидни резултати и ще предоставя скрипта на всички желаещи.
И така, Марковите вериги показват вероятността за преходи между събитията. Ето един примитивен пример от Уикипедия:
Тук „E“ и „A“ са събития, стрелките обозначават преходи между тях (включително прехода от събитието към самото него), а теглата на стрелките са вероятността за преход („теглен граф с насоченост“).
Какво използвахме
Цепната структура се обучаваше с помощта на стандартния функционал на Python, на който предоставяхме логове на активността на студентите. Графът на получената матрица се изграждаше с библиотеката NetworkX.
Логът изглежда така:
Това е csv-файл, съдържащ таблица с три колони: id на студента, наименование на събитието, време, в което е настъпило. Тези три полета са достатъчни, за да проследим движението на клиента, да изградим картата и в крайна сметка да получим Маркова верига.
Библиотеката връща построените графове в .dot или .gexf формат. За визуализация на първите, можете да използвате безплатния пакет Graphviz (инструмент gvedit), ние работихме с .gexf и Gephi, също безплатна.
След това искам да дам два примера за използване на Маркови вериги, които ни позволиха да погледнем отново нашите цели, учебни процеси и самата екосистема Skyeng. Ами и да поправим бъговете.
Първи случай: мобилно приложение
Първо изследвахме пътя на студента по нашия най-популярен продукт — курс General. В този момент работех в детския отдел на Skyeng и искахме да видим колко ефективно работи мобилното приложение с нашата детска аудитория.
Взех логовете и ги пуснах през скрипт, получих нещо такова:
Стартовият възел — Start General, а отдолу три изходни възела: ученикът «засна», смени курса, завърши курса.
- Засна, «Засна» — означава, че вече не посещава занятия, най-вероятно е отпаднал. Оптимистично го наричаме състояние «заснал», тъй като теоретично има възможност да продължи обучението. Най-лошият резултат за нас.
- Смени курса, — преминал е от General на нещо друго и се е изгубил за нашата Маркова верига.
- Завърши курса — идеалното състояние, човекът е преминал 80% от уроците (не всички уроци са задължителни).
Попадането в възела successful class означава успешно преминаване на урока на нашата платформа с учителя. Той фиксира напредъка по курса и приближаването до желания резултат — «Завърши курса». Важно е за нас студентите да посещават него възможно най-много.
За да получим по-точни количествени изводи за мобилното приложение (възел app session), построихме отделни вериги за всеки от финалните възли и след това сравнявахме парно теглата на ребрата:
- от app session обратно в нея съща;
- от app session в successful class;
- от successful class в app session.
Отляво — студенти, завършили курса, отдясно — «заснали»
Тези три ребра показват връзката между успеха на студента и използването на мобилното приложение. Очаквахме да видим, че завършилите курса студенти ще имат по-силна връзка с приложението, отколкото «засналите». Въпреки това, получихме точно противоположни резултати:
- убедихме се, че различни групи потребители взаимодействат различно с мобилното приложение;
- успешните студенти по-рядко използват мобилното приложение;
- заспиващите студенти по-активно използват мобилното приложение.
Това означава, че "заспиващите" студенти започват все повече време да прекарват в мобилното приложение и в крайна сметка остават в него завинаги.
Първоначално се учудихме, но след като помислихме, осъзнахме, че това е напълно закономерен ефект. В своето време самостоятелно учех френски, използвайки два инструмента: мобилното приложение и лекции по граматика в YouTube. В началото делях времето си между тях в пропорция 50 на 50. Но приложението е по-забавно, има геймификация, всичко е просто, бързо и ясно, а в лекциите трябва да се вниква, да се записва нещо и да се практикува в тетрадка. Постепенно започнах да прекарвам повече време на смартфона, докато дялът му не достигна 100%: ако прекарам три часа в него, се създава фалшивото усещане за изпълнена работа, поради което няма желание да отида и да слушам нещо.
Но как така? Ние специално създадохме мобилното приложение, , геймифицирахме, направихме го привлекателно, за да прекарват хората време в него, а се оказва, че то само ги разсейва? Всъщност причината е, че екипът на мобилното приложение се справи твърде добре със задачите си, в резултат на което то стана страхотен самостоятелен продукт и започна да излиза извън нашата екосистема.
В крайна сметка от изследването дойде осъзнаването, че мобилното приложение трябва да се промени по някакъв начин, за да не отклонява толкова много от основното учене. И за децата, и за възрастните. В момента тази работа тече.
Втори случай: бъгове в онбординга
Онбордингът е незадължителна допълнителна процедура при регистрацията на нов ученик, която премахва потенциални технически проблеми в бъдеще. Основният сценарий предполага, че човекът се е регистрирал на лендинга, получил е достъп до личния си профил, свързват се с него и провеждат въвеждащ урок. Въпреки това забелязваме голям процент технически трудности по време на въвеждащия урок: неправилна версия на браузъра, неработещ микрофон или звук, учителят не може веднага да предложи решение, а всичко това е особено сложно, когато става въпрос за деца. Затова разработихме допълнително приложение в личния профил, където може да се извършат четири прости стъпки: проверка на браузъра, камерата, микрофона и потвърждение, че родителите ще бъдат близо по време на въвеждащия урок (в края на краищата именно те плащат за обучението на децата).
Тези няколко страници на онбординга демонстрираха такава воронка:
1: стартов блок с три малко различаващи се (в зависимост от клиента) форми за въвеждане на потребителско име и парола.
2: отметка за съгласие за допълнителната процедура по онбординг.
2.1-2.3: проверка за наличието на родител, версия на Chrome и звук.
3: финален блок.
Изглежда много естествено: през първите две стъпки по-голямата част от посетителите отпадат, осъзнавайки, че трябва да попълват нещо, да проверяват, а времето не стига. Ако клиентът стигне до третата стъпка — по-нататък вече почти сигурно ще достигне до финала. Във воронката не е видима никаква причина да подозираш нещо.
Все пак решихме да анализираме нашия онбординг не на класическата едномерна воронка, а с помощта на Маркови вериги. Включихме малко повече събития, пуснахме скрипт и получихме следното:
Ясно е, че в този хаос можем да разберем само едно: нещо не е наред. Процесът на онбординг е линейнен, това е заложено в дизайна, не трябва да има такава мрежа от връзки. А тук веднага е видно, че потребителят се лута между стъпките, между които изобщо не трябва да има преходи.
Причините за такава странна картина могат да бъдат две:
- грешки в логовата база;
- грешки в самия продукт — онбординг.
Първата причина най-вероятно съществува, но проверката й е доста трудоемка и подобряването на логовете няма да помогне за UX. Що се отнася до втората причина, ако тя съществува, трябваше спешно да се вземат мерки. Затова се заехме с преглед на възлите, идентифициране на ръбовете, които не трябва да съществуват, и търсене на причините за тяхното възникване. Видяхме, че някои потребители се зацикляха и обикаляха в кръг, други - излизаха от средата в началото, а трети изобщо не можеха да се измъкнат от първите два стъпки. Предадохме данните на QA - и да, установихме, че в онбординга имаше много бъгове: това е малко страничен, донякъде хакнат продукт, който не бе тестван достатъчно задълбочено, тъй като не се очакваха проблеми. Сега целият процес на запис се промени.
Тази история ни показа неочаквано приложение на Марковите вериги в областта на QA.
Опитайте сами!
Аз публикувах своя в свободен достъп - ползвайте на здраве. Документацията е на GitHub, въпроси може да задавате тук, ще се постарая да отговоря на всички.
А ето и полезни линкове: , . А тук за Маркови вериги. Графите в статията са направени с помощта на .
Източник: habr.com
