Как я перестал нервничать и начал релизить
Изменения пугают. Каждый апдейт к игре - это всегда риск сломать игру.
Но мы не боимся, потому что отслеживаем воронку. Модель любой игры можно представить в виде событий-конверсий, которые совершает игрок. Например, в Match-3 будут конверсии: 1. Игрок прошёл обучение. 2. Игрок прошёл N-ый уровень.
У нас single player и в нашей модели конверсия - это просто “Игрок прошёл N-ый уровень”. Пример: на прошлой неделе мы добавили сохранение прогресса игрока на облаке. На 6-ом уровне у нас появляется NPC и говорит: “Дорогой игрок, ты прошёл достаточно далеко. Хочешь сохранить прогресс?”. Мы отвечаем “Да!” и данные сохраняются на облаке.
Выкатываем 50% функциональности с сохранением на облаке и сравниванием с игроками без сохранения. Мы ожидаем, что конверсия ухудшится на 6-ом уровне. Запускаем тест и получаем результаты.
Восклицательный знак на 6-ом уровне говорит нам, что да, конверсия действительно просела. Там, где мы ждали, результат статистически значим - дальше 6-го уровня мы точно потеряли в DAU. На 5-ом уровне падение в конверсии такое же, но с точки зрения платформы - это может быть и случайность, т.к. восклицательного знака нет.
Итого:
1. В деньгах мы не выиграли.
2. В конверсии на 5-ом уровне проиграли.
Вывод: фичу “Сохранение данных игрока” надо откатить. А как вы проверяете, зашла ли фича? Пишите в комментариях!
Изменения пугают. Каждый апдейт к игре - это всегда риск сломать игру.
Но мы не боимся, потому что отслеживаем воронку. Модель любой игры можно представить в виде событий-конверсий, которые совершает игрок. Например, в Match-3 будут конверсии: 1. Игрок прошёл обучение. 2. Игрок прошёл N-ый уровень.
У нас single player и в нашей модели конверсия - это просто “Игрок прошёл N-ый уровень”. Пример: на прошлой неделе мы добавили сохранение прогресса игрока на облаке. На 6-ом уровне у нас появляется NPC и говорит: “Дорогой игрок, ты прошёл достаточно далеко. Хочешь сохранить прогресс?”. Мы отвечаем “Да!” и данные сохраняются на облаке.
Выкатываем 50% функциональности с сохранением на облаке и сравниванием с игроками без сохранения. Мы ожидаем, что конверсия ухудшится на 6-ом уровне. Запускаем тест и получаем результаты.
Восклицательный знак на 6-ом уровне говорит нам, что да, конверсия действительно просела. Там, где мы ждали, результат статистически значим - дальше 6-го уровня мы точно потеряли в DAU. На 5-ом уровне падение в конверсии такое же, но с точки зрения платформы - это может быть и случайность, т.к. восклицательного знака нет.
Итого:
1. В деньгах мы не выиграли.
2. В конверсии на 5-ом уровне проиграли.
Вывод: фичу “Сохранение данных игрока” надо откатить. А как вы проверяете, зашла ли фича? Пишите в комментариях!
Что изменилось после того, как мы внедрили AB-тестирование
Когда мы разрабатывали платформу, прежде всего, мы хотели получить инструмент для запуска AB-тестов. Мы не ожидали, что изменится сам процесс. Что изменилось:
1. Мы начали выкладывать апдейты, не тестируя их тщательно.
Наша стратегия - выкладывать как можно больше апдейтов. Платформа сообщает, если мы выложили билд, который сильно ухудшает параметры - тогда можем оперативно откатить его. Мы проводим глубокое регрессионное тестирование после выкладки билда, а фиксим баги в следующем релизе. Так мы сильно увеличиваем частоту апдейтов.
2. На Google Play мы можем выложить апдейт в пятницу вечером.
Если платформа на выходных сигнализирует о проблемах в билде, мы откатываем его буквально одним нажатием кнопки прямо на выходных.
3. У нас нет аналитиков.
Любой член команды может: предложить идею, увидеть, “зашла” фича или нет, увидеть влияние фичи на игру и стат значимость изменения основных параметров в одном дашборде. Освободилась куча времени, нет длительных обсуждений и холиваров. Конечно, меня сейчас съедят. Но для чего ещё нужна автоматизация?
4. Любая фича делается в нескольких вариантах исполнения.
Как правило, в фичу мы закладываем набор параметров, которые можно проверять, не перевыкладывая билд. Мы хотим запускать несколько AB-тестов в рамках одной фичи, чтобы “выжать из неё максимум”.
Пример:
1. В игре мы добавляем карту с ресурсами (смотри рисунок).
2. Как понять сколько кристалликов должно быть на одной ячейке карты? Мы делаем сразу 3-4 варианта: 100, 200, 300 и 400 кристалликов. Храним текущую конфигурацию на сервере. Игра подгружает этот конфиг при запуске.
3. Мы выкладываем новую карту на 50% и последовательно запускаем несколько тестов. Потом просто смотрим, на каком варианте мы заработали больше со статистической достоверностью.
Хорошо, что у нас есть платформа, которая позволяет это делать. Присоединяйтесь к нам!
Когда мы разрабатывали платформу, прежде всего, мы хотели получить инструмент для запуска AB-тестов. Мы не ожидали, что изменится сам процесс. Что изменилось:
1. Мы начали выкладывать апдейты, не тестируя их тщательно.
Наша стратегия - выкладывать как можно больше апдейтов. Платформа сообщает, если мы выложили билд, который сильно ухудшает параметры - тогда можем оперативно откатить его. Мы проводим глубокое регрессионное тестирование после выкладки билда, а фиксим баги в следующем релизе. Так мы сильно увеличиваем частоту апдейтов.
2. На Google Play мы можем выложить апдейт в пятницу вечером.
Если платформа на выходных сигнализирует о проблемах в билде, мы откатываем его буквально одним нажатием кнопки прямо на выходных.
3. У нас нет аналитиков.
Любой член команды может: предложить идею, увидеть, “зашла” фича или нет, увидеть влияние фичи на игру и стат значимость изменения основных параметров в одном дашборде. Освободилась куча времени, нет длительных обсуждений и холиваров. Конечно, меня сейчас съедят. Но для чего ещё нужна автоматизация?
4. Любая фича делается в нескольких вариантах исполнения.
Как правило, в фичу мы закладываем набор параметров, которые можно проверять, не перевыкладывая билд. Мы хотим запускать несколько AB-тестов в рамках одной фичи, чтобы “выжать из неё максимум”.
Пример:
1. В игре мы добавляем карту с ресурсами (смотри рисунок).
2. Как понять сколько кристалликов должно быть на одной ячейке карты? Мы делаем сразу 3-4 варианта: 100, 200, 300 и 400 кристалликов. Храним текущую конфигурацию на сервере. Игра подгружает этот конфиг при запуске.
3. Мы выкладываем новую карту на 50% и последовательно запускаем несколько тестов. Потом просто смотрим, на каком варианте мы заработали больше со статистической достоверностью.
Хорошо, что у нас есть платформа, которая позволяет это делать. Присоединяйтесь к нам!
Работа с балансом в игре
Хороший баланс в игре - это набор цифр, который в идеале делает игроков счастливее (необязательно) и наполняет кошельки владельцев баблом (обязательно).
Допустим, мы решили усложнить нашу игру. Игроки начнут платить и продолжат играть? Или разбегутся, потому что станет слишком сложно? Сколько нервов гейм-дизайнеров, аналитиков и разработчиков потрачено за спорами!
Вопросы цифр в игре мы решаем всегда одинаково - запускаем эксперимент. Механика наших 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
Хороший баланс в игре - это набор цифр, который в идеале делает игроков счастливее (необязательно) и наполняет кошельки владельцев баблом (обязательно).
Допустим, мы решили усложнить нашу игру. Игроки начнут платить и продолжат играть? Или разбегутся, потому что станет слишком сложно? Сколько нервов гейм-дизайнеров, аналитиков и разработчиков потрачено за спорами!
Вопросы цифр в игре мы решаем всегда одинаково - запускаем эксперимент. Механика наших 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
Работа с контентом в игре
Реальный случай из жизни. Приходит художник и говорит:
- Нам нужны новые крипы (враги) на уровнях! Солдаты сейчас всех бесят.
- Давай посмотрим!
Были солдаты, стали - роботы. Запускаем эксперимент и получаем небольшое, но статистически значимое падение конверсии на первом уровне (смотрите скриншот).
С одной стороны, фейл - хотели улучшить жизнь игрокам, но ничего не изменилось. На самом деле, успех - мы получили знание: игрокам не так уж и важно, КТО именно бегает в качестве крипов. Значит похожее исправление в игре мы планировать в ближайшее время не будем.
Хотите получать знания о своей игре? Давайте к нам! abtestreal.com
Реальный случай из жизни. Приходит художник и говорит:
- Нам нужны новые крипы (враги) на уровнях! Солдаты сейчас всех бесят.
- Давай посмотрим!
Были солдаты, стали - роботы. Запускаем эксперимент и получаем небольшое, но статистически значимое падение конверсии на первом уровне (смотрите скриншот).
С одной стороны, фейл - хотели улучшить жизнь игрокам, но ничего не изменилось. На самом деле, успех - мы получили знание: игрокам не так уж и важно, КТО именно бегает в качестве крипов. Значит похожее исправление в игре мы планировать в ближайшее время не будем.
Хотите получать знания о своей игре? Давайте к нам! abtestreal.com
АB-тестирование и работа с когортами
О работе с когортами много говорят, но часто непонятно, как с ними правильно работать. Об этом пойдет речь ниже.
Google Universal Campaign - один из источников трафика для нашей игры. Мы оптимизируем кампании под инсталлы, поэтому почти все наши игроки с Google неплатящие. Из экспериментов нам уже известно:
1. Если показывать больше рекламы платящим игрокам на первых уровнях, то такие игроки раньше уходят и суммарное количество показанной рекламы таким игрокам меньше.
2. Игроки с Google проходят меньше уровней в игре.
Мы хотим проверить гипотезу: если показывать больше рекламы на первых уровнях игрокам с Google (которые не платят и рано уходят из игры), суммарное количество показов вырастет.
Запускаем эксперимент только на игроках с Google:
Показываем игрокам рекламу сразу, начиная с первого уровня, и убираем ограничение на показ рекламы (можем в течение 1 минуты показать несколько раз). Для контрольной группы показываем только на уровнях 2, 4, 6… и оставляем ограничение - не более 1 показа в минуту.
Результат. Суммарное количество показов выросло: доверительный интервал -0.098 — 2.94, вероятность 93.2%. Хотя и рекомендуют принимать решение при вероятности выше 95%, мы немного жульничаем и делаем вывод — показываем игрокам с Google больше рекламы на первых уровнях.
О работе с когортами много говорят, но часто непонятно, как с ними правильно работать. Об этом пойдет речь ниже.
Google Universal Campaign - один из источников трафика для нашей игры. Мы оптимизируем кампании под инсталлы, поэтому почти все наши игроки с Google неплатящие. Из экспериментов нам уже известно:
1. Если показывать больше рекламы платящим игрокам на первых уровнях, то такие игроки раньше уходят и суммарное количество показанной рекламы таким игрокам меньше.
2. Игроки с Google проходят меньше уровней в игре.
Мы хотим проверить гипотезу: если показывать больше рекламы на первых уровнях игрокам с Google (которые не платят и рано уходят из игры), суммарное количество показов вырастет.
Запускаем эксперимент только на игроках с Google:
Показываем игрокам рекламу сразу, начиная с первого уровня, и убираем ограничение на показ рекламы (можем в течение 1 минуты показать несколько раз). Для контрольной группы показываем только на уровнях 2, 4, 6… и оставляем ограничение - не более 1 показа в минуту.
Результат. Суммарное количество показов выросло: доверительный интервал -0.098 — 2.94, вероятность 93.2%. Хотя и рекомендуют принимать решение при вероятности выше 95%, мы немного жульничаем и делаем вывод — показываем игрокам с Google больше рекламы на первых уровнях.
4 июля начинается онлайн интенсив по математической статистике, который проведут наши друзья Виталий Черемисинов и Искандер Мирмахмадов.
Ребята - настоящие специалисты своего дела, которые сильно помогли нам создать нашу платформу. Мы уверены, что они помогут и Вам погрузиться в статистику и разобраться в нюансах проведения А/В-тестов.
Подробная информация: https://www.experiment-fest.ru/ab_course
Ребята - настоящие специалисты своего дела, которые сильно помогли нам создать нашу платформу. Мы уверены, что они помогут и Вам погрузиться в статистику и разобраться в нюансах проведения А/В-тестов.
Подробная информация: https://www.experiment-fest.ru/ab_course
Как правильно выставить цену для in-app’а?
Мы добавили в игру новое специальное предложение, которое дает игроку треть всего внутриигрового контента. Цена - $10. Продажи прут, но на душе неспокойно: “А может мы продешевили? Может надо было $15 сделать? Или вообще $20!”. Ставим эксперимент! Для начала поймем, что такое правильная цена. Рассмотрим следующие варианты.
1. Самая высокая цена.
Вряд-ли. Если поставить цену в $100, покупателей можно и не дождаться.
2. Цена, при которой доход с продажи продукта максимален.
Этот ответ кажется более разумным, но он тоже плохой. Игроки могут больше покупать ваш новый продукт, а старые продукты наоборот - перестать покупать. Проиграем в общем доходе.
3. Цена, при которой суммарный доход максимален.
Похоже, это правильный ответ. С каких бы других продуктов игроки не перескакивали на наш новый, главное, чтобы сумма денежных поступлений по всем продуктам была максимальной.
С задачей разобрались. Подумаем над технической реализацией. Нам надо выставлять цену в каком-то конфиге на облаке и следить за суммарным доходом по игре. Но Google Play позволяет заводить in-app’ы только в игре, и цена на in-app фиксирована. Как нам менять ее?
1. Заводим каждому in-app’у айдишник в игре. Например, ID = SpecialOffer.
2. Заводим несколько in-app’ов на Google Play с разной ценой. Например: SpecialOffer15, SpecialOffer17 и SpecialOffer20.
3. Выносим в конфигуратор на облаке соответствие <ID в игре — ID in-app’а на Google Play>. Например: <SpecialOffer — SpecialOffer15>, где SpecialOffer15 - это ID in-app’а с ценой $15, который мы завели на Google Play.
4. На каждый SpecialOffer со своей ценой проводим AB-тест, в котором сравниваем его с контрольной группой.
Говорим игре “возьми для контрольной группы in-app с ценой $10, а для экспериментальной $15”. Запускаем эксперимент и получаем результат: улучшение в in-apps от $0.01 до $0.42 с вероятностью 96.6%, а impressions не изменились. Мы получили знание “Цена $15 лучше цены $10”, поэтому меняем нашу цену в игре с $10 на $15 и продолжаем эксперименты!
… с помощью платформы abtestreal.com
Мы добавили в игру новое специальное предложение, которое дает игроку треть всего внутриигрового контента. Цена - $10. Продажи прут, но на душе неспокойно: “А может мы продешевили? Может надо было $15 сделать? Или вообще $20!”. Ставим эксперимент! Для начала поймем, что такое правильная цена. Рассмотрим следующие варианты.
1. Самая высокая цена.
Вряд-ли. Если поставить цену в $100, покупателей можно и не дождаться.
2. Цена, при которой доход с продажи продукта максимален.
Этот ответ кажется более разумным, но он тоже плохой. Игроки могут больше покупать ваш новый продукт, а старые продукты наоборот - перестать покупать. Проиграем в общем доходе.
3. Цена, при которой суммарный доход максимален.
Похоже, это правильный ответ. С каких бы других продуктов игроки не перескакивали на наш новый, главное, чтобы сумма денежных поступлений по всем продуктам была максимальной.
С задачей разобрались. Подумаем над технической реализацией. Нам надо выставлять цену в каком-то конфиге на облаке и следить за суммарным доходом по игре. Но Google Play позволяет заводить in-app’ы только в игре, и цена на in-app фиксирована. Как нам менять ее?
1. Заводим каждому in-app’у айдишник в игре. Например, ID = SpecialOffer.
2. Заводим несколько in-app’ов на Google Play с разной ценой. Например: SpecialOffer15, SpecialOffer17 и SpecialOffer20.
3. Выносим в конфигуратор на облаке соответствие <ID в игре — ID in-app’а на Google Play>. Например: <SpecialOffer — SpecialOffer15>, где SpecialOffer15 - это ID in-app’а с ценой $15, который мы завели на Google Play.
4. На каждый SpecialOffer со своей ценой проводим AB-тест, в котором сравниваем его с контрольной группой.
Говорим игре “возьми для контрольной группы in-app с ценой $10, а для экспериментальной $15”. Запускаем эксперимент и получаем результат: улучшение в in-apps от $0.01 до $0.42 с вероятностью 96.6%, а impressions не изменились. Мы получили знание “Цена $15 лучше цены $10”, поэтому меняем нашу цену в игре с $10 на $15 и продолжаем эксперименты!
… с помощью платформы abtestreal.com
Как не потерять доход, отдыхая в Тайланде
Мы - руководители игровых студий - находимся в постоянном страхе. С годами он уменьшается, но все равно каждое обновление игры - это мини-стресс.
Произойти может всякое:
- Игра может крэшиться на каком-то уровне, а игроки уходить навсегда.
- Разработчик может случайно пару рекламных сеток отрубить.
- Кнопку “купить” можно сделать невидимой и пропустить во время тестирования.
Баги в играх - норма жизни. Да, мы стремимся их минимизировать, но у вас наверняка тоже были случаи, когда вы выкатили в продакшн какую-то дичь. Поэтому любой новый билд мы сначала выкладываем на 50% аудитории в продакшн и сравниванием его с текущим стабильным билдом.
Я на Новый Год свалил в Тайланд и утром, проверяя дашборд, увидел такую картину - смотри картинку. Грустный смайлик в дашборде сообщил мне: “Эй! На 6-ом уровне статистически значимое проседание в 9%!”. После такого сигнала я сразу откатил тестовый билд и отправил разработчикам: “Ребят, на 6-ом уровне что-то не то. Посмотрите, пожалуйста”.
Мне не надо разбираться, в чем там дело. Мне не надо скачивать игру и смотреть на 6-ой уровень. Мне не надо знать, что планировали разработчики в апдейте. Вся необходимая информация у меня уже есть. Я просто закрываю ноут и иду к шезлонгу.
И вы можете также - подключайтесь к нашей платформе abtestreal.com
Мы - руководители игровых студий - находимся в постоянном страхе. С годами он уменьшается, но все равно каждое обновление игры - это мини-стресс.
Произойти может всякое:
- Игра может крэшиться на каком-то уровне, а игроки уходить навсегда.
- Разработчик может случайно пару рекламных сеток отрубить.
- Кнопку “купить” можно сделать невидимой и пропустить во время тестирования.
Баги в играх - норма жизни. Да, мы стремимся их минимизировать, но у вас наверняка тоже были случаи, когда вы выкатили в продакшн какую-то дичь. Поэтому любой новый билд мы сначала выкладываем на 50% аудитории в продакшн и сравниванием его с текущим стабильным билдом.
Я на Новый Год свалил в Тайланд и утром, проверяя дашборд, увидел такую картину - смотри картинку. Грустный смайлик в дашборде сообщил мне: “Эй! На 6-ом уровне статистически значимое проседание в 9%!”. После такого сигнала я сразу откатил тестовый билд и отправил разработчикам: “Ребят, на 6-ом уровне что-то не то. Посмотрите, пожалуйста”.
Мне не надо разбираться, в чем там дело. Мне не надо скачивать игру и смотреть на 6-ой уровень. Мне не надо знать, что планировали разработчики в апдейте. Вся необходимая информация у меня уже есть. Я просто закрываю ноут и иду к шезлонгу.
И вы можете также - подключайтесь к нашей платформе abtestreal.com
Как жулики помогают нам больше зарабатывать
На любую надежную и стройную систему всегда найдется ломатель. Там, где есть товар, всегда есть вор.
Работая с разными системами аналитики, мы начали обращать внимание на отличие суммы на графиках и суммы выплат платформы (App Store или Google Play). Причина простая - fraud. Игрок обманывает игру и получает внутриигровой контент бесплатно.
Техническая сторона чаще всего такая:
1. Жулик скачивает приложение, которое стоит между вызовами игры и Google Play.
2. Жулик делает в игре запрос на покупку.
3. Подключается промежуточное приложение, которое принимает этот запрос и высылает игре подтверждение оплаты.
4. Игра, ничего не подозревая, выдает жулику внутриигровой контент.
5. Жулик счастлив.
Решение простое - перед шагом 4 игра отправляет запрос на свой сервер, про который не знает приложение жулика, для проверки транзакции. Выявлять жуликов мы научились. Что теперь с ними делать? Первая наша мысль - банить игроков-жуликов, но мы провели AB-эксперимент.
В контрольной группе мы не давали in-app’ы игрокам-жуликам. В экспериментальной давали жуликам контент, который они хотели получить, и отмечали таких игроков как жуликов. Экспериментальная группа получила статистически значимое увеличение показов рекламы! Оказалось, что жулики нам полезны даже с учетом наворованного.
Поэтому сейчас мы “поддаемся” жуликам и помечаем их для корректного раcчёта in-app’ов. А как fraud отражается на вашей игре? Проверьте с помощью платформы abtestreal.com
На любую надежную и стройную систему всегда найдется ломатель. Там, где есть товар, всегда есть вор.
Работая с разными системами аналитики, мы начали обращать внимание на отличие суммы на графиках и суммы выплат платформы (App Store или Google Play). Причина простая - fraud. Игрок обманывает игру и получает внутриигровой контент бесплатно.
Техническая сторона чаще всего такая:
1. Жулик скачивает приложение, которое стоит между вызовами игры и Google Play.
2. Жулик делает в игре запрос на покупку.
3. Подключается промежуточное приложение, которое принимает этот запрос и высылает игре подтверждение оплаты.
4. Игра, ничего не подозревая, выдает жулику внутриигровой контент.
5. Жулик счастлив.
Решение простое - перед шагом 4 игра отправляет запрос на свой сервер, про который не знает приложение жулика, для проверки транзакции. Выявлять жуликов мы научились. Что теперь с ними делать? Первая наша мысль - банить игроков-жуликов, но мы провели AB-эксперимент.
В контрольной группе мы не давали in-app’ы игрокам-жуликам. В экспериментальной давали жуликам контент, который они хотели получить, и отмечали таких игроков как жуликов. Экспериментальная группа получила статистически значимое увеличение показов рекламы! Оказалось, что жулики нам полезны даже с учетом наворованного.
Поэтому сейчас мы “поддаемся” жуликам и помечаем их для корректного раcчёта in-app’ов. А как fraud отражается на вашей игре? Проверьте с помощью платформы abtestreal.com
Если вы что-то ищете, то вы всегда найдете “что-то”
Как-то наблюдал такой разговор:
Разработчик: Завтра мы выкатываем новую фичу
Аналитик: ОК. Затречьте мне как можно больше событий. Мне нужны: конверсия захода в магазин, количество кликов на кнопке с новой фичей, воронка прохождения игрока от туториала до покупки и список трат ресурсов.
Разработчик: На что ты будешь смотреть в первую очередь?
Аналитик: На все. Посмотрим, как фича зашла игрокам.
Разработчик: При каких условиях мы будем откатывать фичу?
Аналитик: Ни при каких. Если какие-то параметры просядут, будем думать, как улучшить эти параметры.
Если говорить совсем просто, то такая практика порочна. Представьте себе такой эксперимент. Вместо конверсии и воронки вы смотрите, как разные люди подбрасывают монетку 5 раз. Мы знаем, что вероятность выброса орла составляет 50%. Допустим, 5 человек подбрасывают монетку.
Вася: Орел, Решка, Решка, Орел, Орел
Петя: Решка, Решка, Орел, Орел, Орел
Ваня: Решка, Решка, Решка, Решка, Орел
Слава: Решка, Решка, Орел, Орел, Орел
Игорь: Орел, Орел, Решка, Орел, Орел
Если вы рассуждаете как аналитик из примера, то вы можете подумать: “А Ваня хорош в решке! Надо его промоутить как-то. И надо еще на Игоря обратить внимание - как он так научился орлы выбрасывать? Может мы и этому навыку найдем применение?”. Хотя выпадания случайны. Да, пример выглядит абсурдно, но так работают очень многие в игровой индустрии. Очень многие ищут “что-то” и “что-то” находят.
Некорректные множественные сравнения - это одна из форм p-hacking’а. При производстве лекарств нечистоплотные производители ставят большое число экспериментов и, когда они закончены, выбирают тот, который соответствует их гипотезе.
Этот трюк давно известен в научной среде, поэтому если вы хотите опубликовать свою работу в серьезном научном журнале, вы должны подать заявку со списком отслеживаемых параметров ДО ЭКСПЕРИМЕНТА. Вас просто не опубликуют в журнале, если вы придете в один день и заявите: “После новой фичи у нас вырос LTV на игрока!”.
Что делать?
Есть разные способы, но в целом - определяться с отслеживаемыми параметрами до выката фичи. Если вы хотите отслеживать какие-то другие параметры, отслеживайте их в рамках следующих экспериментов.
Возникает вопрос: “А если я хочу смотреть на среднее время сессии, ретеншн, LTV и конверсию?”. Ответ: “Не надо так!”.
Статей на эту тему просто гора. Но самые доходчивые мы нашли в книжке “Доказательная медицина от магии до поисков бессмертия”, Талантов Петр.
Как-то наблюдал такой разговор:
Разработчик: Завтра мы выкатываем новую фичу
Аналитик: ОК. Затречьте мне как можно больше событий. Мне нужны: конверсия захода в магазин, количество кликов на кнопке с новой фичей, воронка прохождения игрока от туториала до покупки и список трат ресурсов.
Разработчик: На что ты будешь смотреть в первую очередь?
Аналитик: На все. Посмотрим, как фича зашла игрокам.
Разработчик: При каких условиях мы будем откатывать фичу?
Аналитик: Ни при каких. Если какие-то параметры просядут, будем думать, как улучшить эти параметры.
Если говорить совсем просто, то такая практика порочна. Представьте себе такой эксперимент. Вместо конверсии и воронки вы смотрите, как разные люди подбрасывают монетку 5 раз. Мы знаем, что вероятность выброса орла составляет 50%. Допустим, 5 человек подбрасывают монетку.
Вася: Орел, Решка, Решка, Орел, Орел
Петя: Решка, Решка, Орел, Орел, Орел
Ваня: Решка, Решка, Решка, Решка, Орел
Слава: Решка, Решка, Орел, Орел, Орел
Игорь: Орел, Орел, Решка, Орел, Орел
Если вы рассуждаете как аналитик из примера, то вы можете подумать: “А Ваня хорош в решке! Надо его промоутить как-то. И надо еще на Игоря обратить внимание - как он так научился орлы выбрасывать? Может мы и этому навыку найдем применение?”. Хотя выпадания случайны. Да, пример выглядит абсурдно, но так работают очень многие в игровой индустрии. Очень многие ищут “что-то” и “что-то” находят.
Некорректные множественные сравнения - это одна из форм p-hacking’а. При производстве лекарств нечистоплотные производители ставят большое число экспериментов и, когда они закончены, выбирают тот, который соответствует их гипотезе.
Этот трюк давно известен в научной среде, поэтому если вы хотите опубликовать свою работу в серьезном научном журнале, вы должны подать заявку со списком отслеживаемых параметров ДО ЭКСПЕРИМЕНТА. Вас просто не опубликуют в журнале, если вы придете в один день и заявите: “После новой фичи у нас вырос LTV на игрока!”.
Что делать?
Есть разные способы, но в целом - определяться с отслеживаемыми параметрами до выката фичи. Если вы хотите отслеживать какие-то другие параметры, отслеживайте их в рамках следующих экспериментов.
Возникает вопрос: “А если я хочу смотреть на среднее время сессии, ретеншн, LTV и конверсию?”. Ответ: “Не надо так!”.
Статей на эту тему просто гора. Но самые доходчивые мы нашли в книжке “Доказательная медицина от магии до поисков бессмертия”, Талантов Петр.
Что мы делаем, когда разработчики заняты
Порой разработчики длительно заняты большой задачей. Например, 3 недели назад мы начали пилить крупный апдейт, который займет примерно месяц. Раньше мы сильно переживали, что игроки надолго остаются без апдейтов. Учитывая, что много апдейтов мы откатываем, можно загрустить.
Сейчас вместо того чтобы торопить разработчиков и срывать нервы, мы:
1. Запускаем тесты на баланс (об этом было подробно в прошлых статьях).
2. Запускаем тесты на удаление фич.
Пункт 2 - наш самый любимый. Запустить его можно очень дешево, а эффект бывает как от дорогой фичи. Рассмотрим пример. В нашей многоуровневой tower defense игре Island Defense есть механика Survival. Крипы вылезают из всех щелей, надо продержаться как можно дольше, чем дольше продержишься, тем больше приз.
Шаги эксперимента:
1. Делим игроков на две группы: контрольная получает версию с фичей (“есть survival”), вторая - без фичи (“нет survival”).
2. Скармливаем данные о покупках и показах рекламы нашей платформе (рассмотрим далее на примере показов).
3. Платформа считает показы для каждого игрока в двух группах: Игрок 2346 - 5 показов, Игрок 5435 - 7 показов, …
4. Собираются данные на 2000-4000 игроков. По предыдущему опыту мы знаем, что примерно на таком количестве наши тесты “красятся”, т.е. платформе достаточно данных для выдачи заключения.
5. Платформа строит распределение разницы средних значений показов через бутстрап. Возможно, страшно прозвучало сейчас :) Бутстрап - это тема отдельной статьи, но если говорить совсем просто, то это моделирование подсчета среднего значения на основе существующих данных. Или еще проще: бутстрап показывает, как могло бы выглядеть среднее на наших данных, если бы они были немного другими.
На графике в этом примере:
1. 95% доверительный интервал разницы находится ниже 0. На человеческий язык это переводится так: “Со значительной степенью уверенности можно говорить, что разница есть”.
2. Границы доверительного интервала: -1.17, -4.64. И опять в переводе на человеческий язык: “Увеличение составляет от 1.17 до 4.64 показа на игрока”.
Ура! Времени потрачено мало, а эффект большой! Выпиливаем survival, чтобы показывать еще больше рекламы игрокам.
Честно говоря, мы показали хороший сценарий, что происходит редко. В большинстве случаев мы не ждем, что выпиливание фичи даст результат. Но когда разработчики заняты, и интересный эксперимент запустить не получается… Почему бы не выпиливать фичи?
Порой разработчики длительно заняты большой задачей. Например, 3 недели назад мы начали пилить крупный апдейт, который займет примерно месяц. Раньше мы сильно переживали, что игроки надолго остаются без апдейтов. Учитывая, что много апдейтов мы откатываем, можно загрустить.
Сейчас вместо того чтобы торопить разработчиков и срывать нервы, мы:
1. Запускаем тесты на баланс (об этом было подробно в прошлых статьях).
2. Запускаем тесты на удаление фич.
Пункт 2 - наш самый любимый. Запустить его можно очень дешево, а эффект бывает как от дорогой фичи. Рассмотрим пример. В нашей многоуровневой tower defense игре Island Defense есть механика Survival. Крипы вылезают из всех щелей, надо продержаться как можно дольше, чем дольше продержишься, тем больше приз.
Шаги эксперимента:
1. Делим игроков на две группы: контрольная получает версию с фичей (“есть survival”), вторая - без фичи (“нет survival”).
2. Скармливаем данные о покупках и показах рекламы нашей платформе (рассмотрим далее на примере показов).
3. Платформа считает показы для каждого игрока в двух группах: Игрок 2346 - 5 показов, Игрок 5435 - 7 показов, …
4. Собираются данные на 2000-4000 игроков. По предыдущему опыту мы знаем, что примерно на таком количестве наши тесты “красятся”, т.е. платформе достаточно данных для выдачи заключения.
5. Платформа строит распределение разницы средних значений показов через бутстрап. Возможно, страшно прозвучало сейчас :) Бутстрап - это тема отдельной статьи, но если говорить совсем просто, то это моделирование подсчета среднего значения на основе существующих данных. Или еще проще: бутстрап показывает, как могло бы выглядеть среднее на наших данных, если бы они были немного другими.
На графике в этом примере:
1. 95% доверительный интервал разницы находится ниже 0. На человеческий язык это переводится так: “Со значительной степенью уверенности можно говорить, что разница есть”.
2. Границы доверительного интервала: -1.17, -4.64. И опять в переводе на человеческий язык: “Увеличение составляет от 1.17 до 4.64 показа на игрока”.
Ура! Времени потрачено мало, а эффект большой! Выпиливаем survival, чтобы показывать еще больше рекламы игрокам.
Честно говоря, мы показали хороший сценарий, что происходит редко. В большинстве случаев мы не ждем, что выпиливание фичи даст результат. Но когда разработчики заняты, и интересный эксперимент запустить не получается… Почему бы не выпиливать фичи?
Как мы выбираем, ЧТО тестировать дальше
Когда стоит выбор, в какой области игры проводить следующий АВ-тест, у нас есть 2 варианта:
1. Искать новые точки роста.
2. Прокачивать существующие.
Мы недавно запустили новую игру и первым делом начали прогонять тесты на баланс и улучшение воронки уровней. Ранее мы писали, что запускаем серию АВ-тестов и подбираем оптимальное значение HP врагов, меняя коэффициент K в формуле: HP крипа = базовое HP * K.
Сначала мы запускаем серию тестов на “поиск точек роста”, чтобы подобрать оптимальное K. Успехом мы будем считать прохождение игроком игры как можно дальше по воронке уровней: 1-ый, 2-ой, 3-ий и т.д.
В играх, которые уже существуют долго, мы так никогда не делаем. В них нас интересуют в первую очередь деньги, а не прохождение. Но т.к. у этой игры монетизация еще не настроена, мы можем позволить себе запустить несколько АВ-тестов на продвижение игроков вглубь игры.
1. Первым шагом мы настраиваем идеальный, с нашей точки зрения как игроков, баланс с K=1.
2. Потом мы запускаем АВ-тест с K=0.8 (у крипов меньше здоровья, уровни простые) и сравниваем значение с контрольной группой, где K=1.
3. Затем с K=1.2 (у крипов совсем много здоровья, уровни совсем сложные).
Получаем результаты тестов:
1. Вариант с K=1.2 (сложный) оказался хуже контрольной группы.
2. Вариант с K=0.8 (легкий) оказался лучше контрольной группы.
Ура! Мы улучшили игру!
Но мы еще и получили знание. Похоже, что мы как разработчики предпочитаем более сложный вариант баланса, чем наши игроки. Взяв эту мысль за гипотезу, мы попробуем прокачать существующую точку роста. Давайте попробуем сделать K=0.6? Сразу скажу, этот тест команда запускает с каменными лицами. С K=1 - играть было интересно. С K=0.8 игра из стратегии уже превратилась в какой-то кликер. K=0.6 - это уже вообще за гранью. Запускаем тест и получаем еще один успешный результат.
Как аналитики мы счастливы. Как разработчики мы получили баланс, который нам не нравится абсолютно. Такая вот точка роста.
Следующим нашим тестом будет K=0.4. А потом будем расставлять пэйволы!
Когда стоит выбор, в какой области игры проводить следующий АВ-тест, у нас есть 2 варианта:
1. Искать новые точки роста.
2. Прокачивать существующие.
Мы недавно запустили новую игру и первым делом начали прогонять тесты на баланс и улучшение воронки уровней. Ранее мы писали, что запускаем серию АВ-тестов и подбираем оптимальное значение HP врагов, меняя коэффициент K в формуле: HP крипа = базовое HP * K.
Сначала мы запускаем серию тестов на “поиск точек роста”, чтобы подобрать оптимальное K. Успехом мы будем считать прохождение игроком игры как можно дальше по воронке уровней: 1-ый, 2-ой, 3-ий и т.д.
В играх, которые уже существуют долго, мы так никогда не делаем. В них нас интересуют в первую очередь деньги, а не прохождение. Но т.к. у этой игры монетизация еще не настроена, мы можем позволить себе запустить несколько АВ-тестов на продвижение игроков вглубь игры.
1. Первым шагом мы настраиваем идеальный, с нашей точки зрения как игроков, баланс с K=1.
2. Потом мы запускаем АВ-тест с K=0.8 (у крипов меньше здоровья, уровни простые) и сравниваем значение с контрольной группой, где K=1.
3. Затем с K=1.2 (у крипов совсем много здоровья, уровни совсем сложные).
Получаем результаты тестов:
1. Вариант с K=1.2 (сложный) оказался хуже контрольной группы.
2. Вариант с K=0.8 (легкий) оказался лучше контрольной группы.
Ура! Мы улучшили игру!
Но мы еще и получили знание. Похоже, что мы как разработчики предпочитаем более сложный вариант баланса, чем наши игроки. Взяв эту мысль за гипотезу, мы попробуем прокачать существующую точку роста. Давайте попробуем сделать K=0.6? Сразу скажу, этот тест команда запускает с каменными лицами. С K=1 - играть было интересно. С K=0.8 игра из стратегии уже превратилась в какой-то кликер. K=0.6 - это уже вообще за гранью. Запускаем тест и получаем еще один успешный результат.
Как аналитики мы счастливы. Как разработчики мы получили баланс, который нам не нравится абсолютно. Такая вот точка роста.
Следующим нашим тестом будет K=0.4. А потом будем расставлять пэйволы!
Сигнал и шум
Не все улучшения игры видно сразу. Когда мы вносим исправления в туториал в начале игры, обычно мы сразу видим результат. Много игроков проходят начальное обучение -> много игроков остаются в игре -> много просмотров рекламы. Самое приятное, что эти изменения мы видим практически сразу же в первый день после выката изменения.
Совсем другое дело, когда мы выкатываем изменения на поздних этапах игры. Если мы внесли исправления на 100-ом уровне, на котором у нас 1% игроков, как мы поймем, что игроки оценили изменения? Даже если изменения будут значительными, их очень сложно разглядеть на 1% игроков.
Для этого мы используем фильтры. Смотрим на стат. значимость изменений не по всем игрокам, а только по тем, которые дошли до 100-го уровня. Таким образом мы устраняем шум - не рассматриваем игроков, которые не дошли до 100-го уровня.
Мы проводили такой эксперимент. В нашей tower defense игре в конце уровня выходил босс - большой сильный крип, которого сложно убить. Уровни поздние, поэтому в рамках эксперимента мы не видели ничего. Отфильтровали только тех игроков, которые реально дошли до уровня с боссом, и увидели проседание в конверсии. Похоже, что игрокам не нужны боссы. Тогда мы попробовали оставить босса как графический элемент, но сделать его таким же слабым как остальные крипы. Т.е. визуал стал интереснее, но геймплей особо не изменился. На таком изменении мы увидели стат. значимость.
Возникает вопрос: Зачем вообще вносить изменения, которые можно увидеть только под микроскопом?
Да, мы стараемся менять игру для всех. Но иногда бывает полезно нащупать стратегическое направление. Например, по незначительному изменению на 100-ом уровне мы видим, что игрокам оно интересно, а следовательно можно продолжать развивать игру в таком же направлении.
Не все улучшения игры видно сразу. Когда мы вносим исправления в туториал в начале игры, обычно мы сразу видим результат. Много игроков проходят начальное обучение -> много игроков остаются в игре -> много просмотров рекламы. Самое приятное, что эти изменения мы видим практически сразу же в первый день после выката изменения.
Совсем другое дело, когда мы выкатываем изменения на поздних этапах игры. Если мы внесли исправления на 100-ом уровне, на котором у нас 1% игроков, как мы поймем, что игроки оценили изменения? Даже если изменения будут значительными, их очень сложно разглядеть на 1% игроков.
Для этого мы используем фильтры. Смотрим на стат. значимость изменений не по всем игрокам, а только по тем, которые дошли до 100-го уровня. Таким образом мы устраняем шум - не рассматриваем игроков, которые не дошли до 100-го уровня.
Мы проводили такой эксперимент. В нашей tower defense игре в конце уровня выходил босс - большой сильный крип, которого сложно убить. Уровни поздние, поэтому в рамках эксперимента мы не видели ничего. Отфильтровали только тех игроков, которые реально дошли до уровня с боссом, и увидели проседание в конверсии. Похоже, что игрокам не нужны боссы. Тогда мы попробовали оставить босса как графический элемент, но сделать его таким же слабым как остальные крипы. Т.е. визуал стал интереснее, но геймплей особо не изменился. На таком изменении мы увидели стат. значимость.
Возникает вопрос: Зачем вообще вносить изменения, которые можно увидеть только под микроскопом?
Да, мы стараемся менять игру для всех. Но иногда бывает полезно нащупать стратегическое направление. Например, по незначительному изменению на 100-ом уровне мы видим, что игрокам оно интересно, а следовательно можно продолжать развивать игру в таком же направлении.
Как не надо считать деньги
Мы в Stereo7 делаем игры, главная задача которых - приносить нам деньги. Внедряя новые механики в игры, мы хотим больше зарабатывать. Когда мы внедряем новую фичу в игру, мы хотим знать хотя бы примерно, сколько денег она принесла. Для этого мы используем A/B-тестирование. Каждый игрок случайным образом получает либо вариант А (без фичи), либо вариант B (с фичей). Этой статьей мы перечислим неправильные способы считать деньги при A/B-тестировании. Все приемы ниже мы наблюдали либо в реальной работе, либо в обсуждениях тематических сообществ.
1. Вычисление суммарных значений
В варианте А (игра без фичи) - 1000 игроков заплатили суммарно $1000. В варианте B (игра с фичей) - 1000 игроков заплатили суммарно $10,000. Ура, новая фича принесла нам дополнительные $9000! Фиксируем улучшение в 1000% и идем отмечать в ближайший бар.
К сожалению для аналитиков и к счастью для всех остальных, есть специфика мобильных игр - игроки очень разные. Один может заплатить $1, другой - в 10 тысяч раз больше. Что будет, если мы посмотрим в сырые данные эксперимента? Может в варианте А у нас 1000 платежей в $1, а в варианте B один случайный платеж в 10000. Вариант B уже не выглядит таким классным - это просто случайность. Игрок-транжира мог и в первой группе с таким же успехом оказаться. Поход в бар отменяется.
2. Мониторинг конверсии
“Большая конверсия - хорошо. Маленькая - плохо. Надо стремиться увеличивать конверсию!”.
Красиво заявление, но к деньгам неприменимо. В супермаркете возле вашего дома конверсия 100%, т.к. каждый посетитель что-нибудь покупает. В магазине Gucci конверсия может быть пониже, но вряд-ли они завидуют супермаркету у дома у которого конверсия 100%. С точки зрения микроэкономики, у каждого товара есть оптимальная цена, при которой прибыль максимальна. Часто бывает так, что с повышением цены товара растет прибыль. Конверсия при этом падает. Падает, и фиг бы с ней! Главное, чтобы прибыль была больше.
3. Использование калькуляторов конверсий для A/B-тестов
Часто концепция выше подается под соусом “научности”. Берется знаменитый калькулятор для A/B-тестов (типа evanmiller.org), которому на вход подается: общее число пользователей для вариантов А и В и число конвертированных пользователей для вариантов А и В. И на выходе калькулятор говорит “есть” или “нет статистической значимости”. К сожалению, усложнение неправильной концепции (смотри пункт 1) не делает ее правильной, а частый совет на вопрос “Как считать?” - “Используй калькуляторы!” в этом случае неприменим.
4. Использование T-test (критерия Стьюдента)
“А мы же в институте проходили это! Все давно уже придумано до нас! Загоняем данные в статистический критерий T-test, и он сам нам скажет, есть статистическая значимость или нет”. Любой статистический критерий имеет какие-то требования. Например, для T-критерия есть такие требования:
а) Нормальность распределения
Почему-то в институте на парах тервера всем нам вдолбили мысль, что вообще любые данные нормально распределены. Эта мысль настолько укоренилась в наших головах, что некоторые “отличники” готовы выборы объявить недобросовестными, просто потому что распределение ненормальное. Пример: habr.com/ru/post/352424.
Если поразмыслить на эту тему больше 5 минут, то понятно, что график распределения платежей - это может быть просто 2 дискретные палки. По оси X цена товара $1 и $10, например. Ну т.е. никакого нормального распределения нет и критерий применять нельзя.
б) Независимость выборок
Один пользователь может заплатить несколько раз. Поэтому ваши выборки уже содержат “зависимые” данные. Это проблема легко решается, но в целом все равно надо понимать, что вы делаете.
Возникает вопрос - как правильно считать деньги? Ответа простого нет. Сложный такой: “Зависит от объема и характера ваших данных”. Мы в своей платформе abtestreal.com используем в частности бутстрэп, про который мы напишем в следующих статьях. Нам было бы очень интересно на эту тему пообщаться. Какой подход вы используете в вашей компании? Пишите в комментариях. Если тема чувствительная, давайте в личке обсудим?
Мы в Stereo7 делаем игры, главная задача которых - приносить нам деньги. Внедряя новые механики в игры, мы хотим больше зарабатывать. Когда мы внедряем новую фичу в игру, мы хотим знать хотя бы примерно, сколько денег она принесла. Для этого мы используем A/B-тестирование. Каждый игрок случайным образом получает либо вариант А (без фичи), либо вариант B (с фичей). Этой статьей мы перечислим неправильные способы считать деньги при A/B-тестировании. Все приемы ниже мы наблюдали либо в реальной работе, либо в обсуждениях тематических сообществ.
1. Вычисление суммарных значений
В варианте А (игра без фичи) - 1000 игроков заплатили суммарно $1000. В варианте B (игра с фичей) - 1000 игроков заплатили суммарно $10,000. Ура, новая фича принесла нам дополнительные $9000! Фиксируем улучшение в 1000% и идем отмечать в ближайший бар.
К сожалению для аналитиков и к счастью для всех остальных, есть специфика мобильных игр - игроки очень разные. Один может заплатить $1, другой - в 10 тысяч раз больше. Что будет, если мы посмотрим в сырые данные эксперимента? Может в варианте А у нас 1000 платежей в $1, а в варианте B один случайный платеж в 10000. Вариант B уже не выглядит таким классным - это просто случайность. Игрок-транжира мог и в первой группе с таким же успехом оказаться. Поход в бар отменяется.
2. Мониторинг конверсии
“Большая конверсия - хорошо. Маленькая - плохо. Надо стремиться увеличивать конверсию!”.
Красиво заявление, но к деньгам неприменимо. В супермаркете возле вашего дома конверсия 100%, т.к. каждый посетитель что-нибудь покупает. В магазине Gucci конверсия может быть пониже, но вряд-ли они завидуют супермаркету у дома у которого конверсия 100%. С точки зрения микроэкономики, у каждого товара есть оптимальная цена, при которой прибыль максимальна. Часто бывает так, что с повышением цены товара растет прибыль. Конверсия при этом падает. Падает, и фиг бы с ней! Главное, чтобы прибыль была больше.
3. Использование калькуляторов конверсий для A/B-тестов
Часто концепция выше подается под соусом “научности”. Берется знаменитый калькулятор для A/B-тестов (типа evanmiller.org), которому на вход подается: общее число пользователей для вариантов А и В и число конвертированных пользователей для вариантов А и В. И на выходе калькулятор говорит “есть” или “нет статистической значимости”. К сожалению, усложнение неправильной концепции (смотри пункт 1) не делает ее правильной, а частый совет на вопрос “Как считать?” - “Используй калькуляторы!” в этом случае неприменим.
4. Использование T-test (критерия Стьюдента)
“А мы же в институте проходили это! Все давно уже придумано до нас! Загоняем данные в статистический критерий T-test, и он сам нам скажет, есть статистическая значимость или нет”. Любой статистический критерий имеет какие-то требования. Например, для T-критерия есть такие требования:
а) Нормальность распределения
Почему-то в институте на парах тервера всем нам вдолбили мысль, что вообще любые данные нормально распределены. Эта мысль настолько укоренилась в наших головах, что некоторые “отличники” готовы выборы объявить недобросовестными, просто потому что распределение ненормальное. Пример: habr.com/ru/post/352424.
Если поразмыслить на эту тему больше 5 минут, то понятно, что график распределения платежей - это может быть просто 2 дискретные палки. По оси X цена товара $1 и $10, например. Ну т.е. никакого нормального распределения нет и критерий применять нельзя.
б) Независимость выборок
Один пользователь может заплатить несколько раз. Поэтому ваши выборки уже содержат “зависимые” данные. Это проблема легко решается, но в целом все равно надо понимать, что вы делаете.
Возникает вопрос - как правильно считать деньги? Ответа простого нет. Сложный такой: “Зависит от объема и характера ваших данных”. Мы в своей платформе abtestreal.com используем в частности бутстрэп, про который мы напишем в следующих статьях. Нам было бы очень интересно на эту тему пообщаться. Какой подход вы используете в вашей компании? Пишите в комментариях. Если тема чувствительная, давайте в личке обсудим?
Как обнаружить проблему
Сегодня мы столкнулись с очень неприятной ситуацией. Мы собрали результаты АБ теста, который запустили в начале недели. Тест показал проседание в рекламе. Вероятность 100%. В среднем мы потеряли примерно 20% от всех impressions (смотри скриншот).
Катастрофа. Ужас. Пожар.
Эксперимент был такой: добавить 20 новых уровней в игру. Каким образом 20 новых уровней могли так сильно сломать рекламу? Непонятно.
1. Может быть новые уровни как-то сломали более ранние уровни?
Например новый контент мог привести к крэшам из-за нехватки памяти.
Мы посмотрели на среднее количество уровней, которые проходит игрок. Оно не изменилось (изменение с вероятностью 7.4% - очень маленькая)
2. Более того. Когда мы посмотрели на воронку - ни один игрок даже не дошел до новых уровней!
На основе этих данных мы делаем вывод: проблема не связана с новыми уровнями.
Но как такое может быть если кроме новых уровней мы ничего не выкладывали?
Начали смотреть коммиты в репозитории. О оказалось что в процессе выкладки, мы случайно выпилили старый фикс бага, который относился к рекламе. Об этом никто не знал, но система все равно "не пропустила" плохой билд.
Иногда в билды проникают изменения о которых мы не знаем. Иногда такие изменения портят игру. Но если каждый билд мы прогоняем через АБ тесты, мы можем обнаружить проблему и все поправить.
Сегодня мы столкнулись с очень неприятной ситуацией. Мы собрали результаты АБ теста, который запустили в начале недели. Тест показал проседание в рекламе. Вероятность 100%. В среднем мы потеряли примерно 20% от всех impressions (смотри скриншот).
Катастрофа. Ужас. Пожар.
Эксперимент был такой: добавить 20 новых уровней в игру. Каким образом 20 новых уровней могли так сильно сломать рекламу? Непонятно.
1. Может быть новые уровни как-то сломали более ранние уровни?
Например новый контент мог привести к крэшам из-за нехватки памяти.
Мы посмотрели на среднее количество уровней, которые проходит игрок. Оно не изменилось (изменение с вероятностью 7.4% - очень маленькая)
2. Более того. Когда мы посмотрели на воронку - ни один игрок даже не дошел до новых уровней!
На основе этих данных мы делаем вывод: проблема не связана с новыми уровнями.
Но как такое может быть если кроме новых уровней мы ничего не выкладывали?
Начали смотреть коммиты в репозитории. О оказалось что в процессе выкладки, мы случайно выпилили старый фикс бага, который относился к рекламе. Об этом никто не знал, но система все равно "не пропустила" плохой билд.
Иногда в билды проникают изменения о которых мы не знаем. Иногда такие изменения портят игру. Но если каждый билд мы прогоняем через АБ тесты, мы можем обнаружить проблему и все поправить.
В своей книге Trustworthy Online Controlled Experiments знаменитый гуру А/Б тестирования из Microsoft Рон Кохави пишет:
До эксперимента сложно оценить ценность идеи
TRUE
Когда мы поняли это, мы решили, что главное - это прогонять много экспериментов, стараясь не тратить много времени на разработку.
Маленькие изменения могут иметь большой эффект
TRUE
Самые успешные наши эксперименты:
перенос показа рекламы с первой минуты игры на третью (к слову сказать, дальнейший перенос ничего не дал).
1 час разработки
добавление анимации “переливчатой кнопки” в местах, где нужен call to action
1 час разработки
В нашем случае опыт можно обобщить как: “ТОЛЬКО маленькие изменения имеют эффект”. Наши игроки равнодушно относятся к любым изменениям в метаигре. Их волнует только core gameplay. Почти все наши успешные эксперименты сейчас - это устранение препятствий на пути к core gameplay.
Эксперименты с большим эффектом редки
TRUE
На одну игру мы запускаем примерно 2 эксперимента в неделю. За год мы насчитали 6-7 успешных экспериментов. К слову, сильного проседания тоже сложно достичь. Как правило результат: “без изменений”.
Критерий оценки эксперимента должен быть известен до эксперимента
TRUE TRUE TRUE
Наш критерий всегда один и тот же - это средний заработок на игрока. В своей работе над продуктом мы не используем никаких других платформ и совершенно не интересуемся такими метриками как 1-day retention, average session length или ARPPU.
До эксперимента сложно оценить ценность идеи
TRUE
Когда мы поняли это, мы решили, что главное - это прогонять много экспериментов, стараясь не тратить много времени на разработку.
Маленькие изменения могут иметь большой эффект
TRUE
Самые успешные наши эксперименты:
перенос показа рекламы с первой минуты игры на третью (к слову сказать, дальнейший перенос ничего не дал).
1 час разработки
добавление анимации “переливчатой кнопки” в местах, где нужен call to action
1 час разработки
В нашем случае опыт можно обобщить как: “ТОЛЬКО маленькие изменения имеют эффект”. Наши игроки равнодушно относятся к любым изменениям в метаигре. Их волнует только core gameplay. Почти все наши успешные эксперименты сейчас - это устранение препятствий на пути к core gameplay.
Эксперименты с большим эффектом редки
TRUE
На одну игру мы запускаем примерно 2 эксперимента в неделю. За год мы насчитали 6-7 успешных экспериментов. К слову, сильного проседания тоже сложно достичь. Как правило результат: “без изменений”.
Критерий оценки эксперимента должен быть известен до эксперимента
TRUE TRUE TRUE
Наш критерий всегда один и тот же - это средний заработок на игрока. В своей работе над продуктом мы не используем никаких других платформ и совершенно не интересуемся такими метриками как 1-day retention, average session length или ARPPU.
Всё для A/B-тестов в одном решении
С гордостью представляем нашу новую систему для конфигурирования А/В-тестов, сплитования пользователей и сбора данных через API.
Теперь наша платформа - это полное решение для проведения А/B-тестов. Никаких дополнительных SDK и сервисов, всё в одном месте. Вставить API в приложение теперь сможет даже джуниор разработчик, за 4 часа справится точно.
Платформа: Заведение нового эксперимента
Просто дайте эксперименту имя и заведите параметры, которые вы хотите передать мобильной игре. Например, в нашем эксперименте мы сейчас показываем Starter Pack с ресурсами после первого уровня. Параметр StarterPack = yes.
Ваша игра: Запрос параметров
Игра запрашивает параметры по URL. Просто вызываете наш метод:
https://tool.abtestreal.com/token/GetParameters?uid=52354
Наша платформа сама определит, какие параметры A/B-эксперимента отдать. Вам останется только обработать его в коде. Например:
if(StarterPack == ’yes’)
{
DisplayStarterPack();
}
else
{
HideStarterPack();
}
Всё, ребята, больше не осталось причин не работать с нами!
Пишите - все покажем, подключим, настроим, запустим!
С гордостью представляем нашу новую систему для конфигурирования А/В-тестов, сплитования пользователей и сбора данных через API.
Теперь наша платформа - это полное решение для проведения А/B-тестов. Никаких дополнительных SDK и сервисов, всё в одном месте. Вставить API в приложение теперь сможет даже джуниор разработчик, за 4 часа справится точно.
Платформа: Заведение нового эксперимента
Просто дайте эксперименту имя и заведите параметры, которые вы хотите передать мобильной игре. Например, в нашем эксперименте мы сейчас показываем Starter Pack с ресурсами после первого уровня. Параметр StarterPack = yes.
Ваша игра: Запрос параметров
Игра запрашивает параметры по URL. Просто вызываете наш метод:
https://tool.abtestreal.com/token/GetParameters?uid=52354
Наша платформа сама определит, какие параметры A/B-эксперимента отдать. Вам останется только обработать его в коде. Например:
if(StarterPack == ’yes’)
{
DisplayStarterPack();
}
else
{
HideStarterPack();
}
Всё, ребята, больше не осталось причин не работать с нами!
Пишите - все покажем, подключим, настроим, запустим!
Закон Тваймена
Сегодня новый эксперимент выдал 3 успеха. Мы получили статистически значимое улучшение по всем ключевым метрикам.
Игроки стали дольше играть в игру, игроки стали больше покупать и больше смотреть рекламу.
Самое время вспомнить про Закон Тваймена из книжки Trustworthy Online Controlled Experiments:
"Любые цифры которые выглядят интересно или сильно отличаются от предыдущих - обычно ошибочны"
Применительно к АБ тестам распространенные ошибки это
Неверная интерпретация
1. Недостаточная мощность.
Малые эффекты сложно увидеть на маленьких объемах.
2. Неверная интерпретация p-value
p-value = 30% это не то же самое что "гипотеза верна с вероятностью 30%"
3. Выборка нужных p-values
Мы недавно писали большой пост на эту тему. Если грубо: если последовательно запускать очень много тестов, то что нибудь да найдется или как говорил мой препод по военной кафедре "Раз в год и ружье стреляет" (оффтопик: это была самая умная мысль за все время обучения)
4. Тестирование нескольких гипотез
Очень похоже на предыдущую, только гипотезы запускаются одновременно а не последовательно.
5. Связанные элементы выборок
Когда например вы звоните кому-то в скайп - вы влияете и на принимающую сторону. Как правило в АБ тестах вам хочется работать с независимыми выборками.
6. Технические проблемы
Сюда относится например знаменитая проблема "мерцания" в web - когда вы меняете контент через JavaScript - у вас элементы страницы "скачут" по странице тем самым влияя на результат
7. Эффект новизны
Мой любимый эффект. Если вы только что внедрили новую фичу, то игроки будут воспринимать ее не так как если бы "она была всегда". У нас, кстати, в играх есть фича "искусственного апдейта". Игроку кажется что мы обновили игру и поменяли UI. Игрок реагирует позитивно. Хотя UI меняется просто после 5го уровня. Мы много раз замеряли эффект от такого контринтуитивного введения - эффект каждый раз подтверждается.
Ну и возвращаясь к нашему эксперименту. Оказалось что с новыми апдейтом, мы полностью выпилили отправку данных в нашу платформу - отсюда такие клевые результаты.
Мы быстро спустились с небес на землю. Хвала Тваймену!
Сегодня новый эксперимент выдал 3 успеха. Мы получили статистически значимое улучшение по всем ключевым метрикам.
Игроки стали дольше играть в игру, игроки стали больше покупать и больше смотреть рекламу.
Самое время вспомнить про Закон Тваймена из книжки Trustworthy Online Controlled Experiments:
"Любые цифры которые выглядят интересно или сильно отличаются от предыдущих - обычно ошибочны"
Применительно к АБ тестам распространенные ошибки это
Неверная интерпретация
1. Недостаточная мощность.
Малые эффекты сложно увидеть на маленьких объемах.
2. Неверная интерпретация p-value
p-value = 30% это не то же самое что "гипотеза верна с вероятностью 30%"
3. Выборка нужных p-values
Мы недавно писали большой пост на эту тему. Если грубо: если последовательно запускать очень много тестов, то что нибудь да найдется или как говорил мой препод по военной кафедре "Раз в год и ружье стреляет" (оффтопик: это была самая умная мысль за все время обучения)
4. Тестирование нескольких гипотез
Очень похоже на предыдущую, только гипотезы запускаются одновременно а не последовательно.
5. Связанные элементы выборок
Когда например вы звоните кому-то в скайп - вы влияете и на принимающую сторону. Как правило в АБ тестах вам хочется работать с независимыми выборками.
6. Технические проблемы
Сюда относится например знаменитая проблема "мерцания" в web - когда вы меняете контент через JavaScript - у вас элементы страницы "скачут" по странице тем самым влияя на результат
7. Эффект новизны
Мой любимый эффект. Если вы только что внедрили новую фичу, то игроки будут воспринимать ее не так как если бы "она была всегда". У нас, кстати, в играх есть фича "искусственного апдейта". Игроку кажется что мы обновили игру и поменяли UI. Игрок реагирует позитивно. Хотя UI меняется просто после 5го уровня. Мы много раз замеряли эффект от такого контринтуитивного введения - эффект каждый раз подтверждается.
Ну и возвращаясь к нашему эксперименту. Оказалось что с новыми апдейтом, мы полностью выпилили отправку данных в нашу платформу - отсюда такие клевые результаты.
Мы быстро спустились с небес на землю. Хвала Тваймену!
У нас небольшая годовщина. Прошел год с момента как мы полностью перешли на нашу платформу для АБ-тестирования. Поначалу было очень волнительно смотреть только на результаты экспериментов и совсем не обращать внимание на метрики типа длины сессии и ретеншена.
Мы совершенно не были уверены что продержимся долго. Казалось, что обязательно произойдет что-то и мы вернемся в Амплитуду или Firebase, чтобы разобраться “по-нормальному”. Но оказалось все совсем не так срашно.
Вот результаты по top-3 странам. LTV/User
1. US: $0.74 (+32.14%)
2. UK: $0.53 (+39.47%)
3. DE: $0.27 (-38.64%)
1. За год мы подняли в Штатах LTV на игрока на 32%. Т. к. большая часть трафика у нас из Штатов, +32% - это основной результат.
2. Я сознательно включил в отчет Германию, чтобы показать, что мы не улучшаем игру для всех стран. Где-то LTV проседает, но мы с этим ничего не делаем так как нацеливаемся на 1st tier в целом.
Мысль вслух. Было бы круто, конечно, тюнить для каждой страны в отдельности. Технически понятно как это можно сделать. Непонятно что делать с объемом трафика. Нам не хватит объемов, чтобы сделать статистические выводы по отдельным странам.
3. В среднем в месяц получается 2.5%. Учитывая что мы запускаем новый эксперимент примерно раз в неделю, выходит примерно полпроцента на каждый эксперимент.
Радует что на анализ данных мы не потратили ни одной минуты. Мы просто выкатывали все что нам говорила платформа.
Похоже что до LTV $1 за игрока нам еще примерно 2 года.
Цель ясна. Работаем дальше!
Мы совершенно не были уверены что продержимся долго. Казалось, что обязательно произойдет что-то и мы вернемся в Амплитуду или Firebase, чтобы разобраться “по-нормальному”. Но оказалось все совсем не так срашно.
Вот результаты по top-3 странам. LTV/User
1. US: $0.74 (+32.14%)
2. UK: $0.53 (+39.47%)
3. DE: $0.27 (-38.64%)
1. За год мы подняли в Штатах LTV на игрока на 32%. Т. к. большая часть трафика у нас из Штатов, +32% - это основной результат.
2. Я сознательно включил в отчет Германию, чтобы показать, что мы не улучшаем игру для всех стран. Где-то LTV проседает, но мы с этим ничего не делаем так как нацеливаемся на 1st tier в целом.
Мысль вслух. Было бы круто, конечно, тюнить для каждой страны в отдельности. Технически понятно как это можно сделать. Непонятно что делать с объемом трафика. Нам не хватит объемов, чтобы сделать статистические выводы по отдельным странам.
3. В среднем в месяц получается 2.5%. Учитывая что мы запускаем новый эксперимент примерно раз в неделю, выходит примерно полпроцента на каждый эксперимент.
Радует что на анализ данных мы не потратили ни одной минуты. Мы просто выкатывали все что нам говорила платформа.
Похоже что до LTV $1 за игрока нам еще примерно 2 года.
Цель ясна. Работаем дальше!
Расскажу про эксперимент из серии: “Не повторяйте дома”.
Эксперимент года.
П№%ц как страшно.
Короче, мы долго подбирались к этому эксперименту и вот 2 недели назад наконец решились. Мы откатили нашу основную игру Steampunk Defense на год назад(!) и запустили АБ эксперимент через нашу платформу на 50% аудитории. Очень страшно было запускать такой эксперимент по нескольким соображениям:
1. Откат игры - это негативный опыт для многих игроков
Не буду даже приводить эти страшные примеры. Скажу только что тут мы подготовились и на любой запрос игроков без вопросов давали доступ к читам типа “нарисуйте себе что хотите, ребята”.
2. Это потерянное бабло
Без комментариев.
3. Технически непонятная задача
Несмотря на то что игра у нас single player, она взаимодействует много с какими внешними сервисами. Ну как-то причесали старый билд.
4. Ну и самое главное
А что будет если результаты покажут что игра просела? Для нас это будет означать что обновлять игру мы вообще не умеем и надо сосредоточиться на чем-то другом (маркетинге или выпуске новых игр).
В прошлом посте я писал о результатах за год - это примерно +32% к LTV. Этот факт никуда не делся. Они корректно посчитаны, но возникает вопрос “а какая часть из этих 30% получилась благодаря платформе?”. Мы достаточно активно экспериментировали с рекламными сетками и медиацией, поэтому совершенно точно большАя часть заслуги из этих 32% - это медиация. Ну а вдруг в остальном мы вообще вредили игре.
Ладно, не буду мучать вас больше. Вот результаты:
Всего игроков в эксперименте: 20 тысяч.
Среднее LTV изменение: $0,02
In-apps 90% дов. интервал: -$0.01-$0.05
P-Value: 86.6%
Среднее Impressions изменение: -1.63
Impressions 90% дов. интервал: -2.80 - -0.89
P-Value: 100%
Если переводить на русский язык - “пока непонятно, но мы скорее не сломали ничего чем что-то сломали”
Подробные комментарии:
1. Показы просели стопроц.
Это ожидаемо. Мы осознано уменьшили кол-во рекламы в игре.
С начала года мы наращивали показы и нарастили до того что рейтинг игры стал 3.9. Для нас это вообще не проблема, но как только рейтинг просел до 3.9 - стало сложно закупать трафик.
Поэтому мы запускали серию экспериментов - искали оптимальную конфигурацию при которой и impressions не сильно просядет, и рейтинг увеличится. Там в итоге отдельная большая история вышла. Кому-то мы показываем рекламу, кому-то мы показываем диалог “поставь рейтинг”. Тема отдельного поста короче...
Короче мы потеряли 1,5 impression’а и это сделано осознано. Без тестов потеряли бы больше.
2. Кажется что in-app’ы увеличились примерно на 50%
Да, мы в принципе видим увеличение среднего по инаппам сравнивая показатели по органике в июне, но к сожалению, мы не можем дождаться завершения эксперимента и сказать математически строго, т. к. этот эксперимент сильно болезненный опыт для игрок. Рейтинг падает, игроки пишут злобные комменты. Короче, останавливаем эксперимент.
Вообщем все ОК, работаем дальше.
PS Вряд-ли бы я поделился результатами если бы они сильно просели. Хорошо что такого не произошло :)
Эксперимент года.
П№%ц как страшно.
Короче, мы долго подбирались к этому эксперименту и вот 2 недели назад наконец решились. Мы откатили нашу основную игру Steampunk Defense на год назад(!) и запустили АБ эксперимент через нашу платформу на 50% аудитории. Очень страшно было запускать такой эксперимент по нескольким соображениям:
1. Откат игры - это негативный опыт для многих игроков
Не буду даже приводить эти страшные примеры. Скажу только что тут мы подготовились и на любой запрос игроков без вопросов давали доступ к читам типа “нарисуйте себе что хотите, ребята”.
2. Это потерянное бабло
Без комментариев.
3. Технически непонятная задача
Несмотря на то что игра у нас single player, она взаимодействует много с какими внешними сервисами. Ну как-то причесали старый билд.
4. Ну и самое главное
А что будет если результаты покажут что игра просела? Для нас это будет означать что обновлять игру мы вообще не умеем и надо сосредоточиться на чем-то другом (маркетинге или выпуске новых игр).
В прошлом посте я писал о результатах за год - это примерно +32% к LTV. Этот факт никуда не делся. Они корректно посчитаны, но возникает вопрос “а какая часть из этих 30% получилась благодаря платформе?”. Мы достаточно активно экспериментировали с рекламными сетками и медиацией, поэтому совершенно точно большАя часть заслуги из этих 32% - это медиация. Ну а вдруг в остальном мы вообще вредили игре.
Ладно, не буду мучать вас больше. Вот результаты:
Всего игроков в эксперименте: 20 тысяч.
Среднее LTV изменение: $0,02
In-apps 90% дов. интервал: -$0.01-$0.05
P-Value: 86.6%
Среднее Impressions изменение: -1.63
Impressions 90% дов. интервал: -2.80 - -0.89
P-Value: 100%
Если переводить на русский язык - “пока непонятно, но мы скорее не сломали ничего чем что-то сломали”
Подробные комментарии:
1. Показы просели стопроц.
Это ожидаемо. Мы осознано уменьшили кол-во рекламы в игре.
С начала года мы наращивали показы и нарастили до того что рейтинг игры стал 3.9. Для нас это вообще не проблема, но как только рейтинг просел до 3.9 - стало сложно закупать трафик.
Поэтому мы запускали серию экспериментов - искали оптимальную конфигурацию при которой и impressions не сильно просядет, и рейтинг увеличится. Там в итоге отдельная большая история вышла. Кому-то мы показываем рекламу, кому-то мы показываем диалог “поставь рейтинг”. Тема отдельного поста короче...
Короче мы потеряли 1,5 impression’а и это сделано осознано. Без тестов потеряли бы больше.
2. Кажется что in-app’ы увеличились примерно на 50%
Да, мы в принципе видим увеличение среднего по инаппам сравнивая показатели по органике в июне, но к сожалению, мы не можем дождаться завершения эксперимента и сказать математически строго, т. к. этот эксперимент сильно болезненный опыт для игрок. Рейтинг падает, игроки пишут злобные комменты. Короче, останавливаем эксперимент.
Вообщем все ОК, работаем дальше.
PS Вряд-ли бы я поделился результатами если бы они сильно просели. Хорошо что такого не произошло :)
Считать деньги больно. Избавиться от этой боли невозможно.
Мы уменьшим боль нашими новыми фичами:
1. Антифрод для Google Play
Аккуратно собранные данные - это must для любого эксперимента. Всегда хочется видеть настоящих плательщиков, а не жуликов, которые обманом получили монетки. Теперь наша платформа умеет сама обращаться к google play с запросом “а правда ли этот игрок заплатил?”. Деньги в эксперименте считаются только в том случае если Google Play отвечает утвердительно на этот вопрос.
Просто дайте нашей платформе доступ до Google Play API вашего аккаунта, и она сама все перепроверит.
2. Конвертор валюты
Вторая проблема - это местные валюты. Один игрок потратил 1000 рублей, другой - 10 долларов. Задача сложить доллары с рублями ложится на хрупкие плечи аналитика (уже 2 месяца не держащего гантели в фитнес-зале). Наша платформа приводит все валюты к долларам. Для этого она сверяется с актуальным курсом доллара онлайн и конвертит местную валюту (рубли например).
Подключайтесь к нам и считайте деньги правильно.
А мы возвращаемся на кухню где приготовим вам что-то еще более вкусненькое!
Мы уменьшим боль нашими новыми фичами:
1. Антифрод для Google Play
Аккуратно собранные данные - это must для любого эксперимента. Всегда хочется видеть настоящих плательщиков, а не жуликов, которые обманом получили монетки. Теперь наша платформа умеет сама обращаться к google play с запросом “а правда ли этот игрок заплатил?”. Деньги в эксперименте считаются только в том случае если Google Play отвечает утвердительно на этот вопрос.
Просто дайте нашей платформе доступ до Google Play API вашего аккаунта, и она сама все перепроверит.
2. Конвертор валюты
Вторая проблема - это местные валюты. Один игрок потратил 1000 рублей, другой - 10 долларов. Задача сложить доллары с рублями ложится на хрупкие плечи аналитика (уже 2 месяца не держащего гантели в фитнес-зале). Наша платформа приводит все валюты к долларам. Для этого она сверяется с актуальным курсом доллара онлайн и конвертит местную валюту (рубли например).
Подключайтесь к нам и считайте деньги правильно.
А мы возвращаемся на кухню где приготовим вам что-то еще более вкусненькое!