- PVSM.RU - https://www.pvsm.ru -
Одна из основных характеристик успешной мобильной игры — ее постоянное оперирование: это и переработка существующего контента, и добавление нового. Но есть и обратная сторона медали – нужно постоянно оценивать риски изменений в очередной версии приложения. Необходимо заранее представлять, как изменения в апдейте повлияют на показатели проекта. Иначе можно оказаться в ситуации, когда во время планового обновления внезапно ломается баланс и нужно срочно поднимать всю команду разработки для выпуска хотфикса.
Еще до сборки нового продакшен-билда мы должны понимать, на какие показатели повлияет нововведение. Ведь в новых версиях игры может быть множество изменений баланса. Без предварительного планирования неизбежно возникнет один из таких вопросов: «Что же повысило ARPU в Канаде — локальные мероприятия в честь национального праздника или общее повышение сложности группы каких-то уровней; а может, просто звезды так совпали?». Безусловно, и после выхода апдейта выполняется всесторонний анализ результатов, но понимать характер изменений нужно заранее.
Перед внедрением новых фич в игру мы стараемся ответить на ряд вопросов:
Когда мы ответили на самые важные вопросы, остается еще парочка. Например, а как мы будем добавлять изменения в игру? Здесь есть два варианта:
Про AB-тесты написано много хорошего и разного, но мы напишем еще чуть-чуть.
Если решили проверить изменения с помощью AB-теста, главное — выделить ключевые моменты, иначе тест окажется бесполезным либо ввиду своей непоказательности, либо ввиду неправильной интерпретации. В любом случае бесполезный тест нам не нужен. Поэтому вот на что мы смотрим, когда планируем AB-тест:
Пример: предполагается, что изменения должны «закрутить гайки» и стимулировать игроков платить для прохождения уровня. Что нам надо оценить: конверсия, ARPU, ретеншен, отвалы, сложность уровня, использование бустов. Нам нужно быть уверенными, что увеличение дохода за счет повышения конверсии стоит потенциальной потери пользователей. Тем более что часть отвалившихся пользователей могла бы в будущем начать смотреть рекламу и приносить доход. Нужно также быть уверенным, что уровень сделан хорошо, что он не слишком рандомный, что нет «серебряной пули» в виде одного буста, гарантирующего прохождение. Хватит ли этих контролируемых метрик или стоит добавить еще?
Пример: модель предсказывает гарантированное отсутствие конверсии у порядка 2000 человек в группе с левел-апом на выбранный уровень в выбранный день. Сколько дней запускать предсказания, чтобы по итогам теста получились значимые результаты при увеличении показа рекламных роликов для данной группы?
Пример: для запуска крупномасштабного теста нужно найти страну с хорошим уровнем конверсии. При этом, набирать только опытных игроков, которые не говорят на английском. Как это формализовать для динамического распределения игроков в тест?
Пример: можем ли мы, параллельно проводить несколько тестов на разные группы уровней и удобным инструментом разделить влияние одних и других на игроков, участвующих сразу в двух тестах?
Пример: стоит ли останавливать тест раньше времени, если резко снизились метрики. Или это временный эффект, характерный для когорты, — и стоит подождать?
Даже если распределять игроков в группы в равных пропорциях, внутри они могут попасть в разные условия. Например те, кто пришли в игру и вошли в тест в начале месяца, могут иметь больший ARPU, чем пришедшие в конце теста. Выбор методологии — это может быть когортный подход или расчет ARPU Daily (ARPDAU) — зависит от определенных целей на стадии планирования и от игроков, распределяемых в тест на регулярной основе.
При когортной оценке результата нужно учитывать, что игроки, распределенные ближе к окончанию теста, могли еще не дойти до «точек конверсии». Нужно или отсечь часть «последних» когорт при анализе, или выждать нужное время после остановки распределения игроков в тест.
Также по-разному можно подходить к анализу итоговых данных групп. Мы используем два основных подхода:
Плюсы: гарантированный результат определения значимого различия при достаточно большой выборке.
Минусы: размеры выборки — чем выше выбранный уровень достоверности, тем больше набирается участников групп. А чем критичнее тестируемое изменение, тем выше уровень значимости, который мы устанавливаем пороговым значением.
Подход базируется на принципе расчета условной вероятности. Если на момент анализа результатов мы знаем, какой вид распределения имеет генеральная совокупность, мы можем восстановить плотность вероятности за счет оптимизации параметров этого распределения.
Если случайная величина не соответствует одному виду типовых распределений, то искомое распределение можно получить с помощью комбинирования нескольких типовых распределений, используя принцип совместной вероятности событий. Например, для ARPPU мы комбинируем распределение дохода от пользователя с распределением платящих пользователей (оптимизируя параметры произведения). Мы описываем модель итогового распределения для случайной величины и в рамках построенной модели сравниваем две выборки. Далее с помощью статистического критерия проверяем, что обе выборки соответствуют описанному в модели распределению и имеют разные параметры.
Плюсы: в случае удачного выбора модели и удачной оптимизации параметров можно улучшить точность и достоверность оценок и в некоторых случаях можно принимать решения, набирая для теста небольшие группы пользователей.
Минусы: удачной модели может не быть, либо она может быть достаточно сложна для прикладного использования.
Приведем в качестве примера несколько тестов на проекте Township. Там использование байесовского подхода вместо частотного позволило улучшить точность.
В первом тесте мы изменили количество платной валюты, т.н. кеша, которое игрок может получить из одного конкретного источника. Мы планировали, что это может привести к небольшому улучшению монетизации. В итоге мы установили разницу:
Таким образом, мы смогли поднять точность до приемлемой без изменения размера групп участников.
В другом тесте мы изменяли настройки показа рекламы для определенной группы игроков в регионе с плохой монетизацией. На тот момент мы уже выяснили, что для некоторых хорошо подобранных групп игроков реклама может не только не портить, но и даже улучшить конверсию или ARPU, и хотели проверить этот подход на более широкой группе.
Независимо от итогового выбора подхода к оценке результатов мы получаем информацию о разнице между контрольной и тестовой группами. Если результат мы считаем положительным для проекта, то включаем изменение для всех пользователей. Еще до полного внедрения изменений в игру у нас есть представление о том, как они могут сказаться на наших игроках.
Конечно, в ряде случаев для нового контента мы можем не проводить AB-тест, если эффект от изменений предсказуем. Например, при добавлении новых матч-3 уровней в игру. Для этих изменений мы используем апостериорный контроль ключевых метрик. Как и в случае с AB-тестом, данные для этого собираются и обрабатываются из событий, которые пришли от пользователей, в автоматическом режиме.
У нас есть свой дашборд, внутренняя разработка на базе opensource-решения Cubes [1]. Им пользуются не только аналитики, но и гейм-дизайнеры, менеджеры, продюсеры и другие участники нашей дружной команды разработки. С помощью этого дашборда (точнее, набора дашбордов) по каждому проекту отслеживаются как ключевые показатели, так и свои внутренние метрики, такие как, например, сложность матч-3 уровней. Данные для дашбордов готовятся в формате olap-кубов, которые, в свою очередь, содержат агрегированные данные из базы данных raw-событий. Благодаря выбору аддитивных моделей для каждого графика есть возможность выполнения drilldown (разложения на составляющие) по необходимым категориям. При желании можно группировать или разгруппировать пользователей для применения фильтров при визуализации метрик. Например, можно сделать drilldown по версии приложения, версии настройки уровней, региону и платежеспособности, оставив только платящих игроков из Австралии с версией игры 1.8 и версией настройки уровней 4.
Конечно, самой интересной связкой по умолчанию является последняя версия игры и последняя версия уровней, которые сравниваются с предыдущим вариантом. Это дает возможность левел-дизайнерам вести непрерывный контроль за текущим состоянием кривой сложности проекта, абстрагированный от глобального анализа апдейта, и оперативно реагировать на отклонения показателей от планового курса.
Автор: 9e9names
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/256736
Ссылки в тексте:
[1] Cubes: http://cubes.databrewery.org/
[2] Источник: https://habrahabr.ru/post/329910/
Нажмите здесь для печати.