bigstock-Big-data

Ересь

С первого дня в геймдеве я сохранил убеждение, которое спорит с ключевым посылом каждой игровой конференции, с главной мыслью каждой второй статьи.
Настоящая ересь.

И звучит она так: никакой data-driven разработки не существует.
Рост KPI на основе данных — иллюзия.
KPI, конечно, растет. Но по другой причине.

Давайте разбираться

Вот команда запускает проект, собирает первые данные.
Сразу отбросим «технические» проблемы: цену, количество и качество трафика. В реальности вы никуда от них не денетесь, ведь качество трафика влияет на KPI больше, чем фичи, но главная проблема не здесь.

Собранные данные предстоит интерпретировать.

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

Обратная модель — «улучшать то, что хорошо» — тоже не универсальна. Чем лучше отдельно взятые механики и контент, тем дороже и неочевиднее их развитие. Возникает риск растратить ресурсы на незначительные мелочи, которые никак не отразятся на успехе; или, хуже того, случайно сломать то, что работает.
И, напротив — чем слабее звено продукта: тутор, воронка, удержании на первых этапах — тем дешевле, очевиднее и эффективнее работа над улучшением.
Так какой же правильный ответ?

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

  • оставить все как есть;
  • доделывать спорную активность, пока она не станет интересна и прибыльна;
  • или сократить, а то и вовсе фичекатнуть ее, чтобы не принуждать игроков к неинтересному.

Переделывать core’вые активности и фичи крайне дорого, но решив проигнорировать или фичекатнуть вы больше не узнаете, была ли это неправильная идея или неправильная реализация. Кроме того, рискуете поломать священный core-loop.
Так что же выбрать?

Правильный ответ

«Правильный ответ» всегда существует.
Просто у нас, как правило, не хватает данных.

Это похоже на расчет позиции каждой монетки, выпавшей из банкомата, сброшенного с горящего самолета. Зная все начальные координаты, скорости, градусы, массы и плотности — все можно рассчитать математически.
Только мы их не знаем. У нас нет всех метрик по всем конкурентам, нет безграничных ресурсов на трафик и бесконечного времени на тесты.

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

Чтобы правильно ответить на оба вопроса — необходимо знать настоящую аудиторию игры. Не ту, которую вы привлекли для софт-лонча и даже не ту, которая платит — а ту, для которой сделан продукт. Аналитика говорит о пользователях, которые у вас уже есть — но не скажет о тех, кого нет; кто, в перспективе, принесет продукту успех.
Возможно, вы до них еще не достучались — и никогда не достучитесь, если не исправите критические ошибки. Но точно ли это ошибки или естественные ограничения продукта? Ошибка ли для Hearthstone отказ от общепринятого в мобильных баттлерах автобоя? Ошибка ли для Clash of Clans непривычно хардкорная механика с «наказанием» за поражение?

Можно поступить от обратного — и скорректировать продукт под пользователя, который лучше на него реагирует. Но для этого, опять же, надо знать не только пользователя, а сам продукт — переживет ли он смену целевой аудитории, не растеряв всю свою привлекательность? Не получится ли, что такой поворот обойдется дороже нового продукта? А реакция первых пользователей — это реакция на сам продукт или на недоработки, которые просто нужно исправить, не меняя ЦА?

К чему мы приходим.

Аналитик, оперирующий продюсер и менеджер по развитию видят данные и готовый продукт. Но живой проект — это еще не готовый продукт, а всего лишь текущая реализация задумки. Чтобы правильно ответить на вопросы, которые ставят аналитики — нужно быть не аналитиком, а человеком, глубоко понимающим задумку: геймдизайнером или продукт-овнером. В общем, тем кто «сделал игру». И правильные ответы — не результат анализа данных, а интерпретация базовой задумки (на основе данных, да).

Поэтому я не верю в data-driven. По крайней мере, в чистом виде.

Немного лирики

Приведу несколько историй из практики — одни случились со мной, другие с коллегами. Истории не прямо подтверждают мой посыл — это просто иллюстрация и отступление. Без имен и ссылок.

1. Весьма хардкорный продукт выходит на традиционно казуальный рынок. В отзывах: «первая нормальная игрушка <на площадке>». Продвигается тяжело, но со временем обрастает комьюнити, прибыль растет, появляются свои киты, но до возврата инвестиций еще далеко. Лиддизайнер, вдохновленный чужими историями о ярдовых прибылях решает сделать пивот и максимально оказуалить продукт, автоматизировать все что можно, и т.д. — чтобы расширить аудиторию. Несколько месяцев доработок, новый запуск — все KPI ниже прежних. Проект решают закрыть.
Вывод (мой): дизайнер допустил ошибку, позволив размыть вижен игры — в оригинальную и, вполне возможно, перспективную задумку было внесено искусственное допущение «раз на площадке казуальная аудитория, то казуальность принесет успех». Это типичный вывод типичного аналитика — и типичная ошибка.

2. Аналитика подключают к оперированию прибыльного продукта с отрицательной динамикой (прибыль падает от месяца к месяцу). Аналитик находит изъяны воронки, команда фокусируется на переделке входа и тутора вместо добавления контента. Продюсер против, но руководство решает послушать аналитика. Воронка выправляется. Прибыль падает еще сильнее.
Вывод (мой): если команда не может тянуть контент и шлифовку одновременно, то выбор следовало доверить тому, кто лучше знает продукт. И важно помнить, что у любого продукта есть срок жизни — отрицательная динамика не всегда следствие ошибок.

3. Команда делает продукт, не сильно думая о целевой аудитории. В процессе как-то решают, что аудитория — это ХХХ (допустим, «родители и дети до 12″). Первое привлечение показывает, что на продукт гораздо лучше откликается совсем другая аудитория (допустим, «Женщины 35+, любители HoG»). Маркетинг фокусируется на них.
Вывод (мой): создатель не всегда лучше знает ЦА, иногда он просто делает классный продукт и без данных не обойтись :)

Share on Facebook0Tweet about this on TwitterShare on VK