1. Введение 3
1.1. Мотивация 3
1.2. Задача 3
2. Основные результаты 5
2.1. Проверка применимости статистических тестов 5
2.2. А/B тест без непосредственного проведения А/B теста 12
2.3. Влияние распределение улучшения от фичи на A/B тесты 14
3. Заключение 19
Список литературы 20
1.1. Мотивация.
Для начала определим, что такое А/B тестирование и как его проводить.
Определение 1. A/B тестирование - это методология исследования пользовательского поведения, состоящая из рандомизированного эксперимента с двумя вариантами, А и В, одной и той же сущности. Задача - сравнить, какой из вариантов лучше (понятие «лучше» определяется аналитиками заранее с учетом специфики поставленной задачи). [1]
Формально процесс А/B тестирования выглядит следующим образом:
• Определяем изменение в нашем продукте(в нашем случае - в игре) и метрику, которую будем сравнивать в конце.
• Формулируем нулевую гипотезу: чаще всего, это гипотеза о том, что изменения не повлияют на метрику.
• Делим пользователей на две независимые группы с одинаковыми важными для нас показателями, одной из групп показываем вариант А нашего продукта, другой - вариант В.
• Сравниваем выбранную нами метрику на этих двух группах с помощью статистического теста (в зависимости от метрики - свой тест)
• Делаем вывод - какой вариант продукта лучше для нас.
Процесс A/B тестирования широко применяем в IT-сфере и дает достаточно достоверные результаты, но есть важные нюансы. Во-первых, проводить A/B тесты - долго и дорого, требуется много ресурсов. Во-вторых, нередко значимая разница между вариантах отсутствует, поэтому необходим большой объем выборки, а данные должны быть качественнее, чего мы не всегда можем добиться.
1.2. Задача.
Тема моей работы - "Исследование А/B тесты в разработке мобильных игр”. Основной задачей является улучшение текущей системы работы с A/B тестами в команде и изучение различных методологий А/B тестирования.
Рассмотрим некоторую игру N, в которой есть несколько уровней сложности и различные активности на этих уровнях. У нас есть базы данных с информацией о пользователях (их уникальные коды (id), дата установки игры и активность, платежи и статусы прохождения уровней).
Введем несколько определений из игровой индустрии:
• Киты (топ донатеры) - самые платящие игроки (в контексте сортировки игроков по средним/общим платежам, чаще всего смотрим конкретный процент от всех игроков)
• ARPU (average revenue per user (в долларах)) - продуктовая метрика, показывающая средний доход с игрока (средние траты игрока), чаще всего за месяц
В нашей команде часто бывают небольшие эффекты, а также некачественные данные, которые еще и долго и сложно собирать, поэтому возникают вопросы: корректно ли мы используем A/B тесты и можно ли в некоторых случаях обойтись без них.
В данной работе представлены результаты по следующим задачам:
1. Проверка применимости статистических тестов.
2. А/B тест без непосредственного проведения А/B теста.
3. Влияние распределения улучшения от фичи на A/B тесты.
В данной работе рассмотрены важные для команды исследования в области A/B тестов.
Начальная задача, связанная с применимостью статистических тестов, важна, поскольку с помощью нее мы можем понять, насколько грамотно мы верифицируем результаты тестов. В первом пункте мы поняли, что с использованием теста на пропорции proportions_ztest на наших данных проблем не возникает, поэтому мы можем быть уверены в корректности его использования. С использованием же ttest_ind в A/B тестах с платежами нужно быть аккуратнее, а также внимательнее анализировать его результаты. Эти исследования показали нам новые направления для изучения и новые подходы к проведению A/B тестов на наших данных.
Исследование ’’A/B-тестов без проведения A/B-тестирования” дало возможность нашей команде проводить аналитику не только ”на будущее”, но и по уже имеющимся данным, если возникает такая необходимость. Это важно, ведь иногда могут быть ситуации (как, например, описано в работе), когда нужно сравнить две группы игроков, отличающихся только одной характеристикой, но при этом нет возможности разделить их и запустить A/B-тест (нехватка времени/ресурсов/etc).
В последней части работы исследованы различные варианты принятия решений и влияние фичей на них. Найдена группа улучшений, для которых не обязательно проводить A/B тестирование и можно сохранить время и ресурсы, что несомненно важно для команды.
