Как выглядит идеальная система аналитики для игрового проекта24.02.2016 20:08

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

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

Начем с формулы Total Revenue = LTV * AU, где LTV (Lifetime Value) — средний объем денег с одного активного пользователя, а AU (Active Users) — аудитория проекта.

LTV при этом часто считают следующим образом: LTV = Lifetime * ARPDAU, где Lifetime — средний срок жизни пользователя в проекте, а ARPDAU (Average revenue per daily active user) — средний доход с одного активного пользователя в день, будь то платящий или неплатящий игрок.

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

Максимизация Lifetime

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

Поиск узких мест нужно начать с первого, что видит пользователь, — его стартовой сессии. Большая, если не бóльшая часть пользователей покидает проект именно во время первой сессии. Обычно это видно, если анализировать показатель Retention первого дня. Скажем, если из 100 пользователей, впервые пришедших в проект вчера, сегодня вернулось лишь 10, то Retention первого дня = 10%. Это сравнительно низкий показатель (в играх ориентиром обычно служит значение 30%), а причину надо искать где-то в начальном опыте взаимодействия пользователя и продукта.

Скриншот из системы devtodev

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

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

Если первая сессия пользователей устраивает и они уходят уже на последующих этапах — нужно разбираться, в чем дело. Надоедает пользоваться продуктом? Однообразная механика? Мало контента? Мало взаимодействия? Чтобы помочь разработчику ответить на эти вопросы, система аналитики должна четко выстраивать график Retention по дням, по уровням, по рангам — как угодно. Вполне вероятно, что где-то на графике найдется аномалия, которая поможет понять, в чем проблема.

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

Как бы то ни было, на этапе максимизации Lifetime разработчик ищет собственные ошибки: где несовершенство проекта мешает пользователю.

Максимизация ARPDAU

Если в воронках мы анализировали свои ошибки, то здесь анализируем успехи. Почему пользователь заплатил? Увидел выгодное предложение и купил по оптовой цене стартовый набор? В игровых автоматах докупил фишки, потому что закончились? В играх жанра match-3 купил дополнительный ход, чтобы пройти сложный уровень после многих попыток?

Задача — понять, почему тот или иной пользователь заплатил и можно ли искусственно создать подобные обстоятельства для других игроков, чтобы они тоже заплатили. Помогут в этом, как всегда, метрики и статистика: данные по платежам, конверсия в платящих, средний чек, повторные платежи, наиболее популярные товары. Все покупают маленький пакет фишек за $0,99? Попробуем поменять пакеты местами, чтобы на этом месте оказался средний за $4,99, или сделаем большую скидку на все остальные, чтобы их стало выгоднее покупать.

Процент платящих пользователей — меньше 0,5%? Добавим супервыгодный стартовый пакет, где игрок за три цента получает товаров на $100 (как это делает Slack: дарит $100 кредитов за прохождение пятиминутного опроса).

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

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

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

Советы от автоматизированного эксперта

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

Предположим, мы видим значение Retention второго дня = 17%. Много это или мало? Это идеальное место, чтобы система аналитики подсказала: Retention второго дня = 17% — это слишком мало для игр жанра match-3 и онлайн-казино, но очень круто, если вы делаете приложение «Твоя психологическая зарплата».

Еще примеры: на воронке первой сессии значительный провал? Система может сказать: «Проверьте четвертый шаг в обучении, у вас там проблема». 10% пользователей не проходят процесс загрузки? Система говорит, что на браузере Safari проект не запускается, а на всех остальных работает.

Главное преимущество провайдера аналитики в том, что он может сравнивать показатели всех проектов между собой и давать эту информацию разработчикам, которые не знают текущей рыночной ситуации. Информация, естественно, в контексте каждого конкретного продукта: как он себя показывает на фоне остальных. Простого показателя из серии «У вас неплохой ARPDAU для этой платформы, но проседает Retention» достаточно, чтобы считать совет полезным. У разработчика появляется надежный советчик, который поможет поднять его доход.

Автоматизированные уведомления

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

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

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

• Сколько новых пользователей пришло в проект.
• Как они платят, сколько денег заработано за неделю.
• Как эта неделя соотносится с прошлой и со средней неделей за последний период.

Помимо отчетов, могут быть еще и уведомления о важных событиях:

• Сегодня в первый раз было больше 100 DAU (число активных пользователей в день — прим. ред.).
• Сегодня в первый раз было больше 2 тысяч регистраций.
• На этой неделе был побит рекорд по DAU.
• Заработали больше $1000.
• Количество регистраций резко возросло.
• Количество успешных загрузок резко упало: возможно, отключился один из серверов.
• Появился новый «кит» — один пользователь заплатил больше 95% медианы остальных за месяц. Можно детально проанализировать его профиль и поведение.

Функциональность идеальной системы аналитики я вижу такой:

• визуализировать данные в любых разрезах;
• минимальными усилиями добавлять новые виды и источники данных;
• находить отклонения в данных и оповещать об этом оператора.

Предиктивная аналитика

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

Источник

Несколько примеров:

• Система считывает значения ARPU за предыдущие 6 месяцев ежедневно, выделяет тренд и сезонность (скажем, в пятницу наблюдается прирост на 5%) и формирует прогноз на несколько недель вперед.
• Система анализирует предыдущее поведение метрики 1-day Retention и формирует доверительный интервал, выход за пределы которого можно будет назвать аномальным.
• Если фактические значения метрики сильно отклоняются от доверительного интервала или от прогноза, система уведомляет об этом разработчика.
• Если пользователи игр с показателями Retention и ARPU, похожими на аналогичные показатели анализируемого проекта, за первую неделю пребывания в игре приносят в среднем по $0,15 — можно посмотреть, сколько они в тех же проектах принесут за первый месяц, и выдать значение, если не как прогноз, то как ориентир.
• Пользователь не был в проекте три дня — на основании поведения предыдущих пользователей можно рассчитать вероятность того, что он уйдет, чтобы разработчик отправил ему push-уведомление.

Аналитика должна помогать общаться с пользователями, а именно предлагать набор инструментов для обращения к каждому конкретному пользователю: push-уведомления, email-рассылки.

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

• Выделяем различные сегменты пользователей (по стране, по источнику трафика, по прохождению или непрохождению выделенного события и так далее).
• Для каждого сегмента оцениваем значения метрик, сопоставляем их между собой, следим в динамике.
• Если значения метрик или их динамика разработчика не устраивает — можно тут же, не сходя с места и не меняя вкладку в браузере, отправить им push-уведомления и впоследствии провести повторные замеры.

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

• Хочешь узнать, как твой проект удерживает пользователей? Отчет по Retention.
• Хочешь узнать, как изменились показатели с последним апдейтом? Когортный анализ.
• Хочешь узнать, где пользователи «отваливаются»? Воронки всех мастей.
• Хочешь узнать паттерны поведения пользователей? Механизмы сегментации.

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

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

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

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

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

Последнее по очереди, но не по значимости — точность данных. Тут и говорить нечего: если данные в системе неточны и недостоверны, то все описанные выше преимущества сходят на нет. Система не должна быть «черным ящиком», и уровень доверия к ней должен достигаться за счет точности данных.

Вывод

Наши рассуждения выявили следующие признаки идеальной аналитики:

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

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

Если вы хотите написать материал для рубрики «Рынок игр», рассказать о разработке своей игры или кейсе её роста, присылайте материал на games@vc.ru.