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

Какое-то время назад все активно начали делиться статьёй от UX-исследователя в Google Ventures о том, как выбрать правильные UX-метрики для продукта (здесь же рассказывается про фреймворк HEART). Статья крутая, но после практического использования возникают вопросы. Я решила сделать вольный перевод и поделиться своими комментариями.

В процессе дизайна можно полагаться на пользовательские данные и на результаты экспериментов. Это то, что сейчас называется data-driven design, но я предпочитаю термин data-informed design — рулит всё ещё дизайнер, а не данные.
Чтобы это работало на практике, надо смотреть на правильные метрики. Базовые данные по трафику (количество просмотров страницы или количество уникальных пользователей, к примеру) легко отслеживать; они дают неплохое понимание, как поживает ваш сайт; но часто они совершенно бесполезны для оценки UX-изменений.
Всё потому, что они слишком общие и напрямую не отражают качество продукта или цели проекта — на их основе сложно понять, что делать дальше. Я работаю UX-исследователем в Google, где мы разработали несколько полезных фреймворков для определения и выбора метрик, отражающих: качество user experience (HEART) и цели вашего продукта или проекта (цели-сигналы-метрики).

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

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

В-третьих, какая-то повальная путаница с тем, что считать метриками продукта, что — метриками проекта, а где вообще продакт-маркетинг затесался.

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

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

Возвращаясь к моей любимой медицинской аналогии: представьте, что вы пришли на приём ко врачу. А он померял у вас температуру, взял анализ крови, отправил на УЗИ, а потом говорит: ну да, температура у вас низковата, давайте я вам таблетки пропишу.

А потом оказалось, что просто градусник сломался, а у вас и не болело ничего, или болело колено, а вас лечат от низкой температуры, потому что оно ниже среднего по больнице, и вообще сказали, что у всех надо мерять температуру, значит, надо мерять.

Помогая Google-командам с UX-метриками, мы заметили, что наши предложения обычно попадают в какую-то из пяти категорий: HEART — Happiness, Engagement, Adoption, Retention, Task success.

Измеряет отношение пользователя, часто через опросы. Примеры метрик: удовлетворение, воспринимаемая лёгкость использования и NPS.

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

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

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

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

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

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

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

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

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

Engagement — это логическое продолжение активации (о которой мы говорили в предыдущем пункте): ответ на вопрос, а продолжают ли пользователи получать пользу от продукта?

Условно говоря, пользователь Slack пригласил десять коллег, что подскажет нам, что они все заинтересованы в продукте? Например, следующие engagement-метрики:

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

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

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

В чём отличие между активацией и вовлечённостью? Активация — это конкретный момент в путешествии пользователя. Соответственно, нас интересует количество людей, дошедших до этой точки, и как это количество можно увеличить. Вот мы упомянули в качестве активации для Spotify N минут прослушивания музыки в день. Как это определяется?

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

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

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

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

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

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

Небольшое количество людей регулярно проверяет, как обновился ваш продукт, особенно если они уже используют конкурента и создали вокруг него какой-то процесс (например, когда я иду на работу, слушаю подкасты в Spotify) или, что ещё хуже для вас, добавили свою персональную информацию (например, когда я делаю фото на телефон, загружаю их в iCloud).

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

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

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

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

Процент пользователей, возвращающихся в продукт. Например, как много активных пользователей в выбранный момент все ещё пользуются продуктом в более поздний момент? Возможно, вам даже больше будет интересна обратная метрика, где удержать пользователей не удалось, — отток.

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

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

Включает в себя традиционные поведенческие UX-метрики, например, оперативность (пример — время на выполнение задания), эффективность (процент выполненных заданий) и процент ошибок. Эта категория наиболее применима к части продукта, ориентированной на выполнение задачи: например, поиск или процесс загрузки.

Пример метрики, которая отлично работает для UX-исследований, но, на мой взгляд, не особо хорошо подходит в качестве продуктовой. Перечисленные выше примеры скорее относятся к техническим метрикам или метрикам здоровья продукта — и это совсем другая категория. Возьмём, к примеру, поиск «Яндекса». Да, можно улучшить время ответа, но при этом найти трешовые или нерелевантные результаты, которые не принесут пользы юзеру. Из этого следуют два вывода:

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

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

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

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

