Как Retentioneering се внедрява в App in the Air

Задържането на потребител в мобилно приложение е цяла наука. Авторът на курса описа основите му в нашата статия на VC.ru Growth Hacking: анализ на мобилни приложения Максим Годзи, ръководител на отдела за машинно обучение в 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: след като човек избере календар, трябва да щракне върху Готово в горния десен ъгъл. Просто не всички потребители го видяха.

Първи екран на App in the Air

В нашата графика видяхме, че около 30% от потребителите не надхвърлят първия екран: това се дължи на факта, че сме доста агресивни в натискането на потребителя да се абонира. На първия екран приложението ви подканва да се регистрирате с Google или Triplt и няма информация за пропускане на регистрацията. От тези, които напускат първия екран, 16% от потребителите кликват върху „Още“ и се връщат отново. Разбрахме, че те търсят начин за вътрешна регистрация в приложението и ще го пуснем в следващата актуализация. Освен това 2/3 от тези, които си тръгват веднага, изобщо не кликват нищо. За да разберем какво се случва с тях, изградихме топлинна карта. Оказва се, че клиентите кликват върху списък с функции на приложението, които не са връзки, върху които може да се кликне.

Уловете микромомент

Често можете да видите хора, които утъпкват пътеки до асфалтовия път. Задържането е опит да се намерят тези пътища и, ако е възможно, да се сменят пътищата.

Разбира се, лошо е, че се учим от реални потребители, но поне започнахме автоматично да проследяваме модели, които показват потребителски проблем в приложението. Сега продуктовият мениджър получава известия по имейл, ако се появят голям брой „цикли“ – когато потребителят се връща към същия екран отново и отново.

Нека да разгледаме какви модели в траекториите на потребителите обикновено са интересни за търсене, за да анализираме проблемите и областите на растеж на приложението:

• Цикли и цикли. Споменатите по-горе цикли са, когато едно събитие се повтаря в траекторията на потребителя, например календар-календар-календар-календар. Цикъл с много повторения е ясен индикатор за проблем с интерфейса или недостатъчно маркиране на събитието. Цикълът също е затворена траектория, но за разлика от цикъла той включва повече от едно събитие, например: преглед на хронологията на полета - добавяне на полет - преглед на хронологията на полета.
• Flowstoppers - когато потребителят поради някакво препятствие не може да продължи желаното от него движение през приложението, например екран с интерфейс, който не е очевиден за клиента. Такива събития забавят и изместват траекторията на потребителите.
• Точките на бифуркация са значими събития, след които се разделят траекториите на клиенти от различен тип. По-специално, това са екрани, които не съдържат директен преход или подканваща фраза към целевото действие, което ефективно тласка някои потребители към него. Например, някои екрани, които не са пряко свързани със закупуване на съдържание в приложение, но на които клиентите са склонни да купуват или да не купуват съдържание, ще се държат по различен начин. Точките на бифуркация могат да бъдат точки на влияние върху действията на вашите потребители със знак плюс - те могат да повлияят на решението за извършване на покупка или кликване или знак минус - те могат да определят, че след няколко стъпки потребителят ще напусне приложението.
• Прекъснатите точки на преобразуване са потенциални бифуркационни точки. Можете да мислите за тях като за екрани, които могат да подтикнат към целево действие, но не го правете. Това също може да бъде момент, когато потребителят има нужда, но ние не я удовлетворяваме, защото просто не знаем за това. Анализът на траекторията трябва да позволи да се идентифицира тази необходимост.
• Точка на отвличане на вниманието - екрани/изскачащи прозорци, които не предоставят стойност на потребителя, не влияят на преобразуването и могат да „замъглят“ траекториите, отвличайки вниманието на потребителя от целевите действия.
• Слепите петна са скрити точки на приложението, екраните и функциите, които са много трудни за достигане от потребителя.
• Дренажи – точки, където изтича трафик

Като цяло, математическият подход ни позволи да разберем, че клиентът използва приложението по напълно различен начин, отколкото продуктовите мениджъри обикновено мислят, когато се опитват да планират някакъв стандартен сценарий на използване за потребителя. Седейки в офиса и посещавайки най-готините продуктови конференции, все още е много трудно да си представим цялото разнообразие от реални полеви условия, в които потребителят ще реши проблемите си с помощта на приложението.

Това ми напомня за страхотен виц. Тестер влиза в бар и поръчва: чаша бира, 2 чаши бира, 0 чаши бира, 999999999 чаши бира, гущер в чаша, -1 чаша бира, qwertyuip чаши бира. Първият истински клиент влиза в бара и пита къде е тоалетната. Барът избухва в пламъци и всички умират.

Продуктовите анализатори, дълбоко потопени в този проблем, започнаха да въвеждат концепцията за микромомент. Съвременният потребител се нуждае от незабавно решение на проблема си. Google започна да говори за това преди няколко години: компанията нарече такива потребителски действия микромоменти. Потребителят се разсейва, случайно затваря приложението, не разбира какво се иска от него, влиза отново ден по-късно, забравя отново и след това следва връзката, която му е изпратил приятел в месинджъра. И всички тези сесии могат да продължат не повече от 20 секунди.

Затова започнахме да се опитваме да настроим работата на услугата за поддръжка, така че служителите да могат да разберат какъв е проблемът почти в реално време. Докато човек дойде на страницата за поддръжка и започне да пише въпроса си, ние можем да определим същността на проблема, знаейки неговата траектория - последните 100 събития. Преди това автоматизирахме разпределението на всички заявки за поддръжка в категории, използвайки ML анализ на текстовете на заявките за поддръжка. Въпреки успеха на категоризацията, когато 87% от всички заявки са правилно разпределени в една от 13-те категории, работата с траектории може автоматично да намери най-подходящото решение за ситуацията на потребителя.

Не можем да пуснем актуализации бързо, но можем да забележим проблема и, ако потребителят следва сценария, който вече сме видели, да му изпратим насочено известие.

Виждаме, че задачата за оптимизиране на приложение изисква богати инструменти за изучаване на потребителските траектории. Освен това, знаейки всички пътища, които поемат потребителите, можете да проправите необходимите пътища и с помощта на персонализирано съдържание, насочени известия и адаптивни елементи на потребителския интерфейс „на ръка“ водят потребителя към целеви действия, които най-добре отговарят на неговите нужди и носят пари , данни и друга стойност за вашия бизнес.

Какво да вземете под внимание

• Изучаването на преобразуването на потребителите само с помощта на фунии като пример означава загуба на богатата информация, която самото приложение ни дава.

• Анализът на задържането на траекториите на потребителите върху графиките ви помага да видите кои функции използвате, за да задържите потребителите или например да ги насърчите да се абонират.
• Инструментите за задържане помагат автоматично, в реално време, да проследяват модели, които показват потребителски проблеми в приложението, да намират и затварят грешки, когато са били трудни за забелязване.

• Те помагат да се намерят неочевидни модели на потребителско поведение.

• Инструментите за задържане правят възможно изграждането на автоматизирани инструменти за машинно обучение за прогнозиране на ключови потребителски събития и показатели: загуба на потребители, LTV и много други показатели, които лесно се определят на графиката.

Ние изграждаме общност около Retentioneering за свободен обмен на идеи. Можете да мислите за инструментите, които разработваме, като за език, на който анализатори и продукти от различни мобилни и уеб приложения могат да обменят прозрения, най-добри техники и методи. Можете да научите как да използвате тези инструменти в курса Growth Hacking: анализ на мобилни приложения Двоичен район.

Източник: www.habr.com