«Систематическая ошибка выжившего» или как избежать основных ошибок при получении фидбэка от игроков

На конференции GDC-2014 менеджер проектов компании «Иннова» Искандер Хабибрахманов прочитал доклад об одной из ключевых ошибок, которую может допустить разработчик, прислушиваясь к мнению своих игроков. С одобрения автора рубрика «Рынок игр» публикует конспект выступления .

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

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

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

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

История помнит немало случаев, когда люди становились жертвой так называемой «систематической ошибки выжившего». Пожалуй, самым известным примером служит история бомбардировщиков Б-24.

Во время Второй мировой войны правительство США думало о способах повышения эффективности авиации, в частности, бомбардировщиков Б-24. Они были большими, медленными и уязвимыми, а поэтому часто становились жертвами вражеских истребителей и артиллерии. Шансы бомбардировщика вернуться после выполнения задания были крайне малы, а при продолжительном участии в операциях крушение самолета становилось лишь вопросом времени.

Для повышения эффективности Б-24 было решено укрепить их дополнительной броней. Она, однако, значительно увеличила бы вес бомбардировщика, поэтому требовалось определить, какие именно места укреплять.

Для решения этой задачи были исследованы «выжившие» самолеты, то есть вернувшиеся с операции. В результате была выявлена закономерность распределения пробоин от пуль вражеских истребителей и ПВО. На рисунке пробоины обозначены красными точками.

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

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

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

Такое игнорирование невидимых по некоторым причинам объектов и концентрация на доступной информации и называется «систематической ошибкой выжившего».

«Систематическая ошибка выжившего» может проявляться в разных контекстах. Я хотел бы рассказать, как она может возникать при оперировании играми с моделью free-to-play (далее F2P) на разных этапах их жизненного цикла.
Большая часть примеров, которыми я хотел бы здесь поделиться, основана на работе с двумя шутерами: Shadow Company и Point Blank.

F2P-шутеры на ранней стадии запуска

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

Вскоре после запуска Shadow Company в конце 2012 года мы обнаружили низкую удовлетворенность игроков, которые не хотели задерживаться в игре и покидали ее в среднем на седьмой день после регистрации.

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

Поняв проблему, мы в срочном порядке начали работать над ее исправлением, шаг за шагом улучшая систему. Как вы думаете, на сколько процентов понизился после этого отток игроков?
Ровно на ноль.

Ошибка была в том, что мы спрашивали не тех игроков. Через форум, во «ВКонтакте» и по внутренним каналам, мы могли достучаться лишь до тех, кому игра нравилась как минимум настолько, чтобы потратить свое время на заполнение небольшой анкеты. Однако большинство пользователей уходило на седьмой день, и им, конечно же, было не до того, чтобы оставлять фидбэк. Будучи игроком, вы просто не можете тратить свое время на каждый непонравившийся проект, пытаясь объяснить разработчикам, что они сделали не так. Скорее всего, вы даже не задумываетесь об этом и просто возвращаетесь в свою любимую игру.

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

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

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

Зависимые от прошлого изменения

Хорошо, допустим, вы запустили игру, «ретеншн» приемлем, и вы планируете дальнейшие обновления игры с целью повышения показателей.

Следующая проблема, с который вы сталкиваетесь, заключается в том, что все изменения в игре «зависимы от прошлого». То есть любое изменения делит вашу аудиторию на тех, кто помнит, каково было до этого изменения, и тех, для кого реальность всегда была с этим изменением. Речь об игроках, зарегистрированных после введения обновления.

Естественно, эти две группы по-разному реагируют на новинку и, скорее всего, дают вам разный фидбэк.

Например, вы решили сделать игру более доступной широкой аудитории и выпустили обновление, в котором «прокачка» до 15 уровня в среднем занимает 7 дней. Едва ли новые игроки воспримут это изменение также как и те, кто только что получил 15 уровень благодаря месяцу, безвылазно проведенному в игре.

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

Это не так быстро происходит для «хардкорных» игр, таких как MMORPG, и в большей степени верно для игр с относительно коротким циклом жизни (шутеры, казуальные игры, большинство мобильных игр). Поэтому иногда бывает полезно отдельно исследовать мнение игроков, которые не помнят прошлого проекта.

Как предсказать результат изменений?

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

Для начала давайте немного подробнее разберемся, как работают скидки. Есть два основных механизма, за счет которых они влияют на выручку. Первый — чисто экономический: снижение цены увеличивает потребление, но уменьшает доход с покупки. Такой механизм может оказывать как положительное, так и отрицательное влияние на выручку.

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

Однако нас особенно интересует первый механизм. Ведь если новая цена более эффективна, мы хотели бы сохранить ее (сделать скидку и больше не повышать цену). Если же новая цена менее эффективна, то, оставляя цену сниженной, со временем мы начнем нести потери.

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

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

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

Вы берете некоторый период времени — например, две недели — и сравниваете доход, полученный от пользователей, зарегистрированных в течение этих двух недель после скидок и зарегистрированных в аналогичный период, но когда никаких скидок не было. Сравнение среднего дохода на игрока из первой и второй групп и даст ответ на интересующий вопрос.

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

Существуют и обратные ситуации. Так, нами было принято решение ощутимо повысить цену на популярный предмет в Point Blank. В результате повышения цен выручка упала, и ситуация вынуждала нас пересматривать цены в сторону снижения.

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

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