Како се имплементира задржувањето во апликацијата во воздухот

Одржувањето корисник во мобилна апликација е цела наука. Авторот на курсот ги опиша неговите основи во нашата статија на VC.ru Хакирање на раст: аналитика на мобилни апликации Максим Гоџи, раководител на машинско учење во App in the Air. Максим зборува за алатките развиени во компанијата користејќи го примерот на работа на анализа и оптимизација на мобилна апликација. Овој систематски пристап за подобрување на производот, развиен во App in the Air, се нарекува Retentioneering. Можете да ги користите овие алатки во вашиот производ: некои од нив се внатре слободен пристап на GitHub.

App in the Air е апликација со повеќе од 3 милиони активни корисници ширум светот, со која можете да следите летови, да добивате информации за промените во времето на поаѓање/слетување, пријавување и карактеристики на аеродромот.

Од инка до траекторија

Сите развојни тимови градат инка за вградување (процес насочен кон прифаќање на производот од страна на корисникот). Ова е првиот чекор што ви помага да го погледнете целиот систем одозгора и да пронајдете проблеми со апликацијата. Но, како што се развива производот, ќе ги почувствувате ограничувањата на овој пристап. Користејќи едноставна инка, не можете да видите неочигледни точки на раст за производот. Целта на инката е да даде општ поглед на фазите на корисниците во апликацијата, да ви ја покаже метриката на нормата. Но, инката претпазливо ќе ги скрие отстапувањата од нормата кон очигледни проблеми или, напротив, посебна корисничка активност.

Во App in the Air изградивме сопствена инка, но поради спецификите на производот, завршивме со песочен часовник. Тогаш решивме да го прошириме пристапот и да ги искористиме богатите информации кои ни ги дава самата апликација.

Кога ќе изградите инка, го губите корисникот кој ги вклучува траекториите. Траекториите се состојат од низа дејства од страна на корисникот и самата апликација (на пример, испраќање известување за притискање).

Користејќи временски печати, можете многу лесно да ја реконструирате траекторијата на корисникот и да направите график од неа за секој од нив. Се разбира, има многу графикони. Затоа, треба да групирате слични корисници. На пример, можете да ги распоредите сите корисници по редови на табели и да наведете колку често користат одредена функција.

Врз основа на таква табела, направивме матрица и ги групиравме корисниците по фреквенција на употреба на функции, односно по јазли во графикот. Ова е обично првиот чекор кон увид: на пример, веќе во оваа фаза ќе видите дека некои корисници воопшто не користат некои од функциите. Кога ја направивме анализата на фреквенцијата, почнавме да проучуваме кои јазли во графикот се „најголеми“, односно кои страници најчесто ги посетуваат корисниците. Веднаш се истакнуваат категориите кои се суштински различни според некој критериум што ви е важен. Еве, на пример, два кластери на корисници што ги поделивме врз основа на одлуката за претплата (вкупно имаше 16 кластери).

Како да го користите

Гледајќи ги вашите корисници на овој начин, можете да видите кои функции ги користите за да ги задржите или, на пример, да ги натерате да се регистрираат. Нормално, матрицата ќе покаже и очигледни работи. На пример, дека оние што купиле претплата го посетиле екранот за претплата. Но, покрај ова, можете да најдете и модели за кои инаку никогаш не би знаеле.

Така, сосема случајно најдовме група корисници кои додаваат лет, активно го следат во текот на денот и потоа исчезнуваат долго време додека повторно не летаат. Кога би го анализирале нивното однесување користејќи конвенционални алатки, би помислиле дека тие едноставно не се задоволни од функционалноста на апликацијата: како инаку да објасниме дека ја користеле еден ден и никогаш не се вратиле. Но, со помош на графикони видовме дека тие се многу активни, едноставно целата нивна активност се вклопува во еден ден.

Сега нашата главна задача е да поттикнеме таков корисник да се поврзе со програмата за лојалност на неговата авиокомпанија додека ја користи нашата статистика. Во овој случај, ќе ги увеземе сите летови што ќе ги купи и ќе се обидеме да го натераме да се пријави веднаш штом ќе купи нов билет. За да го решиме овој проблем, почнавме да соработуваме и со Aviasales, Svyaznoy.Travel и други апликации. Кога нивниот корисник ќе купи билет, апликацијата ги поттикнува да го додадат летот во App in the Air, и ние веднаш ќе го видиме.

