Что такое feedback loop и как он поможет улучшить показатели компании

Руслан Назаренко, глава по развитию Let’s Enhance и основатель Quokka, рассказывает о механике для работы с пользователями feedback loop и объясняет, чем она может быть полезной компаниям.

Бывает, что открываешь аналитику и вот наглядно видно проблему. Например, низкая конверсия с одного шага на другой. И возникает вопрос: а что же делать?

В зависимости от размера компании, в которой работаете, эта задача может уйти в разные отделы. Как правило, это может быть PMM, PM или CRO manager. Что происходит дальше? Начинают накидываться гипотезы, что можно исправить. Они часто звучит как: «Давайте сделаем кнопку побольше», «Надо лучше эту страницу оптимизировать под мобайл» или «Давайте тут другие тексты попробуем».

Как правило, это имеет мало общего с наилучшим решением проблемы, хотя иногда и срабатывает: даже сломанные часы дважды в день правильно показывают время. Но есть правильный способ избавиться от таких проблем: он называется feedback loops (циклы отзывов).

К моему удивлению, даже крупные компании типа Instacart грешат такими же проблемами. Я расскажу, как лучше всего их может решить компания — особенно, небольшая: что спрашивать, когда и какой канал использовать.

Что такое feedback loop

Feedback loop — это сбор фидбека пользователей на масштабе, без привлечения UX или Research-специалистов. Это помогает понять не то, где проблема (для этого есть количественная аналитика), а узнать, почему она возникает и как ее можно решить.

Пример. В ленте новостей сотрудники Blind (приложение для анонимного общения сотрудников крупных технологический компаний в США) каждый день задают новый вопрос своим пользователям. Чаще всего, эти вопросы крутятся вокруг ценности продукта или последних апдейтов, но иногда могут и затрагивать очень узкие темы.

Что спрашивать?

Несмотря на то что все продукты разные, базовые вопросы у всех плюс-минус одинаковые. Для себя я выбрал такой набор: 

  • Почему пользователь решил зарегистрироваться? 
  • Почему он воспользовался фичей Х?
  • Почему он не воспользовался фичей Х сколько-то раз? Тут объясню. Если вы даете пользователю 10 бесплатных кредитов, а он почему-то не использовал их все — стоит узнать почему.
  • Почему пользователь заплатил?
  • Что остановила пользователя от оплаты?
  • Почему пользователь платит нам уже 3-6-12 месяцев?

Опционально в этот список вы можете добавить любые вопросы, к примеру:

  • Кем наш пользователь работает?
  • Как нас нашел?
  • Какие еще решения рассматривал и так далее

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

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

Очевидно, что в какой-то момент может оказаться, что вы задаете пользователям 51 вопрос за первый месяц и это не ок. Как и с данными в целом, у вас всегда есть выбор между «трекать сильно много всего» и «трекать недостаточно». И баланс находится по середине.

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

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

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

Когда спрашивать?

Сначала разбейте весь свой продукт на понятный user journey. В целом не особо важно, используете вы AARRR или какой-то другой подход. Я, к примеру, предпочитаю вариант, который предложил Брайн Балфор: 

Наложите это на свой продукт и, скорее всего, у вас получится немного больше шагов. К примеру, этап активации для типичного SaaS`а может состоять из таких шагов: 

  • Регистрация;
  • Установка;
  • Использование фичи Х;
  • Оплата.

И у вас сразу появляется понимание, что можно было забыть на прошлом этапе. Так, к примеру, вы можете добавить вопрос: «Почему вы не закончили устанавливать продукт?».

Тут есть важный момент. Если вы решите задавать вопрос через email, не стоит это делать сразу же. То есть, если пользователь только-только сделал оплату, отправьте письмо не по факту совершенного действия, а 10-20-30 минут спустя. Так шанс того, что вы прервете пользователя уменьшается. 

Другой вопрос, который тут может возникнуть: а что делать с теми, кто не сделал какое-то действие? Сколько ждать? И на самом деле это очень важный момент. Чем дольше вы ждете, тем больше шансов, что пользователь не вернется. Об этом хорошо написал Паша Левчук вот тут.

На старте я никогда не делаю сразу сложную аналитику, а просто беру медиану времени, которое надо пользователям, чтобы сделать целевое действие. Этот показатель сразу есть у Amplitude прямо из коробки. Найти этот показатель можно в отчетах по funnels, в самом низу. Конкретно в этом случае, мы бы отправили пользователям вопрос примерно через 16,5 часов после создания аккаунта.

Какой канал использовать?

В целом, вы можете использовать любой из этих каналов: 

  • Почта:
  • Сообщения внутри сервиса;
  • Ретаргетированную рекламу;
  • Встроенные решения (как у Blind в самом начале, или как у Google Meet после звонка);
  • Уведомления платформ (если ваш продукт интегрируется с Slack, вы можете спросить через бота).

Правило тут такое же, как и при работе с вовлечением. Все зависит от размера вопроса и ожидаемого ответа, и первый канал должен быть самым дешевым. То есть, очевидно, что если вы даете выбор из нескольких вариантов — сообщения или пуши — уведомление может сработать. И наоборот, если вы ожидаете большие по объему ответы, почта или даже опросники типа Typeform будут вашим выбором.

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

Мой самый любимый вопрос: Why did you decide to sign up / Почему вы решили зарегистрироваться? Я отправляю его через минут 10 после регистрации и это дает просто большое количество инсайтов. Люди тут делятся на две категории: те, кто рассказывает про ожидания от продукта и те, кто рассказывает, что же их триггернуло в вашей рекламе. Обе категории одинаково прекрасны и я советовал всем бы задавать этот вопрос своим пользователям.

Кстати, сам Customer.io использует попапы для того, чтобы задавать вопросы. Мне удалось выловить только дефолтный про NPS, но тут может быть, в целом, все что угодно. 

Из последнего, в Let’s Enhance я добавил вопрос тем пользователям, которые попробовали наш инструмент, но не использовали все бесплатные картинки. От сюда я узнал, что все мои прошлые гипотезы — полная фигня, а настоящая проблема в том, что мы даем не очень много картинок и пользователь просто боится потратить бесплатные.

Ну, и напоследок, хрестоматийный уже пример, но давайте посмотрим на Zoom. Они дают на выбор несколько опций, что было не так. Очень удобно мониторить техническое здоровье продукта.

Одна вещь, которую надо помнить про количественные оценки (оцени звонок от 1 до 5): анализировать такие данные лучше в более продвинутых инструментах типа Tableau, а не в аналитике типа Amplitude. Связано это с тем, что вы хотите видеть динамику оценок, но в большинстве простых инструментах их можно сохранять только как массив. Это не дает возможности удобно разложить показатели на графике и мониторить ситуацию.

Источник: ain.ua



Самые актуальные новости - в Telegram-канале

Читайте также

Вверх