Как използваме Маркови вериги при оценка на решения и търсене на грешки. С Python скрипт

Важно е да разберем какво се случва с нашите студенти по време на обучението и как тези събития влияят на резултата, затова изграждаме Customer Journey Map — карта на клиентското изживяване. Процесът на обучение не е нещо непрекъснато и цялостно, а това е верига от взаимосвързани събития и действия на студента, като тези действия могат да се различават значително между различните ученици. Ето, той е преминал урок: какво ще направи после? Ще се захване с домашното? Ще отвори мобилното приложение? Ще смени курса, ще поиска смяна на учителя? Ще влезе в следващия урок? Или просто ще си тръгне разочарован? Може ли, анализирайки тази карта, да открием закономерности, водещи до успешно завършване на курса или обратното — „изоставяне“ на студента?

Обикновено за изграждането на CJM се използват специализирани, доста скъпи инструменти с затворен код. Но ние искахме да измислим нещо просто, изискващо минимални усилия и по възможност с отворен код. Така се роди идеята да използваме маркови вериги — и ние успяхме. Построихме карта, интерпретирахме данните за поведението на студентите под формата на граф, видяхме напълно неочевидни отговори на глобални бизнес въпроси и дори открихме дълбоко скрити бъгове. Всичко това направихме с помощта на решения с отворен код върху Python скрипт. В тази статия ще разкажа за два случая с тези недотам очевидни резултати и ще споделя скрипта с желаещите.

И така, марковите вериги показват вероятността за преходи между събитията. Ето един примитивен пример от Уикипедия:

Тук „E“ и „A“ са събития, стрелките — преходи между тях (включително преход от събитие към самото него), а теглата на стрелките — вероятност на прехода („взвесен насочен граф“).

Какво използвахме

Верига се обучаваше с помощта на стандартни функции на Python, на които се предоставяха логовете на активността на студентите. Графът на получената матрица беше построен с библиотеката NetworkX.

Логът изглежда така:

Това е CSV файл, съдържащ таблица от три колони: ID на студента, название на събитието, времето, когато е настъпило. Тези три полета са достатъчни, за да проследим движението на клиента, да изградим карта и в крайна сметка да получим маркова верига.

Библиотеката връща построените графове в .dot или .gexf формат. За визуализиране на първите можете да използвате безплатния пакет Graphviz (инструмент gvedit), ние работихме с .gexf и Gephi, също безплатна.

Следващото, което искам да представя, са два примера за използването на Маркови вериги, които ни позволиха да погледнем на нашите цели, учебни процеси и самата екосистема Skyeng от нова перспектива. И да поправим бъговете.

Първи случай: мобилно приложение

В началото изследвахме пътя на студента в нашия най-популярен продукт — курса General. В онзи момент работех в детския департамент на Skyeng и искахме да видим колко ефективно работи мобилното приложение с нашата детска аудитория.

Като взех логовете и ги пуснах през скрипт, получих нещо такова:

Стартовият възел — Start General, а отдолу три крайни ноди: ученик „заспал“, сменил курса, завършил курса.

• Заспа, „Заспа“ — означава, че не посещава занятия и вероятно е отпаднал. Ние оптимистично наричаме това състояние „заспал“, тъй като в теория той запазва възможността да продължи обучението си. Най-лошият резултат за нас.
• Смени курса, премина от General на нещо друго и се загуби за нашата Маркова верига.
• Завършил курса — идеалното състояние, човекът е преминал 80% от уроците (не всички уроци са задължителни).

Попадението в възловата точка successfull class ознаменува успешното преминаване на урока на нашата платформа с учителя. То регистрира напредъка по курса и приближаването до желаното състояние — „Завършил курса“. Важно е за нас студентите да я посещават колкото се може повече.

За да получим по-точни количествени изводи за мобилното приложение (възел app session), изградихме отделни вериги за всеки от финалните възли и след това сравнявахме по двойки тежестите на ръбовете:

• от app session обратно в нея самата;
• от app session в successfull class;
• от successfull class в app session.

Отляво — студенти, завършили курса, отдясно — „заспалите“

Тези три ръба показват връзката между успеха на студента и използването на мобилното приложение. Очаквахме да видим, че между завършилите курса студенти връзката с приложението ще бъде по-силна, отколкото при „заспалите“. Въпреки това на практика получихме точно противоположни резултати:

• убедихме се, че различните групи потребители взаимодействат различно с мобилното приложение;
• успешните студенти по-малко интензивно използват мобилното приложение;
• заспиващите студенти по-активно използват мобилното приложение.

Това означава, че "заспиващите" студенти започват да прекарват все повече време в мобилното приложение и в крайна сметка остават в него завинаги.

