Å holde en bruker i en mobilapplikasjon er en hel vitenskap. Forfatteren av kurset beskrev det grunnleggende i artikkelen vår på VC.ru Maxim Godzi, leder for maskinlæring hos App in the Air. Maxim snakker om verktøyene utviklet i selskapet ved å bruke eksempelet på arbeid med analyse og optimalisering av en mobilapplikasjon. Denne systematiske tilnærmingen til produktforbedring, utviklet i App in the Air, kalles Retentioneering. Du kan bruke disse verktøyene i produktet ditt: noen av dem er inne på GitHub.
App in the Air er en applikasjon med mer enn 3 millioner aktive brukere over hele verden, som du kan spore flyreiser med, få informasjon om endringer i avgangs-/landingstider, innsjekking og flyplasskarakteristikker.
Fra trakt til bane
Alle utviklingsteam bygger en onboarding-trakt (en prosess rettet mot brukeraksept av produktet). Dette er det første trinnet som hjelper deg å se på hele systemet ovenfra og finne applikasjonsproblemer. Men etter hvert som produktet utvikler seg, vil du føle begrensningene ved denne tilnærmingen. Ved å bruke en enkel trakt kan du ikke se ikke-åpenbare vekstpunkter for et produkt. Hensikten med trakten er å gi en generell titt på stadiene til brukere i applikasjonen, for å vise deg normen. Men trakten vil forsiktig skjule avvik fra normen mot åpenbare problemer eller tvert imot spesiell brukeraktivitet.
Hos App in the Air bygde vi vår egen trakt, men på grunn av produktets spesifikasjoner endte vi opp med et timeglass. Da bestemte vi oss for å utvide tilnærmingen og bruke den rike informasjonen som selve applikasjonen gir oss.
Når du bygger en trakt, mister du brukerens ombordstigningsbaner. Baner består av en sekvens av handlinger av brukeren og selve applikasjonen (for eksempel å sende en push-varsling).
Ved å bruke tidsstempler kan du veldig enkelt rekonstruere brukerens bane og lage en graf av den for hver av dem. Selvfølgelig er det mange grafer. Derfor må du gruppere lignende brukere. Du kan for eksempel ordne alle brukere etter tabellrader og liste opp hvor ofte de bruker en bestemt funksjon.
Basert på en slik tabell laget vi en matrise og grupperte brukere etter bruksfrekvens av funksjoner, det vil si etter noder i grafen. Dette er vanligvis det første steget mot innsikt: for eksempel vil du allerede på dette stadiet se at noen brukere ikke bruker noen av funksjonene i det hele tatt. Da vi gjorde frekvensanalysen begynte vi å studere hvilke noder i grafen som er de «største», det vil si hvilke sider brukerne besøker oftest. Kategorier som er fundamentalt forskjellige i henhold til et kriterium som er viktig for deg, blir umiddelbart fremhevet. Her er det for eksempel to brukerklynger som vi delte ut fra abonnementsbeslutningen (det var totalt 16 klynger).
Hvordan bruke det
Ved å se på brukerne dine på denne måten kan du se hvilke funksjoner du bruker for å beholde dem eller for eksempel få dem til å registrere seg. Naturligvis vil matrisen også vise åpenbare ting. For eksempel at de som kjøpte et abonnement besøkte abonnementsskjermen. Men i tillegg til dette kan du også finne mønstre du aldri ville ha visst om ellers.
Så vi fant helt tilfeldigvis en gruppe brukere som legger til en flyreise, aktivt sporer den gjennom dagen og så forsvinner i lang tid til de flyr et sted igjen. Hvis vi analyserte oppførselen deres ved hjelp av konvensjonelle verktøy, ville vi tro at de rett og slett ikke var fornøyd med funksjonaliteten til applikasjonen: hvordan kan vi ellers forklare at de brukte den i én dag og aldri kom tilbake. Men ved hjelp av grafer så vi at de er veldig aktive, det er bare at all aktiviteten deres passer inn i en dag.
Nå er hovedoppgaven vår å oppmuntre en slik bruker til å koble seg til flyselskapets lojalitetsprogram mens han bruker statistikken vår. I dette tilfellet vil vi importere alle flyreisene han kjøper og prøve å presse ham til å registrere seg så snart han kjøper en ny billett. For å løse dette problemet begynte vi også å samarbeide med Aviasales, Svyaznoy.Travel og andre applikasjoner. Når brukeren deres kjøper en billett, ber appen dem om å legge flyet til App in the Air, og vi ser det med en gang.
Takket være grafen så vi at 5 % av folk som går til abonnementsskjermen kansellerer den. Vi begynte å analysere slike tilfeller, og så at det er en bruker som går til den første siden, starter tilkoblingen av Google-kontoen sin, og umiddelbart kansellerer den, kommer til den første siden igjen, og så videre fire ganger. Først tenkte vi: "Noe er tydeligvis galt med denne brukeren." Og så innså vi at det mest sannsynlig var en feil i applikasjonen. I trakten vil dette bli tolket som følger: brukeren likte ikke settet med tillatelser som applikasjonen ber om, og han dro.
En annen gruppe hadde 5 % av brukerne som gikk seg vill på skjermen der appen ber dem velge en fra alle kalenderappene på smarttelefonen. Brukere ville velge forskjellige kalendere om og om igjen og så bare gå ut av appen. Det viser seg at det var et UX-problem: etter at en person valgte en kalender, måtte de klikke på Ferdig øverst til høyre. Det er bare det at ikke alle brukere så det.
Første skjermbilde av App in the Air
I grafen vår så vi at omtrent 30 % av brukerne ikke går utover den første skjermen: Dette skyldes det faktum at vi er ganske aggressive når det gjelder å presse brukeren til å abonnere. På den første skjermen ber appen deg om å registrere deg med Google eller Triplt, og det er ingen informasjon om å hoppe over registreringen. Av de som forlater den første skjermen, klikker 16 % av brukerne «Mer» og kommer tilbake igjen. Vi har funnet ut at de leter etter en måte å registrere seg internt i applikasjonen og vi vil gi den ut i neste oppdatering. I tillegg klikker 2/3 av de som går umiddelbart ikke på noe i det hele tatt. For å finne ut hva som skjer med dem, bygde vi et varmekart. Det viser seg at kunder klikker på en liste over appfunksjoner som ikke er klikkbare lenker.
Fang et mikroøyeblikk
Man kan ofte se folk tråkke stier ved siden av asfaltveien. Retentioneering er et forsøk på å finne disse stiene og om mulig endre veiene.
Selvfølgelig er det ille at vi lærer av ekte brukere, men vi begynte i det minste automatisk å spore mønstre som indikerer et brukerproblem i applikasjonen. Nå mottar produktsjefen e-postvarsler hvis det oppstår et stort antall "løkker" - når brukeren går tilbake til samme skjerm igjen og igjen.
La oss se på hvilke mønstre i brukerbaner som generelt er interessante å se etter for å analysere problemer og vekstområder i en applikasjon:
- Løkker og sykler. Løkkene nevnt ovenfor er når en hendelse gjentas i brukerens bane, for eksempel kalender-kalender-kalender-kalender. En løkke med mye repetisjon er en klar indikator på et grensesnittproblem eller utilstrekkelig hendelsesmerking. En syklus er også en lukket bane, men i motsetning til en sløyfe inkluderer den mer enn én hendelse, for eksempel: se flyhistorikk - legge til en flytur - se flyhistorikk.
- Flowstoppers - når brukeren på grunn av en eller annen hindring ikke kan fortsette sin ønskede bevegelse gjennom applikasjonen, for eksempel en skjerm med et grensesnitt som ikke er åpenbart for klienten. Slike hendelser bremser ned og forskyver banen til brukere.
- Bifurkasjonspunkter er viktige hendelser hvoretter banene til klienter av forskjellige typer skilles. Spesielt er dette skjermer som ikke inneholder en direkte overgang eller handlingsfremmende oppfordring til målhandlingen, noe som effektivt presser noen brukere mot den. For eksempel vil noen skjermer som ikke er direkte relatert til kjøp av innhold i en applikasjon, men som kunder er tilbøyelige til å kjøpe eller ikke kjøpe innhold på, oppføre seg annerledes. Bifurkasjonspunkter kan være innflytelsespunkter på handlingene til brukerne dine med et plusstegn - de kan påvirke beslutningen om å foreta et kjøp eller klikk, eller et minustegn - de kan fastslå at brukeren etter noen få trinn vil forlate applikasjonen.
- Avbrutt konverteringspunkter er potensielle bifurkasjonspunkter. Du kan tenke på dem som skjermer som kan føre til en målhandling, men ikke gjør det. Dette kan også være et tidspunkt hvor brukeren har et behov, men vi tilfredsstiller det ikke fordi vi rett og slett ikke vet om det. Baneanalyse bør gjøre det mulig å identifisere dette behovet.
- Distraksjonspunkt - skjermer/popup-vinduer som ikke gir verdi til brukeren, som ikke påvirker konverteringen og kan "sløre" baner, og distraherer brukeren fra målhandlinger.
- Blindsoner er skjulte punkter i applikasjonen, skjermer og funksjoner som er svært vanskelig for brukeren å nå.
- Avløp – punkter hvor trafikk lekker
Generelt tillot den matematiske tilnærmingen oss å forstå at klienten bruker applikasjonen på en helt annen måte enn produktsjefer vanligvis tror når de prøver å planlegge et standard bruksscenario for brukeren. Når du sitter på kontoret og deltar på de kuleste produktkonferansene, er det fortsatt veldig vanskelig å forestille seg alle de forskjellige virkelige feltforholdene der brukeren vil løse problemene sine ved å bruke applikasjonen.
Dette minner meg om en flott vits. En tester går inn i en bar og bestiller: et glass øl, 2 glass øl, 0 glass øl, 999999999 glass øl, en øgle i et glass, -1 glass øl, qwertyuip glass øl. Den første ekte kunden går inn i baren og spør hvor toalettet er. Baren bryter opp i flammer og alle dør.
Produktanalytikere, dypt fordypet i dette problemet, begynte å introdusere konseptet med et mikromoment. Den moderne brukeren trenger en umiddelbar løsning på problemet sitt. Google begynte å snakke om dette for noen år siden: selskapet kalte slike brukerhandlinger for mikroøyeblikk. Brukeren blir distrahert, lukker applikasjonen ved et uhell, forstår ikke hva som kreves av ham, logger på igjen en dag senere, glemmer igjen, og følger deretter lenken som en venn sendte ham i messengeren. Og alle disse øktene kan ikke vare mer enn 20 sekunder.
Så vi begynte å prøve å sette opp arbeidet til støttetjenesten slik at ansatte kunne forstå hva problemet var nesten i sanntid. Innen en person kommer til støttesiden og begynner å skrive spørsmålet sitt, kan vi bestemme essensen av problemet ved å kjenne banen hans - de siste 100 hendelsene. Tidligere automatiserte vi distribusjonen av alle støtteforespørsler i kategorier ved å bruke ML-analyse av tekstene til støtteforespørsler. Til tross for suksessen med kategorisering, når 87 % av alle forespørsler er riktig fordelt i en av de 13 kategoriene, er det arbeid med baner som automatisk kan finne den mest passende løsningen for brukerens situasjon.
Vi kan ikke gi ut oppdateringer raskt, men vi er i stand til å legge merke til problemet, og hvis brukeren følger scenariet som vi allerede har sett, send ham en push-varsling.
Vi ser at oppgaven med å optimalisere en applikasjon krever rike verktøy for å studere brukerbaner. Videre, ved å kjenne alle veiene som brukerne tar, kan du bane de nødvendige banene, og ved hjelp av tilpasset innhold, push-varsler og adaptive brukergrensesnittelementer "ved hånden" lede brukeren til målrettede handlinger som best passer hans behov og gir penger , data og annen verdi for virksomheten din.
Hva du bør legge merke til
- Å studere brukerkonvertering kun ved å bruke trakter som eksempel betyr å miste den rike informasjonen som selve applikasjonen gir oss.
- Retentioneering-analyse av brukerbaner på grafer hjelper deg med å se hvilke funksjoner du bruker for å beholde brukere eller for eksempel oppmuntre dem til å abonnere.
- Retentioneering-verktøy hjelper automatisk, i sanntid, å spore mønstre som indikerer brukerproblemer i applikasjonen, finne og lukke feil der de var vanskelige å legge merke til.
- De hjelper til med å finne ikke-opplagte mønstre for brukeratferd.
- Retentioneering-verktøy gjør det mulig å bygge automatiserte ML-verktøy for å forutsi viktige brukerhendelser og beregninger: brukertap, LTV og mange andre beregninger som enkelt kan bestemmes på grafen.
Vi bygger et fellesskap rundt Retentioneering for fri utveksling av ideer. Du kan tenke på verktøyene vi utvikler som et språk der analytikere og produkter fra ulike mobil- og nettapplikasjoner kan utveksle innsikt, beste teknikker og metoder. Du kan lære hvordan du bruker disse verktøyene på kurset Binært distrikt.
Kilde: www.habr.com