Одна из основных характеристик успешной мобильной игры — ее постоянное оперирование: это и переработка существующего контента, и добавление нового. Но есть и обратная сторона медали – нужно постоянно оценивать риски изменений в очередной версии приложения. Необходимо заранее представлять, как изменения в апдейте повлияют на показатели проекта. Иначе можно оказаться в ситуации, когда во время планового обновления внезапно ломается баланс и нужно срочно поднимать всю команду разработки для выпуска хотфикса.
Еще до сборки нового продакшен-билда мы должны понимать, на какие показатели повлияет нововведение. Ведь в новых версиях игры может быть множество изменений баланса. Без предварительного планирования неизбежно возникнет один из таких вопросов: «Что же повысило ARPU в Канаде — локальные мероприятия в честь национального праздника или общее повышение сложности группы каких-то уровней; а может, просто звезды так совпали?». Безусловно, и после выхода апдейта выполняется всесторонний анализ результатов, но понимать характер изменений нужно заранее.
Разработка изменений
Перед внедрением новых фич в игру мы стараемся ответить на ряд вопросов:
- Куда будем смотреть? — на какие метрики (как общепринятые KPI, так и внутренние критерии качества) изменение предположительно повлияет, какой эффект мы будем считать успешным для проекта.
- На кого будем смотреть? — для кого предназначено изменение (для китов, для новых игроков, для игроков из Китая, для игроков, застрявших на какой-то конкретной группе уровней, и т.д.).
- Зачем будем смотреть? — какие есть сопутствующие риски (сложнее уровни → больше монетизация и больше отвалы (churn); легче уровни → меньше монетизация и меньше отвалы).
- А есть что смотреть? — вся ли необходимая информация трекается в игре.
Когда мы ответили на самые важные вопросы, остается еще парочка. Например, а как мы будем добавлять изменения в игру? Здесь есть два варианта:
- AB-тест. Мы проводим AB-тесты для новых фич или сильных изменений текущего баланса и геймплея. Когда это возможно, предварительный AB-тест для нас предпочтителен.
- Сразу в игру. Добавление нового контента в игру без AB-теста возможно, когда мы или технически не можем провести AB-тест, или не считаем контент принципиально новым (новый набор уровней, новые декорации и т.д.).
Про AB-тесты написано много хорошего и разного, но мы напишем еще чуть-чуть.
Планирование AB-теста
Если решили проверить изменения с помощью AB-теста, главное — выделить ключевые моменты, иначе тест окажется бесполезным либо ввиду своей непоказательности, либо ввиду неправильной интерпретации. В любом случае бесполезный тест нам не нужен. Поэтому вот на что мы смотрим, когда планируем AB-тест:
- Выбор величин для оценки.
Пример: предполагается, что изменения должны «закрутить гайки» и стимулировать игроков платить для прохождения уровня. Что нам надо оценить: конверсия, ARPU, ретеншен, отвалы, сложность уровня, использование бустов. Нам нужно быть уверенными, что увеличение дохода за счет повышения конверсии стоит потенциальной потери пользователей. Тем более что часть отвалившихся пользователей могла бы в будущем начать смотреть рекламу и приносить доход. Нужно также быть уверенным, что уровень сделан хорошо, что он не слишком рандомный, что нет «серебряной пули» в виде одного буста, гарантирующего прохождение. Хватит ли этих контролируемых метрик или стоит добавить еще?
- Расчет необходимой требуемой выборки для получения значимого результата.
Пример: модель предсказывает гарантированное отсутствие конверсии у порядка 2000 человек в группе с левел-апом на выбранный уровень в выбранный день. Сколько дней запускать предсказания, чтобы по итогам теста получились значимые результаты при увеличении показа рекламных роликов для данной группы?
- Формализация условий запуска теста.
Пример: для запуска крупномасштабного теста нужно найти страну с хорошим уровнем конверсии. При этом, набирать только опытных игроков, которые не говорят на английском. Как это формализовать для динамического распределения игроков в тест?
- Понимание, какие механизмы предусмотрены для сбора данных и анализа результатов.
Пример: можем ли мы, параллельно проводить несколько тестов на разные группы уровней и удобным инструментом разделить влияние одних и других на игроков, участвующих сразу в двух тестах?
- Формализация критериев для принятия решений о завершении теста.
Пример: стоит ли останавливать тест раньше времени, если резко снизились метрики. Или это временный эффект, характерный для когорты, — и стоит подождать?
- Формализация критериев для принятия решения о внедрении изменения в игру. Поговорим об этом в следующем разделе статьи!
Принятие правильных решений по результатам теста
Даже если распределять игроков в группы в равных пропорциях, внутри они могут попасть в разные условия. Например те, кто пришли в игру и вошли в тест в начале месяца, могут иметь больший ARPU, чем пришедшие в конце теста. Выбор методологии — это может быть когортный подход или расчет ARPU Daily (ARPDAU) — зависит от определенных целей на стадии планирования и от игроков, распределяемых в тест на регулярной основе.
При когортной оценке результата нужно учитывать, что игроки, распределенные ближе к окончанию теста, могли еще не дойти до «точек конверсии». Нужно или отсечь часть «последних» когорт при анализе, или выждать нужное время после остановки распределения игроков в тест.
Также по-разному можно подходить к анализу итоговых данных групп. Мы используем два основных подхода:
- Частотный подход — классический подход в оценке результатов. Формулируем нулевую гипотезу об отсутствии достоверной разницы между группами и альтернативную гипотезу, отрицающую нулевую. Итогом исследования станет решение о справедливости какой-либо из двух гипотез для всей генеральной совокупности. Выбираем уровень альфа (1 — альфа = уровень значимости) и проводим тест с использованием статистического критерия (z-критерий, t-критерий). Далее строим доверительные интервалы для контрольной и тестовой групп. Если эти интервалы не пересекаются, то результат достоверный с вероятностью 1 — альфа. По сути, выбранное значение альфа — это вероятность ошибки первого рода, т.е. вероятность, что по результатам эксперимента будет принята альтернативная гипотеза, хотя для генеральной совокупности верна нулевая гипотеза.
Плюсы: гарантированный результат определения значимого различия при достаточно большой выборке.
Минусы: размеры выборки — чем выше выбранный уровень достоверности, тем больше набирается участников групп. А чем критичнее тестируемое изменение, тем выше уровень значимости, который мы устанавливаем пороговым значением.
- Байесовский подход — менее распространенный метод, который базируется на принципе расчета условной вероятности. Он позволяет считать вероятность того или иного события при условии, что генеральная совокупность распределена определенным образом. С точки зрения практики использование байесовского подхода позволяет снизить для ряда метрик требования на количество элементов выборки (участников AB-теста). Это работает, потому что в определенный момент при оптимизации параметров распределения построенная плотность уже не приближается к фактическим результатам в тесте.
Подход базируется на принципе расчета условной вероятности. Если на момент анализа результатов мы знаем, какой вид распределения имеет генеральная совокупность, мы можем восстановить плотность вероятности за счет оптимизации параметров этого распределения.
Если случайная величина не соответствует одному виду типовых распределений, то искомое распределение можно получить с помощью комбинирования нескольких типовых распределений, используя принцип совместной вероятности событий. Например, для ARPPU мы комбинируем распределение дохода от пользователя с распределением платящих пользователей (оптимизируя параметры произведения). Мы описываем модель итогового распределения для случайной величины и в рамках построенной модели сравниваем две выборки. Далее с помощью статистического критерия проверяем, что обе выборки соответствуют описанному в модели распределению и имеют разные параметры.
Плюсы: в случае удачного выбора модели и удачной оптимизации параметров можно улучшить точность и достоверность оценок и в некоторых случаях можно принимать решения, набирая для теста небольшие группы пользователей.
Минусы: удачной модели может не быть, либо она может быть достаточно сложна для прикладного использования.
Приведем в качестве примера несколько тестов на проекте Township. Там использование байесовского подхода вместо частотного позволило улучшить точность.
В первом тесте мы изменили количество платной валюты, т.н. кеша, которое игрок может получить из одного конкретного источника. Мы планировали, что это может привести к небольшому улучшению монетизации. В итоге мы установили разницу:
- DPU (Daily Paying Users) — тестовая группа больше контрольной на 1% с вероятностью 87% при использовании байесовского подхода, тогда как это же расхождение групп при использовании частотного подхода справедливо с вероятностью 50%.
- ARPU Daily (ARPDAU) — тестовая больше контрольной на 2,55%, байесовский подход — 94%, частотный — 74%.
- ARPPU Daily — тестовая больше на 1,8%, байесовский — 89%, частотный — 61%.
Таким образом, мы смогли поднять точность до приемлемой без изменения размера групп участников.
В другом тесте мы изменяли настройки показа рекламы для определенной группы игроков в регионе с плохой монетизацией. На тот момент мы уже выяснили, что для некоторых хорошо подобранных групп игроков реклама может не только не портить, но и даже улучшить конверсию или ARPU, и хотели проверить этот подход на более широкой группе.
- Конверсия в контрольной группе была выше, чем в тестовой, при байесовском подходе с вероятностью 97% это было ясно по 50 000 игроков, при частном — с 95% вероятностью по 75 000 игроков.
- Разницу в ARPU в пользу контрольной группы байесовским подходом мы оценили по итогу с 97% вероятностью за месяц, в то время как при частотном подходе доверительные интервалы у нас так и не разошлись.
Независимо от итогового выбора подхода к оценке результатов мы получаем информацию о разнице между контрольной и тестовой группами. Если результат мы считаем положительным для проекта, то включаем изменение для всех пользователей. Еще до полного внедрения изменений в игру у нас есть представление о том, как они могут сказаться на наших игроках.
Мониторинг метрик
Конечно, в ряде случаев для нового контента мы можем не проводить AB-тест, если эффект от изменений предсказуем. Например, при добавлении новых матч-3 уровней в игру. Для этих изменений мы используем апостериорный контроль ключевых метрик. Как и в случае с AB-тестом, данные для этого собираются и обрабатываются из событий, которые пришли от пользователей, в автоматическом режиме.
У нас есть свой дашборд, внутренняя разработка на базе opensource-решения Cubes. Им пользуются не только аналитики, но и гейм-дизайнеры, менеджеры, продюсеры и другие участники нашей дружной команды разработки. С помощью этого дашборда (точнее, набора дашбордов) по каждому проекту отслеживаются как ключевые показатели, так и свои внутренние метрики, такие как, например, сложность матч-3 уровней. Данные для дашбордов готовятся в формате olap-кубов, которые, в свою очередь, содержат агрегированные данные из базы данных raw-событий. Благодаря выбору аддитивных моделей для каждого графика есть возможность выполнения drilldown (разложения на составляющие) по необходимым категориям. При желании можно группировать или разгруппировать пользователей для применения фильтров при визуализации метрик. Например, можно сделать drilldown по версии приложения, версии настройки уровней, региону и платежеспособности, оставив только платящих игроков из Австралии с версией игры 1.8 и версией настройки уровней 4.
Конечно, самой интересной связкой по умолчанию является последняя версия игры и последняя версия уровней, которые сравниваются с предыдущим вариантом. Это дает возможность левел-дизайнерам вести непрерывный контроль за текущим состоянием кривой сложности проекта, абстрагированный от глобального анализа апдейта, и оперативно реагировать на отклонения показателей от планового курса.
Автор: 9e9names
