Совсем недавно мы в сервисе аналитики мобильных и веб-приложений devtodev выпустили новый отчёт Performance. Отчёт уже прошёл проверку нашими клиентами, и собрал прямо-таки шквал похвальных отзывов. Мы решили пояснить подробнее, чем же он так хорош.



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

И вот за счёт чего мы этого добились:

Набор метрик. В отчёте всего 6 метрик. Это:

• Active Users (DAU) — количество уникальных пользователей, которые заходили в проект в течение дня;
• New Users — количество уникальных пользователей, которые в этот день впервые посетили приложение;
• Gross — общая сумма денег, которую за этот день заплатили пользователи;
• ARPU (Average Revenue Per User) — средний доход с одного активного пользователя за этот день; рассчитывается как Gross / Active Users;
• 1-day retention — процент пользователей, которые вернулись в приложение спустя 1 день после первого своего визита. Как правило, именно эту метрику применяют, говоря о краткосрочном удержании пользователей: понравился ли им внешний вид приложения, поняли ли они, чем оно может быть им полезно;
• 7-days retention — процент пользователей, которые вернулись в приложение спустя 7 дней после первого визита. Пользователи, оставшиеся в приложении на 7 дней, уже более детально в нём разобрались и с меньшей вероятностью покинут его в ближайшие дни.

Таким образом, набор метрик включает в себя и метрики масштаба приложения, анализируя которые, можно понять, насколько оно велико, растёт оно или нет (речь о метриках Active Users, New Users, Gross), и качественные метрики, которые говорят о внутренних изменениях проекта: стал ли проект лучше удерживать пользователей, стали ли пользователи в среднем больше платить (ARPU, 1-day retention, 7-days retention). Такой набор метрик является оптимальным и позволяет сразу взглянуть и на аудиторию, и на деньги, и на качественный показатель удержания.

Период анализа в 30 дней. Мы выбирали между 7, 14 и 30 днями и остановились на 30 днях, потому что именно так можно лучше всего увидеть и актуальную динамику проекта, и сезонное поведение пользователей. Допустим, если в вашем проекте наблюдается подъём выручки каждую пятницу и субботу (что вполне характерно для мобильных игр), то на периоде в 30 дней вы вполне это выявите, а 7 или 14 дней для этого недостаточно. То есть по каждой метрике вы можете видеть, как она себя вела за последние 30 дней, отслеживать её динамику, тренд и сезонность.


Разрезы по странам и девайсам. Мы увидели, что наши клиенты как правило строят отчёты именно в этих разрезах и извлекли из этого знания пользу. Действительно, чаще всего хочется узнать структуру выручки или аудитории именно по странам и по платформам. Есть ещё полезный разрез по источникам трафика, но такой разрез попросту есть не у всех.


Отчет открывается по умолчанию. Ранее по умолчанию у нас открывался другой отчёт, который обновлялся раз в 5 минут и показывал накопительные значения количества пользователей и денег в режиме реального времени в сравнении со вчерашним днём. Против этого отчёта мы ничего не имеем, он остался в devtodev, однако мы решили, что новый отчёт Performance отвечает на больше вопросов. Таким образом, мы хотим минимизировать барьеры между разработчиком приложения и самим приложением, между данными и решениями, принятыми на их основе.

Итак, на какие вопросы можно ответить с помощью отчёта Performance:

• каков размер аудитории проекта?
• сколько пользователей приходит в день?
• сколько денег они платят?
• как проект удерживает пользователей?
• как все эти показатели менялись за последние 30 дней?
• были ли качественные изменения в проекте, как они отразились на его масштабе?
• каковы наиболее популярные по аудитории и по деньгам страны и платформы?

В частности, с помощью одного лишь отчёта Performance можно решить следующие гипотетические (и вполне вероятные) кейсы:

1. У проекта падает доход. Мы смотрим на аудиторию и на средний доход с пользователя (ARPU).




На основании этого мы понимаем, куда бежать, к маркетологу или к геймдизайнеру, и что делать, покупать новый трафик или искать причины внутри самого продукта, оценивать его изменения за последние 30 дней (в приведённом нами примере это как раз тот случай!).

2. У проекта упала аудитория. Гипотез две: либо стало приходить меньше новичков, либо проект стал хуже удерживать уже имеющихся пользователей (смотрим на retention). Если меньше новичков — идём к маркетологу и спрашиваем, что случилось (может, просто деньги на трафик закончились), если упал retention — смотрим, что мы делали в проекте за последние дни. Более того, сравнивая поведение 1-day retention и 7-days retention, мы можем оценить, связано ли падение с изменением первой сессии пользователя или с основным циклом использования приложения (core loop).

3. Что же мы всё о падениях-то. Допустим, мы заметили качественный рост 1-day retention (допустим, за последние 30 дней мы переделали первую сессию, и пользователи стали лучше удерживаться с самого начала). Здесь же мы можем посмотреть, как повлияло это качественное изменение на рост аудитории и дохода.


Обращаем ваше внимание, всё это делается в одном месте, в одном отчёте, без единого клика на нём. Он открывается по умолчанию: вы запускаете devtodev и сразу видите основную информацию о проекте.

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