Почему ваши A/B-тесты требуют больше времени, чем могли бы

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

Сегодня поговорим о том, как можно сократить время для получения сигнала о влиянии тестируемого изменения, изменив процесс добавления пользователей в A/B-тест.

Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.

→ «Симулятор управления продуктом на основе данных» поможет научиться принимать решения с помощью данных и исследований при создании продукта (путь от 0 к 1).

→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).

→ «Симулятор SQL для продуктовой аналитики» поможет освоить SQL и применять его для решения продуктовых и маркетинговых задач.

→ «Симулятор управления ML/AI-проектами» научит применять технологии машинного обучения с пользой для бизнеса.

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

Еще больше ценных материалов и инсайтов — в телеграм-канале GoPractice.

Два подхода к дизайну A/B-теста

Начнем с примера.

Вы заметили, что часть пользователей приложения бросает покупку в процессе чек-аута. Гипотеза состоит в том, что с помощью серии пуш-нотификаций (напоминаний, отзывов других клиентов, предложений рассрочки) вы сможете убедить часть отвалившихся пользователей завершить покупку, что позитивно повлияет на монетизацию.

Стандартный способ проверки гипотезы с помощью A/B-теста:

1. Добавить всех активных пользователей в тест и случайно разделить на две группы.
2. В тестовой группе включить новую логику пушей, в контрольной — нет.
3. Замерить влияние на ключевые метрики, сравнив показатели двух групп.

Рекомендуемый способ проверки гипотезы с помощью A/B-теста:

1. Добавлять пользователя в тест только в момент, когда собираемся изменить его опыт в продукте, то есть впервые отправить пуш из тестируемой кампании.
2. Пользователям, которые попали в тестовую группу, отправить серию пушей, а тем, кто попал в контрольную группу, не отправлять.
3. Замерить влияние на ключевые метрики, сравнив показатели двух групп.

Рекомендуемый дизайн эксперимента предполагает два изменения:

1. Добавлять в тест только пользователей, для которых мог поменяться опыт в продукте (мог, так как мы изменим опыт только для пользователей в тестовой группе).
2. При анализе учитывать данные этих пользователей только с момента, когда мы добавили их в тест, а не с момента, когда мы запустили эксперимент.

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

Добавлять в A/B-тест только пользователей, для которых мог поменяться опыт в продукте

Вы запустили A/B-тест 1 апреля, закончили его 30 апреля.

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

Целевая метрика в эксперименте — конверсия в покупку (доля пользователей в сформированных группах, которые сделали покупку).

• В контрольной группе она будет равна 4.4% ( (4 000 + 400) / 100 000).
• В тестовой группе будет равна 4.5% ( (4 000 + 500) / 100 000).
• Значимой разницы нет (проверить можно здесь). P-value = 28%. Это значит, что c высокой степенью вероятности наблюдаемое изменение — случайность.

Теперь представьте, что мы добавляли в эксперимент только тех, кто мог получить новый опыт в продукте. То есть тех, кто бросил покупку.

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

*мы добавляем пользователей в тест только тогда, когда они бросили покупку, поэтому в тестовых группах число активных пользователей и число пользователей, которые начали покупку, будет равно числу тех, кто покупку бросил

Давайте посчитаем, как изменение способа добавления в тест повлияло на конверсию в покупку:

• Конверсия в покупку для пользователей, которые стали частью эксперимента, будет равна 6.6% (400 / 6 000) в контроле и 8.3% (500 / 6 000) в тесте.
• Разница значимая, причем для получения сигнала о влиянии изучаемого изменения хватило бы и меньшей выборки.

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

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

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

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

Учитывать данные пользователей только с момента, когда их добавили в тест

Другой способ размыть эффект от тестируемого изменения — учитывать при расчете метрик данные пользователей с момента старта A/B-теста, а не с момента, когда каждый конкретный пользователь стал его частью.

Большинство получают новый опыт в продукте не в момент запуска эксперимента, а позже. Если учитывать при расчетах данные конкретного пользователя за период с момента старта эксперимента до момента, когда он стал частью теста, то опять добавится шум.

Мы запустили A/B-тест 1 апреля. Пользователь X бросил покупку 10 апреля и тогда стал частью эксперимента. Правильным будет при расчете метрик учитывать для этого пользователя данные только с 10 апреля. В период с 1 по 10 апреля его данные никаким образом не характеризуют влияние тестируемого изменения.

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

Как понять общий эффект от изменения

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

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

В рассмотренном выше эксперименте прирост числа пользователей, совершивших покупку, составил 25% (если добавлять в тест только тех, кто бросил покупку). Давайте посчитаем, каково общее воздействие на метрики.

В тестовой группе после брошенной покупки ее все же сделали 500 пользователей, в контрольной — 400. Если брать всю базу пользователей за время проведения эксперимента, то в обоих случаях были еще по 4000 пользователей, которые совершили покупки сразу.

В итоге прирост в 25% для пользователей, бросающих покупки, преобразуется в прирост конверсии в покупку на 2% в продукте целиком (4 500 / 4 400 — 1 = 2%).

Как логировать информацию об экспериментах

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

Если вы используете Amplitude или Mixpanel, то можно добавить пользователю глобальный параметр с названием и группой эксперимента в момент, когда он становится его частью. При анализе вы просто отфильтруете события по наличию в них этого параметра.

Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.

→ «Симулятор управления продуктом на основе данных» поможет научиться принимать решения с помощью данных и исследований при создании продукта (путь от 0 к 1).

→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).

→ «Симулятор SQL для продуктовой аналитики» поможет освоить SQL и применять его для решения продуктовых и маркетинговых задач.

→ «Симулятор управления ML/AI-проектами» научит применять технологии машинного обучения с пользой для бизнеса.

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

Еще больше ценных материалов и инсайтов — в телеграм-канале GoPractice.