Mbajtja e një përdoruesi në një aplikacion celular është një shkencë e tërë. Autori i kursit përshkroi bazat e tij në artikullin tonë në VC.ru Maxim Godzi, Drejtor i Mësimit të Makinerisë në App in the Air. Maxim flet për mjetet e zhvilluara në kompani duke përdorur shembullin e punës për analizën dhe optimizimin e një aplikacioni celular. Kjo qasje sistematike për përmirësimin e produktit, e zhvilluar në App in the Air, quhet Retentioneering. Ju mund t'i përdorni këto mjete në produktin tuaj: disa prej tyre janë në në GitHub.
App in the Air është një aplikacion me më shumë se 3 milionë përdorues aktivë në mbarë botën, me të cilin mund të gjurmoni fluturimet, të merrni informacione për ndryshimet në orarin e nisjes/uljes, check-in dhe karakteristikat e aeroportit.
Nga hinka në trajektore
Të gjitha ekipet e zhvillimit ndërtojnë një gyp inboarding (një proces që synon pranimin e produktit nga përdoruesi). Ky është hapi i parë që ju ndihmon të shikoni të gjithë sistemin nga lart dhe të gjeni problemet e aplikimit. Por ndërsa produkti zhvillohet, do të ndjeni kufizimet e kësaj qasjeje. Duke përdorur një gyp të thjeshtë, nuk mund të shihni pika jo të dukshme të rritjes për një produkt. Qëllimi i gypit është të japë një vështrim të përgjithshëm në fazat e përdoruesve në aplikacion, për t'ju treguar matjet e normës. Por gypi do të fshehë me kujdes devijimet nga norma drejt problemeve të dukshme ose, përkundrazi, aktivitetit të veçantë të përdoruesit.
Në App in the Air, ne ndërtuam gypin tonë, por për shkak të specifikave të produktit, përfunduam me një orë rëre. Më pas vendosëm të zgjerojmë qasjen dhe të përdorim informacionin e pasur që na jep vetë aplikacioni.
Kur ndërtoni një gyp, ju humbni përdoruesin duke hyrë në trajektoret. Trajektoret përbëhen nga një sekuencë veprimesh nga përdoruesi dhe vetë aplikacioni (për shembull, dërgimi i një njoftimi shtytës).
Duke përdorur stampat kohore, mund të rindërtoni shumë lehtë trajektoren e përdoruesit dhe të bëni një grafik prej saj për secilën prej tyre. Sigurisht, ka shumë grafikë. Prandaj, duhet të gruponi përdorues të ngjashëm. Për shembull, ju mund t'i rregulloni të gjithë përdoruesit sipas rreshtave të tabelës dhe të listoni sa shpesh përdorin një funksion të caktuar.
Bazuar në një tabelë të tillë, ne bëmë një matricë dhe grupuam përdoruesit sipas shpeshtësisë së përdorimit të funksioneve, domethënë sipas nyjeve në grafik. Ky është zakonisht hapi i parë drejt njohurive: për shembull, tashmë në këtë fazë do të shihni që disa përdorues nuk i përdorin fare disa nga funksionet. Kur bëmë analizën e frekuencës, filluam të studiojmë se cilat nyje në grafik janë "më të mëdhatë", domethënë cilat faqe vizitojnë përdoruesit më shpesh. Kategoritë që janë thelbësisht të ndryshme sipas disa kritereve që janë të rëndësishme për ju, theksohen menjëherë. Këtu, për shembull, janë dy grupime përdoruesish që i kemi ndarë në bazë të vendimit të abonimit (gjithsej ishin 16 grupe).
Si ta përdorni
Duke i parë përdoruesit në këtë mënyrë, mund të shihni se cilat veçori përdorni për t'i mbajtur ata ose, për shembull, t'i detyroni ata të regjistrohen. Natyrisht, matrica do të tregojë gjithashtu gjëra të dukshme. Për shembull, që ata që blenë një abonim vizituan ekranin e abonimit. Por përveç kësaj, mund të gjeni edhe modele për të cilat nuk do t'i kishit ditur kurrë.
Pra, ne gjetëm krejtësisht rastësisht një grup përdoruesish që shtojnë një fluturim, e gjurmojnë atë në mënyrë aktive gjatë gjithë ditës dhe më pas zhduken për një kohë të gjatë derisa të fluturojnë përsëri diku. Nëse do të analizonim sjelljen e tyre duke përdorur mjete konvencionale, do të mendonim se ata thjesht nuk ishin të kënaqur me funksionalitetin e aplikacionit: si mund ta shpjegojmë ndryshe që e përdorën atë për një ditë dhe nuk u kthyen më. Por me ndihmën e grafikëve pamë që ata janë shumë aktivë, thjesht i gjithë aktiviteti i tyre përshtatet në një ditë.
Tani detyra jonë kryesore është të inkurajojmë një përdorues të tillë që të lidhet me programin e besnikërisë së linjës së tij ajrore ndërkohë që ai përdor statistikat tona. Në këtë rast, ne do të importojmë të gjitha fluturimet që ai blen dhe do të përpiqemi ta shtyjmë të regjistrohet sapo të blejë një biletë të re. Për të zgjidhur këtë problem, ne gjithashtu filluam të bashkëpunojmë me Aviasales, Svyaznoy.Travel dhe aplikacione të tjera. Kur përdoruesi i tyre blen një biletë, aplikacioni i kërkon të shtojnë fluturimin te App in the Air dhe ne e shohim atë menjëherë.
Falë grafikut, pamë që 5% e njerëzve që shkojnë në ekranin e abonimit e anulojnë atë. Ne filluam të analizojmë raste të tilla dhe pamë që ka një përdorues që shkon në faqen e parë, inicon lidhjen e llogarisë së tij në Google dhe e anulon menjëherë, shkon përsëri në faqen e parë, e kështu me radhë katër herë. Në fillim menduam, "Diçka nuk është në rregull me këtë përdorues." Dhe më pas kuptuam se, ka shumë të ngjarë, kishte një gabim në aplikacion. Në gyp, kjo do të interpretohej si më poshtë: përdoruesit nuk i pëlqeu grupi i lejeve që kërkon aplikacioni dhe ai u largua.
Një grup tjetër kishte 5% të përdoruesve që humbën në ekran, ku aplikacioni i kërkon të zgjedhin një nga të gjitha aplikacionet e kalendarit në smartfonin e tyre. Përdoruesit do të zgjidhnin kalendarët e ndryshëm pa pushim dhe më pas thjesht dilnin nga aplikacioni. Rezulton se kishte një problem UX: pasi një person zgjodhi një kalendar, ai duhej të klikonte "U krye" në këndin e sipërm djathtas. Vetëm se jo të gjithë përdoruesit e panë atë.
Ekrani i parë i aplikacionit në ajër
Në grafikun tonë, pamë që rreth 30% e përdoruesve nuk shkojnë përtej ekranit të parë: kjo për faktin se ne jemi mjaft agresivë në shtyrjen e përdoruesit për t'u abonuar. Në ekranin e parë, aplikacioni ju kërkon të regjistroheni duke përdorur Google ose Triplt dhe nuk ka asnjë informacion për kapërcimin e regjistrimit. Nga ata që largohen nga ekrani i parë, 16% e përdoruesve klikojnë "Më shumë" dhe kthehen përsëri. Kemi zbuluar se ata po kërkojnë një mënyrë për t'u regjistruar brenda në aplikacion dhe do ta lëshojmë në përditësimin e ardhshëm. Për më tepër, 2/3 e atyre që largohen menjëherë nuk klikojnë fare. Për të zbuluar se çfarë po ndodh me ta, ne ndërtuam një hartë të nxehtësisë. Rezulton se klientët po klikojnë në një listë të veçorive të aplikacionit që nuk janë lidhje të klikueshme.
Kapni një mikro-moment
Shpesh mund të shohësh njerëz që shkelin shtigjet pranë rrugës së asfaltuar. Mbajtja është një përpjekje për të gjetur këto shtigje dhe, nëse është e mundur, për të ndryshuar rrugët.
Sigurisht, është keq që mësojmë nga përdoruesit e vërtetë, por të paktën filluam të gjurmojmë automatikisht modelet që tregojnë një problem përdoruesi në aplikacion. Tani menaxheri i produktit merr njoftime me email nëse ndodhin një numër i madh "loops" - kur përdoruesi kthehet në të njëjtin ekran pa pushim.
Le të shohim se cilat modele në trajektoret e përdoruesve janë përgjithësisht interesante për t'u kërkuar për të analizuar problemet dhe fushat e rritjes së një aplikacioni:
- Sythe dhe cikle. Llojet e përmendura më sipër janë kur një ngjarje përsëritet në trajektoren e përdoruesit, për shembull, calendar-calendar-calendar-calendar. Një lak me shumë përsëritje është një tregues i qartë i një problemi të ndërfaqes ose shënimi i pamjaftueshëm i ngjarjes. Një cikël është gjithashtu një trajektore e mbyllur, por ndryshe nga një cikli përfshin më shumë se një ngjarje, për shembull: shikimi i historisë së fluturimit - shtimi i një fluturimi - shikimi i historisë së fluturimit.
- Flowstoppers - kur përdoruesi, për shkak të ndonjë pengese, nuk mund të vazhdojë lëvizjen e tij të dëshiruar përmes aplikacionit, për shembull, një ekran me një ndërfaqe që nuk është e dukshme për klientin. Ngjarje të tilla ngadalësojnë dhe ndryshojnë trajektoren e përdoruesve.
- Pikat e bifurkacionit janë ngjarje të rëndësishme pas të cilave ndahen trajektoret e klientëve të llojeve të ndryshme. Në veçanti, këto janë ekrane që nuk përmbajnë një tranzicion të drejtpërdrejtë ose thirrje për veprim në veprimin e synuar, duke shtyrë efektivisht disa përdorues drejt tij. Për shembull, disa ekrane që nuk lidhen drejtpërdrejt me blerjen e përmbajtjes në një aplikacion, por në të cilin klientët janë të prirur të blejnë ose të mos blejnë përmbajtje, do të sillen ndryshe. Pikat e bifurkacionit mund të jenë pika ndikimi në veprimet e përdoruesve tuaj me një shenjë plus - ato mund të ndikojnë në vendimin për të bërë një blerje ose klikim, ose një shenjë minus - ato mund të përcaktojnë që pas disa hapash përdoruesi do të largohet nga aplikacioni.
- Pikat e ndërprera të konvertimit janë pika të mundshme bifurkacioni. Ju mund t'i mendoni ato si ekrane që mund të nxisin një veprim të synuar, por jo. Kjo mund të jetë gjithashtu një moment në kohë kur përdoruesi ka një nevojë, por ne nuk e plotësojmë atë sepse thjesht nuk dimë për të. Analiza e trajektores duhet të lejojë që kjo nevojë të identifikohet.
- Pika e shpërqendrimit - ekranet / dritaret kërcyese që nuk i japin vlerë përdoruesit, nuk ndikojnë në konvertim dhe mund të "turbullojnë" trajektoret, duke e shkëputur përdoruesin nga veprimet e synuara.
- Pikat e verbër janë pika të fshehura të aplikacionit, ekranet dhe veçoritë që janë shumë të vështira për t'u arritur nga përdoruesi.
- Kullimet - pikat ku rrjedh trafiku
Në përgjithësi, qasja matematikore na lejoi të kuptojmë se klienti e përdor aplikacionin në një mënyrë krejtësisht të ndryshme nga sa mendojnë zakonisht menaxherët e produkteve kur përpiqen të planifikojnë një skenar standard të përdorimit për përdoruesin. I ulur në zyrë dhe duke marrë pjesë në konferencat më interesante të produkteve, është ende shumë e vështirë të imagjinohet gjithë larmia e kushteve reale në terren në të cilat përdoruesi do të zgjidhë problemet e tij duke përdorur aplikacionin.
Kjo më kujton një shaka të madhe. Një testues hyn në një bar dhe porosit: një gotë birrë, 2 gota birrë, 0 gota birrë, 999999999 gota birrë, një hardhucë në një gotë, -1 gotë birrë, gota qwertyuip birrë. Klienti i parë i vërtetë hyn në lokal dhe pyet se ku është banja. Lokali shpërthen në flakë dhe të gjithë vdesin.
Analistët e produkteve, të zhytur thellë në këtë problem, filluan të prezantojnë konceptin e një mikromomenti. Përdoruesi modern ka nevojë për një zgjidhje të menjëhershme për problemin e tyre. Google filloi të flasë për këtë disa vite më parë: kompania i quajti veprime të tilla të përdoruesve mikro-momente. Përdoruesi shpërqendrohet, mbyll aksidentalisht aplikacionin, nuk kupton se çfarë kërkohet prej tij, hyn përsëri një ditë më vonë, harron përsëri dhe më pas ndjek lidhjen që një mik i ka dërguar në messenger. Dhe të gjitha këto seanca mund të zgjasin jo më shumë se 20 sekonda.
Kështu filluam të përpiqeshim të konfiguronim punën e shërbimit mbështetës në mënyrë që punonjësit të kuptonin se cili ishte problemi pothuajse në kohë reale. Në kohën kur një person vjen në faqen e mbështetjes dhe fillon të shkruajë pyetjen e tij, ne mund të përcaktojmë thelbin e problemit, duke ditur trajektoren e tij - 100 ngjarjet e fundit. Më parë, ne automatizuam shpërndarjen e të gjitha kërkesave për mbështetje në kategori duke përdorur analizën ML të teksteve të kërkesave për mbështetje. Pavarësisht suksesit të kategorizimit, kur 87% e të gjitha kërkesave shpërndahen saktë në një nga 13 kategoritë, është puna me trajektoret që mund të gjejë automatikisht zgjidhjen më të përshtatshme për situatën e përdoruesit.
Ne nuk mund të lëshojmë përditësime shpejt, por jemi në gjendje ta vërejmë problemin dhe, nëse përdoruesi ndjek skenarin që kemi parë tashmë, i dërgojmë atij një njoftim push.
Ne shohim se detyra e optimizimit të një aplikacioni kërkon mjete të pasura për të studiuar trajektoret e përdoruesve. Më tej, duke ditur të gjitha shtigjet që ndjekin përdoruesit, ju mund të hapni shtigjet e nevojshme dhe me ndihmën e përmbajtjes së personalizuar, njoftimet shtytëse dhe elementët përshtatës të UI "nga dora" e çojnë përdoruesin drejt veprimeve të synuara që i përshtaten më mirë nevojave të tij dhe sjellin para. , të dhëna dhe vlera të tjera për biznesin tuaj.
Çfarë duhet të kihet parasysh
- Të studiosh konvertimin e përdoruesve vetëm duke përdorur gypat si shembull do të thotë të humbasësh informacionin e pasur që na jep vetë aplikacioni.
- Analiza ruajtëse e trajektoreve të përdoruesve në grafikë ju ndihmon të shihni se cilat veçori përdorni për të mbajtur përdoruesit ose, për shembull, për t'i inkurajuar ata të abonohen.
- Mjetet e mbajtjes ndihmojnë automatikisht, në kohë reale, të gjurmojnë modelet që tregojnë problemet e përdoruesit në aplikacion, të gjejnë dhe mbyllin defektet ku ishin të vështira për t'u vërejtur.
- Ato ndihmojnë për të gjetur modele jo të dukshme të sjelljes së përdoruesit.
- Mjetet e ruajtjes bëjnë të mundur ndërtimin e mjeteve të automatizuara të ML për parashikimin e ngjarjeve dhe matjeve kryesore të përdoruesve: humbja e përdoruesit, LTV dhe shumë metrika të tjera që përcaktohen lehtësisht në grafik.
Ne po ndërtojmë një komunitet rreth Retentioneering për shkëmbimin e lirë të ideve. Ju mund t'i mendoni mjetet që po zhvillojmë si një gjuhë në të cilën analistët dhe produktet nga aplikacione të ndryshme celulare dhe ueb mund të shkëmbejnë njohuri, teknika dhe metoda më të mira. Ju mund të mësoni se si t'i përdorni këto mjete në kurs Distrikti Binar.
Burimi: www.habr.com