Мінімальні показники життєздатності для мобільних додатків

Одна з найбільш популярних ідей, що з'явилася в індустрії розробки в останні роки, — це концепція Minimum Viable Product, скорочено MVP. У двох словах, це стратегія розробки мінімального по функціональності продукту, що дозволяє отримати зворотний зв'язок від користувачів. Але можна переносити цю концепцію в сферу мобільних додатків і якщо ні, то чи є альтернатива? Ми в Alconost перевели відмінну статтю, яка відповідає на це питання. Всім, хто має справу з мобільного розробкою — читати обов'язково.



Мій досвід показує, що в світі мобільних freemium-додатків стратегія мінімально життєздатного продукту не завжди застосовна — ця концепція не кращим чином переноситься на мобільні платформи. Адже розроблялася для вебу — платформи, що дозволяє миттєве і універсальне поширення версій продукту. На мобільних ж платформах це неможливо. Крім того, з-за різної якості мобільних девайсів «залізо» сильніше, ніж у вебі, впливає на відчуття користувачів від програми на мобільних платформах (особливо в ігровій сфері).

Розробникам мобільних додатків не варто витрачати час на те, щоб вивчати вплив зміни кожного продукту окремо. Чому? Із-за різноманітності пристроїв, за необхідності завантажувати нові версії (що призводить до великої кількості активних версій одночасно), через затримки між завантаженням і публікацією в деяких сторах. Впроваджувати в продукт зміни по одному нерозумно — користувачі просто розбіжаться з-за постійних скачувань все нових і нових оновлень. А щоб заміряти вплив таких змін, готуйтеся багато днів чекати публікації нового релізу.

Щоб методологія мінімально життєздатного продукту працювала для мобайла, розробники повинні бути знайомі з портфелем показників, що дають більш правдиве уявлення про продукт. Це мінімальні показники ефективності (minimum viable metrics) — мінімальний набір пріоритетних показників, які відслідковуються з моменту запуску MVP і постійно поліпшуються з кожної стратегічної, нехай і нешвидкої, ітерацією. Модель мінімальних показників ефективності вбудовує аналітику в концепцію і стратегію розвитку продукту, а також включає мінімальну аналітику вимоги до запуску.

Для мобільних додатків існує чотири групи показників, включаючи ті, які говорять про мінімальної ефективності: утримання користувачів, монетизація, залучення і це. Як по мені, утримання користувачів — це найважливіша група показників. Пріоритетність залишилися, може змінюватись в залежності від типу розроблювального додатка. Я впевнений, що пріоритезація того, що планується зробити в межах ітерації, повинна бути гнучкою і ґрунтуватися на поточних показниках. Пріоритет варто віддавати питань, що забезпечує найкращий ROI (повернення інвестицій).

Показники утримання користувачів

1.1. Утримання на 1-7 день 14 день, 28 день, 90 день і 365 день
Коли я кажу «N-й день», я маю на увазі відсоток користувачів, які повернулися в додаток на N-й день. Наприклад, утримання на 1-й день на рівні 50% означає, що 50% користувачів повернулися в додаток на наступний день після його установки.

Як я вже писав, я вважаю утримання користувачів найважливішим показником (точніше, групою показників) для відстеження мобільними розробниками з двох причин:

1) утримання користувачів дозволяє обчислити приблизну тривалість користування додатком для підрахунку доходу з користувача, і розуміння цього показника (або, принаймні, спроба його компетентній реалістичної оцінки) — єдиний спосіб залучити користувачів, зберігаючи позитивний фінансовий результат;

2) утримання користувачів відображає їх «задоволеність»: це показник того, наскільки добре ваш додаток відпрацьовує свій основний сценарій використання. Немає сенсу намагатися поліпшувати інші показники при низькому стягнення користувачів.



Я розраховую утримання користувачів на перспективній основі, тобто співвідношу утримання на N-й день з днем реєстрації користувачів. Таким чином, якщо 100 користувачів приєдналися сьогодні, 50 повернулися завтра і 40 — післязавтра, то показники утримання на 1-й день і на 2-й день складуть, відповідно, 50% і 40%. У цьому сенсі показник «дивиться назад». Такий підхід спрощує відстеження поліпшень у зв'язку з новими версіями (або запусками нових можливостей), адже розробник може бачити, як конкретно поліпшуються показники утримання користувачів по днях після певного моменту.

