Hur vi använder Markovkedjor för att utvärdera beslut och hitta buggar. Med ett skript i Python

Vi anser att det är viktigt att förstå vad som händer med våra studenter under utbildningen och hur dessa händelser påverkar resultatet. Därför bygger vi en Customer Journey Map — en karta över kundupplevelsen. Utbildningsprocessen är inte en kontinuerlig och enhetlig process utan en kedja av sammanlänkade händelser och studentens handlingar, där dessa handlingar kan variera kraftigt mellan olika elever. Han har genomfört lektionen: vad gör han härnäst? Kommer han att gå vidare till läxan? Ska han starta mobilappen? Kommer han att byta kurs, be om en ny lärare? Går han direkt till nästa lektion? Eller kommer han bara att lämna besviken? Kan vi genom att analysera denna karta identifiera mönster som leder till en framgångsrik kursavslutning eller tvärtom, en elev som ”faller bort”?

Vanligtvis används specialiserade, ganska kostsamma verktyg med stängd kod för att bygga CJM. Men vi ville komma på något enkelt, som kräver minimala ansträngningar och som i möjligaste mån är öppen källkod. Så föddes idén att använda Markovkedjor — och vi lyckades. Vi byggde en karta, tolkade data om studenternas beteende i form av en graf, såg helt ovisade svar på globala affärsfrågor och till och med hittade djupt begravda buggar. Allt detta gjorde vi med hjälp av öppen källkods-lösningar i Python-skript. I den här artikeln kommer jag att berätta om två fall med just dessa ovisade resultat och dela skriptet med alla intresserade.

Så, Markovkedjor visar sannolikheterna för övergångar mellan händelser. Här är ett enkelt exempel från Wikipedia:

Här representerar "E" och "A" händelserna, pilarna representerar övergångarna mellan dem (inklusive övergångar från en händelse till sig själv), och vikterna på pilarna representerar sannolikheten för övergången ("vikta riktade grafer").

Vad som användes

Kedjan tränades med standardfunktioner i Python, där loggar över studenternas aktivitet matades in. Grafen på den resulterande matrisen byggdes med biblioteket NetworkX.

Loggen ser ut så här:

Detta är en csv-fil som innehåller en tabell med tre kolumner: studentens id, händelsens namn, tidpunkten när den inträffade. Dessa tre fält är tillräckliga för att spåra kundens rörelser, bygga en karta och slutligen skapa en Markovkedja.

Biblioteket returnerar byggda grafer i .dot eller .gexf-format. För visualisering av det första kan man använda det kostnadsfria paketet Graphviz (verktyget gvedit). Vi har arbetat med .gexf och Gephi, som också är kostnadsfritt.

Därefter vill jag ge två exempel på användningen av Markovkedjor som har gjort att vi har fått en ny syn på våra mål, inlärningsprocesser och själva ekosystemet Skyeng. Och också rättat till buggar.

Första fallet: mobilapplikationen

Till att börja med undersökte vi studentens väg genom vår mest populära produkt — kursen General. Vid den tidpunkten arbetade jag i Skyengs barnavdelning och vi ville se hur effektivt mobilapplikationen fungerar med vår barnaudience.

Jag tog loggar och körde dem genom ett skript, och fick något sådant:

Startknut — Start General, och längst ner tre utgående noder: eleven "somnade", bytte kurs, avslutade kursen.

• Fell asleep, "Somnade" — vilket betyder att han inte längre deltar i lektioner, troligtvis har han försvunnit. Vi kallar optimistiskt detta tillstånd "somnade", eftersom han teoretiskt fortfarande har möjlighet att fortsätta lära sig. Det sämsta resultatet för oss.
• Dropped general, Bytte kurs — gick från General till något annat och gick förlorad för vår Markovkedja.
• Finished course, Avslutade kursen — det ideala tillståndet, personen har genomfört 80% av lektionerna (inte alla lektioner är obligatoriska).

Att hamna i noden successful class innebär att lektionen har genomförts framgångsrikt på vår plattform tillsammans med läraren. Det registrerar framsteg i kursen och närmar sig önskat resultat — "Avslutade kursen". Det är viktigt för oss att studenterna deltar så mycket som möjligt.

För att få mer exakta kvantitativa resultat för mobilapplikationen (noden app session) byggde vi separata kedjor för varje slutnod och jämförde sedan vikterna på kanterna parvis:

• från app session tillbaka till sig själv;
• från app session till successful class;
• från successful class till app session.

Till vänster — studenter som avslutat kursen, till höger — "somnat"

Dessa tre kanter visar sambandet mellan studentens framgång och användningen av mobilapplikationen. Vi förväntade oss att se att avslutande studenter skulle ha en starkare koppling till applikationen än de "somnat". Men verkligheten visade sig vara helt motsatt:

• vi kunde konstatera att olika grupper av användare interagerar på olika sätt med mobilapplikationen;
• Framgångsrika studenter använder mobilappen mindre intensivt;
• Sovande studenter använder mobilappen mer aktivt.

