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

Какое-то время назад все активно начали делиться вот этой статьей от UX-исследователя в Google Ventures про то, как выбрать правильные UX метрики для продукта. Статья крутая, но после практического использования возникают вопросы: поэтому ловите вольный перевод (в кавычках) и мои комментарии к нему.

Во-первых, да, data-informed. INFORMED by data, not driven. Сначала стратегия и цели, затем метрики. Сначала гипотеза и, опять же, цели, затем эксперимент. Накручивать циферки только ради циферок можно очень долго и очень успешно, только продукт от этого лучше не станет.

Во-вторых, да, на “базовые метрики” смотреть бесполезно. Ну поверьте, нет такой волшебной пилюли, которая работала бы для всех. Безусловно, у вашего продукта могут трекаться такие же метрики, как и других продуктов: те же DAU, Retention, ARPU и прочие. Но вот вопрос, какие из них будут для вас более важны, а какие — менее. Условно говоря, приложение, которое отправляет сигнал SOS в ближайшую службу спасения, вряд ли будет смотреть на Retention.

В-третьих, какая-то повальная путаница с тем, что считать метриками продукта, что — метриками проекта, а где вообще продакт маркетинг затесался. По сути все просто: вот у нас есть продукт, которым можно как-то пользоваться. То, что происходит до начала использования, относится к продакт-маркетингу; то, что происходит во время, к продукту. Проект (~фича) — это гипотеза внутри продукта; соответственно, на высоком уровне успех проекта определяется метриками продукта, но также имеет и собственные “технические” метрики, которые позволят понять, все ли работает хорошо, не сломалось ли чего.

И есть еще отдельная группа метрик для исследований (время выполнения заданий или как раз Task Success, о которой говорится в статье), которые позволяют сделать количественные выводы для usability тестов. Ну это так, для общей картины ;)

Возвращаясь к моей любимой медицинской аналогии:

• Представьте, что вы пришли на прием ко врачу. А он такой померил у вас температуру, взял анализ крови, отправил на УЗИ, а потом говорит: ну да, температура у вас низковата, давайте я вам таблетки пропишу.
• А потом оказалось, что просто градусник сломался, а у вас и не болело ничего.
• Или болело колено, а вас лечат от низкой температуры — потому что ниже среднего по больнице, и вообще: сказали, что у всех надо мерить температуру, значит надо мерить!

Happiness — Счастье

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

Я пользуюсь Spotify каждый день. Я счастливый пользователь? На мой взгляд, это такой же странный вопрос, как — вот вы пользуетесь молотком, вы счастливый пользователь молотка? Эмоции — это про бренд, про историю (которой, к слову, занимается маркетинг); продукт — про решение задачи, про ценность. Пользователи могут питать какие-то чувства к Яндексу или к Гуглу, но не к поисковому движку как таковому — тут у них сугубо рациональный подход.

Опять же, если мы разрабатываем фичу (это метрики проекта, упомянули их в предыдущем посте), то должны думать о метриках продукта — и тут тот же NPS, к примеру, совершенно бесполезен: замерить таким способом влияние отдельно взятой фичи практически невозможно.

Другое дело, если мы спросим: а извлекает ли юзер какую-то пользу из нашего продукта? Концепт ценности (vs счастья) также отлично подходит и для приоритезации новых фич.

Как определить ценность? Идите от обратного: спросите себя — если мы представим идеального пользователя, который получает максимальную пользу от продукта, что он делает?

• Если это Spotify, возможно, он слушает музыку > n минут в день.
• Если это Uber, возможно, он делает n-ное количество поездок за определенный период.
• Если это Slack, возможно, он пригласил n коллег в чат.

По сути, это называется “активация”: первый момент во время использования продукта, когда пользователь извлекает ценность. Важно, что пользователь вполне может и не осознать этот момент

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

Engagement — Вовлеченность

По сути, engagement — это логическое продолжение активации (о которой мы говорили в прошлый раз): ответ на вопрос, а продолжают ли пользователи получать пользу от продукта? Условно говоря, пользователь Slack пригласил 10 коллег, что подскажет нам, что они все заинтересованы в продукте?

