A/B-тестирование в мобильных играх

​​Работа с контентом в игре

Реальный случай из жизни. Приходит художник и говорит:
- Нам нужны новые крипы (враги) на уровнях! Солдаты сейчас всех бесят.
- Давай посмотрим!

Были солдаты, стали - роботы. Запускаем эксперимент и получаем небольшое, но статистически значимое падение конверсии на первом уровне (смотрите скриншот).

С одной стороны, фейл - хотели улучшить жизнь игрокам, но ничего не изменилось. На самом деле, успех - мы получили знание: игрокам не так уж и важно, КТО именно бегает в качестве крипов. Значит похожее исправление в игре мы планировать в ближайшее время не будем.

Хотите получать знания о своей игре? Давайте к нам! abtestreal.com

Работа с балансом в игре

Хороший баланс в игре - это набор цифр, который в идеале делает игроков счастливее (необязательно) и наполняет кошельки владельцев баблом (обязательно).

Допустим, мы решили усложнить нашу игру. Игроки начнут платить и продолжат играть? Или разбегутся, потому что станет слишком сложно? Сколько нервов гейм-дизайнеров, аналитиков и разработчиков потрачено за спорами!

Вопросы цифр в игре мы решаем всегда одинаково - запускаем эксперимент. Механика наших tower defense стратегий следующая:
1. Есть враги, которые бегут по дорожке.
2. У них есть HP (здоровье).
3. Наши герои и пушки их убивают.

Чем больше здоровья у врагов, тем сложнее наша игра. Здоровье вычисляется по формуле: HP = Base HP * K, где K параметр на облачном сервере. В игру мы передаем параметр: {"version":380,"variant":"Variant","parameters":{"HPRateTest": "2:2:2.8"}}

Ставим K=2.8 для уровня 2 и смотрим, заработали мы больше или нет. Если заработали больше, оставляем K=2.8. Если заработали меньше, то запускаем новый эксперимент и ставим, например, K=0.8. Если заработок не изменился, мы смотрим на более чувствительную метрику “конверсия в третий уровень”.

Хорошо, что у нас есть платформа, которая достоверно определяет, заработали мы больше или меньше.

abtestreal.com

​​Что изменилось после того, как мы внедрили AB-тестирование

Когда мы разрабатывали платформу, прежде всего, мы хотели получить инструмент для запуска AB-тестов. Мы не ожидали, что изменится сам процесс. Что изменилось:

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

2. На Google Play мы можем выложить апдейт в пятницу вечером.
Если платформа на выходных сигнализирует о проблемах в билде, мы откатываем его буквально одним нажатием кнопки прямо на выходных.

3. У нас нет аналитиков.
Любой член команды может: предложить идею, увидеть, “зашла” фича или нет, увидеть влияние фичи на игру и стат значимость изменения основных параметров в одном дашборде. Освободилась куча времени, нет длительных обсуждений и холиваров. Конечно, меня сейчас съедят. Но для чего ещё нужна автоматизация?

4. Любая фича делается в нескольких вариантах исполнения.
Как правило, в фичу мы закладываем набор параметров, которые можно проверять, не перевыкладывая билд. Мы хотим запускать несколько AB-тестов в рамках одной фичи, чтобы “выжать из неё максимум”.

Пример:
1. В игре мы добавляем карту с ресурсами (смотри рисунок).
2. Как понять сколько кристалликов должно быть на одной ячейке карты? Мы делаем сразу 3-4 варианта: 100, 200, 300 и 400 кристалликов. Храним текущую конфигурацию на сервере. Игра подгружает этот конфиг при запуске.
3. Мы выкладываем новую карту на 50% и последовательно запускаем несколько тестов. Потом просто смотрим, на каком варианте мы заработали больше со статистической достоверностью.

Хорошо, что у нас есть платформа, которая позволяет это делать. Присоединяйтесь к нам!

​​Как я перестал нервничать и начал релизить

