Мы делаем мобильные игры, главная задача которых - приносить нам деньги. Внедряя новые механики в игры, мы хотим больше зарабатывать. Когда мы внедряем новую фичу в игру, мы хотим знать хотя бы примерно, сколько денег она принесла. Для этого мы используем 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-критерия есть такие требования:
1. Нормальность распределения
Почему-то в институте на парах тервера всем нам вдолбили мысль, что вообще любые данные нормально распределены. Эта мысль настолько укоренилась в наших головах, что некоторые “отличники” готовы выборы объявить недобросовестными, просто потому что распределение ненормальное. Пример: habr.com/ru/post/352424. Если поразмыслить на эту тему больше 5 минут, то понятно, что график распределения платежей - это может быть просто 2 дискретные палки. По оси X цена товара $1 и $10, например. Ну т.е. никакого нормального распределения нет и критерий применять нельзя.
2. Независимость выборок
Один пользователь может заплатить несколько раз. Поэтому ваши выборки уже содержат “зависимые” данные. Это проблема легко решается, но в целом все равно надо понимать, что вы делаете.
Возникает вопрос - как правильно считать деньги? Ответа простого нет. Сложный такой: “Зависит от объема и характера ваших данных”. Мы используем бутстрэп, про который напишем в следующих статьях.
Больше информации в нашем telegram канале https://t.me/abtestingmobilegames