Благодарение на графиконот, видовме дека 5% од луѓето кои одат на екранот за претплата ја откажуваат. Почнавме да ги анализираме таквите случаи и видовме дека има корисник кој оди на првата страница, иницира поврзување на неговата сметка на Google и веднаш ја откажува, повторно доаѓа на првата страница и така четири пати. Отпрвин мислевме: „Нешто не е во ред со овој корисник“. И тогаш сфативме дека, најверојатно, имало грешка во апликацијата. Во инката, ова би се толкувало на следниов начин: на корисникот не му се допаднале сетот на дозволи што ги бара апликацијата и тој си заминал.

Друга група имаше 5% од корисниците кои се изгубија на екранот каде што апликацијата ги поттикнува да изберат една од сите календарски апликации на нивниот паметен телефон. Корисниците би избирале различни календари одново и одново, а потоа едноставно излегувале од апликацијата. Излегува дека имало проблем со UX: откако некое лице избрало календар, морало да кликне Готово во горниот десен агол. Само што не го видоа сите корисници.

Првиот екран на апликацијата во воздухот

Во нашиот графикон, видовме дека околу 30% од корисниците не одат подалеку од првиот екран: ова се должи на фактот дека ние сме прилично агресивни во притискањето на корисникот да се претплати. На првиот екран, апликацијата ве поттикнува да се регистрирате користејќи Google или Triplt и нема информации за прескокнување на регистрацијата. Од оние кои го напуштаат првиот екран, 16% од корисниците кликнуваат на „Повеќе“ и се враќаат повторно. Дознавме дека бараат начин како интерно да се регистрираат во апликацијата и ќе го објавиме во следното ажурирање. Дополнително, 2/3 од оние кои веднаш заминуваат, воопшто не кликнуваат ништо. За да дознаеме што им се случува, направивме топлинска карта. Излегува дека клиентите кликнуваат на списокот со функции на апликацијата што не се линкови за кликање.

Снимајте микро-момент

Често можете да видите луѓе како газат патеки покрај асфалтираниот пат. Задржувањето е обид да се пронајдат овие патеки и, ако е можно, да се сменат патиштата.

Се разбира, лошо е што учиме од вистински корисници, но барем почнавме автоматски да ги следиме шемите што укажуваат на кориснички проблем во апликацијата. Сега менаџерот на производи добива известувања по е-пошта доколку се појават голем број „јамки“ - кога корисникот се враќа на истиот екран одново и одново.

Ајде да погледнеме кои шеми во траекториите на корисниците се генерално интересни да се бараат за да се анализираат проблемите и областите на раст на апликацијата:

• Јамки и циклуси. Јамките споменати погоре се кога еден настан се повторува во траекторијата на корисникот, на пример, календар-календар-календар-календар. Јамка со многу повторувања е јасен показател за проблем со интерфејсот или недоволно обележување на настанот. Циклусот е исто така затворена траекторија, но за разлика од циклусот вклучува повеќе од еден настан, на пример: гледање историја на летот - додавање лет - прегледување историја на летови.
• Flowstoppers - кога корисникот поради некоја пречка не може да го продолжи своето посакувано движење низ апликацијата, на пример, екран со интерфејс кој не е очигледен за клиентот. Ваквите настани забавуваат и ја менуваат траекторијата на корисниците.
• Точките на бифуркација се значајни настани по кои се одвојуваат траекториите на клиентите од различни типови. Особено, ова се екрани кои не содржат директна транзиција или повик за акција до целното дејство, што ефективно ги турка некои корисници кон него. На пример, некој екран кој не е директно поврзан со купување содржина во апликација, но на кој клиентите се склони да купуваат или не купуваат содржина, ќе се однесуваат поинаку. Точките на бифуркација можат да бидат точки на влијание врз постапките на вашите корисници со знак плус - тие можат да влијаат на одлуката за купување или кликнување, или знак минус - тие можат да утврдат дека по неколку чекори корисникот ќе ја напушти апликацијата.
• Прекинатите точки на конверзија се потенцијални точки на бифуркација. Можете да ги замислите како екрани што би можеле да поттикнат целна акција, но немојте. Ова може да биде и момент во време кога корисникот има потреба, но ние не ја задоволуваме затоа што едноставно не знаеме за тоа. Анализата на траекторијата треба да овозможи оваа потреба да се идентификува.
• Точка на одвлекување - екрани/појавни прозорци кои не му даваат вредност на корисникот, не влијаат на конверзијата и можат да ги „заматат“ траекториите, одвлекувајќи го корисникот од целните дејства.
• Слепи точки се скриени точки на апликацијата, екрани и функции до кои корисникот е многу тешко да стигне.
• Одводи – точки каде протекува сообраќајот

