Om 'n gebruiker in 'n mobiele toepassing te hou, is 'n hele wetenskap. Die skrywer van die kursus het die basiese beginsels daarvan beskryf in ons artikel op VC.ru Maxim Godzi, hoof van masjienleer by App in the Air. Maxim praat oor die gereedskap wat in die maatskappy ontwikkel is deur die voorbeeld van werk op ontleding en optimalisering van 'n mobiele toepassing te gebruik. Hierdie sistematiese benadering tot produkverbetering, ontwikkel in App in the Air, word Retentioneering genoem. Jy kan hierdie gereedskap in jou produk gebruik: sommige van hulle is in op GitHub.
App in the Air is 'n toepassing met meer as 3 miljoen aktiewe gebruikers regoor die wêreld, waarmee jy vlugte kan naspoor, inligting kan kry oor veranderinge in vertrek-/landtye, inklok- en lughawe-eienskappe.
Van tregter tot trajek
Alle ontwikkelingspanne bou 'n aanboord-tregter ('n proses wat gemik is op gebruikersaanvaarding van die produk). Dit is die eerste stap wat jou help om van bo af na die hele stelsel te kyk en toepassingsprobleme te vind. Maar soos die produk ontwikkel, sal jy die beperkings van hierdie benadering voel. Deur 'n eenvoudige tregter te gebruik, kan jy nie nie-vanselfsprekende groeipunte vir 'n produk sien nie. Die doel van die tregter is om 'n algemene blik op die stadiums van gebruikers in die toepassing te gee, om jou die maatstawwe van die norm te wys. Maar die tregter sal versigtig afwykings van die norm na ooglopende probleme of, inteendeel, spesiale gebruikersaktiwiteit verberg.
By App in the Air het ons ons eie tregter gebou, maar as gevolg van die besonderhede van die produk het ons met 'n uurglas geëindig. Toe het ons besluit om die benadering uit te brei en die ryk inligting te gebruik wat die toepassing self vir ons gee.
Wanneer jy 'n tregter bou, verloor jy die gebruiker-aanboord-bane. Trajekte bestaan uit 'n reeks aksies deur die gebruiker en die toepassing self (byvoorbeeld die stuur van 'n stootkennisgewing).
Deur tydstempels te gebruik, kan jy baie maklik die gebruiker se trajek rekonstrueer en 'n grafiek daarvan maak vir elkeen van hulle. Natuurlik is daar baie grafieke. Daarom moet jy soortgelyke gebruikers groepeer. Byvoorbeeld, jy kan alle gebruikers volgens tabelrye rangskik en lys hoe gereeld hulle 'n sekere funksie gebruik.
Op grond van so 'n tabel het ons 'n matriks gemaak en gebruikers gegroepeer volgens die gebruiksfrekwensie van funksies, dit wil sê volgens nodusse in die grafiek. Dit is gewoonlik die eerste stap na insigte: byvoorbeeld, reeds op hierdie stadium sal jy sien dat sommige gebruikers glad nie van die funksies gebruik nie. Toe ons die frekwensie-analise gedoen het, het ons begin bestudeer watter nodusse in die grafiek die “grootste” is, dit wil sê watter bladsye gebruikers die meeste besoek. Kategorieë wat fundamenteel verskil volgens een of ander maatstaf wat vir jou belangrik is, word dadelik uitgelig. Hier is byvoorbeeld twee groepe gebruikers wat ons verdeel het op grond van die intekeningbesluit (daar was altesaam 16 groepe).
Hoe om dit te gebruik
Deur op hierdie manier na jou gebruikers te kyk, kan jy sien watter kenmerke jy gebruik om hulle te behou of hulle byvoorbeeld te laat aanmeld. Natuurlik sal die matriks ook ooglopende dinge wys. Byvoorbeeld, dat diegene wat 'n intekening gekoop het, die intekeningskerm besoek het. Maar behalwe dit, kan jy ook patrone vind waarvan jy andersins nooit sou geweet het nie.
Ons het dus heeltemal per ongeluk 'n groep gebruikers gevind wat 'n vlug byvoeg, dit aktief deur die dag volg en dan vir 'n lang tyd verdwyn totdat hulle weer iewers heen vlieg. As ons hul gedrag met behulp van konvensionele instrumente ontleed het, sou ons dink dat hulle eenvoudig nie tevrede was met die funksionaliteit van die toepassing nie: hoe anders kan ons verduidelik dat hulle dit vir een dag gebruik het en nooit teruggekeer het nie. Maar met behulp van grafieke het ons gesien dat hulle baie aktief is, dit is net dat al hul aktiwiteit by een dag inpas.
Nou is ons hooftaak om so 'n gebruiker aan te moedig om aan sy lugredery se lojaliteitsprogram te koppel terwyl hy ons statistieke gebruik. In hierdie geval sal ons al die vlugte wat hy koop invoer en hom probeer druk om aan te meld sodra hy 'n nuwe kaartjie koop. Om hierdie probleem op te los, het ons ook begin om saam te werk met Aviasales, Svyaznoy.Travel en ander toepassings. Wanneer hul gebruiker 'n kaartjie koop, vra die toepassing hulle om die vlug by App in the Air te voeg, en ons sien dit dadelik.
Danksy die grafiek het ons gesien dat 5% van mense wat na die intekeningskerm gaan dit kanselleer. Ons het sulke gevalle begin ontleed en gesien dat daar 'n gebruiker is wat na die eerste bladsy gaan, die verbinding van sy Google-rekening inisieer en dit dadelik kanselleer, weer na die eerste bladsy kom, ensovoorts vier keer. Aanvanklik het ons gedink: "Iets is duidelik fout met hierdie gebruiker." En toe besef ons dat daar heel waarskynlik 'n fout in die toepassing was. In die tregter sou dit as volg geïnterpreteer word: die gebruiker het nie van die stel toestemmings gehou wat die toepassing versoek nie, en hy het vertrek.
'n Ander groep het 5% van gebruikers laat verdwaal op die skerm waar die toepassing hulle vra om een uit al die kalendertoepassings op hul slimfoon te kies. Gebruikers sal verskillende kalenders oor en oor kies en dan eenvoudig die toepassing verlaat. Dit blyk dat daar 'n UX-probleem was: nadat 'n persoon 'n kalender gekies het, moes hulle Klaar in die regter boonste hoek klik. Dit is net dat nie alle gebruikers dit gesien het nie.
Eerste skerm van App in the Air
In ons grafiek het ons gesien dat ongeveer 30% van gebruikers nie verder gaan as die eerste skerm nie: dit is te wyte aan die feit dat ons redelik aggressief is om die gebruiker te druk om in te teken. Op die eerste skerm vra die toepassing jou om met Google of Triplt te registreer, en daar is geen inligting oor hoe om registrasie oor te slaan nie. Van diegene wat die eerste skerm verlaat, klik 16% van gebruikers op "Meer" en keer weer terug. Ons het uitgevind dat hulle 'n manier soek om intern in die toepassing te registreer en ons sal dit in die volgende opdatering vrystel. Boonop klik 2/3 van diegene wat dadelik vertrek glad niks. Om uit te vind wat met hulle gebeur, het ons 'n hittekaart gebou. Dit blyk dat klante op 'n lys toepassingskenmerke klik wat nie klikbare skakels is nie.
Vang 'n mikro-oomblik vas
Jy kan gereeld sien hoe mense paaie langs die asfaltpad trap. Retensie is 'n poging om hierdie paaie te vind en, indien moontlik, die paaie te verander.
Natuurlik is dit sleg dat ons by regte gebruikers leer, maar ons het ten minste begin om outomaties patrone op te spoor wat 'n gebruikerprobleem in die toepassing aandui. Nou ontvang die produkbestuurder e-poskennisgewings as 'n groot aantal "lusse" voorkom—wanneer die gebruiker oor en oor na dieselfde skerm terugkeer.
Kom ons kyk na watter patrone in gebruikerstrajekte oor die algemeen interessant is om na te kyk om probleme en groeiareas van 'n toepassing te ontleed:
- Lusse en siklusse. Die lusse hierbo genoem is wanneer een gebeurtenis in die gebruiker se baan herhaal, byvoorbeeld kalender-kalender-kalender-kalender. 'n Lus met baie herhaling is 'n duidelike aanduiding van 'n koppelvlakprobleem of onvoldoende gebeurtenismerk. 'n Siklus is ook 'n geslote trajek, maar anders as 'n lus sluit dit meer as een gebeurtenis in, byvoorbeeld: kyk na vluggeskiedenis - voeg 'n vlug by - kyk vluggeskiedenis.
- Vloeistoppers - wanneer die gebruiker, as gevolg van een of ander hindernis, nie sy gewenste beweging deur die toepassing kan voortsit nie, byvoorbeeld 'n skerm met 'n koppelvlak wat nie vir die kliënt duidelik is nie. Sulke gebeure vertraag en verskuif die trajek van gebruikers.
- Bifurkasiepunte is betekenisvolle gebeurtenisse waarna die bane van kliënte van verskillende tipes geskei word. Dit is veral skerms wat nie 'n direkte oorgang of oproep tot aksie na die teikenaksie bevat nie, wat sommige gebruikers effektief daarheen stoot. Byvoorbeeld, een of ander skerm wat nie direk verband hou met die aankoop van inhoud in 'n toepassing nie, maar waarop kliënte geneig is om inhoud te koop of nie te koop nie, sal anders optree. Verdeelpunte kan punte van invloed wees op die optrede van jou gebruikers met 'n plusteken - dit kan die besluit om 'n aankoop of klik te maak, of 'n minusteken beïnvloed - hulle kan bepaal dat na 'n paar stappe die gebruiker die toepassing sal verlaat.
- Geaborteerde omskakelingspunte is potensiële bifurkasiepunte. Jy kan aan hulle dink as skerms wat 'n teikenaksie kan aanspoor, maar moenie. Dit kan ook 'n tydstip wees wanneer die gebruiker 'n behoefte het, maar ons bevredig dit nie omdat ons eenvoudig nie daarvan weet nie. Trajekanalise moet toelaat dat hierdie behoefte geïdentifiseer kan word.
- Afleidingspunt - skerms/opspringers wat nie waarde aan die gebruiker verskaf nie, nie omskakeling beïnvloed nie en trajekte kan “vervaag”, wat die gebruiker se aandag van teikenaksies aflei.
- Blinde kolle is versteekte punte van die toepassing, skerms en kenmerke wat vir die gebruiker baie moeilik is om te bereik.
- Dreine – punte waar verkeer lek
Oor die algemeen het die wiskundige benadering ons in staat gestel om te verstaan dat die kliënt die toepassing op 'n heeltemal ander manier gebruik as wat produkbestuurders gewoonlik dink wanneer hulle 'n standaardgebruikscenario vir die gebruiker probeer beplan. As jy in die kantoor sit en die coolste produkkonferensies bywoon, is dit steeds baie moeilik om al die verskeidenheid werklike veldtoestande voor te stel waarin die gebruiker sy probleme met die toepassing sal oplos.
Dit laat my dink aan 'n wonderlike grap. 'n Toetser stap by 'n kroeg in en bestel: 'n glas bier, 2 glase bier, 0 glase bier, 999999999 glase bier, 'n akkedis in 'n glas, -1 glas bier, qwertyuip glase bier. Die eerste regte klant stap by die kroeg in en vra waar die toilet is. Die kroeg slaan in vlamme uit en almal sterf.
Produkontleders, diep verdiep in hierdie probleem, het begin om die konsep van 'n mikromoment bekend te stel. Die moderne gebruiker benodig 'n kitsoplossing vir hul probleem. Google het 'n paar jaar gelede hieroor begin praat: die maatskappy het sulke gebruikersaksies mikro-oomblikke genoem. Die gebruiker word afgelei, maak per ongeluk die toepassing toe, verstaan nie wat van hom vereis word nie, meld weer 'n dag later aan, vergeet weer, en volg dan die skakel wat 'n vriend vir hom in die boodskapper gestuur het. En al hierdie sessies kan nie meer as 20 sekondes duur nie.
Ons het dus begin om die werk van die ondersteuningsdiens te probeer opstel sodat werknemers amper intyds kon verstaan wat die probleem was. Teen die tyd dat 'n persoon na die ondersteuningsbladsy kom en sy vraag begin skryf, kan ons die essensie van die probleem bepaal, met kennis van sy trajek - die laaste 100 gebeurtenisse. Voorheen het ons die verspreiding van alle ondersteuningsversoeke in kategorieë geoutomatiseer deur gebruik te maak van ML-ontleding van die tekste van ondersteuningsversoeke. Ten spyte van die sukses van kategorisering, wanneer 87% van alle versoeke korrek in een van die 13 kategorieë versprei is, is dit werk met trajekte wat outomaties die mees geskikte oplossing vir die gebruiker se situasie kan vind.
Ons kan nie opdaterings vinnig vrystel nie, maar ons kan die probleem opmerk en, as die gebruiker die scenario volg wat ons reeds gesien het, stuur vir hom 'n stootkennisgewing.
Ons sien dat die taak om 'n toepassing te optimaliseer ryk gereedskap vereis om gebruikerstrajekte te bestudeer. Verder, deur al die paaie te ken wat gebruikers loop, kan jy die nodige paaie baan, en met behulp van pasgemaakte inhoud, stootkennisgewings en aanpasbare UI-elemente "met die hand" lei die gebruiker na geteikende aksies wat die beste by sy behoeftes pas en geld bring. , data en ander waarde vir jou besigheid.
Wat om kennis te neem
- Om gebruikersomskakeling slegs met behulp van tregters as voorbeeld te bestudeer, beteken dat ons die ryk inligting verloor wat die toepassing self aan ons gee.
- Retensie-analise van gebruikertrajekte op grafieke help jou om te sien watter kenmerke jy gebruik om gebruikers te behou of hulle byvoorbeeld aan te moedig om in te teken.
- Retensie-instrumente help outomaties, intyds, om patrone op te spoor wat gebruikersprobleme in die toepassing aandui, foute te vind en toe te maak waar dit moeilik was om op te let.
- Hulle help om nie-vanselfsprekende patrone van gebruikersgedrag te vind.
- Retensiegereedskap maak dit moontlik om geoutomatiseerde ML-nutsmiddels te bou vir die voorspelling van sleutelgebruikergebeure en statistieke: gebruikerverlies, LTV en baie ander statistieke wat maklik op die grafiek bepaal kan word.
Ons bou 'n gemeenskap rondom Retentioneering vir die vrye uitruil van idees. Jy kan dink aan die gereedskap wat ons ontwikkel as 'n taal waarin ontleders en produkte van verskillende mobiele en webtoepassings insigte, beste tegnieke en metodes kan uitruil. Jy kan in die kursus leer hoe om hierdie hulpmiddels te gebruik Binêre Distrik.
Bron: will.com