• Информация о поведении игрока в игре – входы в игру, продолжительность игровой сессии, переходы по различным игровым интерфейсам, используемые в бою персонажи, используемое снаряжение, выполняемые задания, создаваемые предметы – буквально все, что игрок делает в игре.
Весь этот комплекс информации позволяет решить сразу несколько проблем, которые могут возникнуть перед нами.
• Обнаружить ошибки, закравшиеся в нашу игру. Вероятнее всего, они будут касаться не каких-то багов, упущенных во время тестирования игры, а работы различных игровых систем и механик.
• Точнее понять аудиторию игры, чтобы развивать продукт в направлении, более подходящем и интересном этим игрокам.
• Оценить эффективность каждого отдельного действия, направленного на развитие игры и бизнеса.
Если какой-то из бизнес-показателей не достигает целевых значений, мы можем попробовать исправить ситуацию, но нам необходимо понять, в чем заключается проблема. Плохие показатели ретеншна – это всего лишь симптом «болезни», диагностировать которую поможет детальное исследование поведения игроков. Его можно провести практически к любой метрике, нужно лишь разобраться в том, какая именно информация поможет нам выявить проблему.
Сам по себе ретеншн показывает количество остающихся в игре игроков, но показывает он это значение в целом и с разделением по дням. Внутри дня может произойти очень много событий, в том числе и в нашей игре, а значит, нам хорошо бы разобраться в том, какое конкретно событие в игре было для игрока последним и почему. Практически в любых играх так или иначе существует некая последовательность действий, через которую проходит игрок. Даже если это игра с открытым миром без какого-то линейного сюжета.
Это может быть обучающий режим, последовательность игровых уровней или квестов, набираемый персонажами опыт, открываемые навыки, предметы или противники. Соответственно, собирая информацию о пройденных этапах обучающего режима, пройденных уровнях, выполненных квестах и так далее, мы можем построить график, подобный графику ретеншна, – конверсию, и по нему понять, в какой именно момент игрок ушел из игры. Возможно, ему не удалось выполнить какую-то задачу обучающего режима, или уровень оказался слишком сложным, или он не понял задачу квеста, или ему просто наскучил сбор игрового опыта для прокачки персонажа.
Примерно так же должна собираться информация и о платежах, совершаемых игроком: они происходят в неких условиях, мотивирующих игрока на покупку. Возможно, это скидочная акция или у игрока закончились необходимые для продолжения игры ресурсы. Изначально при организации отдельных систем, составляющих игру, создается их дизайн, описание задумки, которой система должна служить, например сценарий обучающего режима. Подобный сценарий должен быть и у монетизационных механик. Следует собирать данные, которые помогут проверить, соответствуют ли условия разработанному сценарию или нет, и что происходит с игроком в момент, когда условия сценария вроде бы срабатывают, но платежа все равно не происходит.
В отличие от прямых цепочек прогресса, для изучения монетизации нужно намного больше данных, что значительно осложняет не только их сбор, но и обработку. С одной стороны, можно случайно не учесть какой-то аспект и не начать собирать данные, что отложит обработку данных до тех пор, пока не будет собрана новая более полная информация. С другой стороны, данных может оказаться слишком много, что увеличит шанс совершить ошибку при их обработке. Но и тут на помощь приходят современные технологии, методики машинного обучения и работы с большими данными: программа может сама обнаружить неочевидные закономерности.