Фреймворк pulse что это
Какое-то время назад все активно начали делиться вот этой статьей от UX-исследователя в Google Ventures про то, как выбрать правильные UX метрики для продукта. Статья крутая, но после практического использования возникают вопросы: поэтому ловите вольный перевод (в кавычках) и мои комментарии к нему.
Во-первых, да, data-informed. INFORMED by data, not driven.
Сначала стратегия и цели, затем метрики. Сначала гипотеза и, опять же, цели, затем эксперимент. Накручивать циферки только ради циферок можно очень долго и очень успешно, только продукт от этого лучше не станет.
Во-вторых, да, на “базовые метрики” смотреть бесполезно. Ну поверьте, нет такой волшебной пилюли, которая работала бы для всех. Безусловно, у вашего продукта могут трекаться такие же метрики, как и других продуктов: те же DAU, Retention, ARPU и прочие. Но вот вопрос, какие из них будут для вас более важны, а какие — менее. Условно говоря, приложение, которое отправляет сигнал SOS в ближайшую службу спасения, вряд ли будет смотреть на Retention.
В-третьих, какая-то повальная путаница с тем, что считать метриками продукта, что — метриками проекта, а где вообще продакт маркетинг затесался. По сути все просто: вот у нас есть продукт, которым можно как-то пользоваться. То, что происходит до начала использования, относится к продакт-маркетингу; то, что происходит во время, к продукту. Проект (
фича) — это гипотеза внутри продукта; соответственно, на высоком уровне успех проекта определяется метриками продукта, но также имеет и собственные “технические” метрики, которые позволят понять, все ли работает хорошо, не сломалось ли чего.
И есть еще отдельная группа метрик для исследований (время выполнения заданий или как раз Task Success, о которой говорится в статье), которые позволяют сделать количественные выводы для usability тестов. Ну это так, для общей картины ;)
Возвращаясь к моей любимой медицинской аналогии:
- представьте, что вы пришли на прием ко врачу. А он такой померял у вас температуру, взял анализ крови, отправил на узи, а потом говорит: ну да, температура у вас низковата, давайте я вам таблетки пропишу.
- а потом оказалось, что просто градусник сломался, а у вас и не болело ничего.
- или болело колено, а вас лечат от низкой температуры — потому что ниже среднего по больнице, и вообще: сказали, что у всех надо мерять температуру, значит, надо мерять!
“Помогая гугловым командам с UX метриками, мы заметили, что наши предложения обычно попадают в какую-то из 5 категорий:
H — Happiness (Счастье). Измеряет отношение пользователя, часто через опросы. Примеры метрик: удовлетворение, воспринимаемая легкость использования и NPS”.
Насколько все компании хотели бы улучшать счастье пользователя, настолько же они не знают, как его считать: эмоции — не так легко измеряемая штука, как DAU, например. Вопрос в том, нужно ли это на уровне продукта.
Я пользуюсь Spotify каждый день. Я счастливый пользователь? На мой взгляд, это такой же странный вопрос, как — вот вы пользуетесь молотком, вы счастливый пользователь молотка? Эмоции — это про бренд, про историю (которой, к слову, занимается маркетинг); продукт — про решение задачи, про ценность. Пользователи могут питать какие-то чувства к Яндексу или к Гуглу, но не к поисковому движку как таковому — тут у них сугубо рациональный подход.
Опять же, если мы разрабатываем фичу (это метрики проекта, упомянули их в предыдущем посте), то должны думать о метриках продукта — и тут тот же NPS, к примеру, совершенно бесполезен: замерить таким способом влияние отдельно взятой фичи практически невозможно.
Другое дело, если мы спросим: а извлекает ли юзер какую-то пользу из нашего продукта? Концепт ценности (vs счастья) также отлично подходит и для приоритезации новых фич.
Как определить ценность? Идите от обратного: спросите себя — если мы представим идеального пользователя, который получает максимальную пользу от продукта, что он делает?
Если это Spotify, возможно, он слушает музыку > n минут в день.
Если это Uber, возможно, он делает n-ное количество поездок за определенный период.
Если это Slack, возможно, он пригласил n коллег в чат.
По сути, это называется “активация”: первый момент во время использования продукта, когда пользователь извлекает ценность. Важно, что пользователь вполне может и не осознать этот момент 😉
И последнее, что я повторяю из раза в раз: начинать надо не с метрики, а с цели, а в данном контексте — с определения пользы. Если Uber определяет свою пользу в том, чтобы сделать более удобную и сравнимую по цене замену общественному транспорту, это одно. Если они думают про сокращение использования автомобилей на человека, это другое. И, к слову, польза Uber для водителя и для пассажира будет звучать по-разному.
“E — Engagement (Вовлеченность): уровень вовлечённости пользователя, часто измеряется через поведенческие прокси, такие как частота, интенсивность и глубина взаимодействия за какой-то период. Примеры могут включать количество посещений на пользователя за неделю или количество фото, которые пользователь загружает ежедневно”.
Engagement метрики прекрасны и для определения успешности проекта:
- в случае customer-facing фич engagement должен остаться на том же уровне (при условии улучшения других метрик) или вырасти
- в случае инфраструктурных изменений engagement должен остаться на том же уровне.
В чем отличие между активацией и вовлеченностью?
Активация — это конкретный момент в «путешествии» пользователя. Соответственно, нас интересует количество людей, дошедших до этой точки, и как это количество можно увеличить. Вот мы упомянули в качестве активации для Spotify n минут прослушивания музыки в день. Как это определяется? Spotify выбрал пользователей, которые успешны в их понимании: например, они платящие, они пользуются продуктом уже несколько лет, они оставляют высокие оценки в сторе. Если сравнить их с неуспешными пользователями, было ли какое-то действие, которое они совершили? И, соответственно, дальше — если мы подведём неуспешных пользователей к этому действию, станут ли они успешными?
Вовлечённость — это, собственно, само путешествие; флажки, которые показывают, насколько хорошо функционирует продукт.
“Adoption (Принятие): новые пользователи продукта или фичи. Например: количество аккаунтов, созданных за последние 7 дней, или процент пользователей Gmail, которые используют лейблы”.
А вот здесь надо снова вернуться к метрикам маркетинга vs метрики продукта. Adoption как раз прекрасный пример метрики, которая где-то на стыке.
Может ли улучшение качества продукта или новая крутая фича увеличить количество новых пользователей? Может. Может ли рекламная кампания или пост в блоге увеличить количество регистраций? Может.
В моей практике второе случалось чаще, чем первое; вполне возможно, что из-за специфики продуктов, с которыми я работала. Ещё один немаловажный фактор, почему я все же больше отношу эту метрику к маркетингу, — это пользовательская привычка. Очень небольшое количество людей регулярно проверяет, как там обновился ваш продукт, особенно если они уже используют конкурента и создали вокруг него какой-то процесс (например, когда я иду на работу, слушаю подкасты в Spotify) или, что ещё хуже для вас, добавили свою персональную информацию (например, когда я делаю фото на телефон, загружаю их в iCloud). Чем дольше пользователь использует продукт, тем, вероятно, выше для него будет цена переключения. Таким образом, чтобы заставить пользователя перейти к вам, нужно либо чтобы у конкурента был видимый недостаток, которого у вас нет, либо у вас должна быть киллер-фича, которой нет у конкурента. В обоих случаях это предполагает два варианта:
- Пользователю вроде как все нравится, потому что он не знает, как может быть лучше — маркетинг его информирует об альтернативах.
- Пользователь недоволен текущим решением и пользуется им, потому что не видит/не нашел лучших вариантов — опять же, нужно ему о них рассказать с помощью маркетинговых инструментов.
Безусловно, есть ещё фактор сарафанного радио, когда пользователи в восторге от продукта и делятся рекомендациями с друзьями. Но, на мой взгляд, с точки зрения продукта это лучше отражается тремя другими метриками:
- activation (осознал ли пользователь ценность продукта)
- engagement (продолжает ли он получать пользу)
- retention.
“Retention (Удержание): процент пользователей, возвращающихся в продукт. Например: как много активных пользователей в выбранный момент все ещё пользуются продуктом в более поздний момент? Возможно, вам даже больше будет интересна обратная метрика, где удержать пользователей не удалось, — отток или churn”.
Тут мало что можно добавить: retention для большей части сервисов — одна из важнейших продуктовых метрик. В моей практике retention + engagement определяли успех продукта или фичи и наиболее точно соответствовали ценности, которую получает пользователь.
Churn не работает на уровне фичи, но, наверное, будет самым громким звоночком, что с продуктом что-то не так. Понятно, что будет часть пользователей, которая будет утекать по естественным причинам; нам же наиболее интересны прошедшие активацию пользователи, которые решили уйти.
“Task success (Успех в выполнении задания): включает в себя традиционные поведенческие UX метрики, например, оперативность (пример — время на выполнение задания), эффективность (процент выполненных заданий) и процент ошибок. Эта категория наиболее применима к части продукта, ориентированной на выполнение задачи: например, поиск или процесс загрузки”.
Пример метрики, которая отлично работает для UX-исследований, но, на мой взгляд, не особо хорошо подходит в качестве продуктовой. Перечисленные выше примеры, скорее, относятся к техническим метрикам или метрикам “здоровья продукта”, и это совсем другая категория.
Возьмем, к примеру, яндексовый поиск. Да, можно улучшить время ответа, но при этом найти трешовые или нерелевантные результаты, которые не принесут пользы юзеру. Из этого следуют 2 вывода:
- технические метрики на уровне продукта или сервиса надо рассматривать с учетом пользовательских метрик
- технические метрики показывают эффективность продукта, но далеко не всегда — его ценность и качество.
За технические метрики обычно отвечает не PM, а разработчики или технический менеджер. Улучшают их чаще всего по одной из двух причин:
- Есть определенный стандарт в индустрии, которого надо достичь, чтобы быть конкурентоспособным. Например, если вы делаете поиск, ваше время ответа ну никак не может быть 1 минута.
- Текущие лимиты ограничивают возможности компании для роста.
Следующий фрагмент будет без моих комментариев; но, думаю, вы и так поймете, где там противоречащие друг другу куски ;)
“Эти метрики можно применять на разных уровнях — от всего продукта до конкретной фичи. Например, в Gmail мы можем быть заинтересованы как в adoption продукта в целом, так и в adoption ключевых фич (например, лейблов или архивирования).
Нас часто спрашивают: “Зачем измерять adoption или retention, когда ты просто можешь посчитать уникальных пользователей?”. Безусловно, важно понимать, сколько пользователей к вам приходит за определенный период (например, активные пользователи за 7 дней). Но если вы также измеряете adoption и retention, вы точно отделите новых пользователей от возвращающихся и сможете быстро понять, растет ли ваша аудитория. Это особенно важно для новых продуктов или фич, или для редизайна.
Необязательно создавать метрики во всех из этих категорий — вы можете выбрать только те, которые наиболее важны для вашего проекта. Фреймворк HEART может помочь вам решить, какая из категорий вам нужна. Например, в бизнес-продуктах, которыми пользователи, возможно, пользуются ежедневно и где они интегрированы в рабочий процесс, может быть бессмысленно мерять вовлеченность, зато может быть интереснее сосредоточиться на счастье пользователя или на task success. Как бы то ни было, может быть полезно учитывать engagement на уровне определенных фич, как индикатор их полезности.
“Итак, как же перейти от HEART категорий к метрикам, которые вы можете внедрить и трекать? К сожалению, нет готового HEART дашборда, который магически за вас это сделает, — наиболее вероятно, что самые полезные метрики будут специфичны для вашего продукта или проекта.
Цели
Порой хочется начать думать о метриках, просто составляя длинный лист, но он быстро может стать громоздким и неудобным в приоритезации. В идеале вам нужен небольшой сет ключевых метрик, которые важны для всех членов команды. Чтобы понять, что это за метрики, надо начать на уровень выше: определить цели, а потом уже выбрать метрики, которые помогут вам измерять прогресс по выполнению этих целей.
Порой может быть удивительно сложно сформулировать цели проекта, и в этот момент полезно использовать для дискуссии категории метрик HEART. В YouTube, к примеру, одна из наиболее важных целей относится к категории Engagement: мы хотим, чтобы пользователи наслаждались видео, которые они смотрят, и продолжали открывать больше видео и каналов, которые они хотели бы посмотреть. У вас могут быть разные цели для определенного проекта или фичи — и для продукта в целом. Для YouTube Поиска ключевая цель относится к Task Success категории: когда пользователь вводит запрос, мы хотим, чтобы он быстро и легко нашел наиболее релевантные видео или каналы.
Частая ловушка — определять цели в рамках ваших существующих метрик: например, “наша цель увеличить трафик на сайт”. Да, каждый хочет это сделать, но как UX-улучшения помогут вам в этом? Хотите ли вы увеличить вовлеченность существующих пользователей или привлечь новых?
Вы можете не осознавать, что у разных членов вашей команды могут быть разные представления о целях вашего проекта. Этот процесс предоставляет возможность достичь соглашения о том, в каком направлении вы движетесь.
Сигналы
Следующий шаг — привязать цели к более низкоуровневым сигналам. Как успех или провал в достижении целей может проявить себя в пользовательском поведении или отношении? Например, сигналом вовлеченности для YouTube может быть количество видео, просмотренных пользователем, а еще лучше — время, потраченное на просмотр видео. Сигналом провала в Task Sucess категории для YouTube Search может быть запрос, по которому не было ни одного клика на результаты.
Обычно есть большое количество потенциально полезных сигналов для конкретной цели. Как только вы набросаете какое-то количество “кандидатов”, остановитесь и проведите небольшое исследование.
Во-первых, насколько легко трекать каждый сигнал? Будут ли логироваться нужные действия в продукте, или можно ли это сделать? Можете ли вы выкатывать опросы на постоянной основе? Для Task Success метрик одна из опций — использовать задания в benchmarking исследовании, которые можно проводить с большим количеством участников.
Во-вторых, выбирайте сигналы, которые будут чувствительны к изменениям в вашем дизайне. Если вы уже собираете потенциально полезные сигналы, вы можете проанализировать имеющиеся данные и попытаться понять, какие сигналы будут точнее всего предсказывать достижение соответствующей цели.
Метрики
Сигналы, которые вы выбрали, можно уточнить и превратить в метрики, которые вы будете трекать в динамике или использовать для сравнения в экспериментах. В примере с вовлеченностью в YouTube мы могли бы внедрить сигнал “как долго пользователи смотрят видео” как метрику “среднее количество минут, потраченное на просмотр видео, на пользователя в день”.
Специфика сильно зависит от вашей инфраструктуры. Но, как и на предыдущем шаге, есть множество метрик, которые можно вывести из определенного сигнала, — вам надо будет проанализировать данные и решить, какие будут для вас наиболее полезны. Возможно, вам также надо будет нормализовать сырые числа и использовать среднее или проценты, чтобы сделать их более “говорящими”.
Процесс Цели-Сигналы-Метрики должен привести к приоритезации метрик — важно трекать метрики, которые относятся к вашим ключевым целям. Не добавляйте просто “интересные цифры” в ваш список. Помогут ли они вам принять решение? Нужно ли вам трекать их в динамике, или достаточно одного измерения? Фокусируйтесь на метриках, которые относятся к вашим целям, чтобы избежать затрат на их внедрение и засорения дашборда.
Если вы хотите, чтобы ваш продуктовый дизайн информировался данными, подумайте над метриками, которые отражают качество user experience, и свяжите их с вашими основными целями”.
Когортный анализ (Cohort Analysis)
Метод анализа метрик продукта на основе поведения групп людей (когорт), объединенных по какому-либо признаку во времени. Обычно в одну когорту объединяют людей, которые начали пользоваться продуктом в один и тот же месяц (или неделю).
Метрика полярной звезды NSM (North Star Metric)
Главная метрика продукта на текущий момент, которая измеряет ключевую ценность продукта для клиентов/пользователей.
Например для Netflix это может быть количество минут, проведенных клиентом за просмотром контента.
Показатель лояльности клиентов NPS (Net Promoter Score)
Метод определения лояльности клиентов к продукту, сервису или компании. NPS измеряет готовность рекомендовать продукт другим людям. При этом людей просим оценить продукт по 10-балльной шкале, где 0 соответствует ответу «Ни в коем случае не буду рекомендовать», а 10 — «Обязательно порекомендую».
- оценки 9-10 относим к сторонникам (промоутерам);
- оценки 7-8 относим к нейтральным;
- оценки 0-6 относим к критикам.
NPS = % сторонников — % критиков
Например:
После тренинга от участников собрали данные о том, насколько они готовы рекомендовать данный тренинг своим коллегам или знакомым. Всего в опросе участвовало 20 человек. Из них 9 поставили оценки 9-10 (промоутеры), 8 человек поставили оценки 7-8 (нейтральные) и 3 человека поставили оценки 5-6 (критики).
NPS = (9-3)/20 = 30%
Показатель удовлетворенности клиентов CSI (Customer Satisfaction Index)
Показатель удовлетворенности клиентов от взаимодействия с продуктом, а также насколько для них важны и ценны те или иные характеристики продукта. Обратная связь о степени удовлетворенности и степени важности собирается по нескольким параметрам, а результаты по всем параметрам обобщаются в единый показатель CSI.
Фреймворк AARRR (Пиратские метрики)
Воронка, состоящая из пяти основных этапов взаимодействия клиента с продуктом, и метрики на этих этапах. Метрики часто соответствуют показателям конверсий между этапами.
- Привлечение (Aqcusition);
- Активация (Activation);
- Удержание (Retention);
- Рекомендации (Referral);
- Выручка (Revenue).
В зависимости от типа продукта и способа монетизации, Выручка (Revenue) может переместиться третий шаг воронки, потому что у вас нет пробной версии продукта, и пользователю нужно сначала заплатить, перед тем как начать использовать продукт.
Представим такую ситуацию: мы наняли специалиста и поставили ему задачу выкопать яму. Прошло время, на вопрос «Как яма?» он отвечает: «Я сделал план копания ямы». Ещё через неделю отвечает: «Лопату я уже выбрал, заказал, но бухгалтерия её не оплатила». Далее его ответы с разной периодичностью выглядят так: «Бухгалтерия лопату оплатила, но не привезли»; «Привезли, я нашёл себе курсы по копанию ям, давайте оплатим».
В итоге через три месяца ямы нет, но есть лопата, курсы по копке и пилотная копка у сотрудника на даче. Задача не выполнена, но работа проделана большая, сотрудник движется к цели, но с низкой скоростью и высокими энергозатратами. Производительность таких сотрудников низкая. Оценить её помогут факап-метрики, пришедшие из области оценки лояльности и вовлечённости клиентов.
Стандартный подход
В IT-отрасли для формирования индивидуальных метрик часто используют готовые модели — так называемые фреймворки (англ. framework — «остов, каркас, структура»). Например, фреймворк HEART (Happiness — «счастье», Engagement — «вовлечённость», Adoption — «принятие», Retention — «удержание» и Task Success — «успех ключевых задач»), который создали в Google для изучения опыта пользователя. Модель позволяет дизайнерам и менеджерам создавать и улучшать продукты, опираясь на собранные данные.
Ещё один популярный фреймворк — PULSE (Page views — «просмотры страниц», Uptime — «время устойчивой работы», Latency — «задержки», Seven-day active users — «активные пользователя за неделю» и Earnings — «заработок») — был создан для оценки показателей производительности и работы продукта.
Разработчики фреймворков рекомендуют выделять одну-две ключевые метрики и в первую очередь ориентироваться на них. Остальные отслеживать в фоновом режиме. Ключевыми должны быть метрики, приносящие наибольшую ценность и прибыль бизнесу.
Провал как показатель
Существует и противоположный подход к оценке показателей. Он основывается на контроле факап-метрик. Например, в компании Booking такой метрикой считают процент незавершённых по техническим причинам заказов, и это один из ключевых KPI при управлении разработкой. За показателем следит отдел маркетинга. Если он высокий, значит, команда увлеклась экспериментами и изменениями в ущерб бизнес-показателям, если низкий — компания развивается слишком медленно, необходимо сфокусироваться на управлении сотрудниками.
В метриках активности, например, для отдела продаж, провалом может считаться уход постоянного клиента или доля клиентов, не совершивших покупку после бесплатного пробного периода.
Вот несколько факап-метрик для менеджеров по продажам, которые я рекомендую отслеживать:
- количество несделанных звонков из запланированных;
- объём непрочитанных писем в почте;
- количество просроченных дел;
- показатель оттока и отказа клиентов;
- количество непрочитанных уведомлений в CRM и таск-менеджере.
При введении таких факап-метрик важно продумать и «вилку показателей»: когда такой показатель критический и меры требуются безотлагательно, а когда он временный и связан, например, с сезонным спадом или влиянием других внешних факторов.
Не стоит использовать только одну метрику. Следует уделять внимание балансу любых показателей: классических, собственных или нестандартных.
Наш опыт
Оценку работы сотрудника мы начинаем с диагностики: смотрим на динамику метрик (в том числе и факап-показателей) за определённый период. Это позволяет понять, с каким фронтом работы сотрудник справляется хуже всего. Иногда важно сфокусироваться только на этой части его функционала, а успехи оставить на потом.
Если число промахов растёт, это сигнал к тому, что необходимы перемены. Возможно, стоит анализировать, развивать и менять его компетенции. Возможно, менять рабочие процессы, делегировать часть его задач другому. Главное — не спешить увольнять сотрудника, ведь он может быть не виноват.
Из всего многообразия факап-метрик мы выделяем три ключевых свидетельства того, что у сотрудника проблемы с организацией работы.
Участие в необязательных задачах. Сотрудник может участвовать в согласовании договоров, но не вносить никаких корректировок, потому что у него нет таких полномочий. Эта работа будет лишней, ведь документ не меняется после его «работы», а внимания требует. При этом сотрудник пропускает уведомления по важным, срочным, неотложным задачам, где его участие действительно необходимо.
Преимущества такого подхода важно показать всей команде. Самые мотивированные сотрудники могут использовать факап-метрику для продвижения по карьерной лестнице, улучшая те свои показатели, которые особенно заметны для руководства и важны для достижения стандартных целевых показателей.
Это модель, состоящая из пяти метрик хорошего UX: H — Happiness (Счастье); E — Engagement (Вовлечение); A — Adoption (Принятие); R — Retention (Удержание); T — Task Success (Успех ключевых задач).
Зачем нужен Heart Framework
Если вы хотите улучшить пользовательский опыт или клиентский опыт — этот фреймворк поможет вам принимать правильные решения о том, что лучше для клиента.
Как использовать Heart Framework
Выделите для каждой метрики фреймворка те пункты, которые есть в вашем бизнесе. Что влияет на UX вашего продукта? Далее, найдите узкие места и сфокусируйтесь на них при работе над улучшением метрик.
Фреймворк «Heart»
Используя эту модель вы сможете более сфокусировано управлять пользовательским опытом, развивать его и совершенствовать — как через изменения дизайна, так и через введение новых функций, удаление или совмещение имеющихся.
Давайте разберем подробно в чем суть этого фреймворка, какие метрики здесь предлагаются к отслеживанию, как их сделать более целенаправленными и действительно отражающими потребности вашего бизнеса.
Метрики HEART фреймворка
В фреймворке HEART выделяются пять метрик, которые значимо влияют на пользовательский опыт.
Название фреймворка сформировано из первых букв этих метрик:
- H — Happiness (Счастье)
- E — Engagement (Вовлечение)
- A — Adoption (Принятие)
- R — Retention (Удержание)
- T — Task Success (Успех ключевых задач)
Очень хорошо, если вы внимательны ко всем из этих метрик. Однако, чтобы достигать лучших результатов, авторы фреймворка вам лучше выделить одну или две ключевые метрики, которые наиболее важны — и сфокусировано работать над ними.
Ключевые метрики — те, которые приносят больше ценности вашим клиентам и больше прибыли вашему бизнесу.
Подумайте над этим — ведь неверный выбор метрики может быть критичным для эффективности изменений, которые вы вносите в продукт.
Помимо этих обобщенных метрик HEART Framework предлагает конкретизировать каждую из них в более конкретные единицы, в зависимости от потребностей вашего бизнеса:
Заполнять соответствующую информацию можно на единой таблице, как показано на рисунке. Так у вас сложится комплексное видение того, что можно улучшать в UX вашего бизнеса:
Давайте разберем каждую из областей UX, которые предлагает этот фреймворк, а также посмотрим в чем разница между целями, сигналами и собственно метриками.
Happiness (Счастье)
Насколько счастливы ваши пользователи? Метрики «счастья» можно определить через проведение исследований и интервью.
Что это может быть:
- Выявление в интервью того, насколько удовлетворены потребности пользователей
- Выявление того, насколько просто и удобно пользоваться продуктом, общая удовлетворенность от клиентского пути (Customer Journey)
- Net Promoter Score («Индекс потребительской лояльности»)
Эта метрика является ключевой, если вы хотите, чтобы ваш продукт и сервис были максимально качественными. «Качественными» в том смысле, что они в наибольшей степени соответствуют интересам и потребностям клиентов.
Engagement (Вовлечение)
Вовлеченность пользователей — это то, насколько полно и регулярно они пользуются продуктом.
Примеры такой метрики:
- Как часто и как долго пользователь взаимодействует с вашим продуктом или сервисом в течение определенного периода времени (например, заходит на сервис и делает определенные действия)
- Как часто пользователь загружает контент, обновляет информацию и т.д.
- Как часто пользователь лайкает контент, комментирует, репостит внутри системы и в других системах
Эта метрика может значить очень многое, если у вас бизнес модель, которая подразумевает регулярное взаимодействие с сервисом, и вы получаете прибыль скорее не «в моменте», а в связи с долговременным взаимодействием с пользователем.
Например, если вы получаете доход от показанной рекламы (типичные примеры — Youtube, Яндекс.Дзен и многие другие «контентные» платформы) — вероятно, вам необходимо уделять этой метрике очень пристальное внимание, ведь это напрямую влияет на прибыль.
Adoption (Принятие)
Принятие, с точки зрения фреймворка HEART — это метрика получения новых пользователь. То есть это то, как много людей «входит» в вашу систему в определенный период времени.
- Новые подписки на сервис
- Покупки, совершенные новыми пользователями
- Обновления приложения / софта до новой версии
- Как много клиентов продолжает пользоваться продуктом после пробного периода
Фокусировка на этой метрике может встать во главу угла, если вы только начинаете разработку продукта и у вас мало продаж, или наоборот — если вы уже развили достаточно качественный продукт и вы готовы масштабироваться.
Retention (Удержание)
Retention — метрика, которая определяет как часто клиент «возвращается» и «удерживается в системе».
Конкретными метриками здесь могут быть:
- Как много пользователей продолжают пользоваться продуктом с течением времени
- Как быстро клиенты отписываются и бросают пользование продуктом
- Повторные покупки
Важная метрика в большинстве современных бизнесов, поскольку напрямую влияет на LTV (общую ценность клиента за весь период его взаимодействия с вашим бизнесом).
В отличие от предыдущий метрики, здесь мы фокусируемся на том, чтобы у нас было не больше клиентов, а чтобы каждый клиент приносил больше денег. И иногда — это более важно.
Действительно, смысл от большого потока клиентов, если они быстро «отваливаются» и больше не возвращаются? Особенно, если вы тратите на привлечение каждого пользователя много денег. В таком ситуации, вероятно, лучше работать на развитие удержания.
Task Success (Успех ключевых задач)
Task Success в фреймворке HEART — это то, насколько пользователи реально решают свои задачи в вашем сервисе / продукте. Насколько ваш сервис реально может решать их задачи. А также то, насколько эффективно (то есть быстро и качественно) эти задачи решаются.
Вот такие могут быть успешные задачи:
Как использовать эти метрики
HEART Framework фокусирует нас на то, что важно для пользовательского опыта. Это то, что влияет на отношение клиента к вашему сервису и к вашему бизнесу соответственно.
Все перечисленные метрики у вас должны быть впорядке, и должны развиваться.
Однако, по теории ограничений Элияху Голдратта, всегда существуют вещи, которые наиболее значимы для усовершенствования здесь–и–сейчас. То есть вы можете выбрать из этих метрики одну или две, которые наиболее важны для пользовательского опыта.
Как понять, какие метрики нужно улучшать и отслеживать?
Давайте разберем три других блока фреймворка — цели, сигналы и метрики, и поймем в чем здесь разница.
Чтобы понять, какие конкретно метрики вы будете измерять, вам нужно определиться с целями. С тем, что конкретно вы хотите получить в результате.
Часто команды имеют рассогласованность относительно целей, которые они достигают, потому что эти цели не сформулированы открытым образом перед всей командой. Поэтому этот блок является важным с точки зрения донесения видения продукта и того, как он должен развиваться.
Важно! Распространенная ошибка — сводить все к уже существующим метрикам. Например, что–то вроде «Мы хотим повысить трафик сайта». Но давайте вспомним, что фреймворк HEART отражает метрики UX, пользовательского опыта.
Поэтому лучше ответьте на вопрос — как конкретно вам поможет улучшение пользовательского опыта в одной из областей? Вы хотите повысить вовлеченность? Или хотите привлекать больше новых пользователей? Или чтобы они возвращались чаще? Понятно, что все это повлияет на трафик, и на деньги. Но что конкретно на это повлияет?
Читайте также: