Kasutaja hoidmine mobiilirakenduses on terve teadus. Kursuse autor kirjeldas selle põhitõdesid meie VC.ru artiklis Maxim Godzi, App in the Air masinõppe juht. Maxim räägib ettevõttes arendatud tööriistadest mobiilirakenduse analüüsi ja optimeerimise töö näitel. Seda süstemaatilist lähenemist toote täiustamisele, mis on välja töötatud rakenduses App in the Air, nimetatakse säilitamiseks. Saate neid tööriistu oma tootes kasutada: mõned neist on sees GitHubis.
App in the Air on üle 3 miljoni aktiivse kasutajaga rakendus üle maailma, millega saad jälgida lende, saada infot väljumis-/maandumisaegade muudatuste, registreerimise ja lennujaama omaduste kohta.
Lehtrist trajektoorini
Kõik arendusmeeskonnad loovad liitumislehtri (protsess, mille eesmärk on toote aktsepteerimine kasutajate poolt). See on esimene samm, mis aitab teil kogu süsteemi ülevalt vaadata ja rakendusprobleeme leida. Kuid toote arenedes tunnete selle lähenemisviisi piiranguid. Lihtsat lehtrit kasutades ei saa te toote puhul näha ebaselgeid kasvupunkte. Lehtri eesmärk on anda üldine ülevaade rakenduse kasutajate etappidest, näidata teile normi mõõdikuid. Kuid lehter peidab ettenägelikult kõrvalekaldeid normist ilmsete probleemide või, vastupidi, kasutaja eritegevuse suunas.
App in the Air'is ehitasime oma lehtri, kuid toote spetsiifika tõttu sattusime liivakellani. Seejärel otsustasime lähenemisviisi laiendada ja kasutada rikkalikku teavet, mida rakendus ise meile annab.
Kui loote lehtri, kaotate kasutaja sisenemise trajektoore. Trajektoorid koosnevad kasutaja ja rakenduse enda tegevuste jadast (näiteks tõuketeate saatmine).
Ajatempleid kasutades saab väga lihtsalt rekonstrueerida kasutaja trajektoori ja teha sellest igaühe kohta graafiku. Graafikuid on muidugi palju. Seetõttu peate sarnased kasutajad rühmitama. Näiteks saate korraldada kõik kasutajad tabeliridade järgi ja loetleda, kui sageli nad teatud funktsiooni kasutavad.
Sellise tabeli põhjal tegime maatriksi ja grupeerisime kasutajad funktsioonide kasutussageduse ehk graafiku sõlmede järgi. Tavaliselt on see esimene samm ülevaate poole: näiteks juba selles etapis näete, et mõned kasutajad ei kasuta mõnda funktsiooni üldse. Sagedusanalüüsi tehes hakkasime uurima, millised graafiku sõlmed on “suurimad”, st milliseid lehti kasutajad kõige sagedamini külastavad. Kohe tõstetakse esile kategooriad, mis on mõne sinu jaoks olulise kriteeriumi järgi põhimõtteliselt erinevad. Siin on näiteks kaks kasutajate klastrit, mille jagasime liitumisotsuse alusel (kokku oli 16 klastrit).
Kuidas seda kasutada
Vaadates oma kasutajaid sel viisil, näete, milliseid funktsioone kasutate nende säilitamiseks või näiteks registreerumiseks. Loomulikult näitab maatriks ka ilmseid asju. Näiteks, et need, kes ostsid tellimuse, külastasid tellimuse ekraani. Kuid peale selle võite leida ka mustreid, millest te muidu kunagi teada poleks saanud.
Nii leidsime täiesti kogemata kasutajate grupi, kes lisavad lennu, jälgivad seda päeva jooksul aktiivselt ja kaovad siis pikaks ajaks, kuni jälle kuhugi lendavad. Kui analüüsiksime nende käitumist tavapäraste vahenditega, arvaks, et nad lihtsalt ei olnud rakenduse funktsionaalsusega rahul: kuidas muidu seletada, et nad kasutasid seda ühe päeva ega naasnud kunagi. Kuid graafikute abil nägime, et nad on väga aktiivsed, lihtsalt kogu nende tegevus mahub ühte päeva.
Nüüd on meie peamine ülesanne julgustada sellist kasutajat meie statistikat kasutades oma lennufirma lojaalsusprogrammiga ühendust võtma. Sel juhul impordime kõik tema ostetud lennud ja proovime sundida teda registreeruma kohe, kui ta uue pileti ostab. Selle probleemi lahendamiseks alustasime koostööd ka Aviasalesi, Svyaznoy.Traveli ja teiste rakendustega. Kui nende kasutaja ostab pileti, palub rakendus tal lisada lend rakendusse App in the Air ja me näeme seda kohe.
Tänu graafikule nägime, et 5% inimestest, kes lähevad tellimuse ekraanile, tühistavad selle. Hakkasime selliseid juhtumeid analüüsima ja nägime, et on kasutaja, kes läheb esimesele lehele, algatab oma Google'i konto ühendamise ja katkestab selle kohe, jõuab uuesti esimesele lehele ja nii neli korda. Alguses arvasime: "Selle kasutajaga on midagi selgelt valesti." Ja siis saime aru, et suure tõenäosusega oli rakenduses viga. Lehtris tõlgendataks seda järgmiselt: kasutajale ei meeldinud rakenduse küsitud õiguste komplekt ja ta lahkus.
Teises rühmas oli 5% kasutajatest eksinud ekraanile, kus rakendus palub neil valida üks kõigist oma nutitelefoni kalendrirakendustest. Kasutajad valisid ikka ja jälle erinevaid kalendreid ja seejärel lihtsalt väljuvad rakendusest. Selgus, et tegemist oli UX-i probleemiga: pärast seda, kui inimene valis kalendri, pidi ta klõpsama paremas ülanurgas nuppu Valmis. Lihtsalt kõik kasutajad seda ei näinud.
Rakenduse App in the Air esimene ekraan
Meie graafikul nägime, et umbes 30% kasutajatest ei jõua esimesest ekraanist kaugemale: see on tingitud asjaolust, et oleme üsna agressiivsed, et sundida kasutajat tellima. Esimesel ekraanil palub rakendus teil registreeruda Google'i või Triplti kaudu ja registreerimise vahelejätmise kohta pole teavet. Esimeselt ekraanilt lahkujatest klõpsab 16% kasutajatest „Veel“ ja naaseb uuesti. Saime teada, et nad otsivad võimalust rakenduses sisemiseks registreerumiseks ja avaldame selle järgmises värskenduses. Lisaks ei kliki 2/3 kohe lahkujatest üldse midagi. Et teada saada, mis nendega toimub, koostasime soojuskaardi. Selgub, et kliendid klõpsavad rakenduse funktsioonide loendil, mis ei ole klikitavad lingid.
Jäädvustage mikrohetk
Tihti võib asfalttee ääres näha inimesi, kes tallavad radu. Retentioneering on katse need rajad üles leida ja võimalusel teid muuta.
Muidugi on halb, et me päris kasutajatelt õpime, kuid vähemalt hakkasime automaatselt jälgima mustreid, mis viitavad rakenduse kasutajaprobleemile. Nüüd saab tootejuht meiliteateid, kui ilmneb suur hulk silmuseid – kui kasutaja naaseb ikka ja jälle samale ekraanile.
Vaatame, milliseid kasutajate trajektooride mustreid on üldiselt huvitav otsida, et analüüsida rakenduse probleeme ja kasvuvaldkondi:
- Silmused ja tsüklid. Eespool mainitud tsüklid on siis, kui üks sündmus kordub kasutaja trajektooril, näiteks kalender-kalender-kalender-kalender. Palju korduv tsükkel näitab selgelt liidese probleemi või ebapiisavat sündmuste märgistust. Tsükkel on samuti suletud trajektoor, kuid erinevalt tsüklist sisaldab see rohkem kui ühte sündmust, näiteks: lennuajaloo vaatamine - lennu lisamine - lennuajaloo vaatamine.
- Flowstoppers - kui kasutaja ei saa mõne takistuse tõttu jätkata soovitud liikumist läbi rakenduse, näiteks ekraani, mille liides pole kliendile ilmne. Sellised sündmused aeglustavad ja nihutavad kasutajate liikumist.
- Bifurkatsioonipunktid on olulised sündmused, mille järel eristuvad erinevat tüüpi klientide trajektoorid. Eelkõige on need ekraanid, mis ei sisalda otsest üleminekut või üleskutset tegevusele sihttoimingule, tõugates mõned kasutajad selle poole. Näiteks mõni ekraan, mis ei ole otseselt seotud rakenduses sisu ostmisega, kuid millel kliendid kalduvad sisu ostma või mitte ostma, käituvad teisiti. Bifurkatsioonipunktid võivad olla teie kasutajate tegevust mõjutavad punktid plussmärgiga – need võivad mõjutada ostu või klõpsamise otsust või miinusmärgiga – need võivad määrata, et mõne sammu järel lahkub kasutaja rakendusest.
- Katkestatud teisenduspunktid on potentsiaalsed bifurkatsioonipunktid. Võite pidada neid ekraanideks, mis võivad suunata sihttoimingu, kuid ärge seda tehke. See võib olla ka hetk, mil kasutajal on vajadus, kuid me ei rahulda seda, sest me lihtsalt ei tea sellest. Trajektoorianalüüs peaks võimaldama selle vajaduse tuvastada.
- Tähelepanelik punkt – ekraanid/hüpikaknad, mis ei paku kasutajale väärtust, ei mõjuta konversiooni ja võivad trajektoore hägustada, juhtides kasutaja tähelepanu sihttoimingutelt kõrvale.
- Pimedad alad on rakenduse, ekraanide ja funktsioonide peidetud punktid, kuhu kasutajal on väga raske jõuda.
- Äravoolud – kohad, kus liiklus lekib
Üldjoontes võimaldas matemaatiline lähenemine mõista, et klient kasutab rakendust hoopis teistmoodi, kui tootejuhid tavaliselt kasutajale mõnd standardset kasutusstsenaariumi kavandades arvavad. Kontoris istudes ja kõige lahedamatel tootekonverentsidel osaledes on endiselt väga raske ette kujutada kõiki tegelikke välitingimusi, milles kasutaja oma probleeme rakendust kasutades lahendab.
See tuletab mulle meelde suurt nalja. Testija astub baari ja tellib: klaas õlut, 2 klaasi õlut, 0 klaasi õlut, 999999999 klaasi õlut, sisalik klaasis, -1 klaas õlut, qwertyuip klaasid õlut. Esimene tõeline klient astub baari ja küsib, kus tualett on. Baar lahvatab leekidesse ja kõik surevad.
Sellesse probleemi sügavalt sukeldunud tooteanalüütikud hakkasid tutvustama mikromomendi mõistet. Kaasaegne kasutaja vajab oma probleemile viivitamatut lahendust. Google hakkas sellest rääkima paar aastat tagasi: ettevõte nimetas selliseid kasutajatoiminguid mikrohetkedeks. Kasutaja hajub, sulgeb kogemata rakenduse, ei saa aru, mida temalt nõutakse, logib päev hiljem uuesti sisse, unustab uuesti ja järgib siis linki, mille sõber talle messengeris saatis. Ja kõik need seansid ei tohi kesta kauem kui 20 sekundit.
Nii hakkasimegi püüdma tugiteenistuse tööd sättida nii, et töötajad saaksid peaaegu reaalajas aru, milles probleem on. Selleks ajaks, kui inimene tuleb tugilehele ja hakkab oma küsimust kirjutama, saame tema trajektoori teades kindlaks teha probleemi olemuse – viimased 100 sündmust. Varem automatiseerisime kõigi tugitaotluste jaotamise kategooriatesse, kasutades tugitaotluste tekstide ML-analüüsi. Vaatamata kategoriseerimise edule, kui 87% kõigist päringutest on õigesti jagatud ühte 13 kategooriast, suudab just töö trajektooridega automaatselt leida kasutaja olukorrale sobivaima lahenduse.
Me ei saa värskendusi kiiresti välja anda, kuid suudame probleemi märgata ja kui kasutaja järgib meie poolt juba nähtud stsenaariumi, saadame talle tõuketeate.
Näeme, et rakenduse optimeerimise ülesanne nõuab kasutajate trajektooride uurimiseks rikkalikke tööriistu. Lisaks, teades kõiki kasutajate teid, saate sillutada vajalikke teid ning kohandatud sisu abil juhivad tõukemärguanded ja adaptiivsed kasutajaliidese elemendid „käe kaudu“ kasutaja sihipäraste tegevusteni, mis vastavad kõige paremini tema vajadustele ja toovad raha. , andmeid ja muud väärtust teie ettevõtte jaoks.
Mida tähele panna
- Kasutajate konversioonide uurimine, kasutades näitena ainult lehtreid, tähendab, et kaotame rikkaliku teabe, mida rakendus ise meile annab.
- Kasutajate trajektooride säilitamise analüüs graafikutel aitab teil näha, milliseid funktsioone kasutate kasutajate säilitamiseks või näiteks nende tellimise julgustamiseks.
- Säilitustööriistad aitavad automaatselt, reaalajas jälgida mustreid, mis viitavad kasutaja probleemidele rakenduses, leida ja sulgeda vead, kus neid oli raske märgata.
- Need aitavad leida ebaselgeid kasutaja käitumismustreid.
- Säilitamise tööriistad võimaldavad luua automaatseid ML-tööriistu, mis võimaldavad ennustada peamisi kasutajasündmusi ja mõõdikuid: kasutajakaotus, LTV ja paljud muud mõõdikud, mida on graafikul lihtne määrata.
Ehitame kinnihoidmise ümber kogukonna vabaks ideede vahetamiseks. Meie arendatavaid tööriistu võib pidada keeleks, milles analüütikud ning erinevate mobiili- ja veebirakenduste tooted saavad teadmisi, parimaid tehnikaid ja meetodeid vahetada. Kursusel saate õppida, kuidas neid tööriistu kasutada Binaarne ringkond.
Allikas: www.habr.com