Ang pagpapanatili ng isang user sa isang mobile application ay isang buong agham. Inilarawan ng may-akda ng kurso ang mga pangunahing kaalaman nito sa aming artikulo sa VC.ru Maxim Godzi, Pinuno ng Machine Learning sa App in the Air. Pinag-uusapan ni Maxim ang tungkol sa mga tool na binuo sa kumpanya gamit ang halimbawa ng trabaho sa pagsusuri at pag-optimize ng isang mobile application. Ang sistematikong diskarte na ito sa pagpapahusay ng produkto, na binuo sa App in the Air, ay tinatawag na Retentioneering. Magagamit mo ang mga tool na ito sa iyong produkto: ang ilan sa mga ito ay nasa sa GitHub.
Ang App in the Air ay isang application na may higit sa 3 milyong aktibong user sa buong mundo, kung saan maaari mong subaybayan ang mga flight, makakuha ng impormasyon tungkol sa mga pagbabago sa mga oras ng pag-alis/paglapag, check-in at mga katangian ng airport.
Mula funnel hanggang trajectory
Ang lahat ng mga development team ay bumuo ng onboarding funnel (isang proseso na naglalayong tanggapin ng user ang produkto). Ito ang unang hakbang na tumutulong sa iyong tingnan ang buong system mula sa itaas at mahanap ang mga problema sa application. Ngunit habang umuunlad ang produkto, mararamdaman mo ang mga limitasyon ng diskarteng ito. Gamit ang isang simpleng funnel, hindi mo makikita ang mga hindi halatang growth point para sa isang produkto. Ang layunin ng funnel ay magbigay ng pangkalahatang pagtingin sa mga yugto ng mga user sa application, upang ipakita sa iyo ang mga sukatan ng pamantayan. Ngunit maingat na itatago ng funnel ang mga paglihis mula sa pamantayan patungo sa mga halatang problema o, sa kabaligtaran, espesyal na aktibidad ng user.
Sa App in the Air, gumawa kami ng sarili naming funnel, ngunit dahil sa mga detalye ng produkto, nauwi kami sa isang hourglass. Pagkatapos ay nagpasya kaming palawakin ang diskarte at gamitin ang maraming impormasyon na ibinibigay mismo sa amin ng application.
Kapag bumuo ka ng funnel, mawawala sa iyo ang onboarding trajectories ng user. Ang mga trajectory ay binubuo ng isang pagkakasunud-sunod ng mga aksyon ng user at ang application mismo (halimbawa, pagpapadala ng push notification).
Gamit ang mga timestamp, napakadali mong muling mabubuo ang tilapon ng user at makagawa ng graph mula rito para sa bawat isa sa kanila. Siyempre, maraming mga graph. Samakatuwid, kailangan mong pagpangkatin ang mga katulad na user. Halimbawa, maaari mong ayusin ang lahat ng user ayon sa mga hilera ng talahanayan at ilista kung gaano kadalas nila ginagamit ang isang partikular na function.
Batay sa naturang talahanayan, gumawa kami ng matrix at pinagsama-sama ang mga user ayon sa dalas ng paggamit ng mga function, iyon ay, ayon sa mga node sa graph. Karaniwang ito ang unang hakbang patungo sa mga insight: halimbawa, nasa yugto na ito makikita mo na ang ilang mga user ay hindi gumagamit ng ilan sa mga function. Noong ginawa namin ang pagsusuri sa dalas, sinimulan naming pag-aralan kung aling mga node sa graph ang "pinakamalaking", ibig sabihin, kung aling mga pahina ang madalas na binibisita ng mga user. Ang mga kategorya na sa panimula ay naiiba ayon sa ilang pamantayan na mahalaga sa iyo ay agad na na-highlight. Narito, halimbawa, ang dalawang cluster ng mga user na hinati namin batay sa desisyon ng subscription (may kabuuang 16 na cluster).
Kung paano ito gamitin
Sa pamamagitan ng pagtingin sa iyong mga user sa ganitong paraan, makikita mo kung anong mga feature ang ginagamit mo para mapanatili sila o, halimbawa, ipa-sign up sila. Naturally, ang matrix ay magpapakita din ng mga halatang bagay. Halimbawa, na ang mga bumili ng subscription ay bumisita sa screen ng subscription. Ngunit bukod dito, makakahanap ka rin ng mga pattern na hindi mo malalaman kung hindi man.
Kaya hindi namin sinasadyang natagpuan ang isang pangkat ng mga user na nagdaragdag ng isang flight, aktibong sinusubaybayan ito sa buong araw at pagkatapos ay mawawala nang mahabang panahon hanggang sa lumipad muli sila sa isang lugar. Kung susuriin namin ang kanilang pag-uugali gamit ang mga maginoo na tool, iisipin namin na hindi lang sila nasisiyahan sa functionality ng application: paano pa namin maipapaliwanag na ginamit nila ito sa loob ng isang araw at hindi na bumalik. Ngunit sa tulong ng mga graph nakita namin na sila ay napaka-aktibo, kaya lang lahat ng kanilang aktibidad ay umaangkop sa isang araw.
Ngayon ang aming pangunahing gawain ay hikayatin ang naturang user na kumonekta sa loyalty program ng kanyang airline habang ginagamit niya ang aming mga istatistika. Sa kasong ito, i-import namin ang lahat ng binibili niyang flight at susubukan naming itulak siya na mag-sign up sa sandaling bumili siya ng bagong ticket. Upang malutas ang problemang ito, nagsimula rin kaming makipagtulungan sa Aviasales, Svyaznoy.Travel at iba pang mga application. Kapag bumili ng ticket ang kanilang user, ipo-prompt sila ng app na idagdag ang flight sa App in the Air, at nakita namin ito kaagad.
Salamat sa graph, nakita namin na 5% ng mga tao na pumupunta sa screen ng subscription ay kinakansela ito. Sinimulan naming pag-aralan ang mga ganitong kaso, at nakita namin na mayroong isang gumagamit na pumunta sa unang pahina, sinimulan ang koneksyon ng kanyang Google account, at agad na kinansela ito, nakarating muli sa unang pahina, at iba pa nang apat na beses. Noong una, naisip namin, "May malinaw na mali sa user na ito." At pagkatapos ay napagtanto namin na, malamang, mayroong isang bug sa application. Sa funnel, ito ay bibigyang-kahulugan bilang sumusunod: hindi nagustuhan ng user ang hanay ng mga pahintulot na hinihiling ng application, at umalis siya.
Ang isa pang grupo ay nagkaroon ng 5% ng mga user na nawala sa screen kung saan sinenyasan sila ng app na pumili ng isa mula sa lahat ng app sa kalendaryo sa kanilang smartphone. Ang mga gumagamit ay pipili ng iba't ibang mga kalendaryo nang paulit-ulit at pagkatapos ay lalabas lang sa app. Lumalabas na may isyu sa UX: pagkatapos pumili ng kalendaryo ang isang tao, kailangan nilang i-click ang Tapos na sa kanang sulok sa itaas. Kaya lang hindi lahat ng user ay nakakita nito.
Unang screen ng App in the Air
Sa aming graph, nakita namin na humigit-kumulang 30% ng mga user ang hindi lumalampas sa unang screen: ito ay dahil sa katotohanan na kami ay medyo agresibo sa pagtulak sa user na mag-subscribe. Sa unang screen, sinenyasan ka ng app na magparehistro gamit ang Google o Triplt, at walang impormasyon tungkol sa paglaktaw sa pagpaparehistro. Sa mga umalis sa unang screen, 16% ng mga user ang nag-click sa "Higit pa" at bumalik muli. Nalaman namin na naghahanap sila ng paraan para makapag-rehistro sa loob ng application at ilalabas namin ito sa susunod na update. Bilang karagdagan, 2/3 ng mga umalis kaagad ay hindi nag-click sa anumang bagay. Para malaman kung ano ang nangyayari sa kanila, gumawa kami ng heatmap. Lumalabas na nagki-click ang mga customer sa isang listahan ng mga feature ng app na hindi naki-click na mga link.
Kumuha ng micro-moment
Madalas mong makita ang mga taong tumatapak sa mga landas sa tabi ng kalsadang aspalto. Ang retentioneering ay isang pagtatangka na hanapin ang mga landas na ito at, kung maaari, baguhin ang mga kalsada.
Siyempre, masama na natuto kami mula sa mga totoong user, ngunit hindi bababa sa nagsimula kaming awtomatikong subaybayan ang mga pattern na nagpapahiwatig ng problema ng user sa application. Ngayon ang tagapamahala ng produkto ay tumatanggap ng mga abiso sa email kung ang isang malaking bilang ng mga "loop" ay nangyari-kapag ang user ay bumalik sa parehong screen nang paulit-ulit.
Tingnan natin kung anong mga pattern sa mga trajectory ng user ang karaniwang kawili-wiling hanapin para pag-aralan ang mga problema at mga lugar ng paglago ng isang application:
- Mga loop at cycle. Ang mga loop na binanggit sa itaas ay kapag umuulit ang isang kaganapan sa trajectory ng user, halimbawa, calendar-calendar-calendar-calendar. Ang isang loop na may maraming pag-uulit ay isang malinaw na tagapagpahiwatig ng isang problema sa interface o hindi sapat na pagmamarka ng kaganapan. Ang isang cycle ay isa ring saradong trajectory, ngunit hindi tulad ng isang loop, may kasama itong higit sa isang kaganapan, halimbawa: pagtingin sa history ng flight - pagdaragdag ng flight - pagtingin sa history ng flight.
- Flowstoppers - kapag ang user, dahil sa ilang balakid, ay hindi makapagpatuloy sa kanyang ninanais na paggalaw sa pamamagitan ng application, halimbawa, isang screen na may interface na hindi halata sa kliyente. Ang ganitong mga kaganapan ay bumagal at nagbabago sa trajectory ng mga gumagamit.
- Ang mga punto ng bifurcation ay makabuluhang mga kaganapan pagkatapos kung saan ang mga trajectory ng mga kliyente ng iba't ibang uri ay pinaghihiwalay. Sa partikular, ang mga ito ay mga screen na hindi naglalaman ng direktang paglipat o call-to-action sa target na pagkilos, na epektibong nagtutulak sa ilang user patungo dito. Halimbawa, ang ilang screen na hindi direktang nauugnay sa pagbili ng nilalaman sa isang application, ngunit kung saan ang mga customer ay hilig na bumili o hindi bumili ng nilalaman, ay magiging iba. Ang mga bifurcation point ay maaaring maging mga punto ng impluwensya sa mga aksyon ng iyong mga user na may plus sign - maaari nilang maimpluwensyahan ang desisyon na bumili o mag-click, o isang minus sign - matutukoy nila na pagkatapos ng ilang hakbang ay aalis ang user sa application.
- Ang mga aborted na conversion point ay mga potensyal na bifurcation point. Maaari mong isipin ang mga ito bilang mga screen na maaaring mag-prompt ng isang target na pagkilos, ngunit huwag. Maaari rin itong maging isang punto sa oras kung kailan may pangangailangan ang user, ngunit hindi namin ito natutugunan dahil hindi lang namin alam ang tungkol dito. Dapat pahintulutan ng pagsusuri sa tilapon ang pangangailangang ito na matukoy.
- Distraction point - mga screen/pop-up na hindi nagbibigay ng halaga sa user, hindi nakakaapekto sa conversion at maaaring "mag-blur" ng mga trajectory, na nakakaabala sa user mula sa mga target na aksyon.
- Ang mga blind spot ay mga nakatagong punto ng application, mga screen at feature na napakahirap maabot ng user.
- Drains β mga punto kung saan tumagas ang trapiko
Sa pangkalahatan, ang matematikal na diskarte ay nagbigay-daan sa amin na maunawaan na ginagamit ng kliyente ang application sa isang ganap na naiibang paraan kaysa sa karaniwang iniisip ng mga tagapamahala ng produkto kapag sinusubukang magplano ng ilang karaniwang senaryo ng paggamit para sa user. Nakaupo sa opisina at dumalo sa pinakaastig na mga kumperensya ng produkto, napakahirap pa ring isipin ang lahat ng iba't ibang mga tunay na kondisyon sa larangan kung saan malulutas ng user ang kanyang mga problema gamit ang application.
Ito ay nagpapaalala sa akin ng isang magandang biro. Isang tester ang pumasok sa isang bar at nag-order ng: isang baso ng beer, 2 baso ng beer, 0 baso ng beer, 999999999 na baso ng beer, isang butiki sa isang baso, -1 baso ng beer, qwertyuip na baso ng beer. Ang unang tunay na customer ay pumasok sa bar at nagtanong kung nasaan ang banyo. Nagliyab ang bar at namatay ang lahat.
Ang mga analyst ng produkto, na malalim na nalubog sa problemang ito, ay nagsimulang ipakilala ang konsepto ng isang micromoment. Ang modernong gumagamit ay nangangailangan ng agarang solusyon sa kanilang problema. Sinimulan itong pag-usapan ng Google ilang taon na ang nakalilipas: tinawag ng kumpanya ang mga naturang pagkilos ng user na micro-moments. Nagambala ang user, hindi sinasadyang isinara ang application, hindi naiintindihan kung ano ang kinakailangan sa kanya, nag-log in muli pagkaraan ng isang araw, nakalimutan muli, at pagkatapos ay sinusundan ang link na ipinadala sa kanya ng isang kaibigan sa messenger. At lahat ng mga session na ito ay maaaring tumagal ng hindi hihigit sa 20 segundo.
Kaya sinimulan naming subukang i-set up ang gawain ng serbisyo ng suporta upang maunawaan ng mga empleyado kung ano ang problema sa halos real time. Sa oras na ang isang tao ay pumunta sa pahina ng suporta at nagsimulang magsulat ng kanyang tanong, matutukoy natin ang kakanyahan ng problema, alam ang kanyang tilapon - ang huling 100 mga kaganapan. Dati, na-automate namin ang pamamahagi ng lahat ng kahilingan sa suporta sa mga kategorya gamit ang pagsusuri sa ML ng mga text ng mga kahilingan sa suporta. Sa kabila ng tagumpay ng pagkakategorya, kapag ang 87% ng lahat ng mga kahilingan ay wastong naipamahagi sa isa sa 13 mga kategorya, ito ay gumagana sa mga tilapon na awtomatikong makakahanap ng pinakaangkop na solusyon para sa sitwasyon ng user.
Hindi kami makakapaglabas ng mga update nang mabilis, ngunit napapansin namin ang problema at, kung susundin ng user ang sitwasyong nakita na namin, magpadala sa kanya ng push notification.
Nakikita namin na ang gawain ng pag-optimize ng isang application ay nangangailangan ng mga rich tool para sa pag-aaral ng mga trajectory ng user. Dagdag pa, sa pag-alam sa lahat ng mga landas na tinatahak ng mga user, maaari mong ihanda ang mga kinakailangang landas, at sa tulong ng naka-customize na nilalaman, ang mga push notification at adaptive na elemento ng UI βsa pamamagitan ng kamayβ ay humahantong sa user sa mga naka-target na aksyon na pinakaangkop sa kanyang mga pangangailangan at magdala ng pera , data at iba pang halaga para sa iyong negosyo.
Ano ang dapat tandaan
- Ang pag-aaral ng conversion ng user gamit lamang ang mga funnel bilang isang halimbawa ay nangangahulugan ng pagkawala ng mayamang impormasyon na ibinibigay mismo sa atin ng application.
- Tinutulungan ka ng pagsusuri sa pagpapanatili ng mga trajectory ng user sa mga graph na makita kung aling mga feature ang ginagamit mo para mapanatili ang mga user o, halimbawa, hikayatin silang mag-subscribe.
- Ang mga tool sa retentioneering ay awtomatikong tumutulong, sa real time, na subaybayan ang mga pattern na nagpapahiwatig ng mga problema ng user sa application, maghanap at magsara ng mga bug kung saan mahirap mapansin ang mga ito.
- Tumutulong sila na makahanap ng mga hindi halatang pattern ng pag-uugali ng user.
- Ginagawang posible ng mga tool sa retentioneering na bumuo ng mga automated na tool sa ML para sa paghula ng mga pangunahing kaganapan at sukatan ng user: pagkawala ng user, LTV at marami pang ibang sukatan na madaling matukoy sa graph.
Bumubuo kami ng isang komunidad sa paligid ng Retentioneering para sa libreng pagpapalitan ng mga ideya. Maaari mong isipin ang mga tool na ginagawa namin bilang isang wika kung saan ang mga analyst at produkto mula sa iba't ibang mobile at web application ay maaaring magpalitan ng mga insight, pinakamahusay na diskarte at pamamaraan. Matututuhan mo kung paano gamitin ang mga tool na ito sa kurso Binary District.
Pinagmulan: www.habr.com