Как мы внедрили АБ тестирование в наших играх
Кто мы
Мы в 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...
Я с большим скепсисом отношусь к попыткам разработать “свой движок аналитики”, “свою рендерилку” и т. п. И уж точно не разделяю шовинистических идей в духе: “это плохо потому что разработано не нами”.
Короче, мы задумались о своей платформе для АБ тестирования в которой не было бы недостатков выше.
[продолжение следует]
Кто мы
Мы в 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...
Я с большим скепсисом отношусь к попыткам разработать “свой движок аналитики”, “свою рендерилку” и т. п. И уж точно не разделяю шовинистических идей в духе: “это плохо потому что разработано не нами”.
Короче, мы задумались о своей платформе для АБ тестирования в которой не было бы недостатков выше.
[продолжение следует]