Как выбрать правильные метрики для продукта
Меня зовут Анна Костюк, и несколько месяцев назад я стала Product Manager в Dev-Pro после 7 лет в бизнес-анализе. Решения, которые мы принимали с командой на основе метрик, позволили успешно реализовать несколько новых фич для нашего клиента, что привело к доверительным и надежным отношениям с ним. Я хочу рассказать, как уйти от разработки приложения вслепую и не попасть в ситуацию, когда никто не пользуется фичей, на которую ушли месяцы разработки.
Мы разберем, что такое продуктовые метрики и почему они важны, какую продуктовую метрику считать хорошей, а какая не принесет вам желаемого результата. Обсудим, какие существуют подходы к выбору продуктовых метрик и как определить те, которые подойдут именно вашему продукту. Рассмотрим также практические кейсы.
Будущее за data-informed-разработкой, хотя не все проекты могут похвастаться, что уже следуют этой тенденции. Слово «метрика» звучит сейчас повсюду: люди измеряют эффективность команд, процессов, продуктов, бизнеса в целом. В контексте продакт-менеджмента продуктовая метрика — это показатель, который позволяет оценить успешность фичи.
Ментальная модель метрик
Наш продукт — это ящик. На входе мы имеем потребности пользователей и задачу, которую пытаемся решить, на выходе — решенную проблему пользователя. Но это не черный ящик! Чтобы достичь своих целей, пользователи выполняют определенные действия. Если мы измеряем их во времени, они становятся продуктовыми метриками.
Почему продуктовые метрики важны
Как минимум мы не можем улучшить то, что не способны измерить, а также то, что не имеет цели — места, куда мы ходим прийти. Продуктовые метрики позволяют ответить на основной вопрос: насколько продукт здоров и насколько показатели соответствуют стадии жизненного цикла продукта? Если говорить о базовых примерах, мы можем понять, что прохождение определенного флоу в системе слишком сложное и пользователи не доходят до финального этапа. Это позволяет увидеть области для улучшения фичи.
Метрики также дают информацию, как наши пользователи взаимодействуют с продуктом. Мы предполагаем определенное поведение, когда планируем фичу, но с помощью метрик можем осознать, что пользователи используют ее совсем по-другому.
И конечно, приоритизация дальнейшей работы. Если мы видим общие тренды использования различных фич в продукте, то можем решить, какие фичи развивать, куда инвестировать ресурсы, какие фичи стоит убить или хотя бы приостановить, перестав вкладывать в них деньги, время, силы.
Как это действительно работает, вы сможете рассмотреть на примере нашего проекта, описанного в разделе Case study: мы оценили удобство использования на основе метрик, смогли расставить приоритеты дальнейшей разработки, понять, какие сценарии мы не учли, таким образом улучшив фичу.
Это не панацея. У метрик есть недостатки и ограничения
Они вам скажут, что происходит в вашем продукте, но не ответят на вопрос, почему это происходит. Если мы говорим о продукте как об организме человека, то метрики — это давление, температура, количество ударов сердца в минуту. Узнай вы, что показатель отклоняется от нормы, встревожились бы, но не сделали бы сразу выводы — вам потребуется детальный анализ, чтобы понять, что с вами не так. То же и с продуктом.
Если ваши метрики падают или не достигают уровня, который вы запланировали, важно понять, почему это происходит. Ваша фича решает проблему, которая не важна пользователю? Или она решает эту проблему, но в недостаточной степени? Она решает эту проблему хорошо, но пользователи недовольны производительностью, UX? Тут наступает время детального анализа. Но чтобы иметь достаточно информации для его проведения, необходимо установить хорошую метрику.
Что такое хорошая метрика
В первую очередь метрика должна приводить к действию — влиять на продуктовые решения. Если это просто цифра, которую вы регистрируете и не принимаете во внимание, когда обсуждаете дальнейшие шаги, то это просто цифра. Один из примеров плохой метрики — общее количество посещений сайта. Допустим, вы знаете, сколько людей посещает ваш сайт ежедневно. Что дальше? Если эта метрика падает, какие будут дальнейшие шаги? Скорее всего, полезнее будет понять, какие действия предпринимают пользователи на сайте, сколько времени они проводят. Это позволит локализовать проблемную область.
Хорошая метрика равно понятная метрика. Мы сейчас можем отслеживать фактически все что угодно. Очень легко провалиться в бездну метрик и сабметрик и упустить из виду главную цель. Каждый раз, когда вам приходит в голову посчитать количество Android-пользователей, которые запросили демо в среду перед Днем благодарения, остановитесь и подумайте, что вам дает эта цифра. Как она поможет вам и команде принимать решения? Об этих данных, скорее всего, никто не вспомнит после первого озвучивания.
Метрики должны быть сравнимыми. Вы должны иметь возможность сопоставить их с другими действиями пользователя в системе. Либо с этими показателями в предыдущем периоде.
Не забывайте, что метрики должны быть сопоставлены с бизнес-целями. Например, перед фичей стоит задача улучшить качество поиска. Недостаточно замерить, сколько раз пользователи использовали поиск, потому что это не ответит на вопрос, улучшили ли мы качество поиска. А вот если вы будете отслеживать, сколько было успешных поисков, сколько раз переходили по ссылкам после запроса, эта метрика будет приведена в соответствие с вашими бизнес-целями.
Фреймворки метрик
Их много, но один из самых распространенных — Google’s HEART Framework:
- Happiness — достаточно абстрактная категория, потому что измерять счастье очень сложно. Одна из метрик — NPS score. Всем знакомый экспресс-опрос, предлагающий оценить по шкале от 1 до 10 вероятность того, что вы порекомендуете приложение коллеге. Или рейтинги приложения в аппсторах — тоже показатель счастья. Это достаточно высокоуровневая метрика — общий уровень удовлетворенности клиента вашим продуктом.
- Engagement — категория метрик, которая показывает, насколько глубоко и активно пользователи взаимодействуют с вашим продуктом. Замеряем количество отправленных сообщений, созданных постов или, например, каналов в Slack. Падающие метрики из этой категории должны служить сигналом, что «здоровье» продукта ухудшается и нужно принимать меры.
- Adoption — имеет значение на этапе релизов новых версий или фич. Здесь вы измеряете, сколько пользователей использовали новый функционал, обновили приложение до последней версии и т. д. Низкий adoption может быть обусловлен одним из двух факторов — неэффективным продакт-маркетингом или проблемами с discoverability новой фичи.
- Retention — важно не только, чтобы юзеры попробовали новую фичу (кликнули ее из любопытства), необходимо понимать, сколько человек продолжают ее использовать спустя две недели, месяц, квартал.
- Task Success — насколько легко пользователи достигают цели, пользуясь вашими фичами: какова успешность поиска, количество ошибок и т. д.
Важно! Метрики индивидуальны для вашего продукта, понадобятся не все категории. Например, у вас B2B-проект, в котором пользователи обязаны выполнять определенные действия изо дня в день, потому что это их работа. В таком случае нет смысла измерять Engagement — они вынуждены! Более показательной будет метрика Task Success — насколько просто они могут выполнять свои задачи.
Как же выбрать метрики, которые подходят именно для вашего продукта
В первую очередь метрики должны быть конкретными, специфическими для вашего бизнес-контекста. Если мы говорим, например, о мессенджере, то это количество отправленных одним пользователем сообщений в день. Но если речь идет о LinkedIn, то там она не будет объективной, потому что социальная сеть не предполагает активного и регулярного общения (если это не ваша профессиональная потребность).
Чтобы правильно определить подходящие для вас метрики, задайте себе вопросы: какая цель фичи? кто будет ею пользоваться?
Вернемся к LinkedIn. Если персона пользователя — рекрутер, то, возможно, для него будет актуальной метрика количества отправленных в день сообщений. Когда же мы говорим о персоне обычного пользователя, который заходит проверить аккаунт, это не имеет значения.
Метрики важно сопоставить с «путешествием» пользователя — customer journey. Полезным станет измерить, сколько пользователей проявили намерение воспользоваться фичей (например, сделали необходимый сетап в персональных настройках или перешли на новую страницу), сколько из них непосредственно воспользовались фичей для достижения конечной цели, сколько человек продолжает активно использовать фичу, достигнув цели.
Case study
Я работаю над успешной платформой для sales-менеджеров. Мы с командой создавали фичу, которая позволила в рамках этого продукта назначать встречи с потенциальными клиентами. Всем знакома ситуация, когда предлагаешь созвон: «Давай в понедельник в 14:00», а в ответ получаешь: «Нет, давай во вторник в 15:00». А дальше: «Нет, вторник мне не подходит, давай в среду» — и так до бесконечности, пока клиент не «отвалится». Наша цель — решить эту проблему. Фича заключалась в том, что sales-менеджер открывает свой календарь, просматривает график, выбирает несколько опций и вставляет их в письмо. Потенциальный клиент получает это письмо, видит тайм-слоты и может одним кликом назначить встречу. После клика по ссылке создается событие в календаре.
Какие метрики мы выбрали после релиза:
- Вовлеченность — сколько раз пользователи вставляли свои тайм-слоты в письма. Сколько пользователей открывали календарь, но не выполняли финальное действие — вставку тайм-слотов в письмо.
- Усредненная метрика — сколько раз в неделю в среднем один человек использует эту фичу.
На этапе запуска фичи мы измеряли adoption — сколько уникальных пользователей пришло в течение месяца и квартала после релиза. Так как у нас B2B-продукт, нам было важно понимать не только количество пользователей, но и число уникальных команд, которые начали пользоваться новым функционалом.
Обратили внимание на то, сколько людей продолжает использовать наш новый функционал после первой недели, — так мы понимали, что приносим им ценность, и они постепенно встраивают новую фичу в свой workflow.
Главной категорией стала метрика task success, определявшая, какая была конверсия между отправленными приглашениями и реальными митингами, которые клиенты назначали в своих календарях. Имея высокую конверсию между приглашением и созданной встречей, мы можем заявить об успехе и достижении главной цели — назначение в календаре митинга с клиентом.
Выходя из гугловского фреймворка, мы использовали и другие метрики, чтобы понять паттерны пользовательского поведения. Например, измеряли, сколько в среднем тайм-слотов предлагают клиентам, как часто назначают встречи от имени коллеги...
Здорово, мы получили много-много цифр! Но как мы применяли их в разработке — вот главный вопрос. Как они повлияли на продуктовые решения, которые мы принимали?
Во-первых, функциональность была доступна в двух местах: в самом приложении и в расширении для gmail — числа драматически отличались. Проблема заключалась в UI: доступ в приложении к фиче был сложнее. Чтобы повысить adoption, мы улучшили UI так, чтобы люди легче находили опцию и, следовательно, стали активнее ее использовать.
Во-вторых, мы измеряли, сколько людей вставляют в письма тайм-слоты через календарь и сколько всего писем с приглашениями отправляется. Оказалось, что многие копируют варианты времени из одного сообщения в другое, не заглядывая лишний раз в календарь. Поэтому мы решили задуматься о нативной функциональности копирования.
В-третьих, мы имели данные, сколько в среднем раз sales-менеджеры вставляют тайм-слоты и сколько дней предлагают для встречи с клиентами. Казалось бы, какая нам разница-то? 7, 10 или 15? Пусть делают, что хотят, — мы дали им фичу. Но, имея эту информацию, мы убедились: наш UI максимально удобный, все опции видны и отображаются наилучшим образом, так что человеку, который выбирает подходящий слот, не приходится скроллить и переключаться.
В-четвертых, подтверждение гипотезы. Мы проверили основную гипотезу, что, если sales-менеджер предлагает выбранные тайм-слоты клиентам сразу, а не втягивает их в долгие дискуссии о подходящей дате, получаем более высокую конверсию встреч. Но мы все-таки заметили, что результат мог быть еще лучше: не все клиенты понимали, что они могут сделать это в один клик; они не понимали, что получили ссылки. Мы дали UI более похожий на кнопку — и стали еще успешнее достигать цели.
И в-пятых, открытие. Когда мы разрабатывали фичу, то не знали, что сложится ситуация, когда на момент отправки все временные опции доступны, а через несколько часов уже неактуальны и забронированы. С помощью аналитики мы поняли, что так терялось в среднем 3% потенциальных встреч, и добавили функционал, чтобы дать клиенту возможность запросить новое время.
Выводы
Подводя итоги, с гордостью скажу, что мы не просто собирали данные — мы обрабатывали их и принимали продуктовые решения, основываясь на метриках даже на этапе обсуждения фичи и понимания объема работ и последующих итераций. Конечно, не существует универсального рецепта выбора метрик под ваш продукт. Каждый проект уникален, у него свои цели, пользователи, можно сказать, характер.
Самое главное — не бояться задавать себе вопрос, на который необходимо получить ответ. Далее необходимо думать, с помощью каких цифр можно получить ответ на этот вопрос. Затем измерять эти цифры, анализировать и принимать правильные продуктовые решения.
