Erabiltzailea aplikazio mugikor batean mantentzea zientzia oso bat da. Ikastaroaren egileak bere oinarriak deskribatu zituen VC.ru-n gure artikuluan Maxim Godzi, App in the Air-eko Machine Learning arduraduna. Maximek enpresan garatutako tresnei buruz hitz egiten du mugikorretarako aplikazio baten analisi eta optimizazio lanaren adibidea erabiliz. App in the Air-en garatutako produktuak hobetzeko ikuspegi sistematiko honi Retentioneering deritzo. Tresna hauek erabil ditzakezu zure produktuan: horietako batzuk barne daude GitHub-en.
App in the Air mundu osoko 3 milioi erabiltzaile aktibo baino gehiago dituen aplikazioa da, eta horrekin hegaldien jarraipena egin dezakezu, irteera/lurreratze orduen, fakturazio eta aireportuaren ezaugarrien aldaketei buruzko informazioa jaso dezakezu.
Inbututik ibilbidera
Garapen talde guztiek integrazio-inbutu bat eraikitzen dute (erabiltzaileak produktua onartzera zuzendutako prozesua). Hau da sistema osoa goitik begiratzen eta aplikazioen arazoak aurkitzen laguntzen dizun lehen urratsa. Baina produktua garatzen doan heinean, ikuspegi honen mugak sentituko dituzu. Inbutu soil bat erabiliz, ezin dituzu produktu baten hazkuntza puntu nabariak ez diren ikusi. Inbutuaren helburua aplikazioko erabiltzaileen faseei begirada orokorra ematea da, arauaren neurriak erakusteko. Baina inbutuak zuhurtasunez ezkutatuko ditu arauarekiko desbideratzeak arazo agerikoetarako edo, aitzitik, erabiltzailearen jarduera berezietarako.
App in the Air-n, gure inbutua eraiki genuen, baina produktuaren berezitasunak direla eta, harea erloju batekin amaitu genuen. Orduan, planteamendua zabaltzea eta aplikazioak berak ematen digun informazio aberatsa erabiltzea erabaki genuen.
Inbutu bat eraikitzen duzunean, erabiltzaileak barneratzeko ibilbideak galtzen dituzu. Ibilbideak erabiltzaileak eta aplikazioak berak egindako ekintzen sekuentziaz osatuta daude (adibidez, push jakinarazpena bidaltzea).
Denbora-zigiluak erabiliz, oso erraz berreraiki dezakezu erabiltzailearen ibilbidea eta grafiko bat egin haietako bakoitzarentzat. Noski, grafiko asko daude. Hori dela eta, antzeko erabiltzaileak taldekatu behar dituzu. Adibidez, erabiltzaile guztiak taula-errenkaden arabera antola ditzakezu eta funtzio jakin bat zenbat aldiz erabiltzen duten zerrendatu dezakezu.
Horrelako taula batean oinarrituta, matrize bat egin dugu eta erabiltzaileak funtzioen erabilera maiztasunaren arabera taldekatu ditugu, hau da, grafikoko nodoen arabera. Hau izan ohi da ezagutzarako lehen urratsa: adibidez, fase honetan dagoeneko ikusiko duzu erabiltzaile batzuek ez dituztela funtzio batzuk batere erabiltzen. Maiztasun-analisia egin genuenean, grafikoko zein nodo diren "handienak" aztertzen hasi ginen, hau da, erabiltzaileek gehien bisitatzen dituzten orrialdeak. Zuretzat garrantzitsua den irizpide batzuen arabera funtsean desberdinak diren kategoriak berehala nabarmentzen dira. Hona, adibidez, harpidetzaren erabakiaren arabera banatu ditugun bi erabiltzaile multzo (guztira 16 multzo zeuden).
Nola erabili
Erabiltzaileak horrela ikusita, haiek gordetzeko zein funtzio erabiltzen dituzun ikus dezakezu edo, adibidez, erregistratu ahal izateko. Jakina, matrizeak gauza agerikoak ere erakutsiko ditu. Adibidez, harpidetza bat erosi dutenek harpidetza pantaila bisitatu dutela. Baina honetaz gain, bestela inoiz ezagutuko ez zenituen ereduak ere aurki ditzakezu.
Beraz, ustekabean, hegaldi bat gehitzen duten erabiltzaile talde bat aurkitu dugu, egunean zehar aktiboki jarraipena egiten diona eta, ondoren, denbora luzez desagertuko dira berriro norabait hegan egiten duten arte. Haien portaera ohiko tresnak erabiliz aztertuko bagenu, pentsatuko genuke ez daudela konforme aplikazioaren funtzionaltasunarekin: nola azaldu bestela egun batez erabili dutela eta ez direla inoiz itzuli. Baina grafikoen laguntzaz oso aktibo daudela ikusi dugu, besterik ez da euren jarduera guztia egun batean sartzen dela.
Orain gure zeregin nagusia erabiltzaile hori bere aire konpainiaren leialtasun programara konektatzera bultzatzea da gure estatistikak erabiltzen dituen bitartean. Kasu honetan, erosten dituen hegaldi guztiak inportatuko ditugu eta txartel berri bat erosi bezain pronto izena ematera bultzatzen saiatuko gara. Arazo hau konpontzeko, Aviasales, Svyaznoy.Travel eta beste aplikazio batzuekin ere lankidetzan hasi ginen. Erabiltzaileak txartel bat erosten duenean, aplikazioak hegaldia App in the Air-n gehitzeko eskatzen dio eta berehala ikusiko dugu.
Grafikoari esker, harpidetza pantailara joaten diren pertsonen %5ek bertan behera uzten dutela ikusi dugu. Horrelako kasuak aztertzen hasi ginen, eta ikusi genuen badela erabiltzaile bat lehen orrialdera joaten dena, bere Google kontuaren konexioa hasi eta berehala bertan behera uzten duena, berriro lehen orrialdera iristen dena, eta abar lau aldiz. Hasieran pentsatu genuen: "Argi dago zerbait gaizki dagoela erabiltzaile honekin". Eta orduan konturatu ginen, ziurrenik, aplikazioan akats bat zegoela. Inbutuan, honela interpretatuko litzateke: erabiltzaileari ez zaio gustatu aplikazioak eskatzen duen baimen multzoa, eta utzi egin du.
Beste talde batek erabiltzaileen % 5 galdu egin zuen pantailan, non aplikazioak telefonoko egutegiko aplikazio guztietatik bat hautatzeko eskatzen die. Erabiltzaileek behin eta berriro hautatuko zituzten egutegi desberdinak eta, ondoren, aplikaziotik irteten ziren. Ematen du UX arazo bat zegoela: pertsona batek egutegi bat hautatu ondoren, Goiko eskuineko izkinan Egina sakatu behar izan zuen. Besterik da, erabiltzaile guztiek ez dutela ikusi.
Aplikazioaren lehen pantaila Airean
Gure grafikoan ikusi dugu erabiltzaileen %30 inguru ez dela lehen pantailatik haratago joaten: erabiltzailea harpidetzera bultzatzen nahiko oldarkor garelako da hori. Lehenengo pantailan, aplikazioak Google edo Triplt erabiliz erregistratzeko eskatzen dizu, eta ez dago erregistroa saltatzeko informaziorik. Lehen pantailatik irteten direnetatik, erabiltzaileen % 16k "Gehiago" sakatu eta berriro itzultzen dira. Aplikazioan barnean erregistratzeko modua bilatzen ari direla jakin dugu eta hurrengo eguneraketan kaleratuko dugu. Gainera, berehala ateratzen direnetatik 2/3k ez dute ezer sakatu. Haiei zer gertatzen zaien jakiteko, bero-mapa bat egin dugu. Ematen du bezeroek klik egin daitezkeen estekak ez diren aplikazioen funtzioen zerrendan klik egiten dutela.
Harrapatu mikro-une bat
Askotan ikus daiteke jendea asfaltozko bide ondoko bideak zapaltzen. Atxikitzea bide horiek aurkitzeko eta, ahal bada, errepideak aldatzeko saiakera da.
Noski, txarra da benetako erabiltzaileengandik ikastea, baina gutxienez aplikazioan erabiltzaile-arazo bat adierazten duten ereduak automatikoki jarraitzen hasi ginen. Orain produktu-kudeatzaileak posta elektroniko bidezko jakinarazpenak jasotzen ditu "begizta" ugari gertatzen badira, erabiltzailea pantaila berera behin eta berriro itzultzen denean.
Ikus ditzagun zeintzuk diren erabiltzailearen ibilbideetan orokorrean interesgarriak diren ereduak aplikazio baten arazoak eta hazkunde-eremuak aztertzeko:
- Begiztak eta zikloak. Goian aipatutako begiztak erabiltzailearen ibilbidean gertaera bat errepikatzen denean gertatzen dira, adibidez, egutegia-egutegia-egutegia-egutegia. Errepikapen asko duen begizta bat interfaze-arazo baten adierazle argia da edo gertaera nahikoa ez dela markatuta. Ziklo bat ere ibilbide itxia da, baina begizta batek ez bezala gertaera bat baino gehiago biltzen ditu, adibidez: hegaldien historia ikustea - hegaldi bat gehitzea - ββhegaldien historia ikustea.
- Flowstoppers - erabiltzaileak, oztoporen bat dela eta, aplikazioan nahi duen mugimendua jarraitu ezin duenean, adibidez, bezeroarentzat begi bistakoa ez den interfazea duen pantaila bat. Horrelako gertaerek moteldu eta erabiltzaileen ibilbidea aldatzen dute.
- Bifurkazio-puntuak gertaera esanguratsuak dira eta ondoren mota ezberdinetako bezeroen ibilbideak bereizten dira. Bereziki, helburuko ekintzarako trantsizio zuzenik edo ekintzarako deirik ez duten pantailak dira, erabiltzaile batzuk modu eraginkorrean horretara bultzatuz. Esaterako, aplikazio bateko edukia erostearekin zerikusi zuzena ez duen pantaila batzuk, baina bezeroek edukia erosteko edo ez erosteko joera duten pantaila batzuk, beste modu batera jokatuko dute. Bifurkazio-puntuak gehi ikurra duten erabiltzaileen ekintzetan eragin-puntuak izan daitezke -erosketa edo klik egiteko erabakian eragina izan dezakete, edo minus ikurra - urrats batzuen ondoren erabiltzaileak aplikazioa utziko duela zehaztu dezakete.
- Abortatu diren bihurtze-puntuak bifurkazio-puntuak izan daitezke. Helburuko ekintza bat eska dezaketen pantaila gisa pentsa ditzakezu, baina ez. Erabiltzaileak beharren bat duen une bat ere izan liteke, baina ez dugu asetzen, besterik gabe, horren berri ez dugulako. Ibilbidearen azterketak behar hori identifikatzea ahalbidetu beharko luke.
- Distrakzio-puntua - erabiltzaileari baliorik ematen ez dioten pantailak/pop-up-ak, bihurketari eragiten ez diotenak eta ibilbideak "lausotu" ditzakete, erabiltzailea helburuko ekintzetatik distraituz.
- Puntu itsuak aplikazioaren, pantailen eta funtzionalitatearen ezkutuko puntuak dira, eta erabiltzailearentzat oso zaila da iristea.
- Hustubideak β trafikoa isurtzen duten puntuak
Oro har, ikuspegi matematikoari esker, bezeroak aplikazioa produktu-kudeatzaileek uste ohi duten modu guztiz ezberdinean erabiltzen duela ulertu genuen erabiltzailearentzako erabilera-eszenatoki estandarren bat planifikatzen saiatzean. Bulegoan eserita eta produktuen hitzaldi politenetara joanez, oraindik oso zaila da erabiltzaileak aplikazioa erabiliz bere arazoak konponduko dituen eremu errealen baldintza guztiak imajinatzea.
Honek txiste handi bat gogorarazten dit. Probatzaile bat taberna batera sartzen da eta agindu egiten du: garagardo edalontzi bat, 2 edalontzi garagardo, 0 edalontzi garagardo, 999999999 edalontzi garagardo, musker bat edalontzi batean, -1 garagardo edalontzi, garagardo edalontzi qwertyuip. Benetako lehen bezeroa tabernara sartu eta komuna non dagoen galdetzen du. Taberna sutan piztu eta denak hiltzen dira.
Produktuen analistak, arazo horretan sakonki murgilduta, mikromomentu kontzeptua sartzen hasi ziren. Erabiltzaile modernoak berehalako irtenbidea behar du bere arazoari. Google duela urte batzuk hasi zen honetaz hitz egiten: konpainiak horrelako erabiltzaileen ekintzak mikro-momentu deitu zituen. Erabiltzailea distraitu egiten da, ustekabean aplikazioa ixten du, ez du ulertzen zer eskatzen zaion, egun bat geroago berriro hasten da saioa, berriro ahazten da eta, ondoren, lagun batek mezularira bidali dion esteka jarraitzen du. Eta saio hauek guztiek ezin dute 20 segundo baino gehiago iraun.
Beraz, laguntza zerbitzuaren lana ezartzen saiatzen hasi ginen, langileek arazoa zein zen ia denbora errealean uler zezaten. Pertsona bat laguntza orrira heldu eta bere galdera idazten hasten den unean, arazoaren funtsa zehaztu dezakegu, bere ibilbidea ezagututa - azken 100 gertakariak. Aurretik, laguntza-eskaera guztien banaketa kategorietan automatizatu genuen laguntza-eskaeren testuen ML azterketa erabiliz. Sailkapenak arrakasta izan duen arren, eskaera guztien % 87 13 kategorietako batean behar bezala banatzen direnean, erabiltzailearen egoerarako irtenbide egokiena automatikoki aurkitu dezaketen ibilbideekin egiten da lan.
Ezin ditugu eguneraketak azkar kaleratu, baina gai gara arazoa nabaritu eta, erabiltzaileak lehendik ikusitako eszenatokia jarraitzen badu, push jakinarazpena bidaliko diogu.
Ikusten dugu aplikazio bat optimizatzeko zereginak erabiltzailearen ibilbideak aztertzeko tresna aberatsak behar dituela. Gainera, erabiltzaileek hartzen dituzten bide guztiak ezagututa, beharrezkoak diren bideak ireki ditzakezu, eta eduki pertsonalizatuen laguntzaz, push jakinarazpenak eta UI elementu moldagarriak "eskuz" eramaten dute erabiltzailea bere beharretara hobekien egokitzen diren eta dirua ekartzen duten ekintza zuzenduetara. , datuak eta beste balio zure negoziorako.
Zer kontutan hartu
- Erabiltzaileen bihurketa aztertzeak inbutuak adibide gisa soilik erabiliz gero, aplikazioak berak ematen digun informazio aberatsa galtzea dakar.
- Erabiltzaileen ibilbideak grafikoetan atxikitzeko analisiak erabiltzaileak atxikitzeko erabiltzen dituzun funtzioak ikusten laguntzen dizu edo, adibidez, harpidetzera bultzatzen dituzu.
- Retentioneering tresnek automatikoki, denbora errealean, aplikazioan erabiltzaileen arazoak adierazten dituzten ereduen jarraipena egiten laguntzen dute, akatsak aurkitzen eta ixten dituzte antzematen zailak ziren tokietan.
- Erabiltzaileen portaeraren eredu ez nabariak aurkitzen laguntzen dute.
- Retentioneering tresnek ML tresna automatizatuak eraikitzea ahalbidetzen dute erabiltzailearen gertaerak eta neurgailu nagusiak aurreikusteko: erabiltzaileen galera, LTV eta grafikoan erraz zehazten diren beste hainbat neurketa.
Komunitate bat eraikitzen ari gara Retentioneering-en inguruan ideiak aske trukatzeko. Garatzen ari garen tresnak mugikor eta web aplikazio ezberdinetako analistek eta produktuek ezagutzak, teknika eta metodo onenak truka ditzaketen hizkuntza gisa pentsa ditzakezu. Ikastaroan tresna hauek nola erabiltzen ikas dezakezu Bitar Barrutia.
Iturria: www.habr.com