È importante comprendere cosa accade ai nostri studenti durante l'apprendimento e come questi eventi influenzino il risultato, quindi stiamo creando una Customer Journey Map - una mappa dell'esperienza del cliente. Infatti, il processo di apprendimento non è continuo e omogeneo, ma una sequenza di eventi e azioni correlate degli studenti, le cui azioni possono variare notevolmente da studente a studente. Dunque, dopo aver completato una lezione: cosa farà dopo? Andrà a fare i compiti? Avvierà l'app mobile? Cambierà corso, chiederà di cambiare insegnante? Entrerà direttamente nella prossima lezione? O lascerà semplicemente insoddisfatto? È possibile, analizzando questa mappa, identificare schemi che portano a un completamento con successo del corso o, al contrario, all'abbandono dello studente?
Di solito, per costruire il CJM si utilizzano strumenti specializzati, piuttosto costosi e con codice chiuso. Ma noi volevamo ideare qualcosa di semplice, che richiedesse uno sforzo minimo e, se possibile, open source. È così che è nata l'idea di utilizzare le catene di Markov - e ci siamo riusciti. Abbiamo costruito una mappa, interpretato i dati sul comportamento degli studenti sotto forma di grafo, visto risposte completamente inattese a domande globali di business e persino trovato bug profondamente nascosti. Tutto ciò l'abbiamo fatto grazie a soluzioni open source in uno script Python. In questo articolo parlerò di due casi con quegli stessi risultati poco evidenti e condividerò lo script con tutti i desiderosi.
Quindi, le catene di Markov mostrano la probabilità di transizioni tra eventi. Ecco un esempio primitivo da Wikipedia:
Qui, "E" e "A" sono eventi, le frecce sono le transizioni tra di essi (compresa la transizione da un evento a se stesso), e i pesi delle frecce sono la probabilità di transizione ("grafo orientato pesato").
Cosa abbiamo usato
La catena è stata addestrata con le funzionalità standard di Python, ai quali sono stati forniti i log delle attività degli studenti. Il grafo sulla matrice ottenuta è stato costruito con la libreria NetworkX.
Il log appare così:
È un file csv che contiene una tabella di tre colonne: id studente, nome dell'evento, momento in cui è avvenuto. Questi tre campi sono sufficienti per tracciare i movimenti del cliente, costruire una mappa e infine ottenere una catena di Markov.
La biblioteca restituisce i grafi costruiti in formato .dot o .gexf. Per visualizzare i primi, è possibile utilizzare il pacchetto gratuito Graphviz (strumento gvedit); noi abbiamo lavorato con .gexf e Gephi, anch'esso gratuito.
Voglio ora presentare due esempi di utilizzo delle catene di Markov che ci hanno permesso di rivedere i nostri obiettivi, i processi di apprendimento e l'ecosistema Skyeng. E di correggere i bug.
Primo caso: applicazione mobile
Per iniziare, abbiamo esaminato il percorso dello studente nel nostro prodotto più popolare: il corso General. In quel momento lavoravo nel dipartimento bambini di Skyeng e volevamo vedere quanto fosse efficace l'app mobile con il nostro pubblico infantile.
Prendendo i log e facendoli passare attraverso uno script, ho ottenuto qualcosa di simile:
Nodo iniziale — Start General, e in basso ci sono tre nodi di uscita: lo studente "si è addormentato", ha cambiato corso, ha finito il corso.
- Si è addormentato, "Zasnul" — significa che non partecipa più alle lezioni, molto probabilmente ha abbandonato. Noi lo chiamiamo ottimisticamente "si è addormentato", poiché in teoria ha ancora la possibilità di continuare l'apprendimento. È il risultato peggiore per noi.
- Cambiato corso, ha cambiato da General a qualcos'altro e si è perso per la nostra catena di Markov.
- Finito il corso — condizione ideale, la persona ha completato l'80% delle lezioni (non tutte le lezioni sono obbligatorie).
L'arrivo nel nodo corso riuscito indica il superamento con successo della lezione sulla nostra piattaforma insieme all'insegnante. Essa registra i progressi nel corso e la vicinanza al risultato desiderato — "Finito il corso". È importante per noi che gli studenti partecipino il più possibile.
Per ottenere conclusioni quantitative più precise per l'app mobile (nodo sessione app), abbiamo costruito catene separate per ciascun nodo finale e poi confrontato i pesi degli archi a coppie:
- dalla sessione app di nuovo a se stessa;
- dalla sessione app al corso riuscito;
- dal corso riuscito alla sessione app.
A sinistra — studenti che hanno finito il corso, a destra — "si sono addormentati"
Questi tre archi mostrano la connessione tra il successo dello studente e l'uso dell'app mobile. Ci aspettavamo di vedere che tra gli studenti che hanno finito il corso, la connessione con l'app fosse più forte rispetto a quelli che si sono "addormentati". Tuttavia, in realtà abbiamo ottenuto risultati opposti:
- ci siamo resi conto che diversi gruppi di utenti interagiscono in modo diverso con l'app mobile;
- gli studenti di successo utilizzano meno intensamente l'app mobile;
- gli studenti che si addormentano utilizzano l'app mobile in modo più attivo.
Questo significa che gli studenti "che si addormentano" iniziano a trascorrere sempre più tempo nell'app mobile e alla fine ci rimangono per sempre.
Inizialmente siamo rimasti sorpresi, ma riflettendoci abbiamo capito che si tratta di un effetto del tutto comprensibile. Tempo fa, ho studiato francese da solo, utilizzando due strumenti: l'app mobile e le lezioni di grammatica su YouTube. All'inizio dividevo il tempo tra di essi in modo equo, 50 e 50. Tuttavia, l'app è più divertente, ci sono elementi di gamification, è tutto semplice, rapido e chiaro, mentre nelle lezioni bisogna comprendere, prendere appunti e fare esercizi su un quaderno. Gradualmente ho iniziato a trascorrere più tempo sullo smartphone, fino a quando la sua quota non è salita al 100%: se si sta un'ora lì dentro, si ha una falsa sensazione di aver lavorato, per cui non c'è alcun desiderio di andare a ascoltare qualcosa.
Ma com'è possibile? Abbiamo creato apposta un'app mobile, , gamificando, rendendola attraente per far sì che le persone ci trascorrano del tempo, e invece essa le distrae? In realtà, la ragione è che il team dell'app mobile ha svolto così bene il proprio lavoro che essa è diventata un prodotto autonomo e straordinario, uscendo dalla nostra ecosistema.
Alla fine della ricerca, abbiamo capito che l'app mobile deve essere modificata in modo che distolga meno dal corso principale dell'apprendimento. E questo vale sia per i bambini che per gli adulti. Attualmente è in corso questo lavoro.
Secondo caso: bug dell'onboarding
L'onboarding è una procedura aggiuntiva non obbligatoria durante la registrazione di un nuovo studente, che elimina potenziali problemi tecnici futuri. Lo scenario di base prevede che l'individuo si registri sulla landing page, ottenga accesso al proprio account personale, venga contattato e partecipi a una lezione introduttiva. In questo frangente, abbiamo notato un alto tasso di difficoltà tecniche durante la lezione introduttiva: versione del browser errata, microfono o audio non funzionanti, l'insegnante non riesce subito a suggerire una soluzione, il che risulta particolarmente complicato quando si tratta di bambini. Pertanto, abbiamo sviluppato un'applicazione aggiuntiva nell'account personale, dove è possibile seguire quattro semplici passaggi: controllare il browser, la videocamera, il microfono e confermare che i genitori saranno presenti durante la lezione introduttiva (dopotutto, sono loro a pagare per l'istruzione dei bambini).
Queste poche pagine di onboarding dimostravano un funnel di questo tipo:
1: blocco iniziale con tre moduli di accesso login-password che differiscono leggermente (a seconda del cliente).
2: firma per l'approvazione della procedura di onboarding aggiuntiva.
2.1-2.3: verifica della presenza di un genitore, della versione di Chrome e dell'audio.
3: blocco finale.
Appare molto naturale: nei primi due passaggi la maggior parte dei visitatori abbandona, rendendosi conto che qui devono compilare qualcosa, controllare, e non hanno tempo. Se un cliente raggiunge il terzo passaggio, è quasi certo che arriverà alla fine. Nel funnel non si vedono motivi per sospettare nulla.
Tuttavia, abbiamo deciso di analizzare il nostro onboarding non attraverso il classico funnel unidimensionale, ma utilizzando una catena di Markov. Abbiamo incluso un numero maggiore di eventi, eseguito uno script e ottenuto questo:
In questo caos, si può comprendere con certezza solo una cosa: qualcosa non ha funzionato. Il processo di onboarding è lineare, questo è ciò che il design prevede, non dovrebbe esserci una tale rete di connessioni. Qui è evidente che l'utente viene spostato tra passaggi, tra i quali non dovrebbero esserci transizioni.
Le ragioni di questo strano quadro potrebbero essere due:
- errori si sono infiltrati nel database dei log;
- errori sono presenti nel prodotto stesso — nell'onboarding.
La prima ragione, probabilmente, è valida, ma verificarla è piuttosto laborioso, e correggere i log non aiuterà a migliorare l'UX. Per quanto riguarda la seconda, se esiste, bisognava agire urgentemente. Così abbiamo iniziato a esaminare i nodi, identificare i bordi che non dovevano esserci e cercare le ragioni della loro apparizione. Abbiamo visto che alcuni utenti si bloccavano e giravano in tondo, altri — cadevano da metà all'inizio, altri ancora non riuscivano affatto a superare i primi due passaggi. Abbiamo inviato i dati al QA — e sì, si è scoperto che c'erano diversi bug nel processo di onboarding: è un prodotto secondario, un po' di ripiego, che non è stato testato abbastanza a fondo, poiché non ci si aspettava alcun problema. Ora l'intero processo di registrazione è cambiato.
Questa storia ci ha mostrato un'applicazione inaspettata delle catene di Markov nel campo del QA.
Provalo tu stesso!
Ho pubblicato il mio in accesso aperto — usalo pure. La documentazione è su GitHub, puoi porre domande qui, cercherò di rispondere a tutto.
Ecco alcuni link utili: , . Ma qui sulle catene di Markov. I grafi nell'articolo sono stati realizzati con .
Fonte: habr.com
