Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Что написать на кнопке: “с вас тысяча рублей” или “подайте на хлебушек”? Влияют ли мемасы на продажу платных сервисов? Какую таблетку пользователи предпочитают чаще – красную или синюю? А если предложить им зелёную, то поползут ли метрики вверх? На эти вопросы можно получить ответ, если проводить А/В-эксперименты и growth hack-сессии.
Меня зовут Денис, я бэкенд-разработчик в hh.ru. Эта статья о том, как мы проводим и анализируем различные эксперименты. Дам немного теории, слегка обрисую внутреннюю кухню и расскажу с какими проблемами могут столкнуться команды, которые только внедряют у себя А/В-эксперименты.
А и B сидели на проде
Для начала поговорим о том, кто вообще такие эти А/В-тесты и для чего они нужны.
Идея А/В-тестов предельно проста – пользователи приложения или сайта делятся на две группы или больше. Группа А – контрольная, пользователи этой группы видят приложение или сайт без изменений, as it is. Группа B и остальные, если они есть – экспериментальные. Пользователи из этих групп видят сайт или приложение в несколько измененном виде: с дополнительной функциональностью, измененным дизайном или иначе работающими компонентами.
Короче говоря, в одно и то же время разные группы пользователей видят приложение или сайт по-разному.
Зачем нужны A/B-тесты?
А нужны они вот зачем. При разработке продукта необходимо, чтобы изменения не приводили к ухудшению пользовательского опыта или оттоку пользователей, а наоборот – UX улучшался, пользователям становилось хорошо и их количество возрастало. Если же выпускать изменения без оглядки на реакцию пользователей, руководствуясь лишь своим “чутьем”, то возникает большой риск не заметить что-то, из-за чего пользователям стало хуже. Откатывать неудачные изменения сложно и дорого, гораздо проще провести эксперимент, который можно просто выключить в случае провала.
Метрики или что компании знают о пользователях
Обычно, когда компании приходят к идее А/В-экспериментов, они уже что-то анализируют: собирают метрики, по которым ориентируются на реакцию пользователей. Это может быть время, проведенное на сайте, количество кликов, средний чек покупки etc. Соответственно, когда вы планируете будущий эксперимент, необходимо заранее определиться с метриками, на которые ваш эксперимент должен повлиять. Например, при тестировании различных моделей поиска в hh.ru, одной из ключевых метрик может быть количество откликов соискателей на вакансии из выдачи. А если мы говорим про эксперименты в области монетизации и прайс-листа, то ключевыми метриками станут конверсия покупок или средний чек.
Когда начинать собирать результаты?
После того, как метрики определены, пользователи разбиты на группы и эксперимент запущен, остается дождаться “вызревания” эксперимента – когда придёт нужное число пользователей, чтобы мы смогли анализировать результат. Пример определения такого числа пользователей можно посмотреть в калькуляторе Эвана Миллера. Затем можно интерпретировать результат.
А может сразу на всех раскатить?
Но почему бы не выкатить изменения сразу на всех пользователей? Ведь потом можно просто сравнить метрики после изменений со старыми метриками. Не совсем так. Важную роль играет сезонность: показатели откликов, числа покупок и среднего чека, могут меняться не только от сезона к сезону, но и различаться в рамках недели. И отследить, связаны ли изменения в исследуемых метриках с новой функциональностью или же сезонностью бывает довольно сложно.
Гроусхачим на всю котлету
Говоря про А/B тесты нельзя не затронуть тему гроусхаков.
Гроусхаки – это такие незначительные изменения в дизайне или функциональности, которые могут привести к значительному росту метрик. Отсюда название “growth hack” – сломали привычную систему роста. Из примеров: смена кнопки “положить в корзину” или изменение ее расположения на сайте может привести к значительному росту конверсий покупок. Но может и не привести. Чтобы проверить, к чему в итоге приведут изменения, отлично подходят А/В-эксперименты.
Но не каждый гроусхак в итоге можно провести через А/В. Например, он может быть чересчур экспериментальным, и мы не хотим раскатывать такую функциональность на большое число пользователей. Или становится понятно, что эксперимент придется держать месяц, что в корне не соответствует концепции быстрой проверки. В таком случае можно отойти от А/В-метода в сторону глубинных интервью с пользователями.
В названии “Growth hack” два слова, и “hack” здесь далеко не случайно. Ведь для создания гроусхаков вводятся особые правила. Часто что-то пилится прямо на коленке: в виде развилок в коде if-else, делается упрощенный code review для ускорения вывода на прод. Самое главное, чтобы такие хаки могли моментально выпилиться из кода и не отравляли кодовую базу.
В hh.ru мы часто проводим так называемые “гроусхак-сессии”: продакт, проджект и несколько разработчиков собираются в одной комнатушке и генерируют массу разных гипотез. Какие-то отметаются сразу, какие-то требуют большого количества ресурсов, но есть и те, которые могут принести существенную пользу. Такие сессии могут помочь вам получить множество инсайтов о вашем продукте и аудитории, так что настоятельно рекомендую попробовать.
Теперь на практике
Т.к. я сам из команды “Монетизация”, то и наши эксперименты так или иначе будут связаны с прайс-листом и предоставляемыми услугами. Процесс создания новой услуги, продаваемой на сайте, не прост. Необходимо завести новый код услуги, добавить логику обработки в биллинге, согласовать формулировки закрывающих документов с юристами, сверстать и закодить основную логику. Необходимость всех этих действий сильно замедляет и усложняет процесс вывода новой функциональности. Тратится время и ресурсы команды, притом заранее никогда неизвестно, будет ли востребована новая услуга или все усилия окажутся напрасными. Чтобы предотвратить напрасную трату ресурсов, можно прибегнуть к А/В-тестам и протестировать услугу в несколько упрощенном виде.
Сформулируем гипотезу
Одна из предоставляемых нами услуг – это доступ работодателей к базе кандидатов. Клиенты бывают разные: крупные компании, где найм ведётся 365 дней в году 24/7, и совсем небольшие, которым новый сотрудник нужен раз в пятилетку. И кажется логичным дать последним возможность просмотра контактов поштучно, небольшими пакетами по 1-10 штук. Но внедрить такую услугу – довольно большая задача, которая потребует участия множества людей из самых разных сфер: начиная от разработки с QA и заканчивая маркетингом с юристами. Поэтому надо провести небольшой эксперимент, который позволит понять, а стоит ли овчинка выделки.
Заводим эксперимент в ABT
Итак, мы сформулировали гипотезу. Теперь для нее нужно завести эксперимент. Для этого существует большое количество различных инструментов, например, Google optimise, AB Tasty, Firebase, которые позволяют создавать эксперименты и интерпретировать результат. Каждый из них обладает своими преимуществами, недостатками и ограничениями. Мы в hh.ru используем свой сервис для проведения А/В-тестов – hhABT. Он позволяет проводить эксперименты, добавлять какие-то метрики и интерпретировать результаты. Более подробно про нашу ABT-платформу расскажем в отдельной статье.
А что дальше?
А дальше нужно писать код. Создавать новую услугу с нуля – это слишком большая задача, поэтому поштучные доступы мы реализовывали на уже существующей функциональности. Мы умеем ограничивать длительность доступа и число просмотров контактов, поэтому просто завели две новые конфигурации существующих услуг: доступ на 10 дней с одним просмотром и доступ на 30 дней с десятью просмотрами. После этого выделяем эти конфигурации на нашем UI, где продаем эти услуги.
Делаем акцент на числе просмотров, раскрашиваем баннерами, чтобы привлечь внимание.
И всё, что нам остается сделать – это включить эксперимент и дождаться сбора метрик.
Результаты эксперимента
Прошло несколько недель, мы собрали результаты. И благодаря им поняли, что в таком виде добавлять новую услугу не стоит. Возможно, если изменим конфигурацию, целевую аудиторию и стоимость, у нас получится что-то полезное. Но, так или иначе, мы сэкономили кучу времени и получили новые знания о нашем продукте.
Подытожим
Давайте подведем итоги:
А/В-эксперименты позволяют определить, куда двигаться вашему продукту дальше. Какие фичи вызывают у пользователей экстаз, а от каких они уходят в отказ.
Гроусхаки – полезные штуки, которые позволяют быстро получить инсайты о вашей аудитории, а также могут резко и быстро повысить или понизить метрики.
Есть множество платформ, которые позволяют вам проводить А/В-эксперименты. Мы, например, написали свою. Возможно, в вашем случае дешевле будет использовать готовую.
Вот так мы и проводим в А/В-тесты в hh.ru. Расскажите о своем опыте и задавайте любые вопросы, я буду рад на них ответить.