Генерално, математичкиот пристап ни овозможи да разбереме дека клиентот ја користи апликацијата на сосема поинаков начин отколку што обично мислат менаџерите на производи кога се обидуваат да планираат некое стандардно сценарио за користење за корисникот. Седејќи во канцеларија и присуствувајќи на најкул конференциите за производи, сè уште е многу тешко да се замисли сета разновидност на реални теренски услови во кои корисникот ќе ги реши своите проблеми користејќи ја апликацијата.

Ова ме потсетува на голема шега. Тестер влегува во бар и нарачува: чаша пиво, 2 чаши пиво, 0 чаши пиво, 999999999 чаши пиво, гуштер во чаша, -1 чаша пиво, qwertyuip чаши пиво. Првиот вистински клиент влегува во барот и прашува каде е тоалетот. Шанкот се запали и сите умираат.

Аналитичарите на производи, длабоко нурнати во овој проблем, почнаа да го воведуваат концептот на микромомент. На современиот корисник му треба моментално решение за својот проблем. Google почна да зборува за ова пред неколку години: компанијата ги нарече ваквите кориснички акции микро-моменти. Корисникот се расејува, случајно ја затвора апликацијата, не разбира што се бара од него, повторно се најавува еден ден подоцна, повторно заборава, а потоа го следи линкот што му го испратил пријател во месинџерот. И сите овие сесии можат да траат не повеќе од 20 секунди.

Така, почнавме да се обидуваме да ја поставиме работата на службата за поддршка за вработените да можат да разберат што е проблемот речиси во реално време. До моментот кога некое лице ќе дојде на страницата за поддршка и ќе почне да го пишува своето прашање, можеме да ја одредиме суштината на проблемот, знаејќи ја неговата траекторија - последните 100 настани. Претходно, ја автоматизиравме дистрибуцијата на сите барања за поддршка во категории користејќи ML анализа на текстовите на барањата за поддршка. И покрај успехот на категоризацијата, кога 87% од сите барања се правилно распределени во една од 13-те категории, работата со траектории може автоматски да го најде најсоодветното решение за ситуацијата на корисникот.

Не можеме брзо да објавиме ажурирања, но можеме да го забележиме проблемот и, доколку корисникот го следи сценариото што веќе го видовме, испратете му известување за притисни.

Гледаме дека задачата за оптимизирање на апликација бара богати алатки за проучување на траекториите на корисниците. Понатаму, знаејќи ги сите патеки што ги следат корисниците, можете да ги поплочите потребните патеки и со помош на приспособена содржина, притисни известувања и адаптивни елементи на интерфејсот „од рака“ да го доведете корисникот до насочени дејства кои најдобро одговараат на неговите потреби и носат пари , податоци и друга вредност за вашиот бизнис.

Што да се забележи

• Проучувањето на конверзија на корисници само со користење на инки како пример значи губење на богатите информации што ни ги дава самата апликација.

• Анализата на задржување на траекториите на корисниците на графиконите ви помага да видите кои функции ги користите за да ги задржите корисниците или, на пример, да ги поттикнете да се претплатат.
• Алатките за задржување помагаат автоматски, во реално време, да се следат обрасците што укажуваат на проблеми на корисниците во апликацијата, да се пронајдат и затвораат грешки каде што тешко се забележуваат.

• Тие помагаат да се пронајдат неочигледни модели на однесување на корисниците.

• Алатките за задржување овозможуваат изградба на автоматизирани ML алатки за предвидување на клучните настани и метрика на корисникот: загуба на корисник, LTV и многу други метрики кои лесно се одредуваат на графиконот.

Градиме заедница околу Retentioneering за слободна размена на идеи. Можете да ги замислите алатките што ги развиваме како јазик на кој аналитичарите и производите од различни мобилни и веб-апликации можат да разменуваат увиди, најдобри техники и методи. Можете да научите како да ги користите овие алатки во курсот Хакирање на раст: аналитика на мобилни апликации Бинарен округ.

Извор: www.habr.com