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

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

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

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

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

Какво използвахте?

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

Дневникът изглежда така:

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

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

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

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

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

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

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

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

Попадането в възела на успешния клас означава успешно завършване на урока на нашата платформа заедно с учителя. Той записва напредъка по курса и подхода към желания резултат - „Завършен курсът“. За нас е важно учениците да присъстват колкото се може повече.

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

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

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

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

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

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

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

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

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

Втори случай: грешки при включване

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

Тези няколко въвеждащи страници показаха тази фуния:

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

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

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

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

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

• плитчините се промъкнаха в базата данни с дневници;
• Има грешки в самия продукт - onboarding.

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

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

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

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

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

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