Утрымаць карыстальніка ў мабільным дадатку - гэта цэлая навука. Яе асновы ў нашым артыкуле на VC.ru апісаў аўтар курса Максім Годзі, кіраўнік падраздзялення Машыннага навучання ў App in the Air. Максім распавядае пра распрацаваныя ў кампаніі інструменты на прыкладзе працы па аналізе і аптымізацыі мабільнага прыкладання. Такі сістэмны падыход да ўдасканалення прадукта, распрацаваны ў App in the Air, завуць Retentioneering. Выкарыстоўваць гэтыя прылады вы можаце і ў сваім прадукце: частка з іх ёсць у на GitHub.
App in the Air - дадатак з больш за 3 млн актыўных карыстальнікаў па ўсім свеце, з дапамогай якога можна адсочваць палёты, атрымаць інфармацыю аб змене часу вылету / пасадкі, рэгістрацыі і характарыстыках аэрапортаў.
Ад варонкі да траекторыі
Усе каманды распрацоўкі будуюць варонку онбордынгу (працэс, накіраваны на прыняцце прадукта карыстачом). Гэта першы крок, які дапамагае паглядзець на ўсю сістэму зверху і знайсці праблемы прыкладання. Але па ходзе развіцця прадукта вы адчуеце абмежаванні такога падыходу. З дапамогай простай варонкі нельга ўбачыць невідавочныя кропкі росту для прадукта. Мэта варонкі - даць агульны погляд на этапы карыстальнікаў у дадатку, паказаць вам метрыкі нормы. Але варонка прадбачліва схавае адхіленні ад нормы ў бок відавочных праблем або, наадварот, асаблівай актыўнасці карыстальнікаў.
Мы ў App in the Air будавалі ўласную варонку, аднак з-за спецыфікі прадукта ў нас атрымаліся «пясочны гадзіннік». Тады мы вырашылі пашыраць падыход, і выкарыстоўваць багатую інфармацыю, якую дае нам само дадатак.
Калі вы будуеце варонку, вы губляеце траекторыі праходжання онбордынгу карыстальнікамі. Траекторыі складаюцца з паслядоўнасці дзеянняў карыстальніка і самога дадатку (напрыклад, адпраўка push-паведамлення).
Па часавых пазнаках вы вельмі проста можаце аднавіць траекторыю карыстальніка і зрабіць з яе граф для кожнага з іх. Само сабой, графаў атрымоўваецца вельмі шмат. Таму трэба групаваць падобных карыстальнікаў. Напрыклад, можна размясціць усіх карыстальнікаў па радках табліцы і распісаць, як часта яны выкарыстоўваюць некаторую функцыю.
На аснове такой табліцы мы зрабілі матрыцу і згрупавалі карыстальнікаў па частаце выкарыстання функцый, гэта значыць па вузлах у графе. Звычайна гэта першы крок да інсайтаў: напрыклад, ужо на гэтым этапе вы ўбачыце, што некаторыя карыстачы наогул не выкарыстоўваюць частку функцый. Калі мы зрабілі частотны аналіз, мы пачалі вывучаць, якія вузлы графа "самыя вялікія", гэта значыць на якіх старонках карыстачы часцей за ўсё бываюць. Адразу вылучаюцца катэгорыі, якія прынцыпова адрозніваюцца па нейкім важным для вас крытэрыі. Вось, напрыклад, два кластары карыстальнікаў, якіх мы падзялілі на аснове рашэння аб падпісцы (усяго кластараў было 16).
Як гэта выкарыстоўваць
Паглядзеўшы такім чынам на сваіх карыстальнікаў, можна ўбачыць, з дапамогай якіх функцый вы ўтрымліваеце іх ці, напрыклад, дамагаецеся падпіскі. Натуральна, што матрыца ў тым ліку будзе паказваць відавочныя рэчы. Напрыклад, што тыя, хто набыў падпіску, бывалі на экране падпіскі. Але акрамя гэтага вы зможаце знайсці і патэрны, пра якія ніколі б не даведаліся іншым шляхам.
Так мы зусім выпадкова знайшлі групу карыстальнікаў, якія дадаюць палёт, актыўна адсочваюць яго на працягу дня і пасля знікаюць на доўгі час, пакуль яны зноў не паляцяць куды-небудзь. Калі б мы аналізавалі іх паводзіны з дапамогай звычайных інструментаў, мы б падумалі, што іх проста не задаволіў функцыянал дадатку: як яшчэ растлумачыць, што яны выкарыстоўвалі яго на працягу аднаго дня і больш не вяртаюцца. Але з дапамогай графаў мы ўбачылі, што яны вельмі актыўныя, проста ўся іх актыўнасць укладваецца ў адны суткі.
Цяпер наша галоўная задача падштурхнуць такога карыстальніка падключыць праграму лаяльнасці свайго авіяперавозчыка, пакуль ён карыстаецца нашай статыстыкай. У такім выпадку мы імпартуем усе палёты, якія ён купіць і паспрабуем падштурхнуць яго да падпіскі, як толькі ён набудзе новы білет. Каб вырашыць гэтую праблему, мы таксама сталі супрацоўнічаць з Aviasales, Cвязной.Travel і іншымі праграмамі. Калі іх карыстальнік купляе білет, прыкладанне прапануе яму дадаць палёт у App in the Air, і мы адразу бачым яго.
Дзякуючы графу мы ўбачылі, што 5% людзей, якія заходзяць на экран падпіскі, адмаўляюцца ад яе. Мы сталі аналізаваць такія выпадкі, і ўбачылі, што ёсць карыстач, які заходзіць на першую старонку, ініцыюе падлучэнне свайго Google акаўнта, і тут жа адмяняе яго, зноў пападае на першую старонку, і так чатыры разу. Спачатку мы падумалі: "З гэтым карыстальнікам нешта відавочна не так". А потым зразумелі, што, хутчэй за ўсё, у дадатку ёсць баг. На варонцы гэта б інтэрпрэтавалася так: карыстачу не спадабаўся набор дазволаў, якое запытвае дадатак, і ён сышоў.
У іншай групы 5% карыстачоў гублялася на экране, дзе прыкладанне прапануе абраць адзін з усіх прыкладанняў календара на смартфоне. Карыстальнікі зноў і зноў выбіралі розныя календары, а потым проста выходзілі з дадатку. Аказалася, што тут была UX-праблема: пасля таго, як чалавек абраў каляндар, ён павінен быў націснуць Done у правым верхнім куце. Проста не ўсе карыстачы гэта бачылі.
Першы экран App in the Air
На нашым графе мы ўбачылі, што каля 30% карыстальнікаў не праходзіць далей за першы экран: гэта адбываецца з-за таго, што мы дастаткова агрэсіўна падштурхоўваем карыстальніка да падпіскі. На першым экране прыкладанне прапануе зарэгістравацца з дапамогай Google ці Triplt, і няма інфармацыі аб тым, што можна прапусціць рэгістрацыю. З тых, хто сыходзіць з першага ж экрана, 16% карыстачоў націскаюць "Яшчэ", і зноў вяртаюцца. Мы высветлілі, што яны шукаюць спосаб унутранай рэгістрацыі ў дадатку, і мы выпусцім яе ў наступным абнаўленні. Акрамя таго, 2/3 з тых, хто адразу сыходзіць, не націскаюць увогуле нічога. Каб высветліць, што адбываецца з імі, мы пабудавалі heatmap - цеплавую карту. Аказалася, што кліенты націскаюць на спіс функцый прыкладання, якія не з'яўляюцца актыўнымі спасылкамі.
Лавіць мікрамомант
Часта можна ўбачыць, што людзі пратоптваюць сцяжынкі побач з асфальтаванай дарогай. Retentioneering - гэта спроба знайсці гэтыя сцяжынкі і па магчымасці змяніць дарогі.
Вядома, дрэнна, што мы вучымся на сапраўдных карыстальніках, але хаця б мы сталі аўтаматычна адсочваць патэрны, якія кажуць аб праблеме карыстальнікаў у дадатку. Зараз продакт-мэнэджар атрымлівае апавяшчэнні на пошту, калі ўзнікае вялікая колькасць «завес» - калі карыстач вяртаецца на адзін экран зноў і зноў.
Давайце разбяром, якія патэрны ў траекторыях карыстачоў наогул цікава шукаць для аналізу праблем і кропак росту прыкладання:
- Завесы і цыклы. Згаданыя вышэй завесы – калі адна падзея паўтараецца ў траекторыі карыстальніка, напрыклад, каляндар-каляндар-каляндар-каляндар. Завеса з вялікай колькасцю паўтораў - гэта відавочны паказальнік на праблему з інтэрфейсам або недастатковую разметку івэнтамі. Цыкл таксама з'яўляецца замкнёнай траекторыяй, але ў адрозненне ад пятлі ўключае ў сябе больш за адну падзеі, напрыклад: прагляд гісторыі пералётаў - даданне пералёту - прагляд гісторыі пералётаў.
- Flowstoppers - калі карыстач з-за нейкай перашкоды, не можа працягнуць сваё жаданае перасоўванне па дадатку, напрыклад экран з невідавочным для кліента інтэрфейсам. Такія падзеі затарможваюць і зрушваюць траекторыю карыстальнікаў.
- Bifurcation points - знакавыя падзеі, пасля якіх траекторыі кліентаў розных тыпаў падзяляюцца. У прыватнасці, гэта экраны, якія не змяшчаюць прамога пераходу або call-to-action да мэтавага дзеяння, эфектыўна падштурхоўваюць частку карыстальнікаў да яго. Напрыклад, нейкі экран, не звязаны напрамую з пакупкай кантэнту ў дадатку, але на якім кліенты схільныя купляць ці не купляць кантэнт, будуць паводзіць сябе па-рознаму. Bifurcation points могуць быць кропкамі ўплыву на дзеянні вашых карыстальнікаў са знакам плюс - уплываць на рашэнне аб куплі або патрэбным кліку, або мінус - яны могуць вызначаць, што праз некалькі крокаў карыстальнік пакіне прыкладанне.
- Aborted conversion points - гэта патэнцыйныя bifurcation points. Пра іх можна думаць як пра экраны, якія маглі б сутыкаць на мэтавае дзеянне, але не робяць гэтага. Гэта таксама можа быць момант часу, калі ў карыстача ўзнікае запатрабаванне, але мы яе не задавальняем, бо проста не ведаем пра яе. Разбор траекторыі павінен дазваляць гэтае запатрабаванне выявіць.
- Distraction point - экраны / pop-up, якія не нясуць каштоўнасці карыстачу, не ўплываюць на канверсію і могуць пры гэтым "размываць" траекторыі, адцягваючы карыстальніка ад мэтавых дзеянняў.
- Blind spots - схаваныя кропкі прыкладання, экраны і фічы, да якіх вельмі складана дабрацца карыстачу.
- Drains - кропкі, на якіх адбываецца ўцечка трафіку
У цэлым, матэматычны падыход дазволіў нам зразумець, што кліент карыстаецца дадаткам зусім не так, як звычайна думаюць продакт-менеджэры, спрабуючы спланаваць для карыстальніка нейкі свой, стандартны сцэнар выкарыстання. Седзячы ў офісе і наведваючы самыя стромкія канферэнцыі для прадактаў, усё роўна вельмі цяжка ўявіць сабе ўсю разнастайнасць рэальных палявых умоў, у якіх карыстач будзе вырашаць свае задачы з дапамогай прыкладання.
Гэта нагадвае класны анекдот. Тэстыравальнік заходзіць у бар і заказвае: кубак піва, 2 кубкі піва, 0 кубкаў піва, 999999999 кубкаў піва, яшчарку ў шклянцы, –1 кубак піва, qwertyuip кубкаў піва. Першы рэальны кліент заходзіць у бар і пытаецца, дзе прыбіральню. Бар успыхвае полымем, усё гінуць.
Прадуктовыя аналітыкі, глыбока пагрузіўшыся ў гэтую праблему, сталі ўводзіць паняцце мікрамоманту. Сучаснаму карыстачу трэба імгненнае рашэнне іх праблемы. Пра гэта некалькі гадоў таму пачаў казаць Google: у кампаніі такія дзеянні карыстачоў назвалі мікрамомантамі. Карыстальнік адцягваецца, выпадкова закрывае дадатак, не разумее, што ад яго патрабуецца, заходзіць зноўку праз суткі, зноў забывае, а потым па спасылцы, якую яму даслаў сябар у мэсэнджэры. І ўсе гэтыя сесіі могуць доўжыцца не больш за 20 секунд.
Так мы сталі спрабаваць настроіць працу службы падтрымкі так, каб супрацоўнікі маглі зразумець, у чым праблема практычна ў рэальным часе. Да таго часу, як чалавек прыйшоў на старонку звароту ў службу падтрымкі і пачаў пісаць сваё пытанне, мы можам вызначыць сутнасць праблемы, ведаючы яго траекторыю - апошнія 100 падзей. Раней мы аўтаматызавалі размеркаванне ўсіх зваротаў у службу падтрымкі па катэгорыях з дапамогай ML-аналізу тэкстаў запытаў у службу падтрымкі. Нягледзячы на поспех катэгарызацыі, калі 87% усіх зваротаў правільна размяркоўваюцца па адной з 13 катэгорый, менавіта праца з траекторыямі здольная аўтаматычна знаходзіць найбольш прыдатнае для сітуацыі карыстальніка рашэнне.
Мы не можам хутка выпускаць абнаўленні, але мы здольныя заўважыць праблему і ў выпадку, калі карыстач ідзе па сцэнары, які мы ўжо бачылі, даслаць яму push-апавяшчэнне.
Мы бачым, што задача аптымізацыі прыкладання патрабуе багатага інструментара для даследавання траекторый карыстальніка. Далей, ведаючы ўсе шляхі па якіх ходзяць карыстачы, вы можаце і пракласці патрэбныя сцяжынкі, і з дапамогай кастамізаванага кантэнту, push-паведамленняў і адаптыўных UI элементаў «за ручку» прывесці карыстача да мэтавых дзеянняў, якія лепш за ўсё адпавядаюць яго запатрабаванням і прыносяць грошы, дадзеныя і іншыя каштоўнасці для вашага бізнесу.
Што ўзяць на нататку
- Даследаваць канверсію карыстальнікаў толькі на прыкладзе варонак - губляць багатую інфармацыю, якую дае нам само прыкладанне.
- Retentioneering-аналіз траекторый карыстальнікаў на графах дапамагае ўбачыць, з дапамогай якіх функцый вы ўтрымліваеце карыстальнікаў або, напрыклад, стымулюеце іх да падпіскі.
- Інструменты Retentioneering дапамагаюць аўтаматычна ў рэжыме рэальнага часу адсочваць патэрны, якія гавораць аб праблеме карыстальнікаў у дадатку, знаходзіць і закрываць багі там, дзе іх цяжка было заўважыць.
- Яны дапамагаюць знаходзіць невідавочныя патэрны паводзін карыстальнікаў.
- Інструменты Retentioneering даюць магчымасць пабудовы аўтаматызаваных ML інструментаў для прадказання ключавых падзей з карыстальнікам і метрык: страту карыстальніка, LTV і многія іншыя метрыкі, якія лёгка вызначаюцца на графе.
Мы ствараем супольнасць вакол Retentioneering для свабоднага абмену ідэямі. Можна ўспрымаць інструментар, які мы распрацоўваем, як мову, на якой аналітыкі і продакты з розных мабільных і вэб-прыкладанняў змогуць абменьвацца інсайтамі, лепшымі тэхнікамі і метадамі. Навучыцца карыстацца гэтымі інструментамі можна на курсе Binary District.
Крыніца: habr.com