110. Сервис по выбору ресторанов Битком 24: сколько вариантов ресторанов показать
Изначальная идея сервиса по выбору ресторанов состояла в том, что пользователь после запуска приложения отвечает на несколько вопросов про конкретную ситуацию и получает список нескольких самых подходящих ресторанов. Сами вопросы касаются цели посещения, предпочитаемая кухня, состав соучастников, располагаемое время и пр. Кроме того, приложение учитывает геопозицию и подбирает лучший ресторан.
Но возник вопрос: сколько ресторанов показывать пользователю? Один, три, пять, бесконечный отранжированный список.
Можно провести серию A/B-тестов и выбрать наиболее конверсионный вариант. Осталось только определить конверсию во что мы принимаем как основную метрику A/B-теста.
Запустив самую первую версию приложения мы получили метрику среднего времени одной сессии — 15 секунд. Этого времени как раз хватало на то, чтобы ответить на вопросы и получить предложение от сервиса. Но дошел ли пользователь до ресторана или нет — остается непонятно. Даже непонятно, удовлетворило ли его наше предложение ресторана. Таким образом понять успех A/B-теста будет непросто и ответить на вопрос о количестве предлагаемых ресторанов мы вряд ли сможем.
Ответ был найден. Начав взаимодействие с компанией, оказывающей услуги индивидуализации и кастомизации продукта под конкретного пользователя, мы получили ответ: показывать нужно столько вариантов, сколько нужно каждому конкретному пользователю. Если пользователю удобно видеть один вариант — показываем один вариант. Если три — показываем три. И так далее...
На момент работы над проектом мы могли это реализовать через настройки интерфейса. Простоый выбор: «Количество вариантов в рекомендательной выдаче» и пользователь указывает предпочитаемое количество. Обучить пользоваться этой функцией можно через онбординг. Сейчас это реализуется через ИИ-механики и рекомендательные системы.
В сухом остатке: на некоторые вопросы пользовательского опыта не бывает однозначных ответов и универсальных ответов, подходящих всем; лучше адаптировать продукт под пользователя, если это возможно.
#кейс #кастомизация #онбординг@custdevlab
Изначальная идея сервиса по выбору ресторанов состояла в том, что пользователь после запуска приложения отвечает на несколько вопросов про конкретную ситуацию и получает список нескольких самых подходящих ресторанов. Сами вопросы касаются цели посещения, предпочитаемая кухня, состав соучастников, располагаемое время и пр. Кроме того, приложение учитывает геопозицию и подбирает лучший ресторан.
Но возник вопрос: сколько ресторанов показывать пользователю? Один, три, пять, бесконечный отранжированный список.
Можно провести серию A/B-тестов и выбрать наиболее конверсионный вариант. Осталось только определить конверсию во что мы принимаем как основную метрику A/B-теста.
Запустив самую первую версию приложения мы получили метрику среднего времени одной сессии — 15 секунд. Этого времени как раз хватало на то, чтобы ответить на вопросы и получить предложение от сервиса. Но дошел ли пользователь до ресторана или нет — остается непонятно. Даже непонятно, удовлетворило ли его наше предложение ресторана. Таким образом понять успех A/B-теста будет непросто и ответить на вопрос о количестве предлагаемых ресторанов мы вряд ли сможем.
Ответ был найден. Начав взаимодействие с компанией, оказывающей услуги индивидуализации и кастомизации продукта под конкретного пользователя, мы получили ответ: показывать нужно столько вариантов, сколько нужно каждому конкретному пользователю. Если пользователю удобно видеть один вариант — показываем один вариант. Если три — показываем три. И так далее...
На момент работы над проектом мы могли это реализовать через настройки интерфейса. Простоый выбор: «Количество вариантов в рекомендательной выдаче» и пользователь указывает предпочитаемое количество. Обучить пользоваться этой функцией можно через онбординг. Сейчас это реализуется через ИИ-механики и рекомендательные системы.
В сухом остатке: на некоторые вопросы пользовательского опыта не бывает однозначных ответов и универсальных ответов, подходящих всем; лучше адаптировать продукт под пользователя, если это возможно.
#кейс #кастомизация #онбординг@custdevlab