Как выбрать правильные метрики для продукта
Какое-то время назад все активно начали делиться статьёй от UX-исследователя в Google Ventures о том, как выбрать правильные UX-метрики для продукта (здесь же рассказывается про фреймворк HEART). Статья крутая, но после практического использования возникают вопросы. Я решила сделать вольный перевод и поделиться своими комментариями.
Во-первых, да, data-informed. Informed by data, not driven. Сначала стратегия и цели, затем метрики. Сначала гипотеза и, опять же, цели, затем эксперимент. Накручивать показатели можно очень долго и очень успешно, только продукт от этого лучше не станет.
Во-вторых, да, на базовые метрики смотреть бесполезно. Ну поверьте, нет такой волшебной пилюли, которая работала бы для всех. Безусловно, у вашего продукта могут трекаться такие же метрики, как и других продуктов: те же DAU, Retention, ARPU и прочие. Но вот вопрос, какие из них будут для вас более важны, а какие — менее. Условно говоря, приложение, которое отправляет сигнал SOS в ближайшую службу спасения, вряд ли будет смотреть на Retention.
В-третьих, какая-то повальная путаница с тем, что считать метриками продукта, что — метриками проекта, а где вообще продакт-маркетинг затесался.
Всё просто: вот у нас есть продукт, которым можно как-то пользоваться. То, что происходит до начала использования, относится к продакт-маркетингу; то, что происходит во время — к продукту. Проект (~функция) — это гипотеза внутри продукта; соответственно, на высоком уровне успех проекта определяется метриками продукта, но также имеет и собственные технические метрики, которые позволят понять, всё ли работает хорошо, не сломалось ли чего.
И есть ещё отдельная группа метрик для исследований (время выполнения заданий или как раз Task Success, о которой говорится в статье), которые позволяют сделать количественные выводы для юзабилити-тестов. Это так, для общей картины.
Возвращаясь к моей любимой медицинской аналогии: представьте, что вы пришли на приём ко врачу. А он померял у вас температуру, взял анализ крови, отправил на УЗИ, а потом говорит: ну да, температура у вас низковата, давайте я вам таблетки пропишу.
А потом оказалось, что просто градусник сломался, а у вас и не болело ничего, или болело колено, а вас лечат от низкой температуры, потому что оно ниже среднего по больнице, и вообще сказали, что у всех надо мерять температуру, значит, надо мерять.
Happiness — счастье
Насколько все компании хотели бы улучшать счастье пользователя, настолько же они не знают, как его считать: эмоции — не так легко измеряемая штука, как DAU, например. Вопрос в том, нужно ли это на уровне продукта.
Я пользуюсь Spotify каждый день. Я счастливый пользователь? На мой взгляд, это такой же странный вопрос, как — вот вы пользуетесь молотком, вы счастливый пользователь молотка? Эмоции — это про бренд, про историю (которой, к слову, занимается маркетинг); продукт — про решение задачи, про ценность. Пользователи могут питать какие-то чувства к «Яндексу» или к Google, но не к поисковому движку как таковому — тут у них сугубо рациональный подход.
Опять же, если мы разрабатываем функцию (это метрики проекта, упомянули их выше), то должны думать о метриках продукта — и тут тот же NPS, к примеру, совершенно бесполезен: замерить таким способом влияние отдельно взятой функции практически невозможно.
Другое дело, если мы спросим: а извлекает ли пользователь какую-то пользу из нашего продукта? Концепт ценности (или счастья) также отлично подходит и для приоритезации новых функций.
Как определить ценность? Идите от обратного: спросите себя — если мы представим идеального пользователя, который получает максимальную пользу от продукта, что он делает?
Это называется активация: первый момент во время использования продукта, когда пользователь извлекает ценность. Важно, что пользователь вполне может и не осознать этот момент.
И последнее, что я повторяю из раза в раз: начинать надо не с метрики, а с цели, а в данном контексте — с определения пользы. Если Uber определяет свою пользу в том, чтобы сделать более удобную и сравнимую по цене замену общественному транспорту, это одно. Если они думают про сокращение использования автомобилей на человека, это другое. И, к слову, польза Uber для водителя и для пассажира будет звучать по-разному.
Engagement — вовлечённость
Engagement — это логическое продолжение активации (о которой мы говорили в предыдущем пункте): ответ на вопрос, а продолжают ли пользователи получать пользу от продукта?
Условно говоря, пользователь Slack пригласил десять коллег, что подскажет нам, что они все заинтересованы в продукте? Например, следующие engagement-метрики:
- количество времени, проведённого в чате, на пользователя;
- количество активных каналов;
- количество директ-сообщений на пользователя и так далее.
Engagement-метрики прекрасны и для определения успешности проекта:
- в случае customer-facing функций engagement должен остаться на том же уровне (при условии улучшения других метрик) или вырасти;
- в случае инфраструктурных изменений engagement должен остаться на том же уровне.
В чём отличие между активацией и вовлечённостью? Активация — это конкретный момент в путешествии пользователя. Соответственно, нас интересует количество людей, дошедших до этой точки, и как это количество можно увеличить. Вот мы упомянули в качестве активации для Spotify N минут прослушивания музыки в день. Как это определяется?
Spotify выбрал пользователей, которые успешны в их понимании: например, они платящие, они пользуются продуктом уже несколько лет, они оставляют высокие оценки в магазине приложений. Если сравнить их с неуспешными пользователями, было ли какое-то действие, которое они совершили? И, соответственно, дальше — если мы подведём неуспешных пользователей к этому действию, станут ли они успешными?
Вовлечённость — это, собственно, само путешествие; флажки, которые показывают, насколько хорошо функционирует продукт.
Adoption — принятие
А вот здесь надо снова вернуться к метрикам маркетинга и продукта. Adoption как раз прекрасный пример метрики, которая находится где-то на стыке.
Может ли улучшение качества продукта или новая крутая функция увеличить количество новых пользователей? Может. Может ли рекламная кампания или публикация в блоге увеличить количество регистраций? Может.
В моей практике второе случалось чаще, чем первое; вполне возможно, что из-за специфики продуктов, с которыми я работала. Ещё один немаловажный фактор, почему я всё же больше отношу эту метрику к маркетингу, — это пользовательская привычка.
Небольшое количество людей регулярно проверяет, как обновился ваш продукт, особенно если они уже используют конкурента и создали вокруг него какой-то процесс (например, когда я иду на работу, слушаю подкасты в Spotify) или, что ещё хуже для вас, добавили свою персональную информацию (например, когда я делаю фото на телефон, загружаю их в iCloud).
Чем дольше пользователь использует продукт, тем, вероятно, выше для него будет цена переключения. Таким образом, чтобы заставить пользователя перейти к вам, нужно либо чтобы у конкурента был видимый недостаток, которого у вас нет, либо у вас должна быть киллер-функция, которой нет у конкурента. В обоих случаях это предполагает два варианта.
- Пользователю вроде как всё нравится, потому что он не знает, как может быть лучше — маркетинг его информирует об альтернативах.
- Пользователь недоволен текущим решением и пользуется им, потому что не видит или не нашёл лучших вариантов — нужно ему о них рассказать с помощью маркетинговых инструментов.
Безусловно, есть ещё фактор сарафанного радио, когда пользователи в восторге от продукта и делятся рекомендациями с друзьями. Но на мой взгляд, с точки зрения продукта это лучше отражается тремя другими метриками:
- activation (осознал ли пользователь ценность продукта);
- engagement (продолжает ли он получать пользу);
- retention.
Retention — удержание
Тут мало что можно добавить: retention для большей части сервисов — одна из важнейших продуктовых метрик. В моей практике retention и engagement определяли успех продукта или функции и наиболее точно соответствовали ценности, которую получает пользователь.
Отток не работает на уровне функции, но, наверное, будет самым громким звоночком, что с продуктом что-то не так. Понятно, что будет часть пользователей, которая будет утекать по естественным причинам; нам же наиболее интересны прошедшие активацию пользователи, которые решили уйти.
Task success — успех в выполнении задания
Пример метрики, которая отлично работает для UX-исследований, но, на мой взгляд, не особо хорошо подходит в качестве продуктовой. Перечисленные выше примеры скорее относятся к техническим метрикам или метрикам здоровья продукта — и это совсем другая категория. Возьмём, к примеру, поиск «Яндекса». Да, можно улучшить время ответа, но при этом найти трешовые или нерелевантные результаты, которые не принесут пользы юзеру. Из этого следуют два вывода:
- технические метрики на уровне продукта или сервиса надо рассматривать с учётом пользовательских метрик;
- технические метрики показывают эффективность продукта, но далеко не всегда — его ценность и качество.
За технические метрики обычно отвечает не PM, а разработчики или технический менеджер. Улучшают их чаще всего по одной из двух причин.
- Есть определённый стандарт в индустрии, которого надо достичь, чтобы быть конкурентоспособным. Например, если вы делаете поиск, ваше время ответа ну никак не может быть равно одной минуте.
- Текущие лимиты ограничивают возможности компании для роста.
Следующий фрагмент будет без моих комментариев; но, думаю, вы и так поймёте, где там противоречащие друг другу куски.
Цели — сигналы — метрики
Цели
Сигналы
Метрики
Бывший продакт-менеджер в Intercom и автор блога No Flame No Game Анна Булдакова.
Спасибо!
Комментарий удален модератором