Внедрение новых фич в уже вышедшую игру: подходы и решения
Без обновлений сегодня нельзя. Без разницы, идет ли речь о разработке премиум-проекта или фритуплея. В любом случае игроки ждут добавки. Вот только не каждая может принести пользу. Если обновку игроки не примут, потеряете и деньги, и аудиторию. Поэтому до запуска нужно ее тестировать. Как это делают — рассказываем в статье.
Тестировать новую фичу надо, чтобы не потерять деньги и пользователей
Выпуск обновления к игре – распространенная практика. Когда речь заходит о контентном апдейте, обычно вопросов не возникает. Здесь все сводится к мантре «тех же щей, да погуще влей».
Иное дело новый функционал. Как скажется его появление — не предугадаешь.
Продюсер эстонской Creative Mobile Алина Браздейкене считает, что есть три возможных сценария развития событий после обновления. Первый — благополучный: вырастут метрики. Альтернативные сценарии — сохранение прежних параметров или их изменение в худшую сторону.
«Оба последних варианта — негативные. Сохранение тех же метрик — плохо, поскольку в фичу явно были вложены ресурсы. Терять их неприемлемо, если только вы не пытаетесь проверить какую-то фундаментальную теорию, и получить этот ответ важнее, чем количество ресурсов, которые вы вложите в фичу. Во втором случае — из-за возможной потери своей целевой аудитории», — отмечает Алина.
Алина Браздейкене сейчас работает в Creative Mobile над хидденом X-Files: Deep State
По этой причине сегодня распространенной практикой является предварительное тестирование. Вопрос состоит в том, как это сделать правильно, существуют ли методы, позволяющие наиболее точно понять, как отреагируют пользователи на нововведение.
Первый шаг к добавлению нового функционала — анализ
Тестирование начинается с анализа имеющейся версии проекта.
«Мы всегда стараемся подождать немного после запуска проекта и собрать данные (аналитика, отзывы) до того момента, как решим внедрять что-то новое», — говорит Максим Кочурин, генеральный директор DevGame.
У такого подхода две причины. Первая — собранные данные формируют контрольную группу. С оглядкой на нее и оценивается эффективность будущих обновлений. Вторая — есть от чего отталкиваться при продумывании нововведений.
«Если вы уже заранее знаете, что и как влияет на ваших пользователей, вам в будущем будет более удобно принимать решения о грядущих изменениях: часть гипотез получит больший вес, часть — отпадет сама собой», — говорит о необходимости анализа Василий Сабиров, ведущий аналитик devtodev.
То, что начинать надо с анализа, также уверена Александра Радченко, руководитель отдела исследований Playtestix. Но она отталкивается от другой предпосылки. Саша смотрит на анализ, как на один из видов тестирования.
«Важно проанализировать статистику и мнения игроков, их игровой опыт. Сделать все, что поможет найти критические точки игры. Далее смотрим на наши грядущие изменения. Есть ли точки пересечения проблем и апдейтов? Если да, то риск падения показателей снижен, если нет, то старые и новые проблемы могут сложиться, а аудитория начнет сбегать».
Проще говоря, она призывает проверять, соотносится ли список фич со списком пожеланий игроков.
Когда нет возможности нормально протестировать обновление, можно обойтись только этим подходом. Однако, как отмечает Радченко, лучше его совмещать с другими методами анализа и проверки.
Третий подход к анализу формулирует Сэм Стрижак, продюсер Alternativa Games. Он советует обратиться к построению прогноза, как придуманная фича скажется на самом проекте.
«В результате анализа вы должны получить понятную картину механических связей на проекте и прогноз последствий. Используя эту информацию можно принять гораздо более осмысленное решение по функционалу, исходя из конкретных нужд проекта», – отмечает Стрижак.
Alternativa Games сейчас сосредоточена на своем новом онлайновом боевике Tanki X
Сам анализ зачастую сводится к формулировке вопросов и ответов.
«Мы прежде всего отвечаем на следующие вопросы: какие показатели на наш взгляд максимально влияют на доход в приложении, какие из них и как мы можем улучшить, сколько сил и средств мы потратим на решение этого вопроса?», — объясняет Кочурин.
Со списком вопросов предлагает начать подходить к тестированию и Радченко из Playtestix. «Первоначально нужно разобрать цели наших изменений и соотнести с аудиторией», — пишет она.
При этом Радченко идет дальше. Она предлагает проводить различный анализ в зависимости от типа планируемых изменений (глобальные и частичные) и в соответствии с целевой аудиторией. Отталкиваясь от этого, она строит «матрицу пересечения целей и фокусов». Последняя должна дать команде разработки ответ, какой тип анализа существующей версии оптимальный.
Главная проблема состоит в том, что анализ отодвигает этап непосредственной разработки нового функционала и тестирования, поскольку требует многочисленных исследований.
То есть придется сначала изучить, что и как с конверсией, с отказами, с тем, где отвалы идут, и так далее и тому подобное. И только затем можно будет приступать к самому интересному — интеграции нового функционала.
Типы тестирования
Предположим, анализ позади, разработка новой крутой фичи — тоже. Дальше, если никто не торопится, и наступает этап тестирования.
Готовый функционал ставит перед разработчиками главную проблему: как его проверить. Инструментов много, но не все могут подходить под проверку конкретного нововведения.
Для фич, легких и дешевых в реализации, но при этом эффективных, Алина Браздейкене советует два возможных сценария.
«Первый — добавить инструменты для A/Б-теста в билд (это хорошая инвестиция, которая может еще неоднократно пригодиться в будущем), внимательно протестировать (фичу), вылить обновление и замерить результаты».
«Второй — делаете желаемую фичу, создаете новое приложение. После этого релизим его на узкий круг стран, покупаем пользователей, загоняем их в игру и смотрим результат».
Однако Алина отмечает, что он подходит «только в том случае, если нет возможности прибегнуть к A/Б-тестированию [о котором мы поговорим чуть ниже], а сервисы типа PlaytestCloud* для эксперимента не подходят (особенно, если эксперимент должен дать плюс к монетизации/удержанию в долгосрочной перспективе)».
*PlaytestCloud — сервис, который проводит живые тесты игры на целевой аудитории.
Подводный камень с дублированием заключается в том, что на платформах обычно существуют те или иные ограничения по дублированию, так что команде предстоит сделать новый билд максимально отличным. При этом внесения отличий не должно будет повлиять на чистоту проведения эксперимента.
«По сравнению с этим, реализация фичи А/Б-теста в продукте уже кажется простой и дешевой», — замечает Алина.
Александра Радченко также считает путь, который условно можно назвать софт-лончем новой версии, неудобным. По ее мнению, это не только дороже тестов на выборке пользователей, но и вносит большой риск, ведь обновление могут принять по-разному на реальном рынке и том, где проводится проверка.
Более позитивно она отзывается о практике закрытого бета-тестирования. «Это хорошо известный метод, — уверяет Александра. — Среди целевой аудитории набираем группу энтузиастов-первооткрывателей новых ощущений. Приглашаем в увлекательное путешествие по любимой игре, но с перчинкой. Сравниваем статистику до и после, собираем мнения по изменениям».
Немного иная практика по тестированию функционала у DevGame. Ее ключевое отличие от бета-теста — отсутствие приглашений. Вместо этого идет сразу развертывание на ограниченную аудиторию.
DevGame известна своими детскими проектами по популярным франшизам
«Мы публикуем новую версию на 5-10% пользователей (в зависимости от объема текущей аудитории)», — рассказывает Максим Кочурин. — «После этого собираем данные и анализируем, как новый функционал отобразился на основных показателях и на отзывах аудитории о продукте. Если изменения привели к росту тех показателей, которые мы хотели поправить новым функционалом, у 10% пользователей, мы раскатываем билд на 100%. И так, шаг за шагом внедряем новые фичи».
Главный показатель для DevGame — доход. По этой причине главный «вектор принятия решения о внедрении функционала простой: если гипотеза повышает доход, она внедряется».
От компании к компании инструменты и способы тестирования разнятся, но главным для всех является А/Б-подход. Четыре из пяти команд, с которыми я говорил, к нему прибегают.
Как проводить тестирование (советы и кейсы)
А\Б-тестирование
Однозначным сторонником А\Б-тестирования выступил Сабиров. «Если есть возможность провести A\Б-тест — лучше его провести», — заявил Василий.
По его словам, делать это следует так:
- сформировать набор пользователей (необходимо, чтобы они до этого не взаимодействовали с новым функционалом и увидели его впервые уже в рамках эксперимента);
- случайно разбить их на две или более групп;
- одну из групп выделить как контрольную, для других — задать изменение/изменения;
- провести эксперимент и подвести его итоги.
Еще до его проведения следует «правильно задать итоговые метрики». Василий советует взять для оценки в том числе денежные метрики, к примеру, ARPDAU и накопительный ARPU к седьмому дню.
Правда, от полученных результатов не всегда возможно отталкиваться. Например, при тестировании The X-Files: Deep State случился казус. При А\Б-тестировании стилей диалогов из трех вариантов (саркастичный, ролевой и нейтральный) ни один не победил со значительным отрывом.
В итоге, команда Creative Mobile отталкивалась от видео с плейтестов. «Мы увидели очень положительную реакцию на саркастичные тексты и решили оставить именно их», — рассказывает Алина Браздейкене.
Работа с гипотезой
DevGame давно активно продвигает свой собственный подход к работе с данными. У него нет какого-либо названия. Суть в том, что разработчики компании начинают всегда с формирования гипотезы.
Так они поступили и при работе с игрой «Три Кота: Магазин». Это был второй проект студии по бренду «Три Кота».
«Проблема была в том, что у него, в сравнении с первым проектом, по ряду базовых показателей были очень низкие значения, — рассказывает Максим Кочурин. — Доход также был не очень высоким».
Как они работали дальше?
Поставили проблему: очень большое количество коротких сессий.
Сформулировали гипотезу: при входе на экран выбора игрока, ребенок нажимает на кнопку «Играть», а не на персонажа (вход в основной геймплей). И тем самым уходит играть в дополнительный геймплей (наряжание елки). Игроку становится скучно и он уходит из игры вообще, так и не увидев основного геймплея.
Предложили предполагаемое решение: при первом входе пропускать вообще экран с выбором персонажа и сразу переходить с главного экрана в основной геймплей, при нажатии кнопки Play.
Протестировали: на 10% пользователей.
Затем данные новой версии DevGame сравнила с теми, что у базовой.
Так студия выяснила, что гипотеза была справедливой, ведь удержание первого дня у новой версии оказалось на 10% больше, а длина сессий увеличилась в два раза.
***
Удачи с тестированием нового функционала!
Обязательно пишите, что если у вас возникли дополнительные вопросы.
