ГлавнаяНовости ITПроведение A/B-тестирования: пошаговый разбор

Проведение A/B-тестирования: пошаговый разбор

В каждое изменение в игре команда вкладывает много труда, сил и ресурсов: иногда разработка новой функциональности или уровня занимает несколько месяцев. Задача аналитика — минимизировать риски от внедрения подобных изменений и помочь команде принять верное решение о дальнейшем развитии проекта.

При анализе решений важно руководствоваться статистически значимыми данными, которые соответствуют предпочтениям аудитории, а не интуитивным предположениям. Получить такие данные и оценить их помогает А/В-тестирование. В этой статье поделюсь личными наработками: опишу каждый шаг A/B, освещу сложности и ловушки, с которыми можно столкнуться, и расскажу об опыте их решения.

6 «простых» шагов A/B-тестирования

По поисковому запросу «А/В-тестирование» или «сплит-тестирование» большинство источников предлагает несколько «простых» шагов для успешного проведения теста. В моей стратегии таких шагов шесть.

На первый взгляд всё просто:

  • есть группа А, контрольная, без изменений в игре;
  • есть группа В, тестовая, с изменениями. Например, добавлена новая функциональность, повышена сложность уровней, изменен туториал;
  • запускаем тест и смотрим, у какого варианта показатели лучше.

На практике сложнее. Чтобы команда внедрила лучшее решение, мне как аналитику нужно ответить, насколько я уверена в результатах теста. Разберемся со сложностями пошагово.

Шаг 1. Определяем цель

C одной стороны, мы можем протестировать всё, что приходит в голову каждому члену команды, — от цвета кнопки до уровней сложности игры. Техническая возможность проводить сплит-тесты закладывается в наши продукты еще на этапе проектирования.

С другой — все предложения по улучшению игры важно приоритизировать по уровню эффекта, оказываемого на целевую метрику. Поэтому сначала составляем план запуска сплит-тестирования от наиболее приоритетной гипотезы до наименее.

Мы стараемся не проводить несколько А/В-тестов параллельно, чтобы точно понимать, какая из новых функциональностей повлияла на целевую метрику. Кажется, что при такой стратегии потребуется больше времени на проверку всех гипотез. Но приоритизация помогает отсечь неперспективные гипотезы еще на этапе планирования. Мы получаем данные, максимально отражающие эффект от конкретных изменений, и не тратим время на постановку тестов с сомнительным эффектом.

План запуска обязательно обсуждаем с командой, поскольку на разных этапах жизненного цикла продукта акцент интереса смещается. В начале проекта это обычно Retention D1 — доля игроков, которые вернулись в игру на следующий день после ее установки. На более поздних этапах это могут быть метрики удержания или монетизации: Conversion, ARPU и другие.

Пример. После выхода проекта в софтлонч особого внимания требуют метрики удержания. На этом этапе выделим одну из возможных проблем: Retention D1 не выходит на уровень бенчмарок компании для конкретного жанра игры. Необходимо проанализировать воронку прохождения первых уровней. Допустим, вы заметили большой дроп игроков между стартом и комплитом 3-го уровня — низкий Completion Rate 3-го уровня.

Цель планируемого А/В-теста: повысить Retention D1 за счет увеличения доли игроков, которые успешно завершили 3-й уровень.

Шаг 2. Определяем метрики

До запуска А/В-теста определяем отслеживаемый параметр — выбираем метрику, изменения которой покажут, является ли новая функциональность игры более успешной, чем изначальная.

Метрики бывают двух типов:

  • количественные — средняя продолжительность сессии, величина среднего чека, время прохождения уровня, количество опыта и так далее;
  • качественные — Retention, Conversion Rate и прочие.

Тип метрики влияет на выбор метода и инструментов оценки значимости результатов.

Вероятно, тестируемая функциональность повлияет не на одну целевую, а на ряд метрик. Поэтому мы смотрим на изменения в целом, но не пытаемся найти «хоть что-то», когда статистической значимости при оценке целевой метрики нет.

Согласно цели из первого шага, для предстоящего А/В-теста будем оценивать Completion Rate 3-го уровня — качественную метрику.

Шаг 3. Формулируем гипотезу

Каждый А/В-тест проверяет одну общую гипотезу, которая формулируется перед запуском. Отвечаем на вопрос: какие изменения ожидаем в тестовой группе? Формулировка обычно выглядит так:

«Ожидаем, что (воздействие) вызовет (изменение)»

Статистические методы работают от обратного — мы не можем с их помощью доказать, что гипотеза верна. Поэтому после формулирования общей гипотезы определяют две статистические. Они помогают понять: наблюдаемая разница между контрольной группой A и тестовой группой B — это случайность или результат изменений.

В нашем примере:

  • Нулевая гипотеза (H0): снижение сложности 3-го уровня не повлияет на долю пользователей, успешно завершивших 3-й уровень. Completion Rate 3-го уровня для групп А и В на самом деле не отличаются, и наблюдаемые различия случайны.
  • Альтернативная гипотеза (H1): снижение сложности 3-го уровня увеличит долю пользователей, успешно завершивших 3-й уровень. Completion Rate 3-го уровня в группе B выше, чем в группе A, и эти различия — результат изменений.

На этом этапе, кроме формулирования гипотезы, необходимо оценить ожидаемый эффект.

Гипотеза: «Ожидаем, что уменьшение сложности 3-го уровня вызовет рост Completion Rate 3-го уровня с 85% до 95%, то есть более чем на 11%».

(95%-85%)/85% = 0,117 => 11,7%

В этом примере при определении ожидаемого Completion Rate 3-го уровня мы стремимся приблизить его к среднему значению Completion Rate начальных уровней.

Шаг 4. Настраиваем эксперимент

1. Определяем параметры для А/В-групп перед запуском эксперимента: на какую аудиторию запускаем тест, на какую долю игроков, какие настройки устанавливаем в каждой группе.

2. Проверяем репрезентативность выборки в целом и однородность выборок в группах. Можно предварительно запустить А/А-тест для оценки этих параметров — тест, в котором тестовая и контрольная группы имеют одинаковую функциональность. А/А-тест помогает убедиться, что в обеих группах целевые метрики не имеют статистически значимого различия. Если же различия есть, А/В-тест с такими настройками — объемом выборки и уровнем доверия — запускать нельзя.

Выборка не будет идеально репрезентативной, но мы всегда обращаем внимание на структуру пользователей в разрезе их характеристик — новый/старый пользователь, уровень в игре, страна. Всё привязано к цели А/В-теста и оговаривается заранее. Важно, чтобы структура пользователей в каждой группе была условно одинаковая.

Тут потенциально опасны две ловушки:

  • Высокие показатели метрик в группах во время эксперимента могут быть следствием привлечения хорошего трафика. Трафик хороший, если показатели вовлеченности высокие. Плохой трафик — самая частая причина падения метрик.
  • Неоднородность выборки. Допустим, проект из нашего примера разрабатывается для англоговорящей аудитории. Значит, нам нужно избежать ситуации, когда в одну из групп попадет больше пользователей из стран, где английский язык — не преобладающий.


3. Рассчитываем объем выборки и длительность проведения эксперимента.

Казалось бы, момент прозрачный, принимая во внимание огромный набор онлайн-калькуляторов.

Однако их использование предполагает ввод специфичной начальной информации. Чтобы выбрать соответствующий вариант онлайн-калькулятора, вспомните про типы данных и разберитесь со следующими терминами.

Яндекс.Метрика