Det är viktigt för oss att förstå vad som händer med våra elever under utbildningen och hur dessa händelser påverkar resultatet, så vi bygger en Customer Journey Map - en karta över kundupplevelsen. När allt kommer omkring är inlärningsprocessen inte något kontinuerligt och integrerat, det är en kedja av sammanlänkade händelser och handlingar hos eleven, och dessa handlingar kan variera mycket mellan olika elever. Nu har han slutfört sin lektion: vad ska han göra härnäst? Kommer det att gå till läxor? Kommer det att lansera en mobilapplikation? Kommer han att ändra kurs, be om att få byta lärare? Kommer du att gå direkt till nästa lektion? Eller kommer han bara att gå besviken? Är det möjligt att, genom att analysera denna karta, identifiera mönster som leder till ett framgångsrikt slutförande av kursen eller, omvänt, till "avhopp" hos studenten?
Vanligtvis används specialiserade, mycket dyra verktyg med sluten källkod för att bygga CJM. Men vi ville komma på något enkelt, som kräver minimal ansträngning och, om möjligt, öppen källkod. Så idén kom att använda Markov-kedjor – och vi lyckades. Vi byggde en karta, tolkade data om elevers beteende i form av en graf, såg helt oklara svar på globala affärsfrågor och hittade till och med djupt dolda buggar. Vi gjorde allt detta med Python-skriptlösningar med öppen källkod. I den här artikeln kommer jag att prata om två fall med dessa mycket icke-uppenbara resultat och dela manuset med alla.
Så Markov-kedjor visar sannolikheten för övergångar mellan händelser. Här är ett primitivt exempel från Wikipedia:
Här är "E" och "A" händelser, pilarna är övergångar mellan dem (inklusive övergången från en händelse till densamma), och pilarnas vikt är sannolikheten för övergång ("vägd riktad graf").
Vad använde du?
Kretsen tränades med standard Python-funktionalitet, som matades med elevaktivitetsloggar. Grafen på den resulterande matrisen konstruerades av NetworkX-biblioteket.
Loggen ser ut så här:
Detta är en csv-fil som innehåller en tabell med tre kolumner: student-id, namn på händelsen, tidpunkt då den inträffade. Dessa tre fält räcker för att spåra klientens rörelser, bygga en karta och i slutändan få en Markov-kedja.
Biblioteket returnerar de konstruerade graferna i .dot- eller .gexf-format. För att visualisera det förra kan du använda gratispaketet Graphviz (gvedit tool), vi arbetade med .gexf och Gephi, också gratis.
Därefter skulle jag vilja ge två exempel på hur vi använder Markov-kedjor, som gjorde det möjligt för oss att ta en ny titt på våra mål, utbildningsprocesser och själva Skyeng-ekosystemet. Nåväl, fixa buggarna.
Första fallet: mobilapplikation
Till att börja med utforskade vi studentresan genom vår mest populära produkt – Allmän kurs. I det ögonblicket arbetade jag på barnavdelningen i Skyeng och vi ville se hur effektivt mobilapplikationen fungerade med våra barns publik.
När jag tog loggarna och körde dem genom skriptet fick jag något sånt här:
Startnoden är Start Allmänt, och längst ner finns tre utgångsnoder: studenten "somnade", bytte kurs och avslutade kursen.
- Somnade, "somnade" - detta betyder att han inte längre tar lektioner, troligtvis föll han av. Vi kallar optimistiskt detta tillstånd "sömnande", eftersom... i teorin har han fortfarande möjlighet att fortsätta sina studier. Sämsta resultatet för oss.
- Tappade general, ändrade kurs - bytte från General till något annat och gick vilse för vår Markov-kedja.
- Avslutad kurs, Avslutad kurs - idealisk kondition, personen har genomfört 80% av lektionerna (alla lektioner krävs inte).
Att komma in i den framgångsrika klassnoden innebär att framgångsrikt slutföra lektionen på vår plattform tillsammans med läraren. Den registrerar framsteg längs banan och tillvägagångssätt för det önskade resultatet - "Slutfört kursen." Det är viktigt för oss att eleverna kommer så mycket som möjligt.
För att få mer exakta kvantitativa slutsatser för mobilapplikationen (appsessionsnod) byggde vi separata kedjor för var och en av de slutliga noderna och jämförde sedan kantvikterna parvis:
- från appsessionen tillbaka till den;
- från app-session till framgångsrik klass;
- från lyckad klass till app-session.
Till vänster finns elever som slutfört kursen, till höger är de som "somnade"
Dessa tre kanter visar sambandet mellan en elevs framgång och deras användning av mobilappen. Vi förväntade oss att se att studenter som genomfört kursen skulle ha en starkare koppling till ansökan än studenter som somnade. Men i verkligheten fick vi exakt motsatta resultat:
- vi såg till att olika grupper av användare interagerar med mobilapplikationen på olika sätt;
- framgångsrika studenter använder mobilapplikationen mindre intensivt;
- elever som somnar använder mobilapplikationen mer aktivt.
Det betyder att elever som somnar börjar spendera mer och mer tid i mobilapplikationen och i slutändan stannar kvar i den för alltid.
Först blev vi förvånade, men efter att ha tänkt efter insåg vi att detta var en helt naturlig effekt. En gång studerade jag franska på egen hand med två verktyg: en mobilapplikation och grammatikföreläsningar på YouTube. Först delade jag upp tiden mellan dem i förhållandet 50 till 50. Men applikationen är roligare, det finns gamification, allt är enkelt, snabbt och tydligt, men i föreläsningen måste du fördjupa dig i det, skriva ner något , öva i en anteckningsbok. Gradvis började jag spendera mer tid på min smartphone, tills dess andel växte till 100%: om du spenderar tre timmar på den skapar du en falsk känsla av avslutat arbete, på grund av vilket du inte har någon lust att gå och lyssna på någonting .
Men hur kan detta vara? När allt kommer omkring skapade vi speciellt en mobilapplikation, , gamifierade det, gjorde det attraktivt så att folk skulle spendera tid i det, men det visar sig att det bara distraherar dem? Faktum är att anledningen är att mobilapplikationsteamet klarade sina uppgifter för bra, vilket ledde till att det blev en cool, självförsörjande produkt och började falla ur vårt ekosystem.
Som ett resultat av forskningen blev det tydligt att mobilapplikationen behövde ändras på något sätt så att den skulle vara mindre distraherande från huvudkursen. Och både barn och vuxna. Detta arbete pågår för närvarande.
Andra fallet: onboarding buggar
Onboarding är ett valfritt tilläggsprocedur när du registrerar en ny student, vilket eliminerar potentiella tekniska problem i framtiden. Grundscenariot förutsätter att en person har registrerat sig på målsidan, fått tillgång till sitt personliga konto, kontaktas och får en introduktionslektion. Samtidigt noterar vi en stor andel av tekniska svårigheter under introduktionslektionen: fel version av webbläsaren, mikrofonen eller ljudet fungerar inte, läraren kan inte omedelbart föreslå en lösning, och allt detta är särskilt svårt när det gäller till barn. Därför har vi utvecklat ytterligare en applikation i ditt personliga konto, där du kan genomföra fyra enkla steg: kontrollera din webbläsare, kamera, mikrofon och bekräfta att föräldrar kommer att vara i närheten under introduktionslektionen (det är trots allt de som betalar för deras barns utbildning).
Dessa få onboarding-sidor visade en tratt så här:
1: startblock med tre lite olika (beroende på klient) inloggnings- och lösenordsinmatningsformulär.
2: kryssruta för att godkänna den ytterligare onboarding-proceduren.
2.1-2.3: Kontrollera om föräldrarna är närvarande, Chrome-version och ljud.
3: sista blocket.
Det ser väldigt naturligt ut: i de två första stegen går de flesta av besökarna, inser att det finns något att fylla i, kolla, men det finns ingen tid. Om klienten har nått det tredje steget kommer han nästan säkert att nå finalen. Det finns inte en enda anledning att misstänka något på tratten.
Ändå bestämde vi oss för att analysera vår onboarding inte på en klassisk endimensionell tratt, utan med hjälp av en Markov-kedja. Vi slog på lite fler händelser, körde manuset och fick detta:
I detta kaos kan bara en sak tydligt förstås: något gick fel. Onboardingprocessen är linjär, detta är inneboende i designen, det bör inte finnas någon sådan väv av anslutningar i den. Och här är det direkt klart att användaren kastas mellan stegen, mellan vilka det inte ska finnas några övergångar alls.
Det kan finnas två anledningar till denna konstiga bild:
- stim smög sig in i loggdatabasen;
- Det finns fel i själva produkten - onboarding.
Det första skälet är med största sannolikhet sant, men att testa det är ganska arbetskrävande och att korrigera loggarna hjälper inte att förbättra användarupplevelsen. Men med den andra, om den finns, måste något göras brådskande. Därför gick vi för att titta på noderna, identifiera kanter som inte borde existera och leta efter orsakerna till deras förekomst. Vi såg att vissa användare fastnade och gick i cirklar, andra ramlade ur mitten till början och andra kunde i princip inte ta sig ur de två första stegen. Vi överförde data till QA - och ja, det visade sig att det fanns tillräckligt med buggar i onboarding: det här är en sådan biprodukt, lite av en krycka, det testades inte tillräckligt djupt, eftersom... Vi förväntade oss inga problem. Nu har hela inspelningsprocessen förändrats.
Den här historien visade oss en oväntad tillämpning av Markov-kedjor inom QA-området.
Prova själv!
Jag la upp min i det offentliga området - använd det för din hälsa. Dokumentation på GitHub, frågor kan ställas här, jag ska försöka svara på allt.
Tja, användbara länkar: , . Och här om Markov-kedjor. Graferna i artikeln är gjorda med hjälp av .
Källa: will.com