Det betyder att "sovande" studenter börjar spendera mer och mer tid i mobilappen och till slut stannar de där för alltid.

Först blev vi förvånade, men efter att ha tänkt efter insåg vi att det är en helt rimlig effekt. Jag studerade franska på egen hand en gång i tiden, med hjälp av två verktyg: mobilappen och grammatikföreläsningar på YouTube. I början delade jag tiden mellan dem i en 50/50-fördelning. Men appen är roligare, den har gamification, allt är enkelt, snabbt och klart, medan föreläsningar kräver att man går in i detaljer, skriver ner saker och övar i anteckningsblock. Så småningom började jag spendera mer tid på min smartphone, tills andelen nådde 100%: om man sitter i den i tre timmar ger det en falsk känsla av att man har utfört arbete, vilket gör att man inte har något initiativ att gå och lyssna på något.

Men hur kan det vara så? Vi skapade ju faktiskt mobilappen, integrerade Ebbinghaus kurva,, gamifierade den, gjorde den attraktiv så att folk skulle spendera tid där, men det verkar som att den bara distraherar dem? Egentligen är anledningen att teamet bakom mobilappen hanterade sina uppgifter så bra, att den blev en riktigt bra självständig produkt och började falla ut ur vårt ekosystem.

Som ett resultat av undersökningen kom vi fram till att mobilappen måste förändras på något sätt för att den inte ska dra för mycket från de centrala utbildningskurserna. Detta gäller både barn och vuxna. Det arbetet pågår nu.

Andra fallet: onboarding-buggar

Onboarding är en valfri procedur vid registreringen av en ny elev, som avlägsnar potentiella tekniska problem i framtiden. Det grundläggande scenariot innebär att en person registrerar sig på landningssidan, får tillgång till sitt personliga konto, blir kontaktad och genomgår en introduktionslektion. Vi noterar dock en hög procentandel tekniska svårigheter under introduktionslektionen: fel version av webbläsaren, mikrofonen fungerar inte eller ljudet är borta, läraren kan inte omedelbart ge en lösning, och allt detta är särskilt svårt när det handlar om barn. Därför har vi utvecklat en ytterligare applikation i det personliga kontot, där man kan genomföra fyra enkla steg: kontrollera webbläsaren, kameran, mikrofonen och bekräfta att föräldrarna kommer att vara närvarande under introduktionslektionen (eftersom det är de som betalar för barnens utbildning).

Dessa några sidor av onboarding visade en sådan tratt:

1: startblock med tre något olika (beroende på klienten) inloggning-formulär för användarnamn-lösenord.
2: kryssruta för godkännande av den ytterligare onboarding-proceduren.
2.1-2.3: kontroll av närvaro av förälder, Chrome-version och ljud.
3: avslutande block.

Det ser mycket naturligt ut: på de två första stegen faller majoriteten av besökarna bort, då de inser att de behöver fylla i något, kontrollera och att de inte har tid. Om klienten har kommit till det tredje steget är det nästan säkert att de går hela vägen till slutet. I tratten syns ingen anledning att misstänka något.

Ändå beslutade vi att analysera vår onboarding inte på den klassiska endimensionella tratten, utan med hjälp av en Markovkedja. Vi inkluderade lite fler händelser, körde skriptet och fick fram detta:

Det går entydigt att förstå i detta kaos att något har gått fel. Onboardingprocessen är linjär, det är inbyggt i designen, och den borde inte ha ett sådant nät av kopplingar. Här ser man omedelbart att användaren kastas mellan stegen som inte borde ha några övergångar.

Det kan finnas två orsaker till denna märkliga bild:

• fel har smugit sig in i loggdatabasen;
• fel finns i själva produkten – onboarding.

Den första orsaken är förmodligen närvarande, men att kontrollera den är ganska arbetskrävande, och att fixa loggarna hjälper inte alls med att förbättra UX. Men angående den andra, om den finns, var vi tvungna att agera snabbt. Därför gick vi igenom noder, identifierade kanter som inte skulle finnas, och sökte orsaker till deras uppkomst. Vi såg att vissa användare fastnade och gick i cirklar, andra hoppade från mitten till början, medan tredje gruppen i princip inte kunde ta sig förbi de första två stegen. Vi skickade data till QA — och ja, det visade sig att det fanns en hel del buggar i onboarding-processen: det är en slags biprodukt, lite av en nödlösning, den har inte testats tillräckligt djupt, eftersom vi inte förväntade oss några problem. Nu har hela inspelningsprocessen ändrats.

Denna historia visade oss en oväntad tillämpning av Markov-kedjor inom QA.

Testa själv!

Jag har publicerat min Python-script för att träna Markov-kedjor öppet för allmänheten — använd det gärna. Dokumentationen finns på GitHub, frågor kan ställas här, jag ska försöka svara på allt.

Och några användbara länkar: biblioteket NetworkX, visualisatorn Graphviz. Och här på Habré finns en artikel om Markov-kedjor. Grafikerna i artikeln är gjorda med hjälp av Gephi.

Källa: habr.com