É importante que entendamos o que lles pasa aos nosos estudantes durante a formación e como afectan estes eventos ao resultado, polo que creamos un Mapa da viaxe do cliente: un mapa da experiencia do cliente. Despois de todo, o proceso de aprendizaxe non é algo continuo e integral, é unha cadea de acontecementos e accións do alumno interconectados, e estas accións poden variar moito entre os distintos alumnos. Agora rematou a súa lección: que vai facer despois? Irá aos deberes? ¿Lanzará unha aplicación móbil? Cambiará de rumbo, pedirá cambiar de profesorado? Irás directo á seguinte lección? Ou simplemente marchará decepcionado? É posible, mediante a análise deste mapa, identificar patróns que conducen ao éxito do curso ou, pola contra, ao “abandono” do alumno?
Normalmente, utilízanse ferramentas de código pechado especializadas e moi caras para construír CJM. Pero queriamos dar con algo sinxelo, que requirise un esforzo mínimo e, se é posible, código aberto. Entón xurdiu a idea de usar cadeas de Markov, e conseguímolo. Construímos un mapa, interpretamos datos sobre o comportamento dos estudantes en forma de gráfico, vimos respostas completamente non obvias a problemas comerciais globais e mesmo atopamos erros profundamente ocultos. Fixemos todo isto usando solucións de script Python de código aberto. Neste artigo falarei de dous casos con eses resultados tan pouco obvios e compartirei o guión con todos.
Entón, as cadeas de Markov mostran a probabilidade de transicións entre eventos. Aquí tes un exemplo primitivo da Wikipedia:
Aquí "E" e "A" son eventos, as frechas son transicións entre eles (incluída a transición dun evento ao mesmo) e os pesos das frechas son a probabilidade de transición ("gráfico dirixido ponderado").
Que usaches?
O circuíto adestrouse coa funcionalidade estándar de Python, que se alimentaba con rexistros de actividade dos estudantes. O gráfico da matriz resultante foi construído pola biblioteca NetworkX.
O rexistro ten o seguinte aspecto:
Este é un ficheiro csv que contén unha táboa de tres columnas: ID do alumno, nome do evento, hora en que ocorreu. Estes tres campos son suficientes para rastrexar os movementos do cliente, construír un mapa e, finalmente, obter unha cadea de Markov.
A biblioteca devolve os gráficos construídos en formato .dot ou .gexf. Para visualizar o primeiro, podes usar o paquete gratuíto Graphviz (ferramenta gvedit), traballamos con .gexf e Gephi, tamén gratuíto.
A continuación gustaríame poñer dous exemplos de uso das cadeas de Markov, que nos permitiron botar unha ollada aos nosos obxectivos, procesos educativos e ao propio ecosistema Skyeng. Ben, corrixa os erros.
Primeiro caso: aplicación móbil
Para comezar, exploramos a viaxe dos estudantes a través do noso produto máis popular: o curso Xeral. Nese momento, estaba traballando no departamento de nenos de Skyeng e queriamos ver como funcionaba a aplicación móbil coa nosa audiencia infantil.
Collendo os rexistros e executándoos a través do script, teño algo así:
O nodo de inicio é Inicio xeral, e na parte inferior hai tres nodos de saída: o alumno "quedou durmido", cambiou de curso e rematou o curso.
- Quedou durmido, "Dormeuse" - isto significa que xa non está a tomar clases, o máis probable é que se caera. Con optimismo chamamos a este estado "durmido", porque... en teoría, aínda ten a oportunidade de continuar os seus estudos. O peor resultado para nós.
- Deixouse de xeral, cambiou de rumbo: cambiouse de Xeral a outra cousa e perdeuse pola nosa cadea de Markov.
- Curso rematado, Finalizado o curso - condición ideal, a persoa completou o 80% das leccións (non son necesarias todas as leccións).
Entrar no nó da clase con éxito significa completar con éxito a lección na nosa plataforma xunto co profesor. Rexistra o progreso ao longo do curso e o achegamento ao resultado desexado: "Completou o curso". Para nós é importante que os alumnos asistan o máximo posible.
Para obter conclusións cuantitativas máis precisas para a aplicación móbil (nodo de sesión da aplicación), creamos cadeas separadas para cada un dos nodos finais e despois comparamos os pesos dos bordos por parellas:
- desde a sesión da aplicación de volta a ela;
- desde a sesión da aplicación ata a clase exitosa;
- da clase exitosa á sesión da aplicación.
Á esquerda están os alumnos que remataron o curso, á dereita os que "durmiron"
Estes tres bordos mostran a relación entre o éxito dun alumno e o seu uso da aplicación móbil. Esperabamos ver que os estudantes que completasen o curso tivesen unha conexión máis forte coa aplicación que os estudantes que quedaron durmidos. Non obstante, en realidade obtivemos os resultados exactamente opostos:
- asegurámonos de que diferentes grupos de usuarios interactúan coa aplicación móbil de forma diferente;
- os estudantes exitosos usan a aplicación móbil con menos intensidade;
- os estudantes que quedan durmidos usan a aplicación móbil de forma máis activa.
Isto significa que o alumnado que se queda durmido comeza a pasar cada vez máis tempo na aplicación móbil e, ao final, permanece nela para sempre.
Ao principio sorprendeunos, pero despois de pensalo, decatámonos de que se trataba dun efecto completamente natural. Nun tempo, estudei francés pola miña conta usando dúas ferramentas: unha aplicación móbil e clases de gramática en YouTube. Ao principio, dividín o tempo entre eles nunha proporción de 50 a 50. Pero a aplicación é máis divertida, hai gamificación, todo é sinxelo, rápido e claro, pero na charla hai que afondar nela, anotar algo. , practicar nun caderno. Pouco a pouco, comecei a pasar máis tempo no meu teléfono intelixente, ata que a súa participación chegou ao 100%: se pasas tres horas nel, creas unha falsa sensación de traballo terminado, polo que non tes ganas de ir escoitar nada. .
Pero como pode ser isto? Despois de todo, creamos especialmente unha aplicación móbil, , gamificouno, fíxoo atractivo para que a xente pasase tempo nel, pero resulta que só os distrae? De feito, a razón é que o equipo de aplicacións móbiles afrontou demasiado ben as súas tarefas, polo que se converteu nun produto xenial e autosuficiente e comezou a caer do noso ecosistema.
Como resultado da investigación, quedou claro que a aplicación móbil debía cambiarse dalgún xeito para que distraería menos do curso principal de estudo. E tanto nenos como adultos. Este traballo está actualmente en marcha.
Segundo caso: erros de incorporación
A incorporación é un procedemento adicional opcional ao rexistrar un novo estudante, eliminando posibles problemas técnicos no futuro. O escenario básico supón que unha persoa rexistrouse na páxina de destino, accedeu á súa conta persoal, se contacta e recibe unha lección introdutoria. Ao mesmo tempo, observamos unha gran porcentaxe de dificultades técnicas durante a lección introductoria: a versión incorrecta do navegador, o micrófono ou o son non funcionan, o profesor non pode suxerir inmediatamente unha solución e todo isto é especialmente difícil cando se trata. aos nenos. Por iso, desenvolvemos unha aplicación adicional na túa conta persoal, na que podes completar catro pasos sinxelos: comprobar o teu navegador, a cámara, o micrófono e confirmar que os pais estarán preto durante a lección de iniciación (a fin de contas, son eles os que pagan educación dos seus fillos).
Estas poucas páxinas de incorporación mostraron un funil como este:
1: bloque de inicio con tres formularios de inicio de sesión e contrasinal lixeiramente diferentes (dependendo do cliente).
2: caixa de verificación que acepta o procedemento de incorporación adicional.
2.1-2.3: Comprobe a presenza dos pais, a versión de Chrome e o son.
3: bloque final.
Parece moi natural: nos dous primeiros pasos, a maioría dos visitantes marchan, dándose conta de que hai algo que cubrir, comprobar, pero non hai tempo. Se o cliente chegou ao terceiro paso, case seguro que chegará ao final. Non hai un só motivo para sospeitar nada no funil.
Non obstante, decidimos analizar a nosa incorporación non nun embudo unidimensional clásico, senón utilizando unha cadea de Markov. Activamos un pouco máis de eventos, executamos o guión e obtivemos isto:
Neste caos, só se pode entender claramente unha cousa: algo saíu mal. O proceso de incorporación é lineal, isto é inherente ao deseño, non debería haber esa rede de conexións nel. E aquí queda inmediatamente claro que o usuario é botado entre pasos, entre os que non debería haber transicións en absoluto.
Pode haber dúas razóns para esta estraña imaxe:
- os cardúmenes introducíronse na base de datos de rexistros;
- Hai erros no propio produto: incorporación.
O primeiro motivo probablemente sexa certo, pero probalo é bastante laborioso e corrixir os rexistros non axudará a mellorar a UX. Pero co segundo, se existe, houbo que facer algo con urxencia. Polo tanto, fomos mirar os nodos, identificar arestas que non deberían existir e buscar as razóns da súa aparición. Vimos que algúns usuarios quedaban atascados e andaban en círculos, outros caían do medio ao principio e outros, en principio, non podían saír dos dous primeiros pasos. Transferimos os datos ao control de calidade, e si, resultou que había bastantes erros na incorporación: este é un subproduto, un pouco unha muleta, non se probou o suficientemente a fondo, porque... Non agardabamos ningún problema. Agora todo o proceso de gravación cambiou.
Esta historia mostrounos unha aplicación inesperada das cadeas de Markov no campo do control de calidade.
Próbao ti mesmo.
Publiquei o meu no dominio público: úsao para a túa saúde. Documentación en GitHub, pódense facer preguntas aquí, tentarei responder todo.
Ben, enlaces útiles: , . E aquí sobre as cadeas de Markov. Os gráficos do artigo están feitos usando .
Fonte: www.habr.com