Более 60% пользователей совершают покупки через мобильные приложения, а не через веб-сайты. С помощью метрик мобильного приложения вы поймёте, сколько времени пользователь проводит в приложении, почему оставляет корзину с товарами, сколько вы тратите на пользователя и куда ещё уходит бюджет.

Мы разрабатываем мобильные приложения более 13 лет и в каждом проекте уделяем внимание аналитике метрик. В статье расскажем, за какими показателями стоит следить и как их посчитать.

Финансовые и поведенческие метрики мобильного приложения

Все метрики мобильного приложения делятся на 2 группы — по влиянию на показатели проекта.

Финансовые метрики напрямую связаны с юнит-экономикой: выручка, прибыль, средний доход с пользователя, цена привлечения пользователя, стоимость целевого действия.

Поведенческие метрики показывают взаимодействие пользователя с приложением. Примеры: возвращаемость, среднее время сеанса, количество экранов за сеанс, количество активных пользователей за период, частота неожиданных закрытий приложения.

Метрики часто представляют в виде взаимосвязанного «дерева», где финансовые показатели находятся в кроне, а поведенческие — у корней.

Финансовые метрики, такие как выручка или коэффициент окупаемости (ROI) — это индикаторы экономики бизнеса. Они измеряют прибыльность, но ничего не говорят о том, как пользователи взаимодействуют с приложением.

Когда финансовая метрика растёт, значит, что-то поменялось и в связанной поведенческой. Может получиться такая цепочка: количество пользователей → процент активных пользователей → процент платящих пользователей → выручка.

Дерево метрик помогает находить и визуализировать связи между поведенческими метриками приложения и финансовыми. Например, в ecommerce-приложении есть связь между средним чеком и количеством просмотренных товаров за сессию.

Но есть и опасность: несуществующие связи. Представьте, что команда ecommerce-приложения по продаже мороженого добавила на главный экран карточки товаров. В результате продажи выросли. Кажется, что существует очевидная связь — новый UI повысил конверсию. А на самом деле тест прошёл в июне и на результаты повлияла сезонность покупок.

Опытный бизнес-аналитик поможет правильно выстроить дерево метрик в продукте, где ещё нет статистики использования. В команде Surf в каждом проекте по запросу клиента подключается бизнес-аналитик. Это позволяет выявить, где есть узкие места и сложности с развитием продукта, изменить подход и в итоге повысить прибыль.

Финансовые метрики

Давайте рассмотрим, из каких метрик может состоять дерево. Начнём с финансовых показателей.

Gross и Revenue

Gross и Revenue — это две основополагающие финансовые метрики. Именно они отражают заработок приложения.

Gross — это общая сумма, которую приложение заработало до вычета расходов. Она включает в себя все доходы: покупки в приложении, подписки, заработок с рекламы.

Revenue — это чистый доход приложения, который остаётся после вычета расходов из Gross — комиссии сторов, бюджета на маркетинг, зарплаты сотрудников и всех остальных издержек.

LifeTime Value (LTV)

LTV — это прибыль, которую бизнес получит от каждого клиента за всё время взаимодействия пользователя с приложением. Без этой метрики нельзя узнать оптимальную цену привлечения и удержания платящего пользователя.

Рассчитать LTV можно по разному, но основная идея всегда в том, чтобы оценить суммарную выручку от платящего пользователя. Один из самых простых способов — умножение средней прибыли от клиента за определённый период (например, месяц подписки) на средний срок «жизни» клиента в приложении.

Например, если цена месячной подписки 100 рублей и средний срок взаимодействия с клиентом — 5 месяцев, то LTV будет равен 500 рублей (100 рублей x 5 месяцев).

ARPU и ARPPU

ARPU показывает усреднённую выручку за одного пользователя приложения.

Допустим, ваш доход за год составляет в общем 100 000 рублей, а в приложении 1000 зарегистрированных пользователей. Чтобы посчитать ARPU, поделите общий доход на количество пользователей (не только платящих). Получается, что выручка за месяц будет 100 долларов.

ARPPU (Average Revenue Per Paying User) показывает средний доход на платящего пользователя.

Эта метрика рассчитывается почти так же, как ARPU, но при делении учитываются только платящие пользователи. Например, если в приложении 1000 пользователей, но из них совершают покупки только 200, то остальные 800 не учитываются при делении. Получается, что ARPPU будет 500 рублей.

ARPU и ARPPU — это тесно связанные метрики, которые показывают источник дохода приложения. Например, бывают ситуации, когда прибыль проекта растёт благодаря новым пользователям, а доход от существующих клиентов стоит на месте или уменьшается. В таком случае ARPU растёт, а ARPPU падает.

