É importante entendermos o que acontece com nossos alunos durante o treinamento e como esses eventos afetam o resultado, por isso construímos um Mapa da Jornada do Cliente – um mapa da experiência do cliente. Afinal, o processo de aprendizagem não é algo contínuo e integral, é uma cadeia de eventos e ações interligadas do aluno, e essas ações podem variar muito entre os diferentes alunos. Agora ele completou a lição: o que fará a seguir? Irá para o dever de casa? Será lançado um aplicativo móvel? Ele vai mudar de rumo, pedir para mudar de professor? Você irá direto para a próxima lição? Ou ele simplesmente sairá desapontado? É possível, através da análise deste mapa, identificar padrões que levam à conclusão bem sucedida do curso ou, pelo contrário, à “abandono” do aluno?
Normalmente, ferramentas especializadas e de código fechado muito caras são usadas para construir o CJM. Mas queríamos criar algo simples, que exigisse o mínimo de esforço e, se possível, de código aberto. Então surgiu a ideia de usar cadeias de Markov - e conseguimos. Construímos um mapa, interpretamos dados sobre o comportamento dos alunos na forma de um gráfico, vimos respostas completamente não óbvias para questões de negócios globais e até encontramos bugs profundamente ocultos. Fizemos tudo isso usando soluções de script Python de código aberto. Neste artigo falarei sobre dois casos com resultados nada óbvios e compartilharei o roteiro com todos.
Assim, as cadeias de Markov mostram a probabilidade de transições entre eventos. Aqui está um exemplo primitivo da Wikipedia:
Aqui “E” e “A” são eventos, as setas são transições entre eles (incluindo a transição de um evento para o mesmo), e os pesos das setas são a probabilidade de transição (“gráfico direcionado ponderado”).
O que você usou?
O circuito foi treinado com funcionalidade padrão do Python, que foi alimentada com registros de atividades dos alunos. O gráfico da matriz resultante foi construído pela biblioteca NetworkX.
O registro fica assim:
Este é um arquivo csv contendo uma tabela de três colunas: id do aluno, nome do evento, horário em que ocorreu. Esses três campos são suficientes para rastrear os movimentos do cliente, construir um mapa e finalmente obter uma cadeia de Markov.
A biblioteca retorna os gráficos construídos no formato .dot ou .gexf. Para visualizar o primeiro, você pode usar o pacote gratuito Graphviz (ferramenta gvedit), trabalhamos com .gexf e Gephi, também gratuito.
A seguir, gostaria de dar dois exemplos de uso de cadeias de Markov, que nos permitiram ter uma nova visão de nossos objetivos, processos educacionais e do próprio ecossistema Skyeng. Bem, corrija os bugs.
Primeiro caso: aplicativo móvel
Para começar, exploramos a jornada do aluno por meio de nosso produto mais popular: o curso Geral. Naquele momento, eu trabalhava no departamento infantil da Skyeng e queríamos ver a eficácia do aplicativo mobile com o nosso público infantil.
Pegando os logs e executando-os através do script, obtive algo assim:
O nó inicial é Início Geral e na parte inferior há três nós de saída: o aluno “adormeceu”, mudou de curso e terminou o curso.
- Adormeceu, “Adormeceu” - isso significa que ele não está mais tendo aulas, provavelmente ele caiu. Chamamos com otimismo esse estado de “adormecido”, porque... em teoria, ele ainda tem a oportunidade de continuar seus estudos. Pior resultado para nós.
- Abandonou o general, mudou de curso - mudou de geral para outra coisa e se perdeu em nossa cadeia de Markov.
- Curso concluído, Concluído o curso - condição ideal, a pessoa concluiu 80% das aulas (nem todas as aulas são obrigatórias).
Entrar no nó da aula com sucesso significa concluir com êxito a lição em nossa plataforma junto com o professor. Registra o progresso ao longo do curso e a abordagem ao resultado desejado - “Concluído o curso”. É importante para nós que os alunos compareçam o máximo possível.
Para obter conclusões quantitativas mais precisas para o aplicativo móvel (nó de sessão do aplicativo), construímos cadeias separadas para cada um dos nós finais e, em seguida, comparamos os pesos das arestas aos pares:
- da sessão do aplicativo de volta para ele;
- da sessão do aplicativo à aula de sucesso;
- da aula bem-sucedida à sessão do aplicativo.
À esquerda estão os alunos que concluíram o curso, à direita estão os que “adormeceram”
Essas três arestas mostram a relação entre o sucesso de um aluno e o uso do aplicativo móvel. Esperávamos ver que os alunos que concluíram o curso teriam uma conexão mais forte com o aplicativo do que os alunos que adormeceram. No entanto, na realidade obtivemos resultados exatamente opostos:
- garantimos que diferentes grupos de usuários interajam de maneira diferente com o aplicativo móvel;
- os alunos bem-sucedidos usam o aplicativo móvel com menos intensidade;
- os alunos que adormecem usam o aplicativo móvel de forma mais ativa.
Isso significa que os alunos que adormecem passam a passar cada vez mais tempo no aplicativo mobile e, no final, permanecem nele para sempre.
A princípio ficamos surpresos, mas depois de pensarmos bem, percebemos que se tratava de um efeito totalmente natural. Certa vez, estudei francês sozinho usando duas ferramentas: um aplicativo móvel e aulas de gramática no YouTube. No começo dividi o tempo entre eles na proporção de 50 para 50. Mas o aplicativo é mais divertido, tem gamificação, tudo é simples, rápido e claro, mas na palestra você tem que se aprofundar, escrever alguma coisa , pratique em um caderno. Aos poucos, comecei a passar mais tempo no meu smartphone, até que sua participação cresceu para 100%: se você passar três horas nele, você cria uma falsa sensação de trabalho concluído, por isso você não tem vontade de ir ouvir nada .
Mas como pode ser isso? Afinal, criamos especialmente um aplicativo mobile, , gamificou-o, tornou-o atraente para que as pessoas passassem algum tempo nele, mas acontece que isso apenas as distrai? Na verdade, a razão é que a equipe do aplicativo móvel lidou muito bem com suas tarefas, e como resultado ele se tornou um produto bacana e autossuficiente e começou a sair do nosso ecossistema.
Como resultado da pesquisa, ficou claro que o aplicativo móvel precisava ser alterado de alguma forma para que distraísse menos o curso principal. E crianças e adultos. Este trabalho está em andamento.
Segundo caso: bugs de integração
O onboarding é um procedimento adicional opcional na matrícula de um novo aluno, eliminando possíveis problemas técnicos no futuro. O cenário básico pressupõe que uma pessoa se registrou na landing page, obteve acesso à sua conta pessoal, foi contatada e recebeu uma aula introdutória. Ao mesmo tempo, notamos uma grande porcentagem de dificuldades técnicas durante a aula introdutória: a versão errada do navegador, o microfone ou o som não funcionam, o professor não consegue sugerir uma solução imediatamente, e tudo isso é especialmente difícil quando se trata para crianças. Por isso, desenvolvemos um aplicativo adicional em sua conta pessoal, onde você pode realizar quatro passos simples: verificar seu navegador, câmera, microfone e confirmar se os pais estarão por perto durante a aula introdutória (afinal, são eles quem pagam). educação dos seus filhos).
Essas poucas páginas de integração mostraram um funil como este:
1: bloco inicial com três formulários de login e senha ligeiramente diferentes (dependendo do cliente).
2: caixa de seleção concordando com o procedimento de integração adicional.
2.1-2.3: Verifique a presença dos pais, versão do Chrome e som.
3: bloco final.
Parece muito natural: nas duas primeiras etapas, a maioria dos visitantes sai, percebendo que tem algo para preencher, conferir, mas não dá tempo. Se o cliente chegou à terceira etapa, é quase certo que chegará à final. Não há um único motivo para suspeitar de algo no funil.
No entanto, decidimos analisar nossa integração não em um funil unidimensional clássico, mas usando uma cadeia de Markov. Ativamos mais alguns eventos, rodamos o script e obtivemos isto:
Neste caos, apenas uma coisa pode ser claramente compreendida: algo deu errado. O processo de onboarding é linear, isso é inerente ao design, não deveria haver tal teia de conexões nele. E aqui fica imediatamente claro que o usuário é jogado entre etapas, entre as quais não deve haver nenhuma transição.
Pode haver duas razões para esta imagem estranha:
- cardumes entraram no banco de dados de log;
- Existem erros no próprio produto – integração.
O primeiro motivo provavelmente é verdadeiro, mas testá-lo exige muito trabalho e corrigir os logs não ajudará a melhorar a experiência do usuário. Mas com o segundo, se existir, algo tinha que ser feito com urgência. Portanto, fomos olhar os nós, identificar arestas que não deveriam existir e procurar os motivos de sua ocorrência. Vimos que alguns usuários ficaram presos e andaram em círculos, outros caíram do meio para o início e outros, a princípio, não conseguiram sair das duas primeiras etapas. Transferimos os dados para o controle de qualidade - e sim, descobrimos que havia bugs suficientes na integração: isso é um subproduto, uma espécie de muleta, não foi testado profundamente o suficiente, porque... Não esperávamos nenhum problema. Agora todo o processo de gravação mudou.
Esta história nos mostrou uma aplicação inesperada das cadeias de Markov no campo de controle de qualidade.
Tente você mesmo!
eu postei o meu de domínio público - use-o para sua saúde. Documentação no GitHub, dúvidas podem ser feitas aqui, tentarei responder tudo.
Bem, links úteis: , . E aqui sobre cadeias de Markov. Os gráficos do artigo são feitos usando .
Fonte: habr.com