È fondamentale per noi comprendere cosa accade ai nostri studenti durante il loro percorso formativo e come questi eventi influenzino i risultati. Per questo motivo, creiamo una Customer Journey Map — una mappa dell'esperienza del cliente. Il processo di apprendimento non è un insieme continuo e omogeneo, ma piuttosto una serie di eventi e azioni interconnessi del singolo studente, il cui comportamento può variare notevolmente. Dopo aver completato una lezione, cosa farà poi? Inizierà i compiti a casa? Aprirà l'app mobile? Cambierà corso o chiederà di cambiare insegnante? Inizierà subito la lezione successiva? Oppure si allontanerà deluso? È possibile, analizzando questa mappa, identificare le tendenze che portano a un completamento con successo del corso o, al contrario, all'abbandono da parte dello studente?
Di solito, per costruire un CJM si utilizzano strumenti specializzati, piuttosto costosi e con codice chiuso. Ma volevamo ideare qualcosa di semplice, che richiedesse sforzi minimi e fosse il più possibile open source. Così è 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, abbiamo scoperto risposte sorprendenti a domande globali e persino trovato bug profondamente nascosti. Tutto questo è stato realizzato grazie a soluzioni open source con uno script Python. In questo articolo parlerò di due casi con i risultati inaspettati e condividerò lo script con tutti coloro che sono interessati.
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 transizioni tra di essi (compresa la transizione da un evento a se stesso), e i pesi delle frecce rappresentano la probabilità di transizione ('grafo orientato pesato').
Cosa abbiamo usato
La catena è stata addestrata con le funzionalità standard di Python, a cui sono stati forniti i log delle attività degli studenti. Il grafo sulla matrice ottenuta è stato costruito con la libreria NetworkX.
Il log appare così:
Questo è un file csv che contiene una tabella di tre colonne: id dello studente, nome dell'evento, e l'ora in cui è avvenuto. Questi tre campi sono sufficienti per tracciare i movimenti del cliente, costruire una mappa e alla fine ottenere una catena di Markov.
La libreria restituisce i grafi costruiti nei formati .dot o .gexf. Per visualizzare i primi, si può utilizzare il pacchetto gratuito Graphviz (strumento gvedit); noi abbiamo lavorato con .gexf e Gephi, anch'esso gratuito.
Ora, voglio presentare due esempi di utilizzo delle catene di Markov, che ci hanno permesso di guardare nuovamente ai nostri obiettivi, ai processi di apprendimento e all'ecosistema Skyeng. E di correggere i bug.
Primo caso: applicazione mobile
Innanzitutto, abbiamo esaminato il percorso dello studente nel nostro prodotto più popolare — il corso General. In quel momento, lavoravo nel dipartimento per bambini di Skyeng e volevamo vedere quanto fosse efficace l'applicazione mobile con il nostro pubblico infantile.
Prendendo i log e facendoli passare attraverso uno script, ho ottenuto qualcosa del genere:
Il nodo di partenza è Start General, e in basso ci sono tre nodi in uscita: lo studente «si è addormentato», ha cambiato corso, ha terminato il corso.
- Si è addormentato, «Zasnul» — significa che non sta più seguendo le lezioni, molto probabilmente è andato via. Lo chiamiamo ottimisticamente uno stato di «si è addormentato», poiché in teoria ha ancora la possibilità di riprendere lo studio. Il risultato peggiore per noi.
- Cambiato corso, ha cambiato da General a qualcos'altro ed è andato perso per la nostra catena di Markov.
- Corso concluso, significa che la persona ha completato l'80% delle lezioni (non tutte le lezioni sono obbligatorie).
Entrare nel nodo successful class significa aver completato una lezione sulla nostra piattaforma insieme all'insegnante. Segna i progressi nel corso e la vicinanza al risultato desiderato — «Corso concluso». È importante che gli studenti la frequentino il più possibile.
Per ottenere conclusioni quantitative più precise per l'applicazione mobile (nodo app session), abbiamo costruito catene separate per ciascuno dei nodi finali e poi confrontato in coppia i pesi degli archi:
- da app session di nuovo in essa;
- da app session a successful class;
- da successful class a app session.
A sinistra — studenti che hanno completato il corso, a destra — quelli che si sono "addormentati"
Queste tre barre mostrano il rapporto tra il successo dello studente e l'uso dell'app mobile. Ci aspettavamo di vedere che gli studenti che hanno completato il corso avessero un rapporto con l'app più forte rispetto a quelli che si sono "addormentati". Tuttavia, i risultati ottenuti sono stati esattamente opposti:
- abbiamo constatato che diversi gruppi di utenti interagiscono in modi differenti con l'app mobile;
- gli studenti di successo utilizzano l'app mobile in modo meno intenso;
- gli studenti che si "addormentano" usano attivamente l'app mobile.
Ciò significa che gli studenti "addormentati" iniziano a trascorrere sempre più tempo nell'app mobile e alla fine rimangono attivi in essa per sempre.
All'inizio siamo rimasti sorpresi, ma poi abbiamo capito che si trattava di un effetto del tutto naturale. Tempo fa ho studiato il francese da solo, utilizzando due strumenti: un'app mobile e lezioni di grammatica su YouTube. Inizialmente dividevo il tempo tra di loro in proporzione 50 a 50. Ma l'app era più divertente, con la gamification, tutto era semplice, veloce e chiaro, mentre nelle lezioni dovevo approfondire, scrivere appunti e praticare nel quaderno. Progressivamente ho iniziato a trascorrere più tempo sullo smartphone, finché la sua percentuale non è salita al 100%: dopo tre ore in esso, si crea una falsa impressione di lavoro svolto, che rende poco attraente l'idea di andare a seguire qualcosa.
Ma come può essere? Abbiamo creato appositamente un'app mobile, , gamificando, rendendola attraente affinché le persone vi trascorressero tempo, e invece sembra solo distrarli? In realtà, il motivo è che il team dell'app mobile ha svolto troppo bene i propri compiti, trasformandola in un prodotto autonomo e fantastico che ha iniziato a uscire dal nostro ecosistema.
Dalla ricerca è emerso che è necessario modificare l'app mobile affinché non distolga troppo dall'apprendimento professionale, sia per bambini che per adulti. Attualmente stiamo lavorando a questo.
Secondo caso: problemi di onboarding
L'onboarding è una procedura aggiuntiva non obbligatoria durante la registrazione di un nuovo studente, progettata per eliminare potenziali problemi tecnici futuri. Lo scenario di base prevede che l'utente si sia registrato sulla landing page, abbia ottenuto l'accesso all'area personale, venga contattato e segua una lezione introduttiva. Notiamo un alto tasso di difficoltà tecniche durante la lezione introduttiva: versione errata del browser, microfono o audio non funzionanti, l'insegnante non può suggerire immediatamente una soluzione, e tutto ciò è particolarmente difficile quando si tratta di bambini. Per questo motivo abbiamo sviluppato un'app aggiuntiva nell'area personale, dove è possibile completare quattro semplici passaggi: controllare il browser, la fotocamera, 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 mostrano il seguente funnel:
1: blocco iniziale con tre moduli di accesso leggermente diversi (a seconda del cliente).
2: spunta di consenso per una procedura di onboarding aggiuntiva.
2.1-2.3: verifica della presenza del genitore, versione di Chrome e audio.
3: blocco finale.
Risulta molto naturale: nei primi due passaggi, la maggior parte dei visitatori abbandona, rendendosi conto che devono compilare qualcosa, controllare, e che non hanno tempo. Se il cliente arriva al terzo passo, è quasi certo che raggiungerà il traguardo. Non ci sono ragioni visibili nella funnel per sospettare qualcosa.
Tuttavia, abbiamo deciso di analizzare il nostro onboarding non con la classica funnel unidimensionale, ma tramite una catena di Markov. Abbiamo incluso un numero maggiore di eventi, eseguito lo script e ottenuto questo risultato:
Da questo caos si può capire solo una cosa: qualcosa è andato storto. Il processo di onboarding è lineare, come concepito dal design, e non dovrebbe avere una rete di collegamenti così complessa. Qui si vede chiaramente che l'utente viene spostato tra i passaggi, tra i quali non dovrebbero esserci transizioni.
Le ragioni di questa strana situazione potrebbero essere due:
- errori inseriti nel database dei log;
- i difetti sono presenti nel prodotto stesso — onboarding.
La prima ragione, probabilmente, è valida, ma verificarla è abbastanza laborioso, e correggere i log non aiuterà a migliorare l'esperienza utente. Tuttavia, per la seconda, se esiste, dovevamo agire rapidamente. Quindi abbiamo iniziato a esaminare i nodi, identificare gli archi che non dovevano esserci e cercare le cause della loro comparsa. Abbiamo notato che alcuni utenti si bloccavano e giravano in tondo, altri saltavano dalla metà all'inizio, altri ancora non riuscivano a uscire dai primi due passi. Abbiamo comunicato i dati al QA — e sì, si è scoperto che nel onboarding c'erano molti bug: è un prodotto secondario, un po' improvvisato, non è stato testato a fondo, poiché non ci si aspettava problemi. Ora l'intero processo di registrazione è cambiato.
Questa storia ci ha mostrato un'applicazione inaspettata delle catene di Markov nell'ambito del QA.
Provate voi stessi!
Ho pubblicato il mio in accesso aperto — usatelo pure. La documentazione è disponibile su GitHub, potete fare domande qui e cercherò di rispondere a tutto.
Ecco alcuni link utili: , . Qui sulle catene di Markov. I grafi nell'articolo sono realizzati con .
Fonte: habr.com