Customer Acquisition Cost (CAC)

CAC, или Customer Acquisition Cost (Стоимость привлечения клиента) показывает, сколько компания тратит на привлечение нового платящего пользователя.

CAC — один из главных показателей рентабельности. В прибыльном приложении эта метрика ниже среднего дохода, который приносит клиент (например, ARPU или LTV).

В устойчивой Unit-экономике CAC должен быть минимум в 3 раза выше ARPU. К примеру, при CAC 60 руб., средний доход с пользователя (ARPU) должен быть 180 руб. или выше. В реальной жизни это не всегда так — всё зависит от индустрии, бизнес-модели и целей проекта.

Cost per Install (CPI)

Эта метрика показывает, сколько стоит одна установка приложения. CPI помогает оценивать эффективность рекламных кампаний и управлять бюджетом.

Чтобы рассчитать CPI, разделите общую стоимость рекламной кампании на количество установок приложения из этой кампании. Представьте, что вы запустили рекламную кампанию с бюджетом 1000 рублей и нна принесла 500 установок. Если разделить бюджет на количество установок, получится, что CPI равен 2 рублям.

Cost Per Acquisition (CPA)

Эта метрика показывает стоимость привлечения одного платящего клиента и помогает оценить эффективность рекламы.

Чтобы рассчитать CPA, нужно разделить общую стоимость рекламной кампании на количество пользователей из этой компании — но только тех, кто совершил в приложении транзакцию. Например, в примере выше у нас была рекламная кампания с бюджетом в 1000 рублей. Она принесла нам 500 установок, но только 10 пользователей из этой когорты стали клиентами. Их мы и учтем при расчете. При делении получим, что CPA равен 100 рублям.

Поведенческие метрики

Поведенческие метрики показывают, как пользователи взаимодействуют с продуктом:

• Количество активных пользователей за месяц;
• Сколько пользователей вернулось в приложение после первого сеанса;
• Какие экраны они смотрели и сколько времени уделяли каждому;
• Как часто пользователи сталкиваются с неожиданным закрытием приложения.

Давайте рассмотрим эти метрики подробнее:

Monthly Active Users (MAU)

MAU — количество активных пользователей за месяц. При этом критерий активности варьируется — каждый бизнес выбирает его под свой контекст.

MAU помогает сопоставить вовлеченность пользователей и охват. Представьте, что какое-то приложение установили 100 000 пользователей, но показатель MAU держится на уровне 1000. Это говорит о том, что пользователи нецелевые или что приложением неудобно пользоваться.

Чтобы посчитать MAU, обычно следуют такому процессу:

1. Определение активности: Сначала определитесь, что считается «активным» взаимодействием. Это может быть вход в систему, просмотр страницы, совершение покупки и т.д.
2. Сбор Данных: Затем соберите данные обо всех пользователях, которые выполнили активные действия в течение месяца. Это можно сделать в системе мобильной аналитики: AppsFlyer, AppMetrica или любой другой.
3. Уникальные пользователи: Обязательно убедитесь, что мы считаем уникальных пользователей, а не сессии — если один и тот же пользователь входит в систему несколько раз в месяц, он должен быть посчитан только один раз.

Daily Active Users (DAU)

Эта метрика отличается от MAU только тем, что отражает количество активных уникальных пользователей за день, а не месяц.

При расчете DAU можно вывести средний показатель за определённый период или для какой-то одной когорты пользователей. Это полезно, например, когда вы хотите оценить качество лидов из конкретной маркетинговой кампании.

Retention Rate

Retention — это показатель удержания. Он говорит о проценте пользователей, которые воспользовались приложением больше одного раза.

Retention рассчитывают за несколько периодов: часто используются отметки 1 день, 7 дней и 28 дней.

Низкий retention в первый день может указывать, что приложение неудобно пользователю, и он закроет его до того, как поймет суть продукта. Например, если в приложении слишком много кнопок или постоянно всплывают рекламные блоки, то пользователь закроет приложение не дойдя до целевого действия — например, покупки.

7-и и 28-и дневные периоды используются, чтобы понять, насколько приложение интересно пользователю в краткосрочной и долгосрочной перспективе. В идеале эти показатели должны быть не сильно ниже, чем процент удержания пользователей на следующий день после установки.

Сессии

Пользовательская сессия — это период между открытием и закрытием приложения. Сессии объединяют сразу несколько полезных метрик, которые часто используются для оценки пользовательского опыта.