Изменения пугают. Каждый апдейт к игре - это всегда риск сломать игру.
Но мы не боимся, потому что отслеживаем воронку. Модель любой игры можно представить в виде событий-конверсий, которые совершает игрок. Например, в Match-3 будут конверсии: 1. Игрок прошёл обучение. 2. Игрок прошёл N-ый уровень.

У нас single player и в нашей модели конверсия - это просто “Игрок прошёл N-ый уровень”. Пример: на прошлой неделе мы добавили сохранение прогресса игрока на облаке. На 6-ом уровне у нас появляется NPC и говорит: “Дорогой игрок, ты прошёл достаточно далеко. Хочешь сохранить прогресс?”. Мы отвечаем “Да!” и данные сохраняются на облаке.

Выкатываем 50% функциональности с сохранением на облаке и сравниванием с игроками без сохранения. Мы ожидаем, что конверсия ухудшится на 6-ом уровне. Запускаем тест и получаем результаты.

Восклицательный знак на 6-ом уровне говорит нам, что да, конверсия действительно просела. Там, где мы ждали, результат статистически значим - дальше 6-го уровня мы точно потеряли в DAU. На 5-ом уровне падение в конверсии такое же, но с точки зрения платформы - это может быть и случайность, т.к. восклицательного знака нет.

Итого:
1. В деньгах мы не выиграли.
2. В конверсии на 5-ом уровне проиграли.
Вывод: фичу “Сохранение данных игрока” надо откатить. А как вы проверяете, зашла ли фича? Пишите в комментариях!

​​Как мы делаем выводы на основе экспериментальных данных

Мы говорили в прошлом посте, что наша задача - максимизация прибыли. Небольшое лирическое отступление.
Если вы работаете в игровой индустрии достаточно давно, то для вас стала привычной картина, когда аналитики (или кто-то, кто исполняет эту роль) собираются раз в неделю, и начинается:
- Фича зашла просто супер! Конверсия в платящих выросла в 2 раза.
- А бабла почему-то стало меньше.
- Да ну это сезонный спад. На следующей неделе наверстаем!
- Погодите! А ретеншн упал же?
- Да ну не - конверсия в 2 раза выросла, значит все огонь будет.
Через неделю новостей хороших тоже нет, и все примерно повторяется. Потом в штатах наступает рождество какое-нибудь - бабло растет. Все реже смотрят на относительные показатели. Январь - нерабочие дни. И в конце января все хватаются за голову. Владельца бизнеса абсолютно эти мелочи не интересуют. Мы хотим знать одно - делает новое изменение нас богаче или беднее.

Для ответа на этот вопрос наша платформа на вход получает: Impressions (количество показов рекламы на игрок) и In-Apps (сумма платежей на игрока). На выходе дает заключение - стало лучше или стало хуже. В аттаче иллюстрация нашей старой первой версии платформы.

Слева фильтры, которые позволяют узнать, как эксперимент отразился на разных группах игроков.
Level. Позволяет выделить игроков дошедших до уровня 5, 10 и 15. Часто бывает полезно увидеть, что фича в целом не зашла, но игроки, которые прошли 15 уровней (hardcor’ная аудитория), стали платить в несколько раз больше.
Traffic (organic, non-organic). С его помощью мы делаем кастомизованные под трафик фичи. Об этом отдельный пост будет.
Country. Аудитория наших игр - это 1st tier countries, поэтому мы в первую очередь смотрим на них.

Справа результаты эксперимента: in-apps result (not ready - недостаточно данных для выводов, fail - провал, success - успех) и impressions result (тоже самое про показы рекламы). Решение о дальнейшей судьбе фичи принимается только на основе заключений в этих двух полях. Все остальные данные - позволяют нам лучше понимать, что происходит в игре.

Это лишь самое основное, что есть в платформе. Математика внутри - тема отдельного поста. Как нам живется с платформой сейчас? Вкратце - хорошо. Нас совершенно не интересуют никакие другие показатели, кроме этих двух выводов.
- Мы понятия не имеем, какой у нас 1-day retention. Вот честно - не знаем даже, куда смотреть.
- Мы не хотим даже знать, какая у нас длина сессии на юзера.
- И нам совершенно плевать на то, сколько игроков прошли туториал.
- Не говоря уже о проценте конверсии в платящего игрока.

