Когда вы разрабатываете продукт, каждая новая итерация — это риск уронить метрики и потерять пользователей. Тем не менее иногда, особенно на начальных этапах, компании неосознанно идут на этот риск — меняют продукт, полагаясь только на свои инстинкты и гипотезы.
Мы в Badoo не доверяем ощущениям, зато верим цифрам. Суммарно у наших сервисов больше 500 миллионов пользователей, и свой фреймворк для тестирования мы написали довольно давно. За шесть лет через него прошло 2962 теста, и A/B-тестирование доказало свою важность, надёжность и результативность.
Но в этой статье я расскажу не о том, как работает наша система. На это не хватит одной статьи. Кроме того, многие вещи специфичны для нашей компании и не подойдут другим. Сегодня я расскажу об эволюции наших представлений об A/B-тестах: на какие грабли мы наступали в процессе и как проверяли корректность работы тестов. Это статья для тех, кто ещё не начал тестировать, но думает об этом, а также для тех, кто не уверен в своей системе тестов.
Представим ситуацию: предстоит запуск новой фичи, и наш продакт-менеджер не готов рисковать небольшим, но стабильным доходом продукта. После недолгих раздумий он предлагает запустить фичу через А/B тест и посмотреть, взлетит ли она и не уйдут ли пользователи к конкурентам.
А/B-тесты мы раньше не проводили, поэтому первым делом узнаём, что они из себя представляют. В «Википедии» написано: «А/B-тестирование — метод маркетингового исследования, суть которого заключается в том, что контрольная группа элементов сравнивается с набором тестовых групп, в которых один или несколько показателей были изменены, для того, чтобы выяснить, какие из изменений улучшают целевой показатель». Выходит, нам нужно провести исследование, в котором должны быть контрольная группа, как минимум одна тестовая группа и целевой показатель.
Для тестовой группы мы покажем альтернативный вариант страницы платежа. На ней мы хотим изменить текст, выделить скидку, заменить картинку — и всё это для пользователей из Евразии, чтобы они больше покупали. А для пользователей из Америки мы ничего менять не хотим.
У нас будут и целевые показатели. Давайте возьмём базовые:
На странице планируется одновременно изменить три элемента: текст, кнопку и картинку с информацией о скидке.
Будет довольно сложно понять, какие из этих изменений повлияли на результат, если тестировать их одновременно. Возможно, новый текст будет отталкивать пользователей и приведёт к уменьшению количества покупок, но выделение скидки его увеличит: в итоге у нас получится ноль. Ресурсы разработки будут потрачены впустую, и рабочая гипотеза будет отвергнута.
Поэтому так мы делать не будем. Оставим для тестирования только одно изменение — выделение скидки.
План такой: делим пользователей на две равные группы и ждём результата. Когда мы его получим, мы сравним показатели в контрольной и тестовой группах.
Выглядит всё довольно просто: поделим пользователей на чётных и нечётных и потом посмотрим на статистику.
Пишем код:
Ждём пару недель: результаты потрясающие! Показатель ARPU вырос на 100%! Люди кликают, платят, продакт-менеджер просит скорее раскатить изменение на всех.
Включаем, проходит ещё пара недель, а результатов нет. Общая прибыль не увеличилась.
Что мы делаем не так?
Мы просто разделили пользователей на две равные группы и запустили тест, но так делать нельзя. Ведь что-то изменилось только для пользователей из Евразии. А их у нас гораздо меньше, чем пользователей из Америки. Поэтому получилось так, что внезапный всплеск активности пользователей из Америки повлиял на результаты нашего теста, хотя в действительности они были не самыми хорошими.
Вывод: всегда выделяйте в тестовую группу только тех пользователей, для которых реализованы изменения.
Давайте поправим наш код:
Теперь-то всё должно заработать как надо! Запускаем тест. Ждём пару недель.
Получилось! Показатель ARPU вырос на 80%! Раскатываем изменение на всех пользователей.
И… через тот же промежуток времени графики снова выглядят не так, как мы планировали.
Тест нельзя остановить просто «через пару недель»: полученные результаты могут оказаться неточными. Чем меньше изменилась метрика, за которой мы следим, и чем меньше людей поучаствовали в тесте, тем больше вероятность того, что изменение было случайным.
Эту вероятность можно вычислить. Величина, обозначающая её, называется p-value. Расскажу, как это работает.
При проведении любого тестирования есть шанс получить случайные результаты. Например, пользователи, которые заходили на сайт, могут быть распределены неравномерно — и вся платящая аудитория попадёт в одну из групп. В реальных тестах разница в метриках обычно не такая большая: заметить проблему на графиках трудно или даже невозможно, и без статистических тестов не обойтись. В частности, нам нужно зафиксировать вероятность ошибок первого и второго рода — иными словами, вероятность найти изменения там, где их нет, и, наоборот, не найти их, если они есть. В зависимости от значения метрики и установленных вероятностей нам понадобится разное количество пользователей.
Рассчитать его можно с помощью онлайн-калькулятора: указываете текущие и целевые значения отслеживаемых метрик — получаете необходимое количество юзеров для теста, и наоборот.
Расчёт для конверсии в 10% и изменения в 0,2% относительно текущего значения
Теперь мы получили все необходимые данные и нам понятно, когда останавливать тест. Препятствий больше нет.
Давайте запустим наш А/B-тест и посмотрим на результаты.
На этот раз результаты больше похожи на правду, но всё равно отличные: рост ARPU на 55%.
Останавливаем тест, применяем тестовую группу на всех. И… метрики снова падают. Почему?
Давайте разбираться, сколько пользователей реально зашло на наш сайт, пока проходило тестирование. Судя по логам, только 10% наших тестовых групп, но мы это никак не учитывали.
Если ваш показатель DAU (количество уникальных пользователей в день) — 1000 человек, это не значит, что через десять дней у вас будет 10 000 пользователей в тесте. Всегда логируйте реальные попадания в тест (test hits) и считайте только их.
Реализуем простую логику. Для каждого пользователя, зашедшего на сайт, отправляем на сервер запрос с названиями А/B-теста и контрольной группы. Благодаря этому мы будем точно знать, сколько пользователей к нам зашло, и больше не ошибёмся.
Запускаем А/B-тест.
Результаты отличные. Денег мы снова зарабатываем больше! Включаем наш тест для всех — и что-то снова идёт не так: через пару недель метрики снова ниже прогнозируемых.
Помните, мы начали отправлять хиты для всех пользователей, зашедших на сайт? Никогда так не делайте. Хиты нужно отправлять только для тех пользователей, которые взаимодействовали с тестируемой частью ресурса. И чем точнее вы будете их определять, тем лучше.
К счастью, это легко проверить. Для этого можно провести А/А/B-тест. Он похож на А/B-тест, но в этом случае у вас две контрольные группы и одна тестовая. Зачем это нужно? Если момент для отправки хита выбран неверно, то в тест попадут пользователи, которые никак не взаимодействовали с тестируемой частью сайта. В таком случае в группах А и А будут большие различия в метриках, и вы сможете сразу понять, что что-то не так.
Запускаем А/А/B-тест.
В группе B оставляйте 50% пользователей, а остальные 50% разделите поровну между группами A и A (мы их называем control и control_check). Да, результатов придётся ждать дольше, но по тому, сойдутся ли результаты групп А и А, вы поймёте, корректно ли отправляется хит.
Результаты скромные (рост всего на 20%), но реалистичные. Давайте раскатывать изменение на всех.
Всё работает, отлично!
Но через месяц метрики снова упали.
Оказывается, наш third-party-биллинг тоже проводил свой А/B-тест, который напрямую повлиял на результаты нашего. Поэтому всегда следите за результатами на продакшене и старайтесь тестировать то, что контролируете полностью.
А/B-тесты могут помочь продукту вырасти. Но чтобы доверять тестам, важно проводить их правильно и всегда проверять результаты. Такой подход позволит качественно тестировать ваш продукт и проверять гипотезы перед тем, как они уронят все метрики.
Мы в Badoo не доверяем ощущениям, зато верим цифрам. Суммарно у наших сервисов больше 500 миллионов пользователей, и свой фреймворк для тестирования мы написали довольно давно. За шесть лет через него прошло 2962 теста, и A/B-тестирование доказало свою важность, надёжность и результативность.
Но в этой статье я расскажу не о том, как работает наша система. На это не хватит одной статьи. Кроме того, многие вещи специфичны для нашей компании и не подойдут другим. Сегодня я расскажу об эволюции наших представлений об A/B-тестах: на какие грабли мы наступали в процессе и как проверяли корректность работы тестов. Это статья для тех, кто ещё не начал тестировать, но думает об этом, а также для тех, кто не уверен в своей системе тестов.
Что такое А/B-тест
Представим ситуацию: предстоит запуск новой фичи, и наш продакт-менеджер не готов рисковать небольшим, но стабильным доходом продукта. После недолгих раздумий он предлагает запустить фичу через А/B тест и посмотреть, взлетит ли она и не уйдут ли пользователи к конкурентам.
А/B-тесты мы раньше не проводили, поэтому первым делом узнаём, что они из себя представляют. В «Википедии» написано: «А/B-тестирование — метод маркетингового исследования, суть которого заключается в том, что контрольная группа элементов сравнивается с набором тестовых групп, в которых один или несколько показателей были изменены, для того, чтобы выяснить, какие из изменений улучшают целевой показатель». Выходит, нам нужно провести исследование, в котором должны быть контрольная группа, как минимум одна тестовая группа и целевой показатель.
Для тестовой группы мы покажем альтернативный вариант страницы платежа. На ней мы хотим изменить текст, выделить скидку, заменить картинку — и всё это для пользователей из Евразии, чтобы они больше покупали. А для пользователей из Америки мы ничего менять не хотим.
У нас будут и целевые показатели. Давайте возьмём базовые:
- ARPU (average revenue per user) — прибыль, которую мы в среднем получим с пользователя;
- количество кликов по элементам CTA (call to action) — кнопкам и ссылкам на странице платежа.
Техническое задание
На странице планируется одновременно изменить три элемента: текст, кнопку и картинку с информацией о скидке.
Будет довольно сложно понять, какие из этих изменений повлияли на результат, если тестировать их одновременно. Возможно, новый текст будет отталкивать пользователей и приведёт к уменьшению количества покупок, но выделение скидки его увеличит: в итоге у нас получится ноль. Ресурсы разработки будут потрачены впустую, и рабочая гипотеза будет отвергнута.
Поэтому так мы делать не будем. Оставим для тестирования только одно изменение — выделение скидки.
Первый тест
План такой: делим пользователей на две равные группы и ждём результата. Когда мы его получим, мы сравним показатели в контрольной и тестовой группах.
Выглядит всё довольно просто: поделим пользователей на чётных и нечётных и потом посмотрим на статистику.
Пишем код:
if (userId % 2 == 1) {
showNewAwesomeFeature();
}Ждём пару недель: результаты потрясающие! Показатель ARPU вырос на 100%! Люди кликают, платят, продакт-менеджер просит скорее раскатить изменение на всех.
Включаем, проходит ещё пара недель, а результатов нет. Общая прибыль не увеличилась.
Что мы делаем не так?
Подбираем тестовую группу
Мы просто разделили пользователей на две равные группы и запустили тест, но так делать нельзя. Ведь что-то изменилось только для пользователей из Евразии. А их у нас гораздо меньше, чем пользователей из Америки. Поэтому получилось так, что внезапный всплеск активности пользователей из Америки повлиял на результаты нашего теста, хотя в действительности они были не самыми хорошими.
Вывод: всегда выделяйте в тестовую группу только тех пользователей, для которых реализованы изменения.
Давайте поправим наш код:
if (user.continent === ‘eurasia’ && userId % 2 == 1) {
showNewAwesomeFeature();
}Теперь-то всё должно заработать как надо! Запускаем тест. Ждём пару недель.
Получилось! Показатель ARPU вырос на 80%! Раскатываем изменение на всех пользователей.
И… через тот же промежуток времени графики снова выглядят не так, как мы планировали.
Вычисляем статистическую значимость
Тест нельзя остановить просто «через пару недель»: полученные результаты могут оказаться неточными. Чем меньше изменилась метрика, за которой мы следим, и чем меньше людей поучаствовали в тесте, тем больше вероятность того, что изменение было случайным.
Эту вероятность можно вычислить. Величина, обозначающая её, называется p-value. Расскажу, как это работает.
При проведении любого тестирования есть шанс получить случайные результаты. Например, пользователи, которые заходили на сайт, могут быть распределены неравномерно — и вся платящая аудитория попадёт в одну из групп. В реальных тестах разница в метриках обычно не такая большая: заметить проблему на графиках трудно или даже невозможно, и без статистических тестов не обойтись. В частности, нам нужно зафиксировать вероятность ошибок первого и второго рода — иными словами, вероятность найти изменения там, где их нет, и, наоборот, не найти их, если они есть. В зависимости от значения метрики и установленных вероятностей нам понадобится разное количество пользователей.
Рассчитать его можно с помощью онлайн-калькулятора: указываете текущие и целевые значения отслеживаемых метрик — получаете необходимое количество юзеров для теста, и наоборот.
Расчёт для конверсии в 10% и изменения в 0,2% относительно текущего значения
Теперь мы получили все необходимые данные и нам понятно, когда останавливать тест. Препятствий больше нет.
Давайте запустим наш А/B-тест и посмотрим на результаты.
На этот раз результаты больше похожи на правду, но всё равно отличные: рост ARPU на 55%.
Останавливаем тест, применяем тестовую группу на всех. И… метрики снова падают. Почему?
Проверяем количество пользователей
Давайте разбираться, сколько пользователей реально зашло на наш сайт, пока проходило тестирование. Судя по логам, только 10% наших тестовых групп, но мы это никак не учитывали.
Если ваш показатель DAU (количество уникальных пользователей в день) — 1000 человек, это не значит, что через десять дней у вас будет 10 000 пользователей в тесте. Всегда логируйте реальные попадания в тест (test hits) и считайте только их.
Реализуем простую логику. Для каждого пользователя, зашедшего на сайт, отправляем на сервер запрос с названиями А/B-теста и контрольной группы. Благодаря этому мы будем точно знать, сколько пользователей к нам зашло, и больше не ошибёмся.
Запускаем А/B-тест.
Результаты отличные. Денег мы снова зарабатываем больше! Включаем наш тест для всех — и что-то снова идёт не так: через пару недель метрики снова ниже прогнозируемых.
Помните, мы начали отправлять хиты для всех пользователей, зашедших на сайт? Никогда так не делайте. Хиты нужно отправлять только для тех пользователей, которые взаимодействовали с тестируемой частью ресурса. И чем точнее вы будете их определять, тем лучше.
К счастью, это легко проверить. Для этого можно провести А/А/B-тест. Он похож на А/B-тест, но в этом случае у вас две контрольные группы и одна тестовая. Зачем это нужно? Если момент для отправки хита выбран неверно, то в тест попадут пользователи, которые никак не взаимодействовали с тестируемой частью сайта. В таком случае в группах А и А будут большие различия в метриках, и вы сможете сразу понять, что что-то не так.
Запускаем А/А/B-тест.
В группе B оставляйте 50% пользователей, а остальные 50% разделите поровну между группами A и A (мы их называем control и control_check). Да, результатов придётся ждать дольше, но по тому, сойдутся ли результаты групп А и А, вы поймёте, корректно ли отправляется хит.
Результаты скромные (рост всего на 20%), но реалистичные. Давайте раскатывать изменение на всех.
Всё работает, отлично!
Но через месяц метрики снова упали.
Тестируем то, что можем контролировать
Оказывается, наш third-party-биллинг тоже проводил свой А/B-тест, который напрямую повлиял на результаты нашего. Поэтому всегда следите за результатами на продакшене и старайтесь тестировать то, что контролируете полностью.
Итог
А/B-тесты могут помочь продукту вырасти. Но чтобы доверять тестам, важно проводить их правильно и всегда проверять результаты. Такой подход позволит качественно тестировать ваш продукт и проверять гипотезы перед тем, как они уронят все метрики.
- Всегда проверяйте целевую группу.
- Отправляйте хиты.
- Отправляйте правильные хиты.
- Тестируйте то, что вы контролируете полностью.
- Не беспокойтесь и верьте А/В-тестам!