KPI-подход: метрики и стадии игрового проекта

От софт-лонча до продажи.

Youtube-канал конференции Games Gathering 2016 опубликовал запись лекции ведущего продуктового менеджера iLogos Александра Штаченко (сейчас работает в компании Playbeat) о KPI-менеджменте. Он рассказал о своём подходе к игровым метрикам. 

DTF публикует расшифровку выступления.​

В этом докладе я хочу осветить три момента:

Прежде всего мы будем говорить о free-to-play проектах. Самый универсальный показатель для бизнеса — это деньги. KPI-менеджмент — тонкая надстройка над продуктовым менеджментом, подразумевающая более тонкий подход. 

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

Очевидно: мы хотим больше зарабатывать и только с правильным подходом к метрикам можно повышать доходы, понижать расходы. Основной подход: у вас есть бюджет, ресурсы и вы должны уложиться в них так, чтобы получить наибольшую производительность. Если вы делаете «фичи ради фич»  (потому что они есть у Supercell или King) — это не значит, что они подойдут вам. Каждая механика должна повышать метрики.

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

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

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

Закрытие проекта — сложное решение, которое (если не ориентироваться на KPI) придётся принимать интуитивно. Вот некоторые возможные причины:

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

— Вы сделали игру в жанре, в котором идёт жёсткая конкуренция за трафик. Вам противостоят гранды, и кое-кто из них готов платить за каждого пользователя по 16 долларов. А вы максимум можете отбить четыре.

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

— Или вы вышли на какую-то узкую платформу (например, мессенджер, который «наливает» вам трафик, размещает у себя баннер, продвигает проект с помощью стикеров). Его аудитория тоже так или иначе заканчивается. И если она уже закончилась и осталась только Африка или страны Третьего мира — вопрос о закрытии проекта тоже нужно поднимать на основании KPI.

— Заканчиваются деньги. Если вы не уверены, что вернёте инвестиции — при помощи KPI-менеджмента можно принять решение более взвешено.

Или хороший вариант: вы смотрите на цифры и понимаете, что игра получилась классной. Но ресурсы истощены, вы уже не можете финансировать и развивать проект. А игра должна расти: трафик окупается, вы только вышли на новые рынки. Можно смело искать деньги, вот только их никто не даст, если не показать цифры. Недостаточно будет MAU, DAU и каких-то поверхностных метрик по ретеншену.  

Я пропущу препродакшн и продакшн и начну с момента выхода игры на софт-лонч. У каждого проекта разные цели и сроки софт-лонча. Метрики могут очень сильно отличаться. При KPI-подходе во время «мягкого запуска» для аналитики используются мощные ресурсы: вы решаете, выходить ли на мировой рынок — нельзя делать это «для галочки». 

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

Удержание. Вы замеряете, удаётся ли вернуть человека в игру в течение недели.

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

В последние годы используют ещё одну фазу — проверку виральных метрик и механик. Когда вы покупаете одного пользователя за 10 долларов, а он вам приносит всего лишь шесть, бизнес кажется убыточным. Поэтому нужно, чтобы пользователь за 10 долларов привёл хотя бы одного друга. Тогда его стоимость «делится» на два.

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

Вы прошли софт-лонч и у вас есть ресурсы для масштабирования. В игру вступает не продюсер, а «live-op» менеджер — он мыслит по-другому, у него иные навыки, знания и задачи. Главное правило масштабирования — LTV (прибыль от одного пользователя) должна быть больше, чем URC (стоимость привлечения трафика). Если это справедливо для каждой новой аудитории — масштабирование проходит хорошо. Именно за это отвечает операционный менеджер.

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

Стабилизация нестабильных метрик. Предположим, вы выявили у себя «диванную сессию» — вечернюю, длиннее других. Она есть у каждого активного пользователя, но в ней нестабильная оплата — ARPU разных вечерних сессий сильно отличается друг от друга, и вы думаете, как её стабилизировать. После анализа становится понятно, что не все платящие пользователи получают в этот момент предложение оплаты (paywall). Идёте к программисту из своей команды и узнаёте, можно ли сделать так, чтобы он приходил в нужный момент, отслеживая часовой пояс пользователя по IP или Facebook Connect. 

Так выглядит жизнь проекта на графиках. Рост, падение и длинный «хвост». 

Это график активности пользователей и ваших доходов. Когда продавать проект? У меня нет ответа на этот вопрос.

Отдельная фаза проекта и на ней — свои KPI. Я рассмотрел несколько кейсов продаж, ко мне приходили за оценкой игр. Нужно понимать, что у вас покупают. Причин покупки много, я выделю три.

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

Чтобы в нём не было хаоса, лучше разделить его на матрицу AERM — Acquisition, Engagement, Retention, Monetization (Привлечение, вовлечение, возвращение и монетизация). Фичи, влияющие на отдельные показатели, относятся к трём категориям: core-механика, метагейм и социальный компонент. 

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

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

Если мы говорим, например, о виральности — в разделах Social и Acquisition должны быть самые сильные механики. Откуда бесплатно брать трафик, если не из социальных сетей?

Самая сильная механика в экшн-стратегиях — это кланы. Никто не придумал ничего лучше. Она приводит кучу игроков и объединяет их. Более того, это ещё и механика долгосрочного удержания: вы начинаете меряться силами внутри клана. Универсальная механика, работающая на все показатели.

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

Самый важный инструмент. Нужно выбрать способ расстановки приоритетов.

— Принцип ранжирования. У вас есть 20 задач, вы должны определить, какую брать в работу сегодня, какую — завтра, а какую — в конце следующего месяца. Вы берёте две самые важные задачи и две самые неважные. После — снова по две задачи. Таким образом заполняете список с двух сторон и в конце приходите к середине. Мне этот способ не нравится.

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

21 тысяча — критические задачи. То, без чего игра в принципе не будет работать: сервера, баги, то, как она сделана. Например, пользователь загружает игру и не может включить Facebook Connect, потому что есть проблемы с синхронизацией.

Все задачи я делю на два типа — «мажорные» и «минорные», чтобы как-то определиться, что раньше брать в работу. Мажорные апдейты — то, что я хочу изменить, но сейчас на KPI это никак не влияет, или влияет, но совсем чуть-чуть. Поэтому задачи находятся внизу списка.