что такое минимальная выборка для тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример. С помощью калькулятора Optimizely рассчитаем объем выборки для коэффициента конверсии 1%. Учтем, что предполагаемый размер эффекта составит 5% при 95% уровне доверия (показатель рассчитывается как 1-α). Обратите внимание: в интерфейсе этого калькулятора термин Statistical significance используется в значении «Уровень доверия» при уровне значимости 5%.

Optimizely утверждает, что в каждую группу должны попасть 870 000 пользователей.
Переводим размер выборки в приблизительную длительность теста — два простых вычисления.

Расчет № 1. Размер выборки × количество групп в эксперименте = общее количество необходимых пользователей

Расчет № 2. Общее количество необходимых пользователей ÷ среднее количество пользователей в день = примерное количество дней эксперимента

Если в первую группу требуется 870 000 пользователей, то для теста двух вариантов общее количество пользователей составит 1 740 000. С учетом трафика 1000 игроков в день, тест должен длиться 1740 дней. Такая длительность не оправдана. На этом этапе мы обычно пересматриваем гипотезу, исходные данные и целесообразность проведения теста.

В нашем примере с улучшением 3-го уровня конверсия — это доля тех, кто успешно завершил 3-й уровень. То есть коэффициент конверсии составляет 85%, мы хотим увеличить этот показатель минимум на 11%. При уровне доверия 95% получаем 130 пользователей на группу.

При том же объеме трафика в 1000 пользователей тест, грубо говоря, можно закончить менее чем за день. Этот вывод в корне неправильный, так как не учитывает недельную сезонность. Поведение пользователей отличается в разные дни недели, например, может изменяться по праздникам. И в одних проектах это влияние очень сильное, в других едва заметное. Не во всех проектах и не для всех тестов это необходимое условие, но на проектах, с которыми мне доводилось работать, недельная сезонность в КPI наблюдалась всегда.

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

Шаг 5. Проводим эксперимент

После запуска А/В-теста сразу возникает желание посмотреть на результаты, но большинство источников строго-настрого запрещает это делать, чтобы исключить проблему «подглядывания» (peeking problem). Объяснить суть проблемы простыми словами, на мой взгляд, пока ни у кого не получилось. Авторы подобных статей основывают доказательства на оценке вероятностей, различных результатах математического моделирования, которые уводят читателей в зону «сложных математических формул». Основной их вывод — практически неоспоримый факт: не смотрите на данные до того, как наберется требуемая выборка и пройдет требуемое количество дней после запуска теста. В результате проблему «подглядывания» многие интерпретируют неправильно и следуют рекомендациям буквально.

Мы настроили процессы так, чтобы ежедневно видеть актуальные данные для мониторинга KPI проектов. В заранее подготовленных дашбордах следим за ходом эксперимента с самого запуска: проверяем, равномерно ли набираются группы, нет ли критичных проблем после запуска теста, которые могут повлиять на результаты, и так далее.

Главное правило — не делать преждевременных выводов. Все выводы формулируются в соответствии с заложенным дизайном А/В-теста и сводятся в детализированном отчете. Мы мониторим изменения показателя с момента запуска А/В-теста.

Пример, как в А/В-тесте по дням может меняться Completion Rate. В первые два дня после запуска побеждал вариант игры без изменений (группа А), но это оказалось просто случайностью. Уже после второго дня показатель в группе В приобретает стабильно лучшие результаты. Для завершения тесту нужна не просто статистическая значимость, но и стабильность, поэтому ждем окончания теста.

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

Шаг 6. Анализируем результаты

Расчет ключевых метрик не представляет особой сложности, а вот оценка значимости полученных результатов — отдельная проблема.

Для проверки статистической значимости результатов при оценивании качественных метрик, таких как Retention и Сonvertion, можно использовать онлайн-калькуляторы.

Мой топ-3 онлайн-калькуляторов для таких задач:

Давайте посмотрим, как с помощью калькуляторов построить выводы по данному А/В-тесту.

Если пугает такое количество настроек, нет желания или потребности разбираться с разнообразием рассчитанных калькулятором данных, можно использовать A/B Testing Calculator от Neilpatel.

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

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

Источник

На что мы обращаем внимание при расчете статистической значимости A/B-теста

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

Типичная схема A/B-тестирования у нас (да и у многих) выглядит так:

Статистическая значимость, критерии и ошибки

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

