Att behålla en användare i en mobilapplikation är en hel vetenskap. Författaren till kursen beskrev dess grunder i vår artikel på VC.ru Maxim Godzi, chef för maskininlärning på App in the Air. Maxim berättar om de verktyg som utvecklats i företaget med hjälp av exemplet med arbete med analys och optimering av en mobilapplikation. Denna systematiska metod för produktförbättring, utvecklad i App in the Air, kallas Retentioneering. Du kan använda dessa verktyg i din produkt: några av dem finns i på GitHub.
App in the Air är en applikation med mer än 3 miljoner aktiva användare runt om i världen, med vilken du kan spåra flyg, få information om ändringar i avgångs-/landningstider, incheckning och flygplatsegenskaper.
Från tratt till bana
Alla utvecklingsteam bygger en onboarding-tratt (en process som syftar till att användaren accepterar produkten). Detta är det första steget som hjälper dig att titta på hela systemet uppifrån och hitta applikationsproblem. Men när produkten utvecklas kommer du att känna begränsningarna i detta tillvägagångssätt. Med en enkel tratt kan du inte se icke-uppenbara tillväxtpunkter för en produkt. Syftet med tratten är att ge en allmän titt på användarstadierna i applikationen, för att visa dig normens mått. Men tratten kommer försiktigt att dölja avvikelser från normen mot uppenbara problem eller, tvärtom, speciell användaraktivitet.
På App in the Air byggde vi vår egen tratt, men på grund av produktens särdrag slutade vi med ett timglas. Sedan bestämde vi oss för att utöka tillvägagångssättet och använda den rika information som själva applikationen ger oss.
När du bygger en tratt förlorar du användarens banor. Banor består av en sekvens av åtgärder av användaren och själva applikationen (till exempel att skicka en push-notis).
Med hjälp av tidsstämplar kan du mycket enkelt rekonstruera användarens bana och göra en graf av den för var och en av dem. Naturligtvis finns det många grafer. Därför måste du gruppera liknande användare. Du kan till exempel ordna alla användare efter tabellrader och lista hur ofta de använder en viss funktion.
Baserat på en sådan tabell gjorde vi en matris och grupperade användare efter användningsfrekvens av funktioner, det vill säga efter noder i grafen. Detta är vanligtvis det första steget mot insikter: till exempel kommer du redan i detta skede att se att vissa användare inte använder några av funktionerna alls. När vi gjorde frekvensanalysen började vi studera vilka noder i grafen som är ”störst”, det vill säga vilka sidor användare besöker oftast. Kategorier som är fundamentalt olika enligt något kriterium som är viktigt för dig markeras omedelbart. Här finns till exempel två kluster av användare som vi delat upp utifrån prenumerationsbeslutet (det var totalt 16 kluster).
Hur man använder det
Genom att titta på dina användare på det här sättet kan du se vilka funktioner du använder för att behålla dem eller till exempel få dem att registrera sig. Naturligtvis kommer matrisen också att visa uppenbara saker. Till exempel att de som köpt ett abonnemang besökte prenumerationsskärmen. Men förutom detta kan du också hitta mönster som du aldrig skulle ha känt till annars.
Så vi hittade helt av misstag en grupp användare som lägger till ett flyg, aktivt spårar det hela dagen och sedan försvinner under en lång tid tills de flyger någonstans igen. Om vi analyserade deras beteende med konventionella verktyg skulle vi tro att de helt enkelt inte var nöjda med applikationens funktionalitet: hur kan vi annars förklara att de använde den under en dag och aldrig återvände. Men med hjälp av grafer såg vi att de är väldigt aktiva, det är bara att all deras aktivitet ryms i en dag.
Nu är vår huvuduppgift att uppmuntra en sådan användare att ansluta till sitt flygbolags lojalitetsprogram medan han använder vår statistik. I det här fallet kommer vi att importera alla flyg han köper och försöka pressa honom att registrera sig så fort han köper en ny biljett. För att lösa detta problem började vi också samarbeta med Aviasales, Svyaznoy.Travel och andra applikationer. När deras användare köper en biljett uppmanar appen dem att lägga till flyget i App in the Air, och vi ser det direkt.
Tack vare grafen såg vi att 5 % av personerna som går till prenumerationsskärmen säger upp det. Vi började analysera sådana fall och såg att det finns en användare som går till första sidan, initierar anslutningen av sitt Google-konto och omedelbart avbryter det, kommer till första sidan igen och så vidare fyra gånger. Först tänkte vi, "Något är helt klart fel med den här användaren." Och sedan insåg vi att det troligen fanns en bugg i applikationen. I tratten skulle detta tolkas på följande sätt: användaren gillade inte uppsättningen av behörigheter som applikationen begär, och han lämnade.
En annan grupp hade 5 % av användarna att gå vilse på skärmen där appen uppmanar dem att välja en från alla kalenderappar på sin smartphone. Användare skulle välja olika kalendrar om och om igen och sedan helt enkelt avsluta appen. Det visade sig att det fanns ett UX-problem: efter att en person valt en kalender måste de klicka på Klar i det övre högra hörnet. Det är bara det att inte alla användare såg det.
Första skärmen av App in the Air
I vår graf såg vi att cirka 30 % av användarna inte går längre än den första skärmen: detta beror på att vi är ganska aggressiva när det gäller att pressa användaren att prenumerera. På den första skärmen uppmanar appen dig att registrera dig med Google eller Triplt, och det finns ingen information om att hoppa över registreringen. Av de som lämnar den första skärmen klickar 16 % av användarna på "Mer" och kommer tillbaka igen. Vi har fått reda på att de letar efter ett sätt att registrera sig internt i applikationen och vi kommer att släppa det i nästa uppdatering. Dessutom klickar 2/3 av de som lämnar direkt inte någonting alls. För att ta reda på vad som händer med dem byggde vi en värmekarta. Det visar sig att kunder klickar på en lista med appfunktioner som inte är klickbara länkar.
Fånga ett mikroögonblick
Man kan ofta se människor trampa stigar intill asfaltsvägen. Retentioneering är ett försök att hitta dessa stigar och om möjligt ändra vägarna.
Naturligtvis är det dåligt att vi lär oss av riktiga användare, men vi började åtminstone automatiskt spåra mönster som indikerar ett användarproblem i applikationen. Nu får produktchefen e-postmeddelanden om ett stort antal "slingor" inträffar — när användaren återvänder till samma skärm om och om igen.
Låt oss titta på vilka mönster i användarbanor som generellt är intressanta att leta efter för att analysera problem och tillväxtområden för en applikation:
- Slingor och cyklar. Slingorna som nämns ovan är när en händelse upprepas i användarens bana, till exempel kalender-kalender-kalender-kalender. En loop med många upprepningar är en tydlig indikator på ett gränssnittsproblem eller otillräcklig händelsemarkering. En cykel är också en sluten bana, men till skillnad från en loop innehåller den mer än en händelse, till exempel: visa flyghistorik - lägga till en flygning - visa flyghistorik.
- Flödesstoppare - när användaren på grund av något hinder inte kan fortsätta sin önskade rörelse genom applikationen, till exempel en skärm med ett gränssnitt som inte är uppenbart för klienten. Sådana händelser saktar ner och förskjuter användarnas bana.
- Bifurkationspunkter är viktiga händelser varefter banorna för klienter av olika typer separeras. I synnerhet är dessa skärmar som inte innehåller en direkt övergång eller uppmaning till målåtgärden, vilket effektivt driver vissa användare mot det. Till exempel kommer en skärm som inte är direkt relaterad till att köpa innehåll i en applikation, men där kunder är benägna att köpa eller inte köpa innehåll, bete sig annorlunda. Bifurkationspunkter kan vara punkter som påverkar dina användares handlingar med ett plustecken - de kan påverka beslutet att göra ett köp eller klick, eller ett minustecken - de kan avgöra att efter några steg kommer användaren att lämna applikationen.
- Avbrutna omvandlingspunkter är potentiella bifurkationspunkter. Du kan se dem som skärmar som kan leda till en målåtgärd, men gör det inte. Detta kan också vara en tidpunkt då användaren har ett behov, men vi tillfredsställer det inte eftersom vi helt enkelt inte vet om det. Bananalys bör göra det möjligt att identifiera detta behov.
- Distraktionspunkt - skärmar/popup-fönster som inte ger användaren värde, inte påverkar konverteringen och kan "suddra" banor, vilket distraherar användaren från målåtgärder.
- Döda vinklar är dolda punkter i applikationen, skärmar och funktioner som är mycket svåra för användaren att nå.
- Avlopp – punkter där trafik läcker
Generellt sett tillät det matematiska tillvägagångssättet oss att förstå att klienten använder applikationen på ett helt annat sätt än vad produktchefer brukar tro när de försöker planera något standardanvändningsscenario för användaren. Att sitta på kontoret och delta i de coolaste produktkonferenserna är det fortfarande väldigt svårt att föreställa sig alla de olika verkliga fältförhållandena där användaren kommer att lösa sina problem med applikationen.
Det här påminner mig om ett bra skämt. En testare går in i en bar och beställer: ett glas öl, 2 glas öl, 0 glas öl, 999999999 glas öl, en ödla i ett glas, -1 glas öl, qwertyuip glas öl. Den första riktiga kunden går in i baren och frågar var toaletten är. Baren brinner i lågor och alla dör.
Produktanalytiker, djupt nedsänkta i detta problem, började introducera begreppet ett mikroögonblick. Den moderna användaren behöver en omedelbar lösning på sitt problem. Google började prata om detta för några år sedan: företaget kallade sådana användaråtgärder för mikroögonblick. Användaren blir distraherad, stänger applikationen av misstag, förstår inte vad som krävs av honom, loggar in igen en dag senare, glömmer igen och följer sedan länken som en vän skickade honom i messengern. Och alla dessa sessioner kan inte ta mer än 20 sekunder.
Så vi började försöka lägga upp supporttjänstens arbete så att medarbetarna nästan i realtid kunde förstå vad problemet var. När en person kommer till supportsidan och börjar skriva sin fråga, kan vi fastställa problemets kärna, känna till hans bana - de senaste 100 händelserna. Tidigare automatiserade vi distributionen av alla supportförfrågningar i kategorier med hjälp av ML-analys av texterna för supportförfrågningar. Trots framgången med kategoriseringen, när 87 % av alla förfrågningar är korrekt fördelade i en av de 13 kategorierna, är det arbete med banor som automatiskt kan hitta den mest lämpliga lösningen för användarens situation.
Vi kan inte släppa uppdateringar snabbt, men vi kan märka problemet och, om användaren följer scenariot som vi redan har sett, skicka honom ett push-meddelande.
Vi ser att uppgiften att optimera en applikation kräver rika verktyg för att studera användarbanor. Genom att känna till alla vägar som användarna tar kan du bana de nödvändiga vägarna, och med hjälp av anpassat innehåll, push-meddelanden och adaptiva UI-element "i handen" leder användaren till riktade åtgärder som bäst passar hans behov och ger pengar , data och annat värde för ditt företag.
Vad ska man notera
- Att studera användarkonvertering endast med hjälp av trattar som exempel innebär att förlora den rika information som själva applikationen ger oss.
- Retentioneering-analys av användarbanor på grafer hjälper dig att se vilka funktioner du använder för att behålla användare eller till exempel uppmuntra dem att prenumerera.
- Retentioneering-verktyg hjälper automatiskt, i realtid, att spåra mönster som indikerar användarproblem i applikationen, hitta och stänga buggar där de var svåra att märka.
- De hjälper till att hitta icke-uppenbara mönster av användarbeteende.
- Retentioneering-verktyg gör det möjligt att bygga automatiserade ML-verktyg för att förutsäga viktiga användarhändelser och mätvärden: användarförlust, LTV och många andra mätvärden som enkelt kan avgöras i grafen.
Vi bygger en gemenskap kring Retentioneering för fritt utbyte av idéer. Du kan tänka på verktygen vi utvecklar som ett språk där analytiker och produkter från olika mobil- och webbapplikationer kan utbyta insikter, bästa tekniker och metoder. Du kan lära dig hur du använder dessa verktyg i kursen Binärt distrikt.
Källa: will.com