Хотите чтобы у вас было также? Оставьте заявку - мы вам все настроим! http://abtestreal.com/

Channel name was changed to «A/B-тестирование в мобильных играх»

[продолжение. cмотри начало в предыдущем посте]

В прошлом посте мы писали, что не нашли на рынке хорошей платформы для проведения А/В-тестов и решили написать свою. В этом посте мы расскажем, из чего состоит её техническая часть.

Давайте рассмотрим пример. На прошлой неделе мы перешли с медиации MoPub на Applovin Max. В рамках теста мы хотим узнать, как это изменение повлияло на основные метрики игры.

Remote Config
Настройка любого теста идет через удаленный конфиг, который хранится на облаке. Каждый раз, когда игрок первый раз открывает игру, игра запрашивает конфиг следующего формата:
Пример
ABTestV2ApplovinAndNewTowers28April02 = {"version":301,"variant":"Variant","parameters":{ }}
ABTestV2ApplovinAndNewTowers28April01 = {"version":300,"variant":"Control","parameters":{ }}

В этом примере мы просто говорим платформе: “Пометь всех игроков контрольной версии 300 как Control, а версию 301 как Variant в рамках теста V2ApplovinAndNewTowers28”.

Разделение игроков на группы
Сейчас мы умеем делить игроков на группы двумя способами:
1. Разбиение в рамках версии. Допустим, у нас на Google Play выложена на 100% аудитории версия 301. Мы запускаем тест на этой аудитории.
2. В рамках разных версий. Как в примере с Applovin. Мы выкладываем новый билд и хотим знать, как у него отличаются метрики по сравнению с контрольным.

Процесс сбора данных
Цель нашего эксперимента - заработать больше денег. Деньги мы получаем из двух источников:
1. Продажа In-App’ов. В нашем случае это золото, новые герои, новые башни и топливо. Для каждого игрока мы собираем всю информацию о его покупках.
2. Показ рекламы (impressions). Чем больше рекламы мы показали, тем больше денег заработали.

ВАЖНО в рамках эксперимента рассматривать не отдельные платежи и показы impressions, а сумму которую игроки тратят. На эту тему будет отдельный пост.

Кроме этого, мы собираем еще много всего, но все решения всегда принимаются только на основе данных о рекламе и in-app’ов. Нам абсолютно неважно, что стало с retention, стали ли игроки отваливаться на 5-ом уровне или нет. Эти метрики мы тоже собираем и обрабатываем, но они никогда не имеют веса в принятии решения, а скорее позволяют нам лучше понять, что произошло. Решение же принимается всегда на основе ответа на вопрос: “Стали мы зарабатывать больше или нет?”. Если стали зарабатывать больше, фича идет в продакшн. Если не стали, мы ее откатываем. Откатываем мы примерно 70% от всех фич. Почему так - это тоже тема отдельного поста.

Антифрод
На данный момент существенный процент игроков получает платный игровой контент, не заплатив. Для нашего эксперимента это проблема, потому что мы получаем кривые данные в рамках эксперимента и можем сделать неправильный вывод. Существует несколько способов (и это тоже тема отдельного поста) обмана разработчиков. Если кратко, то суть нашего антифрода - это проведение транзакций через облако.

1. Код на облаке запрашивает подтверждение о каждой транзакции у Google и отдает нашей игре заключение “Этот игрок не читер” или “Это читер”.
2. Игра помечает все in-app’ы как валидные или невалидные
3. В процессе обработки данных мы смотрим только на валидные in-app’ы.

Хранилище данных
Все данные об игроках хранятся в Google Analytics, и несколько раз в сутки мы выгружаем их в Big Query.

Обработка данных
Ядро нашей платформы написано на R. Мы отправляем запросы в Big Query и на стороне сервера обрабатываем их.

Как мы внедрили АБ тестирование в наших играх

Кто мы

