At holde en bruger i en mobilapplikation er en hel videnskab. Forfatteren af kurset beskrev dets grundlæggende i vores artikel om VC.ru Maxim Godzi, Head of Machine Learning hos App in the Air. Maxim fortæller om de værktøjer, der er udviklet i virksomheden ved at bruge eksemplet med arbejde med analyse og optimering af en mobilapplikation. Denne systematiske tilgang til produktforbedring, udviklet i App in the Air, kaldes Retentioneering. Du kan bruge disse værktøjer i dit produkt: nogle af dem er inde på GitHub.
App in the Air er en applikation med mere end 3 millioner aktive brugere rundt om i verden, hvormed du kan spore flyafgange, få information om ændringer i afgangs-/landingstider, check-in og lufthavnskarakteristika.
Fra tragt til bane
Alle udviklingsteams bygger en onboarding-tragt (en proces rettet mod brugeraccept af produktet). Dette er det første trin, der hjælper dig med at se hele systemet fra oven og finde applikationsproblemer. Men efterhånden som produktet udvikler sig, vil du mærke begrænsningerne ved denne tilgang. Ved at bruge en simpel tragt kan du ikke se ikke-indlysende vækstpunkter for et produkt. Formålet med tragten er at give et generelt kig på stadierne af brugere i applikationen, for at vise dig normens metrik. Men tragten vil forsigtigt skjule afvigelser fra normen mod åbenlyse problemer eller tværtimod speciel brugeraktivitet.
Hos App in the Air byggede vi vores egen tragt, men på grund af produktets specifikationer endte vi med et timeglas. Så besluttede vi at udvide tilgangen og bruge den rige information, som selve applikationen giver os.
Når du bygger en tragt, mister du brugerens onboarding-baner. Baner består af en sekvens af handlinger fra brugeren og selve applikationen (for eksempel at sende en push-meddelelse).
Ved hjælp af tidsstempler kan du meget nemt rekonstruere brugerens bane og lave en graf ud af den for hver af dem. Selvfølgelig er der mange grafer. Derfor skal du gruppere lignende brugere. For eksempel kan du arrangere alle brugere efter tabelrækker og angive, hvor ofte de bruger en bestemt funktion.
Ud fra en sådan tabel lavede vi en matrix og grupperede brugere efter hyppighed af brug af funktioner, det vil sige efter noder i grafen. Dette er normalt det første skridt mod indsigt: For eksempel vil du allerede på dette stadium se, at nogle brugere slet ikke bruger nogle af funktionerne. Da vi lavede frekvensanalysen, begyndte vi at undersøge, hvilke noder på grafen der er de “største”, altså hvilke sider brugerne besøger oftest. Kategorier, der er fundamentalt forskellige efter et eller andet kriterium, der er vigtigt for dig, fremhæves straks. Her er for eksempel to klynger af brugere, som vi delte ud fra abonnementsbeslutningen (der var 16 klynger i alt).
Sådan bruges det
Ved at se på dine brugere på denne måde, kan du se, hvilke funktioner du bruger til at beholde dem eller for eksempel få dem til at tilmelde sig. Matricen vil naturligvis også vise indlysende ting. For eksempel at de, der har købt et abonnement, besøgte abonnementsskærmen. Men udover dette kan du også finde mønstre, som du ellers aldrig ville have kendt til.
Så vi fandt helt ved et uheld en gruppe brugere, der tilføjer en flyrejse, aktivt sporer den i løbet af dagen og så forsvinder i lang tid, indtil de flyver et sted hen igen. Hvis vi analyserede deres adfærd ved hjælp af konventionelle værktøjer, ville vi tro, at de simpelthen ikke var tilfredse med applikationens funktionalitet: hvordan kan vi ellers forklare, at de brugte den i én dag og aldrig vendte tilbage. Men ved hjælp af grafer så vi, at de er meget aktive, det er bare, at al deres aktivitet passer ind i én dag.
Nu er vores hovedopgave at opmuntre en sådan bruger til at oprette forbindelse til sit flyselskabs loyalitetsprogram, mens han bruger vores statistik. I dette tilfælde vil vi importere alle de flyvninger, han køber, og forsøge at presse ham til at tilmelde sig, så snart han køber en ny billet. For at løse dette problem begyndte vi også at samarbejde med Aviasales, Svyaznoy.Travel og andre applikationer. Når deres bruger køber en billet, beder appen dem om at tilføje flyet til App in the Air, og vi ser det med det samme.
Takket være grafen så vi, at 5 % af de personer, der går til abonnementsskærmen, annullerer den. Vi begyndte at analysere sådanne tilfælde og så, at der er en bruger, der går til den første side, starter forbindelsen til sin Google-konto og annullerer den straks, kommer til den første side igen, og så videre fire gange. Først tænkte vi, "Der er tydeligvis noget galt med denne bruger." Og så indså vi, at der højst sandsynligt var en fejl i applikationen. I tragten ville dette blive fortolket som følger: Brugeren kunne ikke lide det sæt tilladelser, som applikationen anmoder om, og han gik.
En anden gruppe fik 5 % af brugerne til at fare vild på skærmen, hvor appen beder dem om at vælge en fra alle kalenderapps på deres smartphone. Brugere ville vælge forskellige kalendere igen og igen og derefter blot afslutte appen. Det viser sig, at der var et UX-problem: efter at en person havde valgt en kalender, skulle de klikke på Udført i øverste højre hjørne. Det er bare ikke alle brugere, der så det.
Første skærm af App in the Air
I vores graf så vi, at omkring 30% af brugerne ikke går ud over den første skærm: Dette skyldes, at vi er ret aggressive med at presse brugeren til at abonnere. På den første skærm beder appen dig om at registrere dig ved hjælp af Google eller Triplt, og der er ingen information om at springe registreringen over. Af dem, der forlader den første skærm, klikker 16 % af brugerne på "Mere" og vender tilbage igen. Vi har fundet ud af, at de leder efter en måde at registrere sig internt i applikationen, og vi vil frigive den i næste opdatering. Derudover klikker 2/3 af dem, der går med det samme, ikke på noget som helst. For at finde ud af, hvad der sker med dem, har vi bygget et varmekort. Det viser sig, at kunder klikker på en liste over appfunktioner, der ikke er klikbare links.
Fang et mikro-øjeblik
Man kan ofte se folk trampe på stier ud til asfaltvejen. Retentioneering er et forsøg på at finde disse stier og om muligt ændre vejene.
Selvfølgelig er det dårligt, at vi lærer af rigtige brugere, men i det mindste begyndte vi automatisk at spore mønstre, der indikerer et brugerproblem i applikationen. Nu modtager produktchefen e-mail-notifikationer, hvis der opstår et stort antal "loops" - når brugeren vender tilbage til den samme skærm igen og igen.
Lad os se på, hvilke mønstre i brugerbaner, der generelt er interessante at kigge efter for at analysere problemer og vækstområder i en applikation:
- Sløjfer og cykler. Sløjferne nævnt ovenfor er, når en begivenhed gentages i brugerens bane, for eksempel kalender-kalender-kalender-kalender. En løkke med mange gentagelser er en klar indikator for et grænsefladeproblem eller utilstrækkelig hændelsesmarkering. En cyklus er også en lukket bane, men i modsætning til en sløjfe inkluderer den mere end én begivenhed, for eksempel: visning af flyvehistorik - tilføjelse af en flyvning - visning af flyvehistorik.
- Flowstoppere - når brugeren på grund af en eller anden forhindring ikke kan fortsætte sin ønskede bevægelse gennem applikationen, for eksempel en skærm med en grænseflade, der ikke er indlysende for klienten. Sådanne hændelser bremser og flytter brugernes bane.
- Bifurkationspunkter er væsentlige begivenheder, hvorefter forløbene for klienter af forskellige typer adskilles. Det er især skærme, der ikke indeholder en direkte overgang eller opfordring til handling til målhandlingen, hvilket effektivt skubber nogle brugere hen imod den. For eksempel vil en skærm, der ikke er direkte relateret til køb af indhold i en applikation, men hvor kunder er tilbøjelige til at købe eller ikke købe indhold, opføre sig anderledes. Bifurkationspunkter kan være punkter med indflydelse på dine brugeres handlinger med et plustegn - de kan påvirke beslutningen om at foretage et køb eller klik, eller et minustegn - de kan bestemme, at efter et par trin vil brugeren forlade applikationen.
- Afbrudte konverteringspunkter er potentielle bifurkationspunkter. Du kan tænke på dem som skærmbilleder, der kunne anmode om en målhandling, men gør det ikke. Dette kan også være et tidspunkt, hvor brugeren har et behov, men vi opfylder det ikke, fordi vi simpelthen ikke kender til det. Baneanalyse bør gøre det muligt at identificere dette behov.
- Distraktionspunkt - skærme/pop-ups, der ikke giver værdi til brugeren, ikke påvirker konvertering og kan "sløre" baner, der distraherer brugeren fra målhandlinger.
- Blinde vinkler er skjulte punkter i applikationen, skærme og funktioner, som er meget svære for brugeren at nå.
- Afløb – punkter, hvor trafikken lækker
Generelt gav den matematiske tilgang os mulighed for at forstå, at klienten bruger applikationen på en helt anden måde, end produktchefer normalt tror, når de forsøger at planlægge et standardbrugsscenarie for brugeren. Når man sidder på kontoret og deltager i de fedeste produktkonferencer, er det stadig meget svært at forestille sig alle de mange virkelige feltforhold, hvor brugeren vil løse sine problemer ved hjælp af applikationen.
Det minder mig om en stor joke. En tester går ind i en bar og bestiller: et glas øl, 2 glas øl, 0 glas øl, 999999999 glas øl, et firben i et glas, -1 glas øl, qwertyuip glas øl. Den første rigtige kunde går ind i baren og spørger, hvor toilettet er. Baren bryder i brand, og alle dør.
Produktanalytikere, dybt fordybet i dette problem, begyndte at introducere begrebet et mikromoment. Den moderne bruger har brug for en øjeblikkelig løsning på deres problem. Google begyndte at tale om dette for et par år siden: virksomheden kaldte sådanne brugerhandlinger for mikro-øjeblikke. Brugeren bliver distraheret, lukker ved et uheld applikationen, forstår ikke, hvad der kræves af ham, logger på igen en dag senere, glemmer igen og følger derefter linket, som en ven sendte ham i messengeren. Og alle disse sessioner kan ikke vare mere end 20 sekunder.
Så vi begyndte at forsøge at sætte arbejdet i supporttjenesten op, så medarbejderne næsten i realtid kunne forstå, hvad problemet var. Når en person kommer til supportsiden og begynder at skrive sit spørgsmål, kan vi bestemme essensen af problemet ved at kende hans bane - de sidste 100 begivenheder. Tidligere automatiserede vi distributionen af alle supportanmodninger i kategorier ved hjælp af ML-analyse af teksterne til supportanmodninger. På trods af succesen med kategorisering, når 87% af alle anmodninger er korrekt fordelt i en af de 13 kategorier, er det arbejde med baner, der automatisk kan finde den bedst egnede løsning til brugerens situation.
Vi kan ikke frigive opdateringer hurtigt, men vi er i stand til at bemærke problemet, og hvis brugeren følger det scenarie, vi allerede har set, skal du sende ham en push-meddelelse.
Vi ser, at opgaven med at optimere en applikation kræver rige værktøjer til at studere brugerbaner. Ydermere, ved at kende alle de veje, som brugerne tager, kan du bane de nødvendige veje, og ved hjælp af tilpasset indhold, push-meddelelser og adaptive UI-elementer "i hånden" føre brugeren til målrettede handlinger, der bedst passer til hans behov og giver penge , data og anden værdi for din virksomhed.
Hvad skal man notere sig
- At studere brugerkonvertering kun ved at bruge tragte som eksempel betyder at miste den rige information, som applikationen selv giver os.
- Retentioneering-analyse af brugerbaner på grafer hjælper dig med at se, hvilke funktioner du bruger til at fastholde brugere eller for eksempel tilskynde dem til at abonnere.
- Retentioneering-værktøjer hjælper automatisk i realtid med at spore mønstre, der indikerer brugerproblemer i applikationen, finde og lukke fejl, hvor de var svære at bemærke.
- De hjælper med at finde ikke-indlysende mønstre for brugeradfærd.
- Retentioneering-værktøjer gør det muligt at bygge automatiserede ML-værktøjer til at forudsige nøglebrugerhændelser og -metrics: brugertab, LTV og mange andre metrics, der nemt kan bestemmes på grafen.
Vi bygger et fællesskab omkring Retentioneering for fri udveksling af ideer. Du kan tænke på de værktøjer, vi udvikler, som et sprog, hvor analytikere og produkter fra forskellige mobil- og webapplikationer kan udveksle indsigt, bedste teknikker og metoder. Du kan lære at bruge disse værktøjer på kurset Binært distrikt.
Kilde: www.habr.com