​​Как не надо считать деньги

Мы в 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 используем в частности бутстрэп, про который мы напишем в следующих статьях. Нам было бы очень интересно на эту тему пообщаться. Какой подход вы используете в вашей компании? Пишите в комментариях. Если тема чувствительная, давайте в личке обсудим?