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 месяца не держащего гантели в фитнес-зале). Наша платформа приводит все валюты к долларам. Для этого она сверяется с актуальным курсом доллара онлайн и конвертит местную валюту (рубли например).
Подключайтесь к нам и считайте деньги правильно.
А мы возвращаемся на кухню где приготовим вам что-то еще более вкусненькое!
Написали статью про то как определить нужное число пользователей для эксперимента
https://gushchin-dmitry.medium.com/%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE-%D0%BD%D0%B0%D0%BC-%D0%BD%D0%B0%D0%B4%D0%BE-%D0%B8%D0%B3%D1%80%D0%BE%D0%BA%D0%BE%D0%B2-d569eb2582cc
https://gushchin-dmitry.medium.com/%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE-%D0%BD%D0%B0%D0%BC-%D0%BD%D0%B0%D0%B4%D0%BE-%D0%B8%D0%B3%D1%80%D0%BE%D0%BA%D0%BE%D0%B2-d569eb2582cc
Когда мы проводим эксперименты, мы хотим знать больше о наших игроках. И хотя нашей целью всегда была максимизация дохода LTV, мы хотим лучше понимать как изменения в игре отражаются на игроках и как меняется их поведение.
Новые данные помогут нам формулировать более качественные гипотезы в будущем.
Теперь наша платформа умеет отслеживать такие параметры в А/Б экспериментах:
ARPPU
Средний чек платящего игрока
Lifetime
Общее время в игре
Paying conversion
Конверсию в платящего игрока
Новые данные помогут нам формулировать более качественные гипотезы в будущем.
Теперь наша платформа умеет отслеживать такие параметры в А/Б экспериментах:
ARPPU
Средний чек платящего игрока
Lifetime
Общее время в игре
Paying conversion
Конверсию в платящего игрока
Решил написать обзор книжек по А/Б тестированию.
Я по профессии программист, а не математик, поэтому мои оценки полезности могут быть интересны разработчикам, а не математикам.
Я предпочитаю честность политкорректности, поэтому если знания из книжки невозможно применить на практике (реализовать новую фичу) - я ставлю полезность 0.
Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Kohavi, Ron
Оценка: 4/5
Кохави - самый известный автор работ по АБ тестированию. Основное место работы - оптимизация Bing в Microsoft.
+ доступный язык (если вы читаете по английски)
+ реальные (а не надуманные) проблемы и задачи.
- нет ничего такого до чего невозможно догадаться самому
Наглядная математическая статистика. Лагутин Михаил
Оценка: 0/5
+ Русский язык
- Нужен сильный математический бэкграунд. Я разбирал примеры с мехматовцами. Сходу даже им непонятно о чем она.
- Примеры не из жизни. В работе применить точно не получится.
Практическая статистика для специалистов Data Science. Брюс Эндрю, Брюс Питер
Оценка: 5/5
Смелый автор. Хорошо понимает как работает bootstrap, хорошо объясняет и не стесняется творчески применять его.
+ Русский язык
+ Написана для инженеров. После книжки сразу можно писать код.
- Мало. Статистике в книжке посвящено около 5 страниц.
Doing Bayesian Data Analysis: A Tutorial with R, JAGS, and Stan Hardcover, John Kruschke
Оценка: 4/5
Книжка по Байесовскому анализу. Крутой филосовский трактат по разным аспектам статистики. Это почему-то общее качество для всех Байесовцов. В них всегда половина книжка - это текст без формул.
+ Очень подробно и понятно
+ Широкий список тем
- Длинная очень. Если не пролистывая читать - пару месяцев можно выделить.
Голая статистика, Чарльз Уилан
Оценка: 2/5
Хорошая книжка как введение, чтобы в общем о терминах иметь представление.
+ Русский язык
+ Все понятно
- Нет практической ценности
Статистика. Базовый курс в комиксах, Грейди Клейн
Оценка: 3/5
Хорошая книжка как введение, чтобы в общем о терминах иметь представление. Написано в точности все то же самое что и в предыдущей, но прочитать можно быстрее гораздо.
+ Русский язык
+ Все понятно
+ Очень быстро читается
- Нет практической ценности
Я по профессии программист, а не математик, поэтому мои оценки полезности могут быть интересны разработчикам, а не математикам.
Я предпочитаю честность политкорректности, поэтому если знания из книжки невозможно применить на практике (реализовать новую фичу) - я ставлю полезность 0.
Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Kohavi, Ron
Оценка: 4/5
Кохави - самый известный автор работ по АБ тестированию. Основное место работы - оптимизация Bing в Microsoft.
+ доступный язык (если вы читаете по английски)
+ реальные (а не надуманные) проблемы и задачи.
- нет ничего такого до чего невозможно догадаться самому
Наглядная математическая статистика. Лагутин Михаил
Оценка: 0/5
+ Русский язык
- Нужен сильный математический бэкграунд. Я разбирал примеры с мехматовцами. Сходу даже им непонятно о чем она.
- Примеры не из жизни. В работе применить точно не получится.
Практическая статистика для специалистов Data Science. Брюс Эндрю, Брюс Питер
Оценка: 5/5
Смелый автор. Хорошо понимает как работает bootstrap, хорошо объясняет и не стесняется творчески применять его.
+ Русский язык
+ Написана для инженеров. После книжки сразу можно писать код.
- Мало. Статистике в книжке посвящено около 5 страниц.
Doing Bayesian Data Analysis: A Tutorial with R, JAGS, and Stan Hardcover, John Kruschke
Оценка: 4/5
Книжка по Байесовскому анализу. Крутой филосовский трактат по разным аспектам статистики. Это почему-то общее качество для всех Байесовцов. В них всегда половина книжка - это текст без формул.
+ Очень подробно и понятно
+ Широкий список тем
- Длинная очень. Если не пролистывая читать - пару месяцев можно выделить.
Голая статистика, Чарльз Уилан
Оценка: 2/5
Хорошая книжка как введение, чтобы в общем о терминах иметь представление.
+ Русский язык
+ Все понятно
- Нет практической ценности
Статистика. Базовый курс в комиксах, Грейди Клейн
Оценка: 3/5
Хорошая книжка как введение, чтобы в общем о терминах иметь представление. Написано в точности все то же самое что и в предыдущей, но прочитать можно быстрее гораздо.
+ Русский язык
+ Все понятно
+ Очень быстро читается
- Нет практической ценности
Нас часто спрашивают:
Как провести А/Б эксперимент с наименьшим ущербом для бизнеса?
Кратко: никак.
Теперь чуть подробнее:
Рассмотрим проблему чуть подробнее. У нас есть какая-то рискованная гипотеза. Мы боимся что потеряем существенную часть дохода работающего продукта пока будем ее проверять. Какие у нас есть варианты?
1. Запустить эксперимент на 5% аудитории
При классической схеме мы запускаем эксперимент на 50%. Интуитивно кажется что запуская эксперимент на 5% результаты эксперимента мы будем получать примерно в 10 раз медленнее (на самом деле будет еще медленнее - мощность падает нелинейно).
Наша глобальная цель как бизнеса - откручивать много экспериментов и делать это быстро. Пока мы "возимся" с экспериментом который, как нам кажется, принесет убытки, мы теряем возможность запустить другие эксперименты, которые стоят в очереди и лишают нас возможности зарабатывать больше.
2. Запустить эксперимент на какое-то подмножество пользователей
Ну например: "У нас есть пользователи из 150 стран. Давайте запустим для начала на Бразилию? Там доход не большой. Соответственно потери незначительные. Если покажет себя хорошо - выкатим на 100%".
С уверенностью можно сказать что пользователи Бразилии отличаются от пользователей в Штатах, поэтому предложение выше преобразовывается в "Давайте если в Бразилии прокатит, выкатим на 100% в Штаты не проверяя!". Это странно - я бы предпочел запустить на Штатах тоже на 50% сначала.
3. Не запускать АБ тест
Без комментариев.
Итого:
По умолчанию эксперименты запускаются на 50% вашей аудитории. Исключение - случаи когда вы понимаете что делаете и что выигрываете/теряете.
Хорошие новости: достаточно сложно даже придумать эксперимент который обрушит вам выручку, скажем на 25%. Это очень постараться надо.
Падение в 25% на 50% аудитории конвертируются в падение 12.5% от общей выручки. Помните что вы на половину пользователей запускаете? Фактически это и есть верхняя граница оценки риска.
Удачного тестирования!
Как провести А/Б эксперимент с наименьшим ущербом для бизнеса?
Кратко: никак.
Теперь чуть подробнее:
Рассмотрим проблему чуть подробнее. У нас есть какая-то рискованная гипотеза. Мы боимся что потеряем существенную часть дохода работающего продукта пока будем ее проверять. Какие у нас есть варианты?
1. Запустить эксперимент на 5% аудитории
При классической схеме мы запускаем эксперимент на 50%. Интуитивно кажется что запуская эксперимент на 5% результаты эксперимента мы будем получать примерно в 10 раз медленнее (на самом деле будет еще медленнее - мощность падает нелинейно).
Наша глобальная цель как бизнеса - откручивать много экспериментов и делать это быстро. Пока мы "возимся" с экспериментом который, как нам кажется, принесет убытки, мы теряем возможность запустить другие эксперименты, которые стоят в очереди и лишают нас возможности зарабатывать больше.
2. Запустить эксперимент на какое-то подмножество пользователей
Ну например: "У нас есть пользователи из 150 стран. Давайте запустим для начала на Бразилию? Там доход не большой. Соответственно потери незначительные. Если покажет себя хорошо - выкатим на 100%".
С уверенностью можно сказать что пользователи Бразилии отличаются от пользователей в Штатах, поэтому предложение выше преобразовывается в "Давайте если в Бразилии прокатит, выкатим на 100% в Штаты не проверяя!". Это странно - я бы предпочел запустить на Штатах тоже на 50% сначала.
3. Не запускать АБ тест
Без комментариев.
Итого:
По умолчанию эксперименты запускаются на 50% вашей аудитории. Исключение - случаи когда вы понимаете что делаете и что выигрываете/теряете.
Хорошие новости: достаточно сложно даже придумать эксперимент который обрушит вам выручку, скажем на 25%. Это очень постараться надо.
Падение в 25% на 50% аудитории конвертируются в падение 12.5% от общей выручки. Помните что вы на половину пользователей запускаете? Фактически это и есть верхняя граница оценки риска.
Удачного тестирования!
Эксперимент UI в мобильной игре
Нам бывает сложно предсказать результаты экспериментов. Мы планируем улучшить рекламную монетизацию, а по факту увеличиваем доход с инапов.
На прошлой неделе мы завершили такой эксперимент.
Описание:
У нас есть tower defense игра про вторую мировую войну с уровнями. Когда игрок проходит уровень, он получает награду. У игрока есть возможность удвоить эту награду если он посмотрит рекламу.
Гипотеза:
Сейчас соотношение “награды до просмотра рекламы” к “награде после просмотра рекламы” - 50/50. Возможно изменение этого соотношения на 80/20 мотивирует игроков смотреть больше рекламу.
Меняем UI как на скриншоте.
Результат:
Inapp’ы выросли примерно в полтора раза.
Вывод:
Да, мы плохие предсказатели.
Значит будем запускать еще больше экспериментов.
Нам бывает сложно предсказать результаты экспериментов. Мы планируем улучшить рекламную монетизацию, а по факту увеличиваем доход с инапов.
На прошлой неделе мы завершили такой эксперимент.
Описание:
У нас есть tower defense игра про вторую мировую войну с уровнями. Когда игрок проходит уровень, он получает награду. У игрока есть возможность удвоить эту награду если он посмотрит рекламу.
Гипотеза:
Сейчас соотношение “награды до просмотра рекламы” к “награде после просмотра рекламы” - 50/50. Возможно изменение этого соотношения на 80/20 мотивирует игроков смотреть больше рекламу.
Меняем UI как на скриншоте.
Результат:
Inapp’ы выросли примерно в полтора раза.
Вывод:
Да, мы плохие предсказатели.
Значит будем запускать еще больше экспериментов.