Самый распространенный параметрический тест — критерий Стьюдента. Для двух независимых выборок (случай A/B-теста) его иногда называют критерием Уэлча. Этот критерий работает корректно, если исследуемые величины распределены нормально. Может показаться, что на реальных данных это требование почти никогда не удовлетворяется, однако на самом деле тест требует нормального распределения выборочных средних, а не самих выборок. На практике это означает, что критерий можно применять, если у вас в тесте достаточно много наблюдений (десятки-сотни) и в распределениях нет совсем уж длинных хвостов. При этом характер распределения исходных наблюдений неважен. Читатель самостоятельно может убедиться, что критерий Стьюдента работает корректно даже на выборках, сгенерированных из распределений Бернулли или экспоненциального.

Из непараметрических критериев популярен критерий Манна — Уитни. Его стоит применять, если ваши выборки очень малого размера или есть большие выбросы (метод сравнивает медианы, поэтому устойчив к выбросам). Также для корректной работы критерия в выборках должно быть мало совпадающих значений. На практике нам ни разу не приходилось применять непараметрические критерии, в своих тестах всегда пользуемся критерием Стьюдента.

Проблема множественного тестирования гипотез

Например, для трёх экспериментальных групп получим 14.3% вместо ожидаемых 5%. Решается проблема поправкой Бонферрони на множественную проверку гипотез: нужно просто поделить уровень значимости на количество сравнений (то есть групп) и работать с ним. Для примера выше уровень значимости с учётом поправки составит 0.05/3 = 0.0167 и вероятность хотя бы одной ошибки первого рода составит приемлемые 4.9%.

P-value первой гипотезы сравнивается с уровнем статистический значимости . Если гипотеза принимается, то переходим ко второй и сравниваем её p-value с уровнем статистической значимости , и так далее. Как только какая-то гипотеза отвергается, процесс останавливается и все оставшиеся гипотезы так же отвергаются. Самое жёсткое требование (и такое же, как в поправке Бонферрони) накладывается на гипотезу с наименьшим p-value, а большая мощность достигается за счёт менее жёстких условий для последующих гипотез. Цель A/B-теста — выбрать одного единственного победителя, поэтому методы Бонферрони и Холма — Бонферрони абсолютно идентичны в этом приложении.

Строго говоря, сравнения групп по разным метрикам или срезам аудитории тоже подвержены проблеме множественного тестирования. Формально учесть все проверки довольно сложно, потому что их количество сложно спрогнозировать заранее и подчас они не являются независимыми (особенно если речь идёт про разные метрики, а не срезы). Универсального рецепта нет, полагайтесь на здравый смысл и помните, что если проверить достаточно много срезов по разным метрикам, то в любом тесте можно увидеть якобы статистически значимый результат. А значит, надо с осторожностью относиться, например, к значимому приросту ретеншена пятого дня новых мобильных пользователей из крупных городов.

Проблема подглядывания

Частный случай множественного тестирования гипотез — проблема подглядывания (peeking problem). Смысл в том, что значение p-value по ходу теста может случайно опускаться ниже принятого уровня значимости. Если внимательно следить за экспериментом, то можно поймать такой момент и ошибочно сделать вывод о статистической значимости.

Предположим, что мы отошли от описанной в начале поста схемы проведения тестов и решили подводить итоги на уровне значимости 5% каждый день (или просто больше одного раза за время теста). Под подведением итогов я понимаю признание теста положительным, если p-value ниже 0.05, и его продолжение в противном случае. При такой стратегии доля ложноположительных результатов будет пропорциональна количеству проверок и уже за первый месяц достигнет 28%. Такая огромная разница кажется контринтуитивной, поэтому обратимся к методике A/A-тестов, незаменимой для разработки схем A/B-тестирования.

Идея A/A-теста проста: симулировать на исторических данных много A/B-тестов со случайным разбиением на группы. Разницы между группами заведомо нет, поэтому можно точно оценить долю ошибок первого рода в своей схеме A/B-тестирования. На гифке ниже показано, как изменяются значения p-value по дням для четырёх таких тестов. Равный 0.05 уровень значимости обозначен пунктирной линией. Когда p-value опускается ниже, мы окрашиваем график теста в красный. Если бы в этом время подводились итоги теста, он был бы признан успешным.

Рассчитаем аналогично 10 тысяч A/A-тестов продолжительностью в один месяц и сравним доли ложноположительных результатов в схеме с подведением итогов в конце срока и каждый день. Для наглядности приведём графики блуждания p-value по дням для первых 100 симуляций. Каждая линия — p-value одного теста, красным выделены траектории тестов, в итоге ошибочно признанных удачными (чем меньше, тем лучше), пунктирная линия — требуемое значение p-value для признания теста успешным.

