Проверка гипотез: два подхода, о которых рассказали в chibbis

Из чего состоит гипотеза, которую есть смысл тестировать

Гипотеза в продукте — утверждение, которое можно опровергнуть цифрой. Рабочая формула такая: «Если мы сделаем X для сегмента Y, метрика Z изменится на N% за срок T». Без метрики и срока получается пожелание, а не эксперимент.

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

Короткий пример. Перенос выбора времени доставки с шага оплаты в корзину. Ожидание — рост конверсии корзины на 3% за две недели.

Очередь гипотез: как приоритизировать по ICE и RICE

Гипотез всегда больше, чем рук в разработке. Чаще всего их ранжируют по ICE — Impact, Confidence, Ease: влияние, уверенность и простота, каждая по шкале от 1 до 10. Метод придумал Шон Эллис, автор термина growth hacking.

В RICE, который популяризировал Intercom, добавлен охват — сколько пользователей затронет изменение за период. Он честнее для продуктов с большой аудиторией, где правка в редком сценарии выглядит важной, но касается 2% людей.

Два подхода к тестированию гипотез в сравнении

Из разговора с chibbis я вынес простую рамку. Есть путь «тестируем всё», и есть путь «копим экспертизу и тестируем только спорное». Ниже — как я вижу их различия на практике разработки.

Когда тестировать всё подряд оправдано

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

Как запускать эксперимент технически

Для мобильного приложения агрегатора тесты обычно запускают через флаги функций: Firebase Remote Config, Unleash или собственный сервис настроек. Флаг включает вариант для доли пользователей, а аналитика пишет, кто какой вариант видел.

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

Когда хватает экспертизы

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

Сколько трафика нужно для A/B-теста

Здесь чаще всего ошибаются небольшие сайты. Посчитаю на примере: базовая конверсия 3%, хотим заметить рост на 10% относительно, то есть до 3,3%. При уровне значимости 95% и мощности 80% нужно около 53 тысяч пользователей на каждый вариант.

Сайту ресторана с 5 тысячами визитов в месяц такой тест займёт почти два года. Поэтому малому проекту бессмысленно тестировать цвет кнопки: результат не наберёт значимости.

Для расчёта удобно брать калькулятор размера выборки Эвана Миллера. В России A/B-тесты на сайте делают через Varioqube от Яндекса, а Google объявил, что закроет Google Optimize в сентябре 2023 года.

Что делать малому сайту вместо A/B-теста

Смотреть записи сессий в Вебвизоре, проводить 5–7 интервью с пользователями и сравнивать периоды до и после правки. Это слабее рандомизированного теста, но честнее, чем тест, который никогда не досчитается.

Типичные ошибки при тестировании гипотез

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

• Остановить тест на третий день, увидев «значимый» рост. Это подглядывание, и оно в разы повышает шанс ложного результата.
• Менять в одном варианте сразу дизайн, текст и цену. Потом непонятно, что сработало.
• Не зафиксировать метрику успеха до старта и выбрать её задним числом.
• Тестировать меньше полной недели. В доставке еды поведение в пятницу вечером и во вторник днём отличается в разы.
• Не проверить, что трафик разделился поровну. Перекос 52 на 48 при большой выборке говорит об ошибке в разбивке, а не о победе варианта.

Что я забираю из разговора с chibbis

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

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

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