Например, вот такие engagement метрики:

• количество времени, проведённое в чате, на пользователя
• количество активных каналов
• количество директ-сообщений на пользователя

и так далее.

Engagement метрики прекрасны и для определения успешности проекта:

• в случае customer-facing фич engagement должен остаться на том же уровне (при условии улучшения других метрик) или вырасти
• в случае инфраструктурных изменений engagement должен остаться на том же уровне.

В чем отличие между активацией и вовлеченностью?

Активация — это конкретный момент в «путешествии» пользователя. Соответственно, нас интересует количество людей, дошедших до этой точки, и как это количество можно увеличить. Вот мы упомянули в качестве активации для Spotify n минут прослушивания музыки в день. Как это определяется? Spotify выбрал пользователей, которые успешны в их понимании: например, они платящие, они пользуются продуктом уже несколько лет, они оставляют высокие оценки в сторе. Если сравнить их с неуспешными пользователями, было ли какое-то действие, которое они совершили? И, соответственно, дальше — если мы подведём неуспешных пользователей к этому действию, станут ли они успешными?

Вовлечённость — это, собственно, само путешествие; флажки, которые показывают, насколько хорошо функционирует продукт.

Adoption — Принятие

А вот здесь надо снова вернуться к метрикам маркетинга vs метрики продукта. Adoption как раз прекрасный пример метрики, которая где-то на стыке.

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

В моей практике второе случалось чаще, чем первое; вполне возможно, что из-за специфики продуктов, с которыми я работала. Ещё один немаловажный фактор, почему я все же больше отношу эту метрику к маркетингу, — это пользовательская привычка. Очень небольшое количество людей регулярно проверяет, как там обновился ваш продукт, особенно если они уже используют конкурента и создали вокруг него какой-то процесс (например, когда я иду на работу, слушаю подкасты в Spotify) или, что ещё хуже для вас, добавили свою персональную информацию (например, когда я делаю фото на телефон, загружаю их в iCloud). Чем дольше пользователь использует продукт, тем, вероятно, выше для него будет цена переключения. Таким образом, чтобы заставить пользователя перейти к вам, нужно либо чтобы у конкурента был видимый недостаток, которого у вас нет, либо у вас должна быть киллер-фича, которой нет у конкурента. В обоих случаях это предполагает два варианта:

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

Безусловно, есть ещё фактор сарафанного радио, когда пользователи в восторге от продукта и делятся рекомендациями с друзьями. Но, на мой взгляд, с точки зрения продукта это лучше отражается тремя другими метриками:

• activation (осознал ли пользователь ценность продукта)
• engagement (продолжает ли он получать пользу)
• retention.

Retention — Удержание

Тут мало что можно добавить: retention для большей части сервисов — одна из важнейших продуктовых метрик. В моей практике retention + engagement определяли успех продукта или фичи и наиболее точно соответствовали ценности, которую получает пользователь.

Churn не работает на уровне фичи, но, наверное, будет самым громким звоночком, что с продуктом что-то не так. Понятно, что будет часть пользователей, которая будет утекать по естественным причинам; нам же наиболее интересны прошедшие активацию пользователи, которые решили уйти.

Task success — Успех в выполнении задания

Пример метрики, которая отлично работает для UX-исследований, но, на мой взгляд, не особо хорошо подходит в качестве продуктовой. Перечисленные выше примеры, скорее, относятся к техническим метрикам или метрикам “здоровья продукта”, и это совсем другая категория.

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

• технические метрики на уровне продукта или сервиса надо рассматривать с учетом пользовательских метрик
• технические метрики показывают эффективность продукта, но далеко не всегда — его ценность и качество.

За технические метрики обычно отвечает не PM, а разработчики или технический менеджер. Улучшают их чаще всего по одной из двух причин:

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

Следующий фрагмент будет без моих комментариев; но, думаю, вы и так поймете, где там противоречащие друг другу куски ;)

Джон Белл (Twitter): будущее дизайна уже наступило, и оно связано с данными