Първоначално се учудихме, но след като помислихме, разбрахме, че това е съвсем закономерен ефект. Преди време изучавах френски самостоятелно, използвайки два инструмента: мобилното приложение и лекции по граматика в YouTube. В началото делях времето си между тях в пропорция 50 на 50. Но приложението е по-забавно, там има геймификация, всичко е просто, бързо и ясно, а в лекциите трябва да се задълбочавам, да записвам нещо, да практикувам в тетрадката. Постепенно започнах да прекарвам все повече време на смартфона, докато делът му не достигна 100%: ако прекарвам три часа в него, се създава илюзия за свършена работа, поради която нямам желание да отида и да слушам нещо.

Но как така? Нали ние специално създадохме мобилното приложение, вградихме в него кривата на Еббингауз,, геймифицирахме, направихме го привлекателно, за да прекарват хората време в него, а се оказва, че то само ги разсейва? Всъщност причината е, че екипът на мобилното приложение е свършил прекалено добре работата си, в резултат на което то стана страхотен самодостатъчен продукт и започна да излиза от нашата екосистема.

В края на изследването стигнахме до разбирането, че мобилното приложение трябва да бъде променено, за да отнема по-малко от основния курс на обучение. А и за децата, и за възрастните. Сега тази работа продължава.

Вторият случай: проблеми с онбординга.

Онбордингът е незадължителна допълнителна процедура при регистрацията на нов ученик, която избавя от потенциални технически проблеми в бъдеще. Основният сценарий предполага, че човекът се е регистрирал на лендинга, получил е достъп до личния си профил, свързват се с него и провеждат въвеждащ урок. В същото време забелязваме голям процент технически трудности по време на въвеждащия урок: не е правилната версия на браузъра, микрофонът или звукът не работят, учителят не може веднага да предложи решение, и всичко това е особено сложно, когато става въпрос за деца. Затова разработихме допълнително приложение в личния кабинет, където може да се извършат четири прости стъпки: да се провери браузърът, камерата, микрофонът и да се потвърди, че родителите ще бъдат в близост по време на въвеждащия урок (в края на краищата, именно те плащат за обучението на децата).

Тези няколко страници за онбординг демонстрираха следната фуния:

1: стартов блок с три малко различаващи се (в зависимост от клиента) форми за въвеждане на потребителско име и парола.
2: отметка за съгласие с допълнителната процедура на онбординг.
2.1-2.3: проверка на присъствието на родителя, версията на Chrome и звука.
3: финален блок.

Изглежда много естествено: на първите две стъпки, голямата част от посетителите отпадат, осъзнавайки, че трябва да попълват нещо, да проверяват, а времето е недостатъчно. Ако клиентът е стигнал до третата стъпка — почти сигурно е, че ще стигне до финала. Няма видима причина в фунията да се усъмним в нещо.

Въпреки това решихме да анализираме нашия онбординг не на класическата одномерна фуния, а с помощта на маркови вериги. Включихме малко повече събития, пуснахме скрипт и получихме нещо такова:

В този хаос може да се разбере само едно: нещо не е наред. Процесът на онбординг е линеен, това е заложено в дизайна, не би трябвало да има такава сложна мрежа от връзки. А тук веднага се вижда, че потребителят бива хвърлян между стъпки, между които изобщо не би трябвало да има преходи.

Причините за такава странна картина може да са две:

• грешки в базата от логове;
• грешки в самия продукт — онбординга.

Първата причина вероятно е налице, но проверката ѝ изисква много усилия и коригирането на логовете не би помогнало за подобряване на потребителския опит. Но по отношение на втората причина, ако тя съществува, се наложи бързо да предприемем действия. Затова започнахме да разглеждаме узлите, да идентифицираме ръбовете, които не би трябвало да съществуват, и да търсим причините за тях. Установихме, че част от потребителите зациклят и обикалят в кръг, други — изскачат от средата в началото, а трети по принцип не могат да напуснат първите две стъпки. Изпратихме данните на QA — и да, установи се, че в онбординга имаше много бъгове: това е страничен, малко недомислен продукт, който не беше тестван достатъчно дълбоко, тъй като не очаквахме проблеми. Сега вече целият процес на запис е променен.

Тази история ни показа неочаквано приложение на марковските вериги в областта на QA.

Опитайте сами!

Аз публикувах своя Python скрипт за обучение на марковски вериги в открит достъп — ползвайте на здраве. Документацията е на GitHub, въпросите можете да зададете тук, ще се постарая да отговоря на всичките.

И полезни линкове: библиотека NetworkX, визуализатор Graphviz. А тук на Хабра има статия за марковските вериги. Графите в статията са направени с помощта на Gephi.

Източник: habr.com