Продуктовые истории. Как на самом деле проводят A/B-тесты? Дизайн и сбор данных
Продолжаю делиться своим продуктово-аналитическим опытом. Предыдущая серия тут, а сегодня поговорим про проведение A/B-тестов, о том, какие нюансы и проблемы всплывают на практике. Пост получился огромным, поэтому в двух частях пройдёмся по всем шагам от дизайна до принятия решения по итогам, расскажу про каждый этап и что там происходит, помимо того, что вы уже могли слышать в сухой теории. Отдельно отмечу, что могу рассказывать о процессе не только как аналитик, но и как продакт, которому потом как-то нужно принимать решение.
Сама идея статьи родилась из комментария, который звучал примерно так «А расскажи, как РЕАЛЬНО проходят A/B?». Комментарий навёл меня на две мысли. Во-первых, мне встречался примерно миллион статей о теории проведения, вот эти вот все «Определить размер выборки исходя из MDE, не подглядывать, принять решение не раньше, чем время, отведенное под эксперимент…». Но почти не попадались рассказы о реальных проблемах и нюансах, всплывающих на каждом из этапов. Во-вторых, вопрос «А давай задизайним A/B-тест» почти всегда всплывает на собеседованиях на роль продуктового аналитика (пользуясь случаем напомню, что у меня есть курс, посвященный прохождению собесов). И по тому, насколько много таких вот нюансов-факапов рассказывает кандидат, можно легко понять, насколько глубоко он погружался в тему A/B-тестирования. Надеюсь, пост вам поможет подготовиться, если собираетесь на собеседование в ближайшее время! Сегодня поговорим про подготовку и проведение, про анализ и принятие решение будет в следующей части. Погнали!
Перед проведением теста неплохо бы зафиксировать, что мы вообще хотим проверить и какого результата ожидаем — какая проблема решается, какая метрика должна вырасти, чтобы показать, что мы реально чего-то достигли. В типовом сценарии 1.идея теста имеет смысл 2.метрика определена и понятна. И аналитик идёт делать расчёт длительности теста — об этом как раз хорошо написано в упомянутом выше миллионе статей. Отмечу только про размер эффекта — чтобы рассчитать длительность теста, нужно знать:
а) Исходное значение метрики (тут проблем нет, берем из исторических данных) б) Теоретический эффект — насколько наш будущий тест её двинет. Вот тут проблемы есть, так как заранее мы наверняка знать не можем, как сильно наше изменение улучшит метрику. И как быть, если хрустального шара для предсказывания будущего нет? Мы обычно поступали следующим образом — просчитывали несколько вариантов, на выходе получали таблицу вида MDE (эффект, который будет значимым на такой длительности теста) + длительность. Например:
+2% 4 недели
Помним, что чем меньше изменения, тем больше трафика (времени) нужно для их детектирования. Исходя из полученных цифр и других ограничений (например, тестов в очереди на этот же сценарий в продукте) принимали решение о том, сколько можем позволить себе крутить тест.
Но самое интересное на этом этапе происходит в обратных случаях. А когда можно вообще обойтись без A/B-теста? Отказаться от теста в следующих сценариях:
— Новая функциональность не меняет пользовательский опыт, а просто исправляет текущий и больше похожа на фикс бага. Иногда PM-ов заносит, и по инерции они предлагают гнать через A/B то, что нужно просто зарелизить на всех как можно скорее.
— Просто очень плохая идея. Если есть шанс не тестировать откровенные глупости, то стоит им воспользоваться. Слышал, что в одной компании через A/B провели идею «А давайте при загрузке приложения будет непропускаемый экран с рекламой на 15 секунд». Тест уронил все метрики, и не сказать чтобы это было совсем неожиданно и нельзя было предсказать это заранее.
— Мало трафика. Увы, случается чаще, чем хотелось бы. Даже в крупных продуктах в некоторые специфичные сценарии заходит так мало пользователей, что ждать значимой разницы между группами придётся месяцами. Сразу в прод! Ну или как вариант, провести A/B для очистки совести, просто проверить, что мы ничего (капитально) не сломали.
— Очень надо. Иногда некоторые, даже спорные штуки, нужно сразу выкатить на всех юзеров. Даже если они могут двинуть метрики не в ту сторону (и двигают!). Как общий пример — механизм промокодов, под которые запустилась рекламная кампания — было бы странно рекламу показывать всем, но давать скидку/промик только половине юзеров. Другой пример, уже из моей практики — новый движок поиска, на который был завязан старт у нашего партнёра. Даже понимая проблемы, запустились, так как партнёрская интеграция просто не была рассчитана на старый поисковый движок. Приняли волевое решение «запускаем как есть на всех, допиливаем в процессе».
После решения «делам а/б» начинается относительно спокойная для аналитика часть — разработка идёт проектировать и кодить тестовый вариант, активного участия аналитика не требуется. Из потенциальных граблей тут только логирование в тестовой группе — аналитику нужно убедится, что все аналитические события, необходимые для расчёта A/B, либо есть, либо будут запрограммированы. Очень обидно, знаете ли, крутить тест только чтобы узнать, что посчитать результаты толком нельзя. И вот, тест закожен, проверен QA на тестовой и продовой средах и готов к запуску. В нашей компании рубильник, с благославления продакт менеджера, дёргает аналитик. Хорошим тоном является (аналитику) ещё раз проверить работу контрольной и тестовой групп на себе, благо современные тулы для A/B-тестирования это позволяют. После, в первые часы теста ещё раз убедится, что группы раздаются и фиксируются пользователям. Как назло, тесты, в которых забивали на этот простой шаг, потом и оказывались с неправильным распределением трафика или какой-нибудь гадостью, типа «группы раздаются, юзеры корректно видят тест/контроль, но это информация не сохраняется в аналитических данных». Тут только всё останавливать, чинить, и перезапускать тест — потеря времени! Но обычно этап подготовки и старта теста проходит гладко. А вот дальше уже становится веселее…
Почти все, кто хоть как-то изучал тему A/B-тестирования, помнят — подглядывать в идущий тест очень плохо, это страшное преступление против статистики. Конечно же аналитики именно этим и занимаются, с первых дней теста. А что, так можно было? Да, причём по очень уважительной причине — если вдруг в тестовую группу закралась какая-то непредвиденная ошибка, которая роняет все метрики и ухудшает жизнь пользователям, то узнать о ней лучше заранее, а не через 2-3 недели после старта теста. Поэтому у аналитиков обычно есть дашборды или прям отдельные тулы для мониторинга a/b-тестов.
Окей, можно значит остановить тест, если он явным образом не работает и почти гарантировано ломает жизнь юзерам (и проблемы реально воспроизвелись). А если я заглянул в эту тулу, и увидел через 3 дня «значимый» прирост метрики, то можно остановится заранее? В классическом случае — нет, это как раз то самое подглядывание, когда случайные гуляния метрики можно принять за успех. И что, ждать отведенные две-три недели? Не обязательно, если аналитики подготовили в дополнение к классическим методам A/B тестирования что-то вроде последовательного тестирования — это как раз методика, которая с элементами магии и байесовской статистики даст ответ на вопрос «Если тестовая группа стабильно отрабатывает лучше контрольной в течение нескольких дней подряд, то можем ли быть достаточно уверены, что она реально лучше (и остановить тест уже сейчас)». Этот подход, если реализован верно, действительно позволит вам остановить тест пораньше, если эффект оказался сильно круче того, который вы ожидали. У нас, увы, почти никогда не срабатывает, приходится ждать положенной длительности.
А как ещё бывает? В одном из свежих A/B нам пришлось остановить тест уже буквально через день-два и полностью перейти на тестовую версию. Почему так? Потому что мы тестировали две версии очень высоконагруженного сервиса, но недооценили тот факт, что крутятся они на одном железе. Как итог — более хрупкая контрольная версия просто начала критично тормозить и заваливаться от нагрузки на железо. Посмотрев пару раз на часовой даунтайм в контрольной группе решили её не мучать и добить, переведя весь трафик в тестовую ветку. Помониторили пару дней, убедились, что тестовая группа на 100% трафика не выкидывает нам никаких фокусов, да и так и остались на ней — с технической точки зрения сервис в тестовой группе был однозначно лучше, в A/B мы хотели убедится, что ничего случайно не сломали + в идеале заметить положительный эффект.
На этом закончим первую часть. В продолжении пойдём в самую мякоту — анализ результатов и принятие решений!