Проектируем А-Б-эксперименты грамотно

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

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

Кому будет полезна статья:

• Новичкам в A/B-тестировании: если вы никогда не запускали A/B-эксперименты и хотите узнать, с чего начать.

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

Формулируем гипотезу, которая сработает 

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

Хорошая гипотеза должна отвечать нескольким ключевым критериям, которые помогут сделать её проверяемой и полезной для эксперимента:

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

2. Измеримость: важно, чтобы гипотеза была выражена в числовых показателях, которые можно измерить. Это позволяет объективно оценить, достигнут ли результат.

3. Проверяемость: гипотеза должна быть такой, чтобы её можно было проверить на практике. Если гипотезу невозможно подтвердить или опровергнуть с помощью тестирования, она не имеет ценности.

4. Актуальность: гипотеза должна быть релевантной текущей ситуации и соответствовать целям бизнеса или проекта.

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

Ошибки при формулировке гипотезы: наш опыт с приложением Wednesday Frog

Для эксперимента мы взяли приложение Wednesday Frog – простое приложение с одной кнопкой без лишней функциональности. 

Вариант 1

Чтобы проверить, насколько улучшение пользовательского опыта скажется на доходах, мы сформулировали следующую гипотезу: 

«Улучшение пользовательского опыта позволит повысить общие доходы приложения».

Проблема.  Формулировка гипотезы была слишком общей и не уточняла, какие именно изменения следует внести и как измерить их влияние на доход.

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

Вариант 2

После уточнения гипотезы мы получили следующее предположение: 

«Изменение кнопки на главном экране позволит увеличить дневную выручку приложения до 5000 рублей».

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

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

Вариант 3

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

1. Изменим цвет кнопки на главном экране с синего на зелёный.

2. Изменим текст на кнопке с «вывести 189 тысяч» на «все средства».

Предположение: Эти изменения могут побудить пользователей чаще нажимать на кнопку и выводить больше средств. 

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

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

«Изменение цвета и текста кнопки позволит увеличить дневную выручку приложения до 5000 рублей».

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

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

Вариант 4

Мы решили сосредоточиться на одном изменении и тщательно продумать метрики для оценки его влияния.

«Изменение цвета кнопки позволит увеличить дневную выручку приложения до 5000 рублей».

Проблема: Гипотеза требует ясного определения инструментов и метрик для оценки. Без этого трудно будет проверить, насколько успешным было изменение.

Решение: Необходимо определить конкретную метрику и установить целевой процент прироста при формулировании гипотезы.

Вариант 5

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

Примечание

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

Выбираем процент роста

Процент роста метрики, с другой стороны, более сложен. В нашем примере мы решили зафиксировать статистическое изменение при увеличении метрики на 1%. Это изменение может показаться незначительным и простым, но на практике задача может оказаться более сложной. Если мы посмотрим на формулу, можно предположить, что увеличение метрики на 50% сокращает время эксперимента, так как большие изменения быстрее фиксируются статистически.

Однако тут возникает другая проблема: сможет ли ваша новая фича реально обеспечить такой рост в 50%? Если ваша гипотеза действительно оправдается и вы сможете добиться такого значительного увеличения, тогда ваш эксперимент может занять всего несколько дней. Но если увеличение метрики на 50% окажется недостижимым, то вам придется более тщательно планировать эксперимент, что повлияет на его длительность.

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

Итак, в  эксперименте с приложением Wednesday Frog мы выбрали изменение в  1% как наиболее сбалансированное. Это значение достижимо с точки зрения изменения конверсии и достаточно велико для получения статистической значимости.

Итоговый вариант гипотезы: 

«Изменение цвета кнопки позволит увеличить количество кликов на 1%». 

Гипотеза сформулирована, перейдем к следующему этапу – определение длительности эксперимента.

Длительность эксперимента

Рассмотрим пример использования интерфейса системы Remote Config, в котором представлен автоматический калькулятор для расчёта длительности эксперимента в зависимости от целевого изменения метрики.

