Нам важна разумець, што адбываецца з нашымі студэнтамі падчас навучання, і як гэтыя падзеі ўплываюць на вынік, таму мы выбудоўваем Customer Journey Map - карту кліенцкага вопыту. Бо працэс навучання - не нешта бесперапыннае і суцэльнае, гэта ланцужок узаемазвязаных падзей і дзеянняў студэнта, прычым гэтыя дзеянні могуць моцна адрознівацца ў розных вучняў. Вось ён прайшоў урок: што ён зробіць далей? Пойдзе ў хатняе заданне? Запусціць мабільнае прыкладанне? Зменіць курс, папросіць змяніць настаўніка? Адразу зойдзе ў наступны ўрок? Ці проста сыдзе расчараваным? Ці можна, прааналізаваўшы гэтую карту, выявіць заканамернасці, якія прыводзяць да паспяховага заканчэння курса ці наадварот, "адвальванню" студэнта?
Звычайна для выбудоўвання CJM выкарыстоўваюць спецыялізаваныя, вельмі дарагія прылады з зачыненым кодам. Але нам хацелася прыдумаць нешта простае, якое патрабуе мінімальных намаганняў і па магчымасці апенсорнае. Так з'явілася ідэя скарыстацца ланцугамі Маркава - і ў нас атрымалася. Мы пабудавалі карту, інтэрпрэтавалі дадзеныя аб паводзінах студэнтаў у выглядзе графа, убачылі зусім невідавочныя адказы на глабальныя пытанні бізнесу і нават знайшлі глыбока схаваныя багі. Усё гэта мы зрабілі з дапамогай апенсорсных рашэнняў Python-скрыпту. У гэтым артыкуле я раскажу пра два кейсы з тымі самымі невідавочным вынікам і падзялюся скрыптам з усімі жадаючымі.
Такім чынам, ланцугі Маркава паказваюць імавернасць пераходаў паміж падзеямі. Вось прымітыўны прыклад з Вікіпедыі:
Тут "E" і "A" - падзеі, стрэлачкі - пераходы паміж імі (у тым ліку і пераход з падзеі ў яго ж), а вагі стрэлачак - верагоднасць пераходу ("узважаны арыентаваны граф").
Што выкарыстоўвалі
Ланцуг навучаўся стандартным функцыяналам Python, якому скормліваліся логі актыўнасці студэнтаў. Граф на атрыманай матрыцы будаваўся бібліятэкай NetworkX.
Лог выглядае так:
Гэта csv-файл, які змяшчае табліцу з трох слупкоў: id студэнта, найменне падзеі, час, калі яно адбылося. Гэтых трох палёў дастаткова, каб прасачыць рухі кліента, пабудаваць карту і ў выніку атрымаць ланцуг Маркава.
Бібліятэка вяртае пабудаваныя графы ў фармаце .dot ці .gexf. Для візуалізацыі першых можна скарыстацца бясплатным пакетам Graphviz (інструмент gvedit), мы працавалі з .gexf і Gephi, таксама бясплатнай.
Далей хачу прывесці два прыклады выкарыстання ланцугоў Маркава, якія дазволілі нам па-новаму зірнуць на нашы мэты, навучальныя працэсы і саму экасістэму Skyeng. Ну і падправіць багі.
Першы кейс: мабільнае прыкладанне
Для пачатку мы даследавалі шлях студэнта па нашым самым папулярным прадукце – курсе General. У той момант я працаваў у дзіцячым дэпартаменце Skyeng і мы хацелі паглядзець, наколькі эфектыўна працуе мабільнае прыкладанне з нашай дзіцячай аўдыторыяй.
Узяўшы логі і прагнаўшы іх праз скрыпт, я атрымаў нешта такое:
Стартавы вузел - Start General, а ўнізе тры выходныя ноды: вучань "заснуў", змяніў курс, скончыў курс.
- Fell asleep, «Заснуў» - значыць, больш не праходзіць заняткі, хутчэй за ўсё, ён адваліўся. Мы аптымістычна завём гэты стан «заснуў», т.я. у тэорыі ў яго захоўваецца магчымасць прадоўжыць навучанне. Найгоршы вынік для нас.
- Dropped general, Змяніў курс перайшоў з General на нешта іншае і згубіўся для нашага ланцуга Маркава.
- Finished course, Скончыў курс - ідэальны стан, чалавек прайшоў 80% урокаў (не ўсе ўрокі абавязковыя).
Пападанне ў ноду successfull 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