Эти метрики можно применять на разных уровнях — от всего продукта до конкретной функции. Например, в Gmail мы можем быть заинтересованы как в adoption продукта в целом, так и в adoption ключевых функций (например, лейблов или архивирования).
Нас часто спрашивают, зачем измерять adoption или retention, когда ты просто можешь посчитать уникальных пользователей. Безусловно, важно понимать, сколько пользователей к вам приходит за определённый период (например, активные пользователи за семь дней).
Но если вы также измеряете adoption и retention, вы точно отделите новых пользователей от возвращающихся и сможете быстро понять, растёт ли ваша аудитория. Это особенно важно для новых продуктов, функций или для редизайна.
Необязательно создавать метрики во всех из этих категорий — вы можете выбрать только те, которые наиболее важны для вашего проекта. Фреймворк HEART может помочь вам решить, какая из категорий вам нужна.
Например, в бизнес-продуктах, которыми аудитория, возможно, пользуюется ежедневно, и где они интегрированы в рабочий процесс, может быть бессмысленно мерять вовлёченность, зато может быть интереснее сосредоточиться на счастье пользователя или на task success. Как бы то ни было, может быть полезно учитывать engagement на уровне определенных функций как индикатор их полезности.
Мы применяли фреймворк HEART к широкому спектру проектов в Google и считаем, что это очень полезный инструмент, чтобы направить обсуждение с командой в нужное русло. Акроним хорошо запоминается; его можно использовать для фасилитации встреч, просто обозначая категории на доске.

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

Порой хочется начать думать о метриках, просто составляя длинный лист, но он быстро может стать громоздким и неудобным в приоритизации. В идеале вам нужен небольшой сет ключевых метрик, которые важны для всех членов команды. Чтобы понять, что это за метрики, надо начать на уровень выше: определить цели, а потом уже выбрать метрики, которые помогут вам измерять прогресс по выполнению этих целей.
Порой может быть удивительно сложно сформулировать цели проекта, и в этот момент полезно использовать для дискуссии категории метрик HEART. В YouTube, к примеру, одна из наиболее важных целей относится к категории Engagement: мы хотим, чтобы пользователи наслаждались видео, которые они смотрят, и продолжали открывать больше видео и каналов, которые они хотели бы посмотреть.
У вас могут быть разные цели для определённого проекта или функции — и для продукта в целом. Для поиска YouTube ключевая цель относится к Task Success категории: когда пользователь вводит запрос, мы хотим, чтобы он быстро и легко нашёл наиболее релевантные видео или каналы.
Частая ловушка — определять цели в рамках ваших существующих метрик: например, увеличение трафика сайта. Да, каждый хочет это сделать, но как UX-улучшения помогут вам в этом? Хотите ли вы увеличить вовлечённость существующих пользователей или привлечь новых?
Вы можете не осознавать, что у разных членов вашей команды могут быть разные представления о целях вашего проекта. Этот процесс предоставляет возможность достичь соглашения о том, в каком направлении вы движетесь.

Следующий шаг — привязать цели к более низкоуровневым сигналам. Как успех или провал в достижении целей может проявить себя в пользовательском поведении или отношении?
Например, сигналом вовлечённости для YouTube может быть количество видео, просмотренных пользователем, а еще лучше — время, потраченное на просмотр видео. Сигналом провала в Task Sucess категории для YouTube Search может быть запрос, по которому не было ни одного клика на результаты.
Обычно есть большое количество потенциально полезных сигналов для конкретной цели. Как только вы набросаете какое-то количество кандидатов, остановитесь и проведите небольшое исследование.
Во-первых, насколько легко трекать каждый сигнал? Будут ли логироваться нужные действия в продукте и можно ли это сделать? Можете ли вы выкатывать опросы на постоянной основе? Для метрик Task Success одна из опций — использовать задания в benchmarking-исследовании, которые можно проводить с большим количеством участников.
Во-вторых, выбирайте сигналы, которые будут чувствительны к изменениям в вашем дизайне. Если вы уже собираете потенциально полезные сигналы, вы можете проанализировать имеющиеся данные и попытаться понять, какие сигналы будут точнее всего предсказывать достижение соответствующей цели.

Сигналы, которые вы выбрали, можно уточнить и превратить в метрики, которые вы будете трекать в динамике или использовать для сравнения в экспериментах. В примере с вовлечённостью в YouTube мы могли бы внедрить сигнал «Как долго пользователи смотрят видео» как метрику «Среднее количество минут, потраченное на просмотр видео, на пользователя в день».
Специфика сильно зависит от вашей инфраструктуры. Но, как и на предыдущем шаге, есть множество метрик, которые можно вывести из определённого сигнала, — вам надо будет проанализировать данные и решить, какие будут для вас наиболее полезны.
Возможно, вам также надо будет нормализовать сырые числа и использовать среднее или проценты, чтобы сделать их более говорящими.

Процесс цели-сигналы-метрики должен привести к приоритизации метрик — важно трекать метрики, которые относятся к вашим ключевым целям. Не добавляйте просто «интересные данные» в ваш список. Помогут ли они вам принять решение? Нужно ли вам трекать их в динамике, или достаточно одного измерения? Фокусируйтесь на метриках, которые относятся к вашим целям, чтобы избежать затрат на их внедрение и засорения дашборда.

Если вы хотите, чтобы ваш продуктовый дизайн информировался данными, подумайте над метриками, которые отражают качество опыта взаимодействия, и свяжите их с вашими основными целями.

Бывший продакт-менеджер в Intercom и автор блога No Flame No Game Анна Булдакова.

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

Happiness — счастье

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

Adoption — принятие

Retention — удержание

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

Цели — сигналы — метрики

Цели

Сигналы

Метрики