Site icon AppTractor

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

devtodev

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доход — это произведение количества на качество, то есть аудитории на 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 выявили две сущности, которые встречаются в играх очень часто:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exit mobile version