Как правильно оценивать продуктовые изменения? Да-да, любое продуктовое изменение, связано оно с почтой или нет. Другой цвет кнопок в письмах, обновлённый дизайн формы поиска, новая платная услуга – как убедиться, что действительно стало лучше, а не говорить себе "вроде бы сработало"?
В различных проектах мне неоднократно приходилось сталкиваться с ситуациями, когда у продакт менеджера появлялась понятная и простая идея, такая, про которую все говорили - “как же мы не догадались раньше!”. Например, слать уведомления о новых сообщениях вдвое чаще для того, чтобы увеличить число сессий на сайте и число отправленных сообщений.
Такое изменение внедрялось, целевая метрика заметно росла, однако через несколько месяцев фичу отменяли. Почему отменяли? Потому что слишком часто приходящие емейлы через какое-то время “доставали” пользователей, в результате чего они выключали емейл-уведомления, бывшие основным каналом поддержания активности, после чего происходило массовое отмирание аккаунтов.
Поэтому
я уверен, что A/B тестирование – единственный работающий подход, позволяющий получить достоверные результаты, а не искать выход на ощупь.
Что же такое A/B тестирование и как его делать правильно? Думаю, вы это и так знаете, но на всякий случай я дам ссылку на
статью в википедии и расскажу в паре предложений сам. Итак, A/B тест – это когда вы тестируете два варианта страницы, фичи (старый и новый), или сам факт наличия фичи (нет или есть) на двух группах людей. Тут есть два важных момента:
- группы должны быть однородными (например, в обеих только парни из Москвы);
- каждый пользователь должен на протяжении всего теста видеть только один вариант из двух.
Как только вы разделили людей таким образом и собрали данные об их активности/конверсии и т.п., у вас достаточно сведений, чтобы понять, даёт ли предлагаемое изменение позитивные результат.
Что такое A/B тест мы разобрались, теперь надо понять, как правильно его выполнить.
Любое крупное изменение, даже самое очевидное, достойно тестирования
В эту пользу говорит несколько аргументов. Часто бывает так, что тест проводится в виде “включим его только в такой-то стране/городе, а если там всё будет хорошо, то включим везде”. Так поступать нельзя, потому что:
- Во время тестирования в этой стране была очень плохая погода, поэтому люди сидели дома и проводили больше времени на сайте (внимание, это пример из реальной жизни!) - а вы посчитаете, что тест удачный.
В случае, если бы вы проводили A/B тест, то вы бы наблюдали действительную картину, сравнивая 2 группы людей в плохой погоде, а не группу людей в хорошую погоду и группу людей в плохую.
- Получив хорошие результаты в стране А вы не имеете никакой гарантии, что в целом по всему проекту это изменение также даст положительный эффект. Правильным было бы провести тест на 5-50% (в зависимости от ваших ожиданий об успешности теста) от всех пользователей.
Пример из реальной жизни: люди из западных стран, особенно UK и US, неохотно пользуются фичами рассылки инвайтов, в то время как в Восточной Европе и Латинской Америке это прекрасно работает. В результате, проведя тест только в UK и US, можно отказаться от фичи, которая прекрасно сработает в других странах.
Следует смотреть не только на показатели, относящиеся непосредственно к изменяемой фиче, но и на все базовые метрики в целом
Другая ошибка, допущенная в описанном в начале этого раздела случае (учащение отправки уведомлений о сообщениях) заключается в том, что по результатам изменения смотрели исключительно на метрики чата, который пытались оптимизировать, но совсем не обратили внимание на процент юзеров, возвращающихся на сайт спустя неделю/месяц после регистрации. Очевидно, что правильным было бы рассматривать все базовые метрики, чтобы убедиться, что никакая из них заметно не просела, в то время как целевые показатели улучшились.
Такое вот категоричное мнение у меня сложилось. Может быть у вас другой опыт? Есть что сказать – пишите в комментариях.