На графике можно насчитать 7 ложноположительных тестов, а всего среди 10 тысяч их было 502, или 5%. Хочется отметить, что p-value многих тестов по ходу наблюдений опускались ниже 0.05, но к концу наблюдений выходили за пределы уровня значимости. Теперь оценим схему тестирования с подведением итогов каждый день:

Красных линий настолько много, что уже ничего не понятно. Перерисуем, обрывая линии тестов, как только их p-value достигнут критического значения:

Всего будет 2813 ложноположительных тестов из 10 тысяч, или 28%. Понятно, что такая схема нежизнеспособна.

Хоть проблема подглядывания — это частный случай множественного тестирования, применять стандартные поправки (Бонферрони и другие) здесь не стоит, потому что они окажутся излишне консервативными. На графике ниже — доля ложноположительных результатов в зависимости от количества тестируемых групп (красная линия) и количества подглядываний (зелёная линия).

Хотя на бесконечности и в подглядываниях мы вплотную приблизимся к 1, доля ошибок растёт гораздо медленнее. Это объясняется тем, что сравнения в этом случае независимыми уже не являются.

Методы досрочного завершения теста

Есть варианты тестирования, позволяющие досрочно принять тест. Расскажу о двух из них: с постоянным уровнем значимости (поправка Pocock’a) и зависимым от номера подглядывания (поправка O’Brien-Fleming’a). Строго говоря, для обеих поправок нужно заранее знать максимальный срок теста и количество проверок между запуском и окончанием теста. Причём проверки должны происходить примерно через равные промежутки времени (или через равные количества наблюдений).

Pocock

Метод заключается в том, что мы подводим итоги тестов каждый день, но при сниженном (более строгом) уровне значимости. Например, если мы знаем, что сделаем не больше 30 проверок, то уровень значимости надо выставить равным 0.006 (подбирается в зависимости от количества подглядываний методом Монте-Карло, то есть эмпирически). На нашей симуляции получим 4% ложноположительных исходов — видимо, порог можно было увеличить.

Несмотря на кажущуюся наивность, некоторые крупные компании пользуются именно этим способом. Он очень прост и надёжен, если вы принимаете решения по чувствительным метрикам и на большом трафике. Например, в «Авито» по умолчанию уровень значимости принят за 0.005.

O’Brien-Fleming

Соответствующие уровни значимости вычисляются через перцентиль стандартного распределения, соответствующий значению статистики Стьюдента :

На тех же симуляциях это выглядит так:

Ложноположительных результатов получилось 501 из 10 тысяч, или ожидаемые 5%. Обратите внимание, что уровень значимости не достигает значения в 5% даже в конце, так как эти 5% должны «размазаться» по всем проверкам. В компании мы пользуемся именно этой поправкой, если запускаем тест с возможностью ранней остановки. Прочитать про эти же и другие поправки можно по ссылке.

Калькулятор A/B-тестов

Специфика нашего продукта такова, что распределение любой метрики очень сильно меняется в зависимости от аудитории теста (например, номера класса) и времени года. Поэтому не получится принять за дату окончания теста правила в духе «тест закончится, когда в каждой группе наберётся 1 млн пользователей» или «тест закончится, когда количество решённых заданий достигнет 100 млн». То есть получится, но на практике для этого надо будет учесть слишком много факторов:

Все метрики у нас рассчитываются на уровне объектов теста. Если метрика — количество решённых задач, то в тесте на уровне учителей это будет сумма решённых задач его учениками. Так как мы пользуемся критерием Стьюдента, можно заранее рассчитать нужные калькулятору агрегаты по всем возможным срезам. Для каждого дня со старта теста нужно знать количество людей в тесте , среднее значение метрики и её дисперсию . Зафиксировав доли контрольной группы , экспериментальной группы и ожидаемый прирост от теста в процентах, можно рассчитать ожидаемые значения статистики Стьюдента и соответствующее p-value на каждый день теста:

Далее легко получить значения p-value на каждый день:

Зная p-value и уровень значимости с учетом всех поправок на каждый день теста, для любой продолжительности теста можно рассчитать минимальный аплифт, который можно задетектировать (в англоязычной литературе — MDE, minimal detectable effect). После этого легко решить обратную задачу — определить количество дней, необходимое для выявления ожидаемого аплифта.

Заключение

В качестве заключения хочу напомнить основные посылы статьи:

Источник