Išlaikyti vartotoją mobiliojoje programoje yra visas mokslas. Kurso autorius aprašė jo pagrindus mūsų straipsnyje VC.ru Maksimas Godzi, „App in the Air“ mašininio mokymosi vadovas. Maksimas pasakoja apie įmonėje kuriamus įrankius naudodamas mobiliosios aplikacijos analizės ir optimizavimo darbo pavyzdį. Šis sistemingas požiūris į produkto tobulinimą, sukurtas programoje „App in the Air“, vadinamas „Retentioneering“. Šiuos įrankius galite naudoti savo gaminyje: kai kurie iš jų yra „GitHub“.
App in the Air – tai programa, turinti daugiau nei 3 milijonus aktyvių vartotojų visame pasaulyje, su kuria galite sekti skrydžius, gauti informaciją apie išvykimo/nusileidimo laiko pasikeitimus, registraciją ir oro uosto charakteristikas.
Nuo piltuvo iki trajektorijos
Visos kūrimo komandos sukuria įjungimo piltuvą (procesą, kuriuo siekiama, kad vartotojas priimtų produktą). Tai pirmasis žingsnis, padedantis pažvelgti į visą sistemą iš viršaus ir rasti programos problemas. Tačiau gaminiui tobulėjant pajusite šio požiūrio apribojimus. Naudojant paprastą piltuvą, nematote neakivaizdžių produkto augimo taškų. Piltuvo paskirtis – pateikti bendrą vaizdą apie programos naudotojų etapus, parodyti normos metriką. Tačiau piltuvėlis apdairiai paslėps nukrypimus nuo normos iki akivaizdžių problemų arba, priešingai, specialios vartotojo veiklos.
Programoje „App in the Air“ susikūrėme savo piltuvėlį, tačiau dėl produkto specifikos gavome smėlio laikrodį. Tada nusprendėme išplėsti požiūrį ir panaudoti turtingą informaciją, kurią mums suteikia pati programa.
Kai sukuriate kanalą, prarandate naudotojo prisijungimo trajektorijas. Trajektorijas sudaro vartotojo ir pačios programos veiksmų seka (pavyzdžiui, iš karto išsiųstas pranešimas).
Naudodami laiko žymas galite labai lengvai atkurti vartotojo trajektoriją ir sudaryti iš jos kiekvieno iš jų grafiką. Žinoma, yra daug grafikų. Todėl reikia sugrupuoti panašius vartotojus. Pavyzdžiui, galite išdėstyti visus vartotojus pagal lentelės eilutes ir nurodyti, kaip dažnai jie naudoja tam tikrą funkciją.
Remdamiesi tokia lentele, sudarėme matricą ir sugrupavome vartotojus pagal funkcijų naudojimo dažnumą, tai yra pagal grafiko mazgus. Paprastai tai yra pirmas žingsnis įžvalgų link: pavyzdžiui, jau šiame etape pamatysite, kad dalis vartotojų kai kurių funkcijų visiškai nenaudoja. Atlikdami dažnio analizę, pradėjome tirti, kurie grafiko mazgai yra „didžiausi“, tai yra, kuriuose puslapiuose vartotojai lankosi dažniausiai. Iš karto išryškinamos kategorijos, kurios iš esmės skiriasi pagal kokį nors jums svarbų kriterijų. Pavyzdžiui, yra dvi vartotojų grupės, kurias suskirstėme pagal prenumeratos sprendimą (iš viso buvo 16 grupių).
Kaip ja naudotis
Taip žiūrėdami į savo vartotojus galite pamatyti, kokias funkcijas naudojate, kad juos išlaikytumėte arba, pavyzdžiui, priverstumėte juos prisiregistruoti. Natūralu, kad matrica parodys ir akivaizdžius dalykus. Pavyzdžiui, kad prenumeratą įsigiję asmenys apsilankė prenumeratos ekrane. Be to, taip pat galite rasti modelių, apie kuriuos niekada nežinotumėte.
Taigi visiškai netyčia radome grupę vartotojų, kurie prideda skrydį, aktyviai jį seka visą dieną ir po to dingsta ilgam, kol vėl kažkur išskrenda. Jei išanalizuotume jų elgesį naudodami įprastus įrankius, manytume, kad jie tiesiog nebuvo patenkinti programos funkcionalumu: kaip kitaip paaiškintume, kad jie naudojosi vieną dieną ir niekada negrįžo. Tačiau grafikų pagalba pamatėme, kad jie labai aktyvūs, tiesiog visa jų veikla telpa į vieną dieną.
Dabar mūsų pagrindinė užduotis yra paskatinti tokį vartotoją prisijungti prie savo aviakompanijos lojalumo programos, kol jis naudojasi mūsų statistika. Tokiu atveju importuosime visus jo perkamus skrydžius ir stengsimės priversti jį užsiregistruoti, kai tik nusipirks naują bilietą. Norėdami išspręsti šią problemą, mes taip pat pradėjome bendradarbiauti su Aviasales, Svyaznoy.Travel ir kitomis programomis. Kai jų vartotojas perka bilietą, programa paragins pridėti skrydį prie „App in the Air“ ir mes tai iškart pamatysime.
Diagramos dėka pamatėme, kad 5% žmonių, kurie apsilanko prenumeratos ekrane, jį atšaukia. Pradėjome analizuoti tokius atvejus ir pamatėme, kad yra vartotojas, kuris nueina į pirmą puslapį, inicijuoja savo Google paskyros prisijungimą ir iškart jį atšaukia, vėl patenka į pirmą puslapį ir taip keturis kartus. Iš pradžių manėme: „Kažkas aiškiai negerai su šiuo vartotoju“. Ir tada supratome, kad greičiausiai programoje yra klaida. Piltuvėlyje tai būtų aiškinama taip: vartotojui nepatiko leidimų rinkinys, kurio prašo programa, ir jis išėjo.
Kitoje grupėje 5 % vartotojų pasiklydo ekrane, kur programa ragina juos pasirinkti vieną iš visų savo išmaniajame telefone esančių kalendoriaus programų. Vartotojai vėl ir vėl pasirinkdavo skirtingus kalendorius ir tiesiog išeidavo iš programos. Pasirodo, buvo UX problema: kai asmuo pasirinko kalendorių, jis turėjo spustelėti Atlikta viršutiniame dešiniajame kampe. Tiesiog ne visi vartotojai tai matė.
Pirmasis „App in the Air“ ekranas
Savo diagramoje matėme, kad apie 30% vartotojų neperžengia pirmojo ekrano ribų: taip yra dėl to, kad mes gana agresyviai verčiame vartotoją užsiprenumeruoti. Pirmajame ekrane programa ragina užsiregistruoti naudojant „Google“ arba „Triplt“, o informacijos apie registracijos praleidimą nėra. Iš tų, kurie palieka pirmąjį ekraną, 16% vartotojų spusteli „Daugiau“ ir grįžta dar kartą. Sužinojome, kad jie ieško būdo, kaip programoje užsiregistruoti viduje, ir mes jį išleisime kitame atnaujinime. Be to, 2/3 išeinančiųjų iš karto visiškai nieko nespaudžia. Norėdami sužinoti, kas su jais vyksta, sukūrėme šilumos žemėlapį. Paaiškėjo, kad klientai spusteli programos funkcijų, kurios nėra spustelėjamos nuorodos, sąrašą.
Užfiksuokite mikro akimirką
Šalia asfaltuoto kelio dažnai galima išvysti takus trypančius žmones. Išlaikymas – tai bandymas surasti šiuos kelius ir, esant galimybei, pakeisti kelius.
Žinoma, blogai, kad mokomės iš tikrų vartotojų, bet bent jau pradėjome automatiškai sekti šablonus, kurie rodo vartotojo problemą programoje. Dabar produkto vadybininkas gauna pranešimus el. paštu, jei įvyksta daug „kilpų“, kai vartotojas vėl ir vėl grįžta į tą patį ekraną.
Pažiūrėkime, kokių modelių naudotojų trajektorijose paprastai įdomu ieškoti norint analizuoti programos problemas ir augimo sritis:
- Kilpos ir ciklai. Aukščiau paminėtos kilpos yra tada, kai vienas įvykis kartojasi vartotojo trajektorijoje, pavyzdžiui, kalendorius-kalendorius-kalendorius-kalendorius. Ciklas su daug pasikartojimo yra aiškus sąsajos problemos arba nepakankamo įvykio žymėjimo rodiklis. Ciklas taip pat yra uždara trajektorija, tačiau, skirtingai nei ciklas, jis apima daugiau nei vieną įvykį, pavyzdžiui: skrydžio istorijos peržiūra - skrydžio pridėjimas - skrydžių istorijos peržiūra.
- Flowstoppers – kai vartotojas dėl kokios nors kliūties negali tęsti norimo judėjimo per programą, pavyzdžiui, ekraną su klientui neaiškia sąsaja. Tokie įvykiai sulėtina ir keičia vartotojų trajektoriją.
- Bifurkacijos taškai yra reikšmingi įvykiai, po kurių išskiriamos skirtingų tipų klientų trajektorijos. Visų pirma, tai yra ekranai, kuriuose nėra tiesioginio perėjimo ar raginimo veikti prie tikslinio veiksmo, o tai veiksmingai skatina kai kuriuos vartotojus jo link. Pavyzdžiui, kai kurie ekranai, kurie nėra tiesiogiai susiję su turinio pirkimu programoje, bet kuriuose klientai yra linkę pirkti arba nepirkti turinio, elgsis kitaip. Bifurkacijos taškai gali turėti įtakos jūsų vartotojų veiksmams su pliuso ženklu – jie gali turėti įtakos apsisprendimui pirkti ar spustelėti, arba minuso ženklą – jie gali nustatyti, kad po kelių žingsnių vartotojas paliks programą.
- Nutraukti konversijos taškai yra galimi bifurkacijos taškai. Galite galvoti apie juos kaip apie ekranus, kurie gali paskatinti tikslinį veiksmą, bet to nedarykite. Tai taip pat gali būti momentas, kai vartotojas turi poreikį, bet mes jo nepatenkiname, nes paprasčiausiai apie tai nežinome. Trajektorijos analizė turėtų leisti tai nustatyti.
- Išsiblaškymo taškas – ekranai/iššokantieji langai, kurie nesuteikia vertės vartotojui, neturi įtakos konversijai ir gali „sulieti“ trajektorijas, atitraukiant vartotoją nuo tikslinių veiksmų.
- Aklosios dėmės yra paslėptos programos, ekranų ir funkcijų taškai, kuriuos vartotojui labai sunku pasiekti.
- Nutekėjimai – taškai, kuriuose nuteka eismas
Apskritai matematinis požiūris leido suprasti, kad klientas programą naudoja visiškai kitaip, nei paprastai galvoja produktų vadybininkai, bandydami suplanuoti kokį nors standartinį vartotojo naudojimo scenarijų. Sėdint biure ir dalyvaujant šauniausiose produktų konferencijose, vis dar labai sunku įsivaizduoti visą realių lauko sąlygų įvairovę, kurioje vartotojas spręs savo problemas naudodamasis programa.
Tai man primena puikų pokštą. Įeina į barą testuotojas ir užsisako: bokalą alaus, 2 bokalus alaus, 0 bokalų alaus, 999999999 bokalus alaus, driežas stiklinėje, -1 bokalą alaus, qwertyuip bokalus alaus. Pirmasis tikras klientas įeina į barą ir klausia, kur yra tualetas. Baras užsidega ir visi miršta.
Produkto analitikai, giliai pasinėrę į šią problemą, pradėjo diegti mikromomento sąvoką. Šiuolaikiniam vartotojui reikia greito savo problemos sprendimo. „Google“ apie tai pradėjo kalbėti prieš keletą metų: tokius vartotojų veiksmus įmonė pavadino mikromomentais. Vartotojas išsiblaško, netyčia uždaro programą, nesupranta, ko iš jo reikalaujama, po dienos vėl prisijungia, vėl pamiršta, o paskui seka nuorodą, kurią draugas jam atsiuntė messengeryje. Ir visos šios sesijos gali trukti ne ilgiau kaip 20 sekundžių.
Taigi pradėjome bandyti sutvarkyti pagalbos tarnybos darbą taip, kad darbuotojai beveik realiu laiku suprastų, kokia yra problema. Tuo metu, kai žmogus ateina į palaikymo puslapį ir pradeda rašyti savo klausimą, žinodami jo trajektoriją – paskutinius 100 įvykių, galime nustatyti problemos esmę. Anksčiau automatizavome visų paramos užklausų paskirstymą į kategorijas, naudodami paramos užklausų tekstų ML analizę. Nepaisant sėkmingo skirstymo į kategorijas, kai 87% visų užklausų teisingai paskirstomi į vieną iš 13 kategorijų, būtent darbas su trajektorijomis gali automatiškai rasti tinkamiausią sprendimą vartotojo situacijai.
Negalime greitai išleisti naujinimų, tačiau galime pastebėti problemą ir, jei vartotojas laikosi jau matyto scenarijaus, išsiųsti jam tiesioginį pranešimą.
Matome, kad programos optimizavimo užduotis reikalauja turtingų įrankių, skirtų vartotojų trajektorijoms tirti. Be to, žinodami visus kelius, kuriais eina vartotojai, galite nutiesti reikiamus kelius, o tinkinto turinio pagalba tiesioginiai pranešimai ir prisitaikantys vartotojo sąsajos elementai „iš rankų“ nukreipia vartotoją į tikslinius veiksmus, kurie geriausiai atitinka jo poreikius ir atneša pinigų. , duomenis ir kitą vertę jūsų verslui.
Į ką atkreipti dėmesį
- Tiriant naudotojų konversiją tik naudojant kanalus kaip pavyzdį, prarandame turtingą informaciją, kurią mums suteikia pati programa.
- Išlaikoma naudotojų trajektorijų analizė diagramose padeda pamatyti, kurias funkcijas naudojate naudotojams išlaikyti arba, pavyzdžiui, paskatinti juos užsiprenumeruoti.
- Išlaikymo įrankiai padeda automatiškai, realiu laiku sekti šablonus, nurodančius vartotojo problemas programoje, rasti ir uždaryti klaidas, kuriose jas sunku pastebėti.
- Jie padeda surasti neakivaizdžius vartotojo elgesio modelius.
- Išlaikymo įrankiai leidžia sukurti automatizuotus ML įrankius, skirtus numatyti pagrindinius naudotojų įvykius ir metrikas: vartotojų praradimą, VTV ir daugelį kitų metrikų, kurios lengvai nustatomos diagramoje.
Kuriame bendruomenę aplink išlaikymą, kad galėtume laisvai keistis idėjomis. Galite galvoti apie mūsų kuriamus įrankius kaip kalbą, kuria analitikai ir produktai iš įvairių mobiliųjų ir žiniatinklio programų gali keistis įžvalgomis, geriausiomis technikomis ir metodais. Kurso metu galite išmokti naudotis šiais įrankiais Dvejetainė apygarda.
Šaltinis: www.habr.com