Как найти и решить проблему в экономике игры?

Изначально материал был прочитан в формате доклада – в том числе на White Nights St.Petersburg 2017. По его мотивам Сабиров написал статью.

Василий Сабиров

Аналитику проекта можно сравнить с тем, как проходит обследование человека врачом. Алгоритм диагностики примерно один и тот же.

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 – сколько в среднем денег приносит один пользователь за все время пребывания в проекте.

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

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

Кейс 1

Рассмотрим на примере: ваш доход начал падать. Что не так?

Вам поможет такой инструмент, как карта метрик. Ниже вы можете найти упрощенную и достаточно универсальную карту. По факту же все имеющиеся под рукой метрики я рекомендовал бы объединить в такую карту, расставив между ними стрелки, обозначающие причинно-следственные связи между показателями.

Итак, доход падает. Что же делать?

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

Чем может быть обусловлено снижение ARPPU? Возможны варианты. Например, такое бывает при снижении цен в проекте: вы рассчитывали, что снижение цен увеличит долю платящих, но по факту платят лишь те, кто платил и ранее, просто меньше. Либо же вы провели некачественную акцию, и пользователи (которые и ранее были платящими) просто воспользовались ею. Либо изменилась структура платящей аудитории, и теперь платят преимущественно недавно появившиеся игроки.

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

Уровень 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 позволяет отследить изменение любого численного параметра локации в перерасчете на попытку, успешную или неуспешную (это могут быть шаги, единицы здоровья, бустеры, что угодно).

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

Выяснилось, что игроки попросту опасались перейти на уровень 8. В этой игре первые 7 уровней были начальными, а уровни начиная с восьмого — условно «профессиональными». То есть игроки просто хотели быть лучшими из новичков (и играть в свое удовольствие), нежели худшими из профессионалов. Такой резкий переход в сложности игры — ошибка гейм-дизайна и в частности системы матчмэйкинга, и геймдизайнерам пришлось её поправить.

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

Финальный этап анализа – изучение того, как работает экономика проекта.

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

• накопления валюты на счету игрока;
• средние траты;
• средний заработок в игре;
• среднее количество купленных единиц валюты;
• основные покупки.

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

Заключение

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

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

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

Постскриптум

Есть ещё один уровень анализа – по сегментам аудитории.

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

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

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

Оригинальный материал появился на страницах Apptractor.