В этом примере мы сравниваем длительность эксперимента для различных уровней изменения метрики при одинаковой истории данных. Если наша цель — увеличить метрику на 1%, эксперимент займет примерно 7 дней. Однако, если мы снизим целевое изменение до 0,05%, длительность эксперимента может увеличиться в три и более раз. Это объясняется тем, что очень маленькие изменения требуют значительно больше времени для выявления статистической значимости, особенно при текущем объеме данных и числе пользователей.

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

Как делить аудиторию

При планировании экспериментов важно учитывать размер вашей аудитории, так как это напрямую влияет на выбор целевых изменений метрики и длительность эксперимента. Небольшие процентные изменения наиболее актуальны для крупных продуктов, таких как почтовые сервисы, где большие объемы данных позволяют эффективно фиксировать минимальные изменения. Для начинающих мобильных приложений с аудиторией в 5-10 тысяч пользователей в месяц лучше выбрать более значительное изменение, например, 1% или больше. Это позволит быстрее получить статистически значимые результаты. 

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

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

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

Выбор пропорции деления аудитории также имеет значение. Вы можете выбрать разные варианты, например, 50% и 50% или 20% и 80%. Пропорция зависит от вашего уровня уверенности в новом варианте. Если вы уверены, что новая функция существенно улучшит продукт и хотите, чтобы как можно больше пользователей её увидели, пропорция 20% на 80% может быть обоснованной.

При наличии нескольких вариантов разделите их равномерно: 33% для трех вариантов, 25% для четырех.

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

Сегментация пользователей

Следующий шаг в планировании эксперимента — выбрать способ сегментации пользователей. Рассмотрим наиболее распространённые методы:

1. Гео-таргетинг: ограничение по региону, стране или миру. Этот метод позволяет тестировать изменения на пользователей из определенного географического региона.

2. Язык устройства: сегментация по языковым настройкам устройства, например, английский, русский и другие.

3. Версия операционной системы: различия между Android и iOS, а также версиями их сборок. Это позволяет учитывать особенности различных версий системы.

4. Тип пользователей: можно направить изменения на новых пользователей или на старых, чтобы протестировать, как они воспринимают обновления.

5. Модель устройства: сегментация по производителю или модели устройства, например, только Samsung или только Apple.

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

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

Пересечения аудитории экспериментов

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

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

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

1. Разделение аудитории на слои

Один из способов управления пересечениями — разделение аудитории на условные блоки или слои. Например, можно разделить аудиторию на 20%-ные слои и назначить каждому слою конкретные условия экспериментов.

Пример: Первый эксперимент проводится на верхних 50% аудитории, а второй — на нижних 50%. Это позволяет избежать случайных пересечений, однако стоит отметить, что такая возможность доступна не во всех системах, и распределение пользователей может быть менее предсказуемым, если функциональность отсутствует.

2. Использование дополнительного маркера (соль)

Другой эффективный метод управления пересечениями — использование уникальных маркеров или «соли» для каждого эксперимента. Это позволяет точно отслеживать распределение аудитории между различными экспериментами.

Пример использования соли:

• Эксперимент 1: изменение цвета кнопки. Вы применяете маркер «Эксперимент 1» и выбираете верхние 50% пользователей.

• Эксперимент 2: изменение текста. В этом случае также используется маркер «Эксперимент 1», но берутся нижние 50% пользователей.

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

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

Итоги эксперимента

В завершение нашего анализа и подготовки к проведению эксперимента, подведем итоги по ключевым аспектам:

1. Цель эксперимента: Мы сосредоточимся на одном эксперименте, чтобы упростить анализ и обеспечить точные результаты. В данном эксперименте мы планируем изменить цвет всех кнопок в интерфейсе приложения.

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

3. Целевое изменение: Мы ставим цель повысить среднее количество кликов по кнопке на 1%. Это небольшое, но значительное изменение поможет нам лучше понять влияние на пользовательский опыт. Если изменения превысят 1%, мы обязательно их учтем.

4. Распределение аудитории: Мы применим пропорцию 50/50 для распределения аудитории. Половина пользователей увидит новый цвет кнопок, а другая половина останется на текущем варианте. Это сбалансированное распределение поможет нам получить точные и надежные результаты.

5. Длительность эксперимента: Согласно расчетам калькулятора, мы определили, что эксперимент продлится 7 дней. Эта длительность была выбрана для достижения статистической значимости и надежности результатов.

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

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

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