• Общее количество сессий за период: говорит о популярности приложения.
• Количество экранов за сессию: показывает, насколько глубоко пользователи взаимодействуют с приложением. Эта метрика особенна важна для таких направлений, как ecommerce, foodtech и entertainment — в таких приложениях есть каталоги и разнообразный контент.
• Среднее время сессии: сколько времени проходит между открытием и закрытием приложения. Эта метрика критична для приложений, которые зарабатывают за счёт контента, например, приложения The Hole — это аналог YouTube, который разработала команда Surf. А вот в приложениях, которые работают в основном в фоновом режиме (VPN, фитнес-трекеры) не всегда нужно увеличивать время сессии.
• Основные экраны: на каком экране пользователи проводят больше всего времени? Если вы знаете ответ,, то сможете эффективнее приоритизировать бэклог проекта и фокусироваться на ключевых для пользователя разделах приложения.

При анализе метрик всегда полезно следить за тем, как они меняются со временем: допустим, вы выпустили новый релиз и количество сессий резко упало. Скорее всего, виной этому критический баг.

Ещё одна стратегия, которую стоит взять на вооружение — находить корреляции между метриками и группировать пользователей в когорты по поведению. Например, в приложении есть часть пользователей, которые проводят в приложении мало времени, но смотрят много экранов. Возможно, они не могут найти то, что ищут, и здесь нужно добавить своевременную подсказку

Crash Rate

Crash Rate — важный показатель стабильности приложения. Он отражает частоту неожиданных закрытий, или «крашей».

Допустим, за определённый период вы зафиксировали 50 крашей, а общее количество сессий составило 10,000. Тогда Crash Rate будет рассчитываться следующим образом:

(50 / 10,000) × 100% = 0.5%

Это означает, что в 0.5% всех сессий приложение неожиданно закрылось.

Высокий crash rate обычно коррелирует с низким уровнем удовлетворенности пользователей и приводит к плохой оценке в сторах. Поэтому это один из главных показателей, за которым стоит следить — вне зависимости от специфики приложения.

Например, когда команда Burger King обратилась к нам с задачей редизайна и повышения надежности своего приложения, отслеживание Crash Rate помогло оценить частоту сбоев, разобраться, в чем их причины и увеличить отказоустойчивость iOS-приложения до 99,9%. Сегодня у приложения оценки в 4,8 и 4,5 балла в App Store и Google Play соответственно.

Как отслеживать метрики приложения

Вы можете использовать разные системы аналитики, настраивать в них события и визуализировать данные на дашбордах. Многие сервисы специально адаптированы под мобильные приложения. Самые популярные — это AppsFlyer, Firebase, и App Annie.

AppsFlyer

В AppsFlyer есть функционал для маркетинговой и пользовательской мобильной аналитики — этот сервис подходит для точечных UX-исследований благодаря инструментам для сегментации пользователей и для оценки эффективности рекламы.

У AppsFlyer необычная модель прайсинга — стоимость складывается из количества конверсий. Цена одной конверсии начинается с 7-и центов.

Firebase

Firebase — это платформа для разработки и релизов мобильных и веб-приложений от Google. В ней есть аналитические инструменты с фокусом на A/B-тестирование и отслеживание стабильности.

Платформа дает подробные отчеты о крашах приложения и упрощает запуск параллельных тестов — это полезно для сравнения разных версий интерфейса. Большая часть функций Firebase платная, но это касается в основном разработки. Аналитическая часть функционала бесплатна.

Data.ai (ранее App Annie)

Data.ai — инструмент мобильной аналитики с фокусом на анализ больших данных и создание отчетов с помощью ИИ. Инструмент сравнивает данные из вашего приложения с рыночными трендами и на основе этого рекомендует дальнейшие шаги развития. В сервисе есть полезные инсайты, но, как и с любым ИИ-продуктом, полагаться только на него не стоит.

Среди клиентов Data.ai в основном крупные компании, и стоимость рассчитывается индивидуально для каждого проекта.

Google Analytics

Для мобильной аналитики подходит и Google Analytics. Платформу можно использовать, например, когда у команды нет опыта работы со специализированными инструментами, но есть опыт в GA4. Правда, поскольку инструмент заточен в основном под веб-сайты, рассматривать его как основной — несколько «костыльное» решение из-за неудобной настройки и отсутствия многих отчетов из коробки.

Настройте аналитику мобильных приложений с командой Surf

Команда Surf станет надежным партнером в аналитике мобильных приложений. Мы проведем рыночные и пользовательские исследования и поможем настроить инструменты аналитики в вашем продукте за 1–3 недели.