Мы в Stereo7 Games делаем стратегии в жанре tower defense. Наш текущий главный проект - это игра Steampunk Defense: https://play.google.com/store/apps/details…. При разработке, мы уже более 2-ух лет активно используем АБ-тесты о которых я хотел бы рассказать ниже:

Краткое описание процесса
Наша основная платформа - это Google Play. Google Play дает возможность выкладывать каждый новый билд на 50% аудитории. Таким образом часть игроков видит новую фичу (персонажи, уровни, механики), а часть - не видит. Мы смотрим на игру в течение недели-двух и сравниваем заработок на версии с фичей с версией без фичи.


Что мы пробовали
Начали мы с
𝗔𝗺𝗽𝗹𝗶𝘁𝘂𝗱𝗲: https://amplitude.com/
Для анализа результатов, каждого игрока мы случайно определяли его в группу, которая либо видит новую фичу либо нет. Мы выделяли каждому игроку свойство Tes=[имя теста] и свойство Control или Variant и через Amplitude пытались понять больше мы заработали или меньше. Мы столкнулись с такими проблемами:

1. В Amplitude нет модуля статистики.
Амплитуда не смогла сказать нам - является ли изменение статистически значимым.

Пример: Мы видим
на контрольной группе LTV/DAU=$0.5
а на варианте мы видим LTV/DAU=$0,6

Как понять - мы действительно больше стали зарабатывать или это просто случайность?

Мы говорили с их консультантами - они предлагают подключить Optimizely за $100,000.

2. Amplitude плохо работает с Google Play in-app’ами
Т. к. все цены приходят в локальной валюте сложно посчитать суммарную выручку. 100 долларов + 10 рублей - это сколько?

𝗙𝗶𝗿𝗲𝗯𝗮𝘀𝗲
У Google есть бесплатное решение Firebase, которое решает проблемы выше. У них есть статистический модуль и in-app’ы приводятся к долларам США. Некоторые недостатки мы увидели сразу, но решили на первое время закрыть на них глаза. Вот они:


1. Firebase не позволяет сравнивать средние значения для рекламы.
Т. е. если вы хотите (а мы хотели еще как!) максимизировать число показов рекламы, вы можете сделать это только в случае если используете AdMob. У нас AdMob не единственная сетка, поэтому Firebase не подходил для этой задачи.

2. Firebase не позволяет сравнивать средние значения для произвольной метрики.
Если вы в рамках теста хотите максимизировать число прохождения уровней (например), то Firebase вам это не позволит. Единственное что он даст - это отслеживать конверсию вида: “игрок дошел до 5-го уровня”.

Конечно, с помощью костылей можно извратиться и попытаться отследить среднее для произвольной метрики, он корректно это сделать невозможно.

3. Не очень аккуратная работа с фродом
Firebase в целом отсеивает игроков, которые проводят махинации с in-app’ами, но иногда мы видели разницу в финансовых отчетах от Google Play и Firebase.

Проблема заключается в том что Firebase считает что некоторые игроки заплатили, хотя на самом деле они не платили.

4. Слабый (а точнее никакой) движок обработки тестов
Первое время мы понастроили костылей и решили работать с Firebase, закрыв глаза на пункты выше. Тесты проходили очень быстро. Много тестов заканчивались успехом. Но вот только выручка почему-то не росла...

Чтобы проверить движок, мы начали запускать АА Тесты. АА Тест - это классический прием в АБ тестировании для проверки работоспособности движка обсчета, когда игроки в обеих группах игроки получают в точности одинаковую версию игры.

К нашему удивления Firebase очень быстро находил победителя в АА тестах. Т. е. другими словами он писал “Вариант А лучше с вероятностью 99%” хотя на самом деле никакого варианта А не было - он был в точности равен варианту Б.

𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲𝗹𝘆
По слухам они работают хорошо, но блин $100,000...

Я с большим скепсисом отношусь к попыткам разработать “свой движок аналитики”, “свою рендерилку” и т. п. И уж точно не разделяю шовинистических идей в духе: “это плохо потому что разработано не нами”.

Короче, мы задумались о своей платформе для АБ тестирования в которой не было бы недостатков выше.

[продолжение следует]

Channel created