«Серёга, диктуй код из смс»: как мы ускорили проверку гипотезы с помощью эксперимента

Привет! Меня зовут Алина Бузинова, я менеджер продукта Отелло , сервиса бронирования отелей от 2ГИС.

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

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

От запроса — к созданию продукта

Многие из 70 миллионов пользователей 2ГИС ищут объекты в рубрике «Гостиницы». Ранее в карточке компании можно было за один шаг перейти к бронированию, но после ухода Booking и Airbnb путь пользователя стал менее удобным. Мы понимали, что привычный сценарий перестал работать, а потребность осталась. Так в 2022 появилась идея, а через три месяца и сам продукт — Отелло.

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

Тогда мы решили определить, что станет ключевой метрикой и поможет оценить результат изменений. Так мы сосредоточились на NSM — конверсии в прожитую бронь, и перешли к генерации гипотез.

Генерация идей для роста NSM

Конверсия в прожитую бронь — это показатель, определяющий долю пользователей, которые пришли в сервис, успешно прошли все шаги в сценарии бронирования, заехали в отель и прожили свою бронь.

На основе аналитики 2ГИС и Отелло мы знали, что текущая конверсия в прожитую бронь значительно уступает целевой, и мы можем кратно её увеличить, просто пока не знаем как. По итогу этапа генерации идей:

• Сформулировали более 20 гипотез, в которые верим.
• Приоритизировали их, используя RISE и сердечко, конечно:)
• Решили, что на проверку каждой из них хотим выделять на разработку не более трёх дней, а для больших интеграционных — не более 14.
• Запланировали сезон экспериментов.

Фичи, от которых мы ожидали максимального эффекта, требовали значительных затрат. Например, из топ-20 гипотез мы выбрали «Добавить новый способ оплаты: оплата на месте». Ранее в Отелло можно было бронировать отели только с предварительной оплатой. Фича потенциально могла удвоить конверсию в бронь, но разработку оценили в шесть месяцев. Сразу возникло много вопросов:

• Как убедиться во влиянии фичи сейчас, а не через полгода?
• Может эффективнее доставлять итерационно много небольших улучшений, чем одну, но через шесть месяцев?
• Не станет ли фича ещё дороже в процессе разработки?
• И главное: можем ли мы дешёво проверить гипотезу?

Цель есть, осталось найти путь. Так мы решили провести эксперимент: реализовать бесшовный e2e-сценарий для пользователя на бою с ограничением в сроках реализации — две недели для проверки гипотезы.

Разобрали сценарий пользователя до мелочей, определили самые дорогие в разработке части, подключили саппорт, описали сценарий ручной поддержки — и уложились в сроки!

Запускаем эксперимент

Путь пользователя, который хочет забронировать отель, выглядит так: человек заходит в сервис онлайн-бронирования, выбирает отель и способ оплаты, нажимает кнопку «Забронировать». Пользователь оплачивает бронирование, деньги списываются, бронь подтверждается и приходит ваучер. Взаимодействие с сервисом завершилось. В случае оплаты в отеле нам необходимо зарезервировать номер и сформировать бронь без фактической оплаты от пользователя.

Для достоверности эксперимента, нам было важно, чтобы со стороны пользователя сценарий был максимально простым и приближен к целевому. Так его результаты будут наиболее достоверны.

В то же время «под капотом» происходило следующее:

Для начала в выбранных для эксперимента городах мы продублировали все тарифы с новым вариантом «оплата на месте». Эти тарифы существовали только в нашем сервисе, мы не забирали их напрямую от отеля.

Пользователь оформлял по сути несуществующий тариф на сайте, не оплачивая его. После нажатия кнопки «Забронировать» пользователю приходило уведомление о том, что скоро мы отправим ему ваучер на почту. В это время наша поддержка получала сообщение, что у нас есть участник эксперимента, который ждёт свою бронь.

И её срочно нужно создать!

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

Бронирование готово, есть ваучер! Но! Там указано, что бронь оплачена по карте… Мы убирали эту информацию и только тогда отправляли ваучер пользователю. 90% действий для бронирования с оплатой на месте саппорт делал вручную.

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

В итоге получилось, что пользователь успешно бронировал отель со способом оплаты, которого на самом деле не было.

За две недели мы подготовили инфраструктуру для проведения эксперимента, настроили алерты саппорту, написали инструкции, скоординировали действия всех людей, запаслись тремя цифрами от банковской карты директора. И успешно завершили эксперимент.

Подводим итоги эксперимента

Мы провели эксперимент сначала в Новосибирске, позже в Москве. Результаты впечатляли! До начала эксперимента у нас были единичные брони, с момента запуска эксперимента их число начало стабильно расти. Мы также заметили небольшую каннибализацию — некоторые пользователи, которые раньше выбирали оплату картой, начали предпочитать оплату на месте. Новый тариф стал удобнее и для них.

Конверсия в бронирование возросла на 157%, а совокупный объем выручки (GMV) увеличился на 131%. Это значительно превзошло наши ожидания! И приняли однозначное решение — фичу делаем!

Сайд-эффект проведённого эксперимента: мы сократили срок разработки честной боевой версии фичи с 6 до 2,5 месяцев.

Можно подумать, что мы ошиблись в оценках, но это не так. Мы сфокусировались на доставке конкретной функции — оплаты на месте. В ходе эксперимента мы не обращали внимания на мелкие недоработки, быстро решали возникающие вопросы, были вовлечены сразу все — и бизнес, и КАМы, бэкенд и фронтенд, дизайнеры и аналитики. Такой подход и результаты эксперимента позволили снизить уровень неопределенности для команды практически до нуля и обеспечили четкий план действий, чтобы у пользователя был идеальный сценарий использования продукта.

В каких случаях эксперимент – хорошая идея?

Если перед вами встал вопрос — стоит ли реализовывать ту или иную идею, при этом ресурсы ограничены, нет возможности сделать честный АБ-тест, то эксперимент — вполне рабочая история.

Я выделяю три «проблемы», когда эксперимент однозначно поможет:

1. Невысокая степень уверенности во влиянии гипотезы на результаты. То есть неясно, стоит ли выделять ресурсы на разработку.
2. Дорогая стоимость разработки функциональности. Это подкрепляет неуверенность из первого пункта.
3. Нужна приоритизация задач в бэклоге. Если идей много, ресурсов мало, нужно выбрать с чего начать.

Также необходимо придерживаться важных принципов:

1. Выбрать конкретную метрику, на которую хотим повлиять. В нашем случае это конверсия в прожитую бронь.
2. Допустить, что всё делается на выброс. Мы держали это в голове, когда пытались идеализировать путь клиента или техническое решение.
3. Определить самые дорогие участки. Для нас это были интеграционные участки, изменение шага с выбором способа оплаты.
4. Если дешевле руками, делать руками. Дорогие участки мы либо скоупили, либо делали руками. Максимально все, что можно, переносили на техподдержку.
5. Не бояться ухудшить опыт. Я не о том, что мы создаём негативный опыт. Наша цель — обеспечить клиенту опыт, максимально приближенный к тому, что он получит в продукте при целевой реализации. Однако мы не боимся, что он будет неидеальным во время эксперимента.
6. Эксперимент — это не бесплатно. Две недели — значительное количество стори-поинтов, что также требует ресурсов компании.
7. Всегда есть этап сбора данных и выводы. Перед и после эксперимента обязательно анализируем результаты. Должны быть определены метрики. Вся команда, включая разработчиков, должна четко понимать текущую ситуацию, проблему, которую мы решаем, и ожидаемый результат. Важно, чтобы все это было задокументировано.

И самое важное в таких экспериментах: ресурсы и время неизменны, а скоуп – можно резать. Как бы не хотелось добавить «ещё пару дней», не делайте этого, режьте скоуп. Удачный опыт проведения эксперимента в таком виде позволяет нам не откладывать «навечно» большие и сложные фичи, а проводить эксперименты и своевременно принимать решение брать или не брать задачу в работу.

И если у вас возник вопрос «Как не выгореть за две недели?», то ответ простой — доставлять эффективные и полезные фичи. Удовольствие от роста целевых метрик заряжает покруче отпуска!

Если у вас остались вопросы, пишите в комментарии — буду рада ответить.

Откликается наш подход? Заглядывайте в вакансии продактов и будете вместе с нами работать над сервисами, которыми пользуются десятки миллионов пользователей.