Я відстежую утримання користувачів на 28-й день, а не на 30-й, тому що 28-й день враховує тижневий цикл використання, що іноді дозволяє виявити цікаві особливості окремих днів тижня. Я розміщую все показники утримання користувачів на одному графіку у вигляді лінійних діаграм з можливістю керувати відображенням кожної з них. Сьогоднішні показники я маю так, щоб з рухом по осі Х до поточної дати зліва направо показники падали до 0 (тому що підрахунок утримання користувачів на 7 день для вчорашнього дня неможливий).

Стратегію поліпшення показників утримання користувачів я обговорював цієї статті, але я вірю, що в цілому упевнені показники утримання досягаються донесенням якості і глибини на ранніх етапах використання програми, освоєнням повторюваного залучення в основний цикл на наступних етапах і наданням достатнього контенту для задоволення самих захоплених користувачів на пізніх етапах.

1.2. Активні користувачі за день (DAU)
Кількість людей, які користуються додатком в певний день.

1.3. Нові користувачі за день (DNU)
Кількість людей, які встановили і відкрили додаток в певний день.

2. Показники монетизації

2.1. Дохід
Я відстежую дохід на щоденній основі і поділяю за джерелами: продажі всередині програми і реклама. В підсумку в мене виходить складова лінійна діаграма.

2.2. Середній дохід з користувача (ARPU)
За цим показником я стежу щодня і вираховується його як загальний дохід за день, поділений на кількість користувачів, що використали додаток в цей день (DAU). Якщо відслідковувати його за день, ARPU співпаде з іншим широко використовуваним показником ARPDAU, але вони розходяться, якщо обчислювати ARPU за більш тривалий період.

2.3. Середній дохід з граючого користувача (ARPPU)
За ним я стежу так само, як і за ARPU, і вираховується його як загальний дохід, поділений на кількість користувачів, що зробили внутрішньоігрові покупки.



2.4. Конверсія
Відстежується щодня. Це відсоток користувачів, що зробили внутрішньоігрові покупки. Я не відстежую рекламну «конверсію», показник конверсії враховує тільки внутрішньоігрові покупки.

3. Показники залученості

3.1. Середня і медіанна тривалість сесій
Я відстежую медіанну тривалість сесії, так як вважаю за краще не видаляти значення сігми >3 з набору даних. Скорочується або росте тривалість сесії — хороший індикатор змін залучення досвідчених користувачів. Цей показник відстежується по днях.

3.2. Середнє і медіанне кількість сесій
Відстежується і візуалізується так само, як і тривалість сесій.

4. Показники виральности

4.1. K-фактор
Це середня кількість додаткових користувачів, яких наводить кожен користувач. Для додатків це підрахувати дуже важко, оскільки мобільні платформи не враховують майже ніяких даних про джерела заходу в магазин додатків. Але мені здається, що оцінка До-фактора важлива, тому що це увеличивает окупність платного залучення користувачів.

Якщо додаток інтегровано в соціальну платформу зразок Twitter або Facebook (як, напевно, і повинно бути у відповідних випадках), відстеження «соціальних» запрошень — проста задача. цієї статті описані деякі втрачені можливості при запуску і в стратегії раннього розвитку Vine, які не повинен упускати ні один менеджер проектів розробки мобільних додатків.

Як «продати» мінімальні показники ефективності

Найбільш трудомісткою частиною впровадження цих метрик в середу розробки MVP може виявитися внутрішня «продаж» ідеї. Вона може бути непопулярним пропозицією в невеликих командах, які побоюються корпоративної бюрократії, гальмує творчий процес і розмиває бачення самих проривних додатків.

Але я як і раніше вірю: найкращою відповіддю буде те, що методи можна (і потрібно) зруйнувати, як і вертикалі продуктів. Методологія «бережливого стартапу» ефективна в разі веба, але вимагає доробки для використання на мобільних платформах, враховуючи фундаментальні відмінності між платформами. Розробка додатків для мобільних пристроїв вимагає більше покладатися на дані і менше — на інтуїцію при проектуванні.

Сенс цього посту в тому, щоб дати відправну точку для розвитку ініціативи по аналітиці для мінімально життєздатного мобільного продукту. Для цього я також створив шаблон панелі управління (вихідний код тут), який дасть деякий візуальне уявлення про верстку та форматування таблиць. Всі дані рандомізовані, але технічні показники можуть використовуватися шляхом редагування функції для обчислення дані в шаблоні.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.