Ваша игра может стать лучше: Как найти проблемы и точки роста

Точки роста и улучшения игры — главный аналитик devtodev Василий Сабиров делится опытом развития проектов .

Весной 2017 года мы, аналитики devtodev, подготовили доклад “Where is the money, Lebowski? How to identify and solve the problem in game economy”, успешно прочли его на конференциях в Таллине, Вильнюсе, Мальмё и Москве, а теперь решили отправить доклад на покой и сделать вместо него данную статью.

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

1. Сначала вы замеряете базовые показатели (рост, вес, температура, пульс / аудитория и доход);
2. Если этого достаточно, чтобы принять решение о том, что делать в данном случае, лечить или не лечить (а если лечить, то как), то на этом алгоритм диагностики заканчивается;
3. Если нет, то требуется более детальное исследование (например, анализ крови / разбиение игры по уровням).

В обоих случаях лучше спрашивать совета подготовленного человека, а не заниматься самолечением. Аналогом врача-терапевта для игрового проекта будут продюсер, аналитик, геймдизайнер. И не исключено, что после консультации “терапевта” вам нужно будет обратиться к более узкому специалисту (допустим, левел-дизайнеру).

В данной статье мы хотим предоставить алгоритм анализа игры от первичной диагностики до детальных исследований.

Уровень 1. Метрики масштаба

Речь о базовых показателях проекта:

• доход,
• аудитория (DAU, WAU, MAU),
• новые пользователи,
• пиковый онлайн.

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

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

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

Уровень 2. Метрики качества проекта

Метрики качества от метрик количества отличить очень легко: они измеряются не в пользователях и условных единицах, а в процентах и условных единицах на пользователя (per user).

Речь о таких метриках, как:

• Retention (day 1 retention, day 7 retention, day 28 retention и так далее) — доля пользователей, активных в проекте спустя N дней после входа;
• Rolling retention за те же периоды — доля пользователей, активных в проекте спустя N дней или позже после входа;
• Churn (отток пользователей) — доля пользователей, покинувших проект;
• Lifetime — среднее время пребывания пользователя в проекте;
• Sticky factor = DAU / MAU; показатель “липкости” проекта, говорящий о регулярности входов пользователей;
• ARPU, Average revenue per user = Revenue / DAU (или MAU, в зависимости от того, за какой период считаете) — величина, которая говорит о том, сколько в среднем денег приносит за период один активный пользователь;
• ARPPU, Average revenue per paying user = Revenue / Paying users; величина, которая говорит о том, сколько денег за период (с учётом повторных платежей) приносит один платящий пользователь;
• Paying share — доля платящих пользователей среди активных;
• LTV, lifetime value — сколько в среднем денег приносит один пользователь за всё время пребывания в проекте.

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

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

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

Уровень 3. События, воронки и точки роста

Есть ещё одна важная метрика, точнее целая категория метрик. Я говорю о конверсии, то есть о доле пользователей, выполнивших конкретное действие (тех, кто просматривал игру в магазине и в итоге её купил / тех, кто зарегистрировался и прошёл туториал / тех, кто сделал первый платёж / тех, кто сделал шаг Б после шага А).

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

Чтобы хорошо считать конверсии, вам нужно при интеграции аналитической системы чётко и правильно расставить передаваемые события. Очень многие ограничиваются лишь двумя событиями: вход и платёж. Этого достаточно, чтобы рассчитать все метрики на уровнях 1 и 2, но недостаточно для более детального изучения пользовательской траектории. Поэтому мы всегда рекомендуем передавать ещё и другие важные события (custom events), чтобы строить воронки событий, находить узкие места при переходе от шага к шагу и таким образом углубляться в пользовательские конверсии.

Вот несколько рекомендаций от devtodev:

1. Выделите ключевые события. Чего вы ждёте от пользователя? Совершения покупки, очевидно. Чего ещё? Нажатия на кнопку “Рассказать друзьям”, прохождения туториала, активации на 5 уровне, тут возможно множество вариантов.
2. Продумайте последовательность событий до того, как свершится ключевое событие. Например, чтобы пользователь совершил покупку, ему нужно открыть магазин, выбрать нужный товар, прочесть его описание, нажать на кнопку “Купить”, подтвердить покупку. Все эти события, составляющие эту “окрестность” ключевого события, также лучше передавать. Тогда вы сможете строить воронки и выяснять, на каких шагах пользователи не выполняют то, чего вы от них хотите.
3. Можете заранее прикинуть, какие воронки вы будете строить, какие устойчивые последовательности шагов выполняют ваши пользователи. Это поможет добавить ещё несколько событий для трекинга.
4. Проработайте параметры событий. Какую ещё информацию о совершённом событии вы хотите учесть в будущих воронках? Если пользователь, допустим, убил босса, то может быть полезно отследить, за какое время и за сколько шагов, какие ресурсы на это были потрачены.
5. Важно различать параметры пользователя (дата установки, страна, девайс, язык и так далее) и параметры события (свойства именно того события, которое выполнил пользователь). Как правило, у аналитических систем есть ограничения на количество параметров, передаваемых в событии, и есть смысл в этих параметрах передавать именно свойства события. А свойства пользователя система должна учитывать отдельно (по крайней мере, в devtodev это работает именно так).
6. Обратите особое внимание на туториал. Первая сессия вообще очень важна, и не только в играх. Особенностью работы с туториалом является то, что изменения как правило стоят довольно дёшево (скажем, просто поменять текст на подсказке), а влияние их может быть значительно (retention 1 дня может значительно подняться). Мы рекомендуем передавать события в туториале максимально подробно. По крайней мере, в devtodev в воронке по туториалу можно передавать до 120 событий, и наши клиенты этим пользуются.

Уровень 4. Структура игры и точки роста

Каждая игра уникальна (не считая клонов), и не так просто найти две игры с абсолютно одинаковой структурой. Тем не менее, анализируя структуры множества игр, можно найти некоторые общие черты.
В частности, мы в devtodev выявили две сущности, которые встречаются в играх очень часто:

• Уровень игрока. Игрок получает опыт, развивается, становится более скиллованным, и от этого повышается его уровень (поговаривают, некоторые эльфы доходят до восьмидесятого!). После первого уровня всегда идёт второй, и прохождение уровня как правило связано с другой величиной (чаще всего это опыт).
• Игровая локация. Здесь речь идёт об уровне в игре, а не об уровне игрока. Мы говорим о некоторой “географической” точке в игре, на которой находится игрок. Игрок может пройти или не пройти локацию, может застрять на ней. И после локации N необязательно следует N+1 — порядок между локациями необязательно линейный.

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

Помимо этого, devtodev позволяет отследить изменение любого численного параметра локации в перерасчёте на попытку, успешную или неуспешную (это могут быть шаги, единицы здоровья, бустеры, что угодно).

Уровень 5. Экономика игры

Прежде всего хотелось бы порекомендовать посмотреть видео круглого стола по игровой экономике с DevGamm — 2017 (Москва).

Мне посчастливилось принять участие в нём в качестве модератора, и я могу смело заявить: для погружения в тему игровой экономики это очень неплохой материал.

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

1. Накопления валюты на счету игрока;
2. Средние траты;
3. Средний заработок в игре;
4. Среднее количество купленных единиц валюты;
5. Основные покупки.

Анализируя эти величины, можно заметить дисбаланс (обычно это проявляется в виде резких скачков показателей вверх или вниз) в игровой экономике. Затем этот дисбаланс можно (и нужно!) править за счёт изменения параметров покупок (допустим, подкрутить цену у сундука), а также за счёт акций (если вы видите, что на уровне X скопилось много валюты, а игроки там предпочитают покупать товар Y, так дайте на него скидку всем игрокам уровня X).

Таким образом, алгоритм выглядит следующим образом:

1. Основные показатели проекта;
2. Показатели качества;
3. События и воронки;
4. Структура игры;
5. Экономика игры.

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

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

• Платящие — неплатящие. Вообще, в игре это два разных мира. Ваша задача — перетащить как можно больше людей из неплатящих в платящих. Для этого надо детально знать их поведение: с какими проблемами они сталкиваются, почему они могут уйти, что стимулирует их менять категорию.
• Платящие — неплатящие, редко играющие — часто играющие. И мы имеем уже четыре сегмента, и можем отдельно влиять на каждый из них.
• RFM-анализ — только для платящих. Вы выделяете различные сегменты платящих пользователей по частоте платежей, их размеру, по давности последнего платежа. Таким образом, например, можно выделить сегменты тех игроков, кто сделал всего один платёж, затем поделить их на тех, кто сделал его давно (и скорее всего больше не заплатит) и недавно (и надо стимулировать их сделать второй платёж). Ещё один пример сегмента, получаемого RFM-анализом — это уходящие киты: те, кто платил много и часто, но в последнее время не платит. Надо разобраться, в чём дело, и всеми силами вернуть их в игру — это именно те пользователи, которые вас кормят.
• Сегментация по Бартлу. То самое разделение игроков на achievers, killers, socializers, explorers. Про неё и так много написано, мы лишь порекомендуем статью, в которой хорошо описано, как этих игроков выделять и что с ними делать.

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

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

Успехов вашей игре!