Презентация: как работать с devtodev?

Сам доклад построен на примерах. Каждый слайд – та или иная стандартная ситуация, которая может возникнуть в процессе работы над мобильной игрой.

Но сначала напомним о самом devtodev. Это инструмент, который предоставляет статистику по 6 магазинам приложений, а также анализирует пользовательское поведение и выдает эти данные. Другими словами, сервис помогает собирать и анализировать данные, с помощью которых разработчики принимают решения о дальнейшем развитии своего продукта. 

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

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

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

Например, вы решили провести внутри игры маркетинговую акцию и хотите посмотреть, насколько успешно она проходит.

Оценить качество проще всего по тому, растет ли доход. Devtodev позволяет отследить данные по сумме дохода практически в режиме реального времени с агрегацией в 5 минут. Чуть выше можно видеть два графика — это рост дохода за текущий и прошедший дни. Как мы видим, доход вырос по сравнению с предыдущим днем. Значит, акция прошла успешно.

Вся оперативная информация доступна на стандартном дашборде приложения. 

Но давайте вернемся немного назад и поговорим о том, какие вообще бывают типы метрик и зачем они нужны. 

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

Одна из них — доход.

Давайте представим, что у вас есть три приложения (например, под iphone, ipad, android), и вы хотите оценить свой доход. Можно вывести на одном графике суммарный доход, а можно детализировать, чтобы понять какое приложение приносит наибольший.

Но доход — это финальный результат ваших трудов, его мониторинг мало помогает в принятии решений о каких-то конкретных улучшениях.

Чуть выше уже упоминалось, что увеличить доход можно двумя способами: привлечением пользователей и увеличением среднего дохода с каждого.

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

На начальном этапе в качестве метрик вовлеченности используются длина сессии, показатели возвратов и оттока пользователей, а также DAU/MAU.

Логично, что сами по себе эти метрики вам скажут немного — нужно с чем-то сравнивать. Если у вас уже есть подобные игры, то вы можете просто сопоставить данные по ним и посмотреть на разницу. 

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

Или, например, мы поменяли что-то и теперь хотим узнать, повлияло ли это на вовлеченность наших игроков. Можно построить сравнительный график для одного приложения за два временных периода.

Судя по графику, наше обновление увеличило среднюю длину сессии. Отлично!

Но время сессии — это только один показатель, и он не говорит о том, что игрок будет возвращаться. 

Процент возвратов показывает, насколько игра интересна нашим пользователям, поэтому на этапе запуска проекта на него обращается особое внимание.

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

Само понятие возвратов тесно связано с когортным анализом. Мы определяем retention как процент пользователей, которые начали играть в момент времени А и продолжали играть в момент Б. 

В качестве примера приведу данные по одному приложению. Это игра в жанре city-builder. Суть в следующем: мы закупили трафик в своей любимой рекламной сетке. Прошло 14 дней и мы решили посмотреть, насколько качественным оказались инсталлы. Выглядеть это будет примерно как на графике чуть ниже:

Судя по всему, рекламная кампания прошла весьма успешно: 24% пользователей продолжают играть спустя 2 недели. Что удивительно, это даже больше, чем обычно, а значит трафик был действительно качественный. 

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

Например, на втором уровне задерживается больше всего игроков. Возможно, что-то тут не так…нужно посмотреть на отток пользователей с этого уровня, чтобы делать какие-то выводы. Давайте вернемся к нашей игре и посмотрим, на каких уровнях игроки перестают играть.

Обычно пользователи массово отваливаются сначала на самых первых шагах, если их ожидания от игры не оправдываются. Например, он ждал крутой RPG, а получил ферму с космическими свинками. Затем они побегут, когда вы начнете просить денег. Ну и, наконец, на высоких уровнях игра может просто надоесть: недостаточно интересно, нет развития. На таком графике всю эту историю можно отследить и на основе этого подправить что-то в игровом балансе.

Если помните, на предыдущем графике у нас был большой пик на втором уровне, т. е. Наибольшее количество наших игроков там задерживалось.

А здесь видим, что на этом уровне отток больше 80%. Если при этом нам известно, что никакой монетизации тут еще нет, то очевидно такой большой показатель отказов связан с обманутыми ожиданиями. Или закончился туториал, а что делать дальше — неочевидно.

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

Конечно, одной вовлеченности мало для того, чтобы оценить структуру вашей аудитории. И поскольку конечная цель всё-таки чаще всего доход, а не мир во всем мире, то хорошо бы понимать, откуда вы его получаете.

Для этого существует группа метрик монетизации.

ARPU и ARPPU показывают сколько в среднем приносит один пользователь и один платящий пользователь. 

Кроме того, полезно посчитать процентную долю платящих, количество платежей на пользователя и средний чек.

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

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

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

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

Для каждого подключенного приложения выдается отчет по транзакциям, в котором отделяются реальные и фиктивные платежи. Выглядит это примерно как на слайде чуть выше.

Но это только часть возможностей devtodev. Сервис также предоставляет статистику по шести магазинам приложений: вы можете следить за определенными чартами, или за позициями определенных приложений в чартах.

При разработке интерфейса особое внимание уделялось возможностям по работе над большим количеством проектов, поэтому данные по всем метрикам вы можете смотреть для одного проекта, сравнивать проекты между собой, или получать суммарные данные для группы приложений. Данные идут из двух источников: SDK и аккаунта разработчика в iTunes Connect или Google Play.

Оригинальную презентацию можно найти здесь.