×Закрыть

Как выбрать правильные метрики для продукта

Меня зовут Анна Костюк, и несколько месяцев назад я стала 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% потенциальных встреч, и добавили функционал, чтобы дать клиенту возможность запросить новое время.

Выводы

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

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

LinkedIn

5 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

> не все клиенты понимали, что они могут сделать это в один клик; они не понимали, что получили ссылки. Мы дали UI более похожий на кнопку
як ви такі речі відслідковуєте «клиенты понимали»? говорили з клієнтами про це чи пробували різні варіанти кнопок, а потім зробили висновок що вони не розуміли? цікавить як краще відслідковувати моменти розуміє клієнт чи ні? Для одного труднощів жодних не може бути, а для іншого цілий квест

Спасибо за статью!
Я недавно прочитал книгу Lean Analytics и пошарил мои выводы с коллегами:

— Ideally you should have only OMTM (One Metric That Matters) that you use to understand whether you are successful or not
— Company has different stages: Empathy, Stickiness, Virality, Revenue and Scale
— OMTM is different on different stage. On early stage it’s important to get more customers, on later stages important to get revenue
— Metrics (charts) that are Up and Right are useless. For example total registered customer count over time will be always growing, but it does not tell you much about your recent change
— Rate metrics (registrations/week, payments per customer/month, etc.) are good and help you to understand if your change affects something in a positive or negative way
— Don’t measure too much — it’s hard to handle too much numbers and easy to get lost. Measure things that will be important for decision making — OMTM.
— Good startups are growing 5% per week. Bets startups are growing 20% per week
— Mobile app size should be <50Mb, otherwise registration rate drops
— If you ask credit card details in order to start trial — amount of paying customers drops significantly

В книге 6 примеров разных типов бизнесов (e-commerce, mobile game, SaaS и так далее) с конкретными примерами метрик на разных этапах жизни компании. Рекомендую всем кто интересуется аналитикой и развитием продукта!

Спасибо за статью. Метрики продукта сильно зависят от бизнес модели и стадии его развития. Обычно метрики удобно изображать иерархически с линиями связи и влияния друг на друга.
Много полезной информации по иетрикам можно найти в канле t.me/ProductAnalytics

Понравилось, продолжайте писать!

Подписаться на комментарии