Во времена господства data driven, компании запускают сотни тестов чтобы полагаться на данные при принятии решения, стараясь тем самым быть более осознанными. Проблема в том, что если не учитывать тонкости во время тестов, то все ваше время на них может быть потрачено зря и решения, которые вы примете, на самом деле окажутся ничем не подкреплены. Проводя собесы аналитиков к нам в команду, я выявил топ 5 упущений, которые существуют на их текущей работе или они их допускают при выполнении задания.
Почти все знают, что нужно искать статистическую значимость, но далеко не каждый рассчитывает доверительные интервалы.
Статистическая значимость означает, что результат эксперимента вероятно не связан со случайностью, указывая на то, что функция, которую вы тестируете, действительно повлияла на выбранные метрики.
Доверительный интервал дает еще больше вводных, а именно, насколько изменилась метрика и какой уровень точности этого изменения вы смогли затрекать. И пожалуйста, не используйте в интерпретациях простую разность между метриками в группах, это делает ваш анализ очень неточным, что в итоге приведет к несостыковкам в будущем.
Допустим, вы добавили новую фичу в ваше приложение, и тест показывает, что теперь им пользуется больше людей. Это звучит здорово. Но что, если доверительный интервал показывает, что в лучшем случае вовлеченность пользователей может увеличиться на 10%, а в худшем — только на 1%? В таком случае стоит ли эта фича ваших усилий?
Проверка доверительных интервалов позволяет вам взвешивать потенциальные преимущества, затраты и усилия, необходимые для реализации. Они добавят больше уверенности в то, что изменения, в которые вы инвестируете, действительно сделают разницу.
Некоторые команды игнорируют поправки на множественное тестирование, что часто приводит к неправильному принятию гипотезы — создавая ложный положительный результат.
Когда вы тестируете несколько метрик и групп, риск получения ложного положительного результата увеличивается. Например, если вы измеряете четыре группы и сравниваете их с тремя метриками, каждая группа и метрика несут 5% шанс ложного положительного результата, а для трёх экспериментальных групп вероятность ошибки первого рода будет 14.3% вместо ожидаемых 5%.
Есть разные методы, которые можно применять, чтобы уменьшить вероятность ошибки при множестве тестов:
Метод Бонферрони — это самый простой способ. Делите ваш α на количество проверок. Например, если вы проводите 4 теста, уровень значимости для каждого будет α/4.
Метод Холма — это последовательная коррекция, которая является модификацией поправки Бонферрони. Тесты сортируются по уровню значимости, и уровень значимости для самого значимого теста корректируется так же, как в поправке Бонферрони. Для следующего по значимости теста уровень значимости корректируется уже на меньшее количество тестов и так далее.
Контроль FDR (False Discovery Rate) — вместо того чтобы контролировать вероятность хотя бы одной ошибки первого рода, вы контролируете ожидаемую долю ошибочно отвергнутых гипотез, например через Метод Бенджамини — Хохберга.
Планируйте эксперименты — вместо проверки множества гипотез одновременно, можно планировать эксперименты так, чтобы проверять только одну или небольшое количество гипотез за раз.
Обычно команды делятся на 2 типа: те, кто выбирают очень верхнеуровневые метрики (оборот, количество ставок, конверсия в активацию) и те, кто выбирают очень низкоуровневые (CTR, время сессии, вовлеченность в фичи). Правильный подход — комбинация этих метрик. Для того чтобы понять как тестируемое изменение влияет на пользователей, лучше сперва анализировать низкоуровневые метрики, но затем не забудьте проверить как в целом это влияет на продукт и стоило ли это того.
Например, e-commerce тестирует новую, более заметную кнопку «Добавить в корзину», чтобы увеличить покупки. Хотя основная метрика (CTR) значительно улучшается, второстепенные метрики показывают другую историю: более высокий уровень брошенных корзин и снижение среднего времени сессии. В итоге, больше пользователей нажимают на кнопку, меньше совершают покупку, а общая вовлеченность на сайте снижается.
Сегментация в A/B тестах гарантирует, что вы понимаете, как изменения влияют на конкретные типы пользователей, а не просто смотрите на средний эффект для всех .
Многие считают сегментацию в тестах сложной и времязатратной, особенно при ограниченных ресурсах. Кроме того, существует тенденция сосредоточиваться на более широких результатах теста, ища общие выводы, применимые ко всей базе пользователей.
Разные сегменты могут реагировать по-разному на одно и то же изменение: то, что работает для одной группы, может не работать для другой.
Представьте, что вы в команде продукта онлайн стриминга, и проводите A/B тест новой фичи, которая рекомендует фильмы на основе истории просмотров. Сегментируя пользователей, ваша команда узнает, что, хотя функция популярна среди молодых людей, она менее эффективна для пользователей старше 50 лет. Может вам тогда внедрить ее только для молодежи?
Возможно, но вам может потребоваться больше данных для уверенности. Чтобы избежать ложных положительных результатов, вам следует повторно провести эксперимент, нацеленный на молодых людей, чтобы проверить, действительно ли вы нашли положительное влияние на метрики.
Если полноценная сегментация невозможна, как минимум, сравните свои результаты с вашим наиболее важным сегментом пользователей. Спросите себя: действительно ли результаты этого теста точно отражают ваших наиболее важных пользователей? Такой подход дает представление о том, насколько хорошо ваш тест соответствует потребностям основной аудитории.
Каждый A/B тест представляет ценность как оптимизация вашего продукта, но также представляет собой урок.
Правильная документация позволит создать базу знаний, на основании которой могут учиться ваши команды. Таким образом, участники команд могут понять, что сработало, а что нет и почему.
Представьте, что данные о поведении пользователей — это сырое кофейное зерно. A/B тесты — это уже обжаренный кофе с описанной технологией как его обжарить. Из него вы либо можете сразу приготовить хороший кофе или увидеть тонкости в технологии обжарки, которые позволят обжарить кофе в следующий раз еще вкуснее :)
Так что заведите notion, confluence или хотя бы гугл табличку куда будете записывать:
Гипотеза: Если ... , то ...
Как выглядит опыт пользователей
На каких пользователях тестируем
Ключевые метрики
Ожидаемый эффект
Был ли тест стат значимый
Результаты теста с доверительными интервалами
Если у вас много команд, то вы удивитесь насколько это окажется полезной штукой, когда вы вновь соберетесь генерить гипотезы.
Подписывайтесь на мой телеграм канал, где рассказываю про развитие продуктов и аналитику, а также добавляйте статью в избранное!
Мы активно расширяемся, поэтому нам нужны продуктовые аналитики! Если ты фанат данных, хочешь быть самым полезным в команде и жаждешь результата, то artem.moiseenkov@ligastavok.ru или присылай резюме через hh.