Привет! Меня зовут Алина Бузинова, я менеджер продукта Отелло, сервиса бронирования отелей от 2ГИС.
Для молодого продукта на конкурентном рынке часто важна скорость доставки полезных решений. Планировать шестимесячную разработку и не получать ожидаемого профита — непозволительная роскошь. Так, после генерации идей, направленных на поиск решений для роста конверсий продукта, мы решили, что готовы выделить на проверку каждой из гипотез не более трёх дней, а на дорогие интеграционные — максимум две недели.
В статье расскажу о том, как нам удалось за две недели реализовать пользовательский сценарий, разработка которого оценивалась в полгода. И каких принципов можете придерживаться вы, чтобы применить такой подход в своём продукте.
От запроса — к созданию продукта
Многие из 70 миллионов пользователей 2ГИС ищут объекты в рубрике «Гостиницы». Ранее в карточке компании можно было за один шаг перейти к бронированию, но после ухода Booking и Airbnb путь пользователя стал менее удобным. Мы понимали, что привычный сценарий перестал работать, а потребность осталась. Так в 2022 появилась идея, а через три месяца и сам продукт — Отелло.
И вот мы оказались в точке, когда минимально достаточный функционал доставлен, а конверсии на разных шагах далеки от идеала. Идей много, вопросов ещё больше — нужно всё систематизировать, оценить и понять, что нам позволит кратно расти дальше.
Тогда мы решили определить, что станет ключевой метрикой и поможет оценить результат изменений. Так мы сосредоточились на NSM — конверсии в прожитую бронь, и перешли к генерации гипотез.
Генерация идей для роста NSM
Конверсия в прожитую бронь — это показатель, определяющий долю пользователей, которые пришли в сервис, успешно прошли все шаги в сценарии бронирования, заехали в отель и прожили свою бронь.
На основе аналитики 2ГИС и Отелло мы знали, что текущая конверсия в прожитую бронь значительно уступает целевой, и мы можем кратно её увеличить, просто пока не знаем как. По итогу этапа генерации идей:
Сформулировали более 20 гипотез, в которые верим.
Приоритизировали их, используя RISE и сердечко, конечно:)
Решили, что на проверку каждой из них хотим выделять на разработку не более трёх дней, а для больших интеграционных — не более 14.
Запланировали сезон экспериментов.
Фичи, от которых мы ожидали максимального эффекта, требовали значительных затрат. Например, из топ-20 гипотез мы выбрали «Добавить новый способ оплаты: оплата на месте». Ранее в Отелло можно было бронировать отели только с предварительной оплатой. Фича потенциально могла удвоить конверсию в бронь, но разработку оценили в шесть месяцев. Сразу возникло много вопросов:
Как убедиться во влиянии фичи сейчас, а не через полгода?
Может эффективнее доставлять итерационно много небольших улучшений, чем одну, но через шесть месяцев?
Не станет ли фича ещё дороже в процессе разработки?
И главное: можем ли мы дешёво проверить гипотезу?
Цель есть, осталось найти путь. Так мы решили провести эксперимент: реализовать бесшовный e2e-сценарий для пользователя на бою с ограничением в сроках реализации — две недели для проверки гипотезы.
Разобрали сценарий пользователя до мелочей, определили самые дорогие в разработке части, подключили саппорт, описали сценарий ручной поддержки — и уложились в сроки!
Запускаем эксперимент
Путь пользователя, который хочет забронировать отель, выглядит так: человек заходит в сервис онлайн-бронирования, выбирает отель и способ оплаты, нажимает кнопку «Забронировать». Пользователь оплачивает бронирование, деньги списываются, бронь подтверждается и приходит ваучер. Взаимодействие с сервисом завершилось. В случае оплаты в отеле нам необходимо зарезервировать номер и сформировать бронь без фактической оплаты от пользователя.
Для достоверности эксперимента, нам было важно, чтобы со стороны пользователя сценарий был максимально простым и приближен к целевому. Так его результаты будут наиболее достоверны.
В то же время «под капотом» происходило следующее:
Для начала в выбранных для эксперимента городах мы продублировали все тарифы с новым вариантом «оплата на месте». Эти тарифы существовали только в нашем сервисе, мы не забирали их напрямую от отеля.
Пользователь оформлял по сути несуществующий тариф на сайте, не оплачивая его. После нажатия кнопки «Забронировать» пользователю приходило уведомление о том, что скоро мы отправим ему ваучер на почту. В это время наша поддержка получала сообщение, что у нас есть участник эксперимента, который ждёт свою бронь.
И её срочно нужно создать!
Сотрудник поддержки оформлял бронирование за пользователя по предоставленным данным. Так как фактически тарифа с оплатой в отеле в сервисе нет, чтобы создать бронирование — его нужно было оплатить. Периодически приходилось будить нашего директора в ночи с просьбой: «Серёга, продиктуй код из смс». Скорость поддержки напрямую влияла на успех эксперимента, так как во время обработки запроса могла измениться стоимость, а номера могли перестать быть доступными. Такие кейсы случались, поэтому на помощь также приходила команда бизнеса, которая согласовывала с отельерами изменения и рассказывала про наш эксперимент.
Бронирование готово, есть ваучер! Но! Там указано, что бронь оплачена по карте… Мы убирали эту информацию и только тогда отправляли ваучер пользователю. 90% действий для бронирования с оплатой на месте саппорт делал вручную.
Дальше мы связывались с отелем, проверяли, что бронь есть, рассказывали, что сейчас проводим эксперимент с новым способом оплаты на месте и договаривались, чтобы отель взял плату с гостя, когда тот приедет заселяться. Некоторые отели соглашались сразу, понимая, что эта возможность популярна и эксперимент направлен на увеличение числа бронирований, другие требовали больше времени. Но итог один — мы всегда находили решение, бронирование подтверждали, и гости заселялись.
В итоге получилось, что пользователь успешно бронировал отель со способом оплаты, которого на самом деле не было.
За две недели мы подготовили инфраструктуру для проведения эксперимента, настроили алерты саппорту, написали инс��рукции, скоординировали действия всех людей, запаслись тремя цифрами от банковской карты директора. И успешно завершили эксперимент.
Подводим итоги эксперимента
Мы провели эксперимент сначала в Новосибирске, позже в Москве. Результаты впечатляли! До начала эксперимента у нас были единичные брони, с момента запуска эксперимента их число начало стабильно расти. Мы также заметили небольшую каннибализацию — некоторые пользователи, которые раньше выбирали оплату картой, начали предпочитать оплату на месте. Новый тариф стал удобнее и для них.
Конверсия в бронирование возросла на 157%, а совокупный объем выручки (GMV) увеличился на 131%. Это значительно превзошло наши ожидания! И приняли однозначное решение — фичу делаем!
Сайд-эффект проведённого эксперимента: мы сократили срок разработки честной боевой версии фичи с 6 до 2,5 месяцев.
Можно подумать, что мы ошиблись в оценках, но это не так. Мы сфокусировались на доставке конкретной функции — оплаты на месте. В ходе эксперимента мы не обращали внимания на мелкие недоработки, быстро решали возникающие вопросы, были вовлечены сразу все — и бизнес, и КАМы, бэкенд и фронтенд, дизайнеры и аналитики. Такой подход и результаты эксперимента позволили снизить уровень неопределенности для команды практически до нуля и обеспечили четкий план дейст��ий, чтобы у пользователя был идеальный сценарий использования продукта.
В каких случаях эксперимент – хорошая идея?
Если перед вами встал вопрос — стоит ли реализовывать ту или иную идею, при этом ресурсы ограничены, нет возможности сделать честный АБ-тест, то эксперимент — вполне рабочая история.
Я выделяю три «проблемы», когда эксперимент однозначно поможет:
Невысокая степень уверенности во влиянии гипотезы на результаты. То есть неясно, стоит ли выделять ресурсы на разработку.
Дорогая стоимость разработки функциональности. Это подкрепляет неуверенность из первого пункта.
Нужна приоритизация задач в бэклоге. Если идей много, ресурсов мало, нужно выбрать с чего начать.
Также необходимо придерживаться важных принципов:
Выбрать конкретную метрику, на которую хотим повлиять. В нашем случае это конверсия в прожитую бронь.
Допустить, что всё делается на выброс. Мы держали это в голове, когда пытались идеализировать путь клиента или техническое решение.
Определить самые дорогие участки. Для нас это были интеграционные участки, изменение шага с выбором способа оплаты.
Если дешевле руками, делать руками. Дорогие участки мы либо скоупили, либо делали руками. Максимально все, что можно, переносили на техподдержку.
Не бояться ухудшить опыт. Я не о том, что мы создаём негативный опыт. Наша цель — обеспечить клиенту опыт, максимально приближенный к тому, что он получит в продукте при целевой реализации. Однако мы не боимся, что он будет неидеальным во время эксперимента.
Эксперимент — это не бесплатно. Две недели — значительное количество стори-поинтов, что также требует ресурсов компании.
Всегда есть этап сбора данных и выводы. Перед и после эксперимента обязательно анализируем результаты. Должны быть определены метрики. Вся команда, включая разработчиков, должна четко понимать текущую ситуацию, проблему, которую мы решаем, и ожидаемый результат. Важно, чтобы все это было задокументировано.
И самое важное в таких экспериментах: ресурсы и время неизменны, а скоуп – можно резать. Как бы не хотелось добавить «ещё пару дней», не делайте этого, режьте скоуп. Удачный опыт проведения эксперимента в таком виде позволяет нам не откладывать «навечно» большие и сложные фичи, а проводить эксперименты и своевременно принимать решение брать или не брать задачу в работу.
И если у вас возник вопрос «Как не выгореть за две недели?», то ответ простой — доставлять эффективные и полезные фичи. Удовольствие от роста целевых метрик заряжает покруче отпуска!
Если у вас остались вопросы, пишите в комментарии — буду рада ответить.
Откликается наш подход? Заглядывайте в вакансии продактов и будете вместе с нами работать над сервисами, которыми пользуются десятки миллионов пользователей.
