Утримати користувача в мобільному додатку це ціла наука. Її основи у нашій статті на 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-повідомлень та адаптивних UI елементів «за ручку» привести користувача до цільових дій, які найкраще відповідають його потребам і приносять гроші, дані та інші цінності для вашого бізнесу.
Що взяти на замітку
- Дослідити конверсію користувачів тільки на прикладі вирв – втрачати багату інформацію, яку дає нам сама програма.
- Retentioneering-аналіз траєкторій користувачів на графах допомагає побачити, за допомогою яких функцій ви утримуєте користувачів чи, наприклад, стимулюєте їх до передплати.
- Інструменти Retentioneering допомагають автоматично в режимі реального часу відстежувати патерни, які говорять про проблему користувачів у додатку, знаходити та закривати баги там, де їх важко було помітити.
- Вони допомагають знаходити неочевидні патерни поведінки користувачів.
- Інструменти Retentioneering дають можливість побудови автоматизованих ML інструментів для передбачення ключових подій з користувачем та метрик: втрату користувача, LTV та багато інших метриків, які легко визначаються на графі.
Ми створюємо спільноту навколо Retentioneering для вільного обміну ідеями. Можна сприймати інструментарій, який ми розробляємо, як мову, якою аналітики та продукти з різних мобільних та веб-додатків зможуть обмінюватися інсайтами, найкращими техніками та методами. Навчитися користуватися цими інструментами можна на курсі Binary District.
Джерело: habr.com