Продуктовые метрики. Чем занимается продуктовый аналитик: задачи и обязанности

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

При определении требований к ПО задаются соответствующие им внешние характеристики и их атрибуты (субхарактеристики), определяющие разные стороны управления продуктом в заданной среде. Для набора характеристик качества ПО, приведенных в требованиях, определяются соответствующие метрики, модели их оценки и диапазоны их значений для измерения отдельных атрибутов качества.

Согласно стандарту 1БО 14598 метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика), и особенно на этапе тестирования или функционирования (внешние метрики) продукта. Остановимся на классификации существующих метрик ПО, правилах проведения метрического анализа и процессах их измерения.

Существует три типа метрик: метрики программного продукта, которые используются при измерении его характеристик или свойств; метрики процесса, которые используются при измерении свойств процесса ЖЦ создания продукта; метрики использования.

Метрики программного продукта. Эти метрики используют внешние метрики, обозначающие свойства продукта, видимые пользователю, и внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики программного продукта:

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

Внутренние метрики программного продукта:

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

Существует также некая общая мера - степень трассируемости ПП, которая определяется числом трасс, прослеживаемых с помощью моделей сценариев типа иМЬ, и оценкой количества требований, сценариев и действующих лиц, объектов, включенных в сценарий.

Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.

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

Метрики продукта часто описываются комплексом моделей для установки различных свойств, значений модели качества или прогнозирования. Измерения проводятся, как правило, после калибровки метрик на ранних этапах проекта.

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

Специальной мерой может служить уровень повторного использования компонентов программной системы, измеряемый как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется также при определении стоимости и качества ПО. В качестве примеров таких метрик можно привести следующие характеристики: общее число объектов и число повторно используемых; общее число повторно используемых и новых операций; число классов, наследующих специфические операции; число классов, от которых зависит данный класс; число пользователей класса/операций и др.

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

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

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

• общее время разработки и отдельно время для каждой стадии;
• время модификации моделей;
• время выполнения работ на процессе;
• число найденных ошибок при инспектировании;
• стоимость проверки качества;
• стоимость процесса разработки.

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

Стандартная оценка показателей качества. В соответствии с рассмотренной четырехуровневой моделью качества оценка качества ПО начинается с нижнего уровня иерархии, т.е. с самого элементарного свойства оцениваемого атрибута показателя качества согласно установленным мерам. На этапе проектирования устанавливают значения оценочных элементов для каждого атрибута показателя качества анализируемого ПО, включенного в требования.

По определению стандарта 180/1Е89126-2 метрика качества ПО представляет собой «модель измерения атрибута, связываемого с показателем его качества». При измерении показателей качества ПО стандарт 180/1Е89126-2 рекомендует использовать следующие типы мер:

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

Метрики качества используются при оценке качества программы (безотказной работы, выполнимости функций, удобства применения интерфейсов пользователей, БД и т.п.) с помощью данных, полученных после проведения испытаний на множестве тестов.

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

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

Если в требованиях к ПО было указано использовать несколько показателей, то каждый просчитанный после сбора данных показатель умножается на соответствующий весовой коэффициент, а затем все показатели суммируются для получения комплексной оценки уровня качества ПО. На основе измерения количественных характеристик и проведения экспертизы качественных показателей с применением весовых коэффициентов вычисляется итоговая оценка качества продукта путем суммирования результатов по отдельным показателям и сравнения их с эталонными показателями ПО (стоимость, время, ресурсы и др.).

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

В конечном итоге результат оценки качества является критерием эффективности и целесообразности применения используемых методов проектирования, инструментальных средств и методик оценивания результатов создания программного продукта на стадиях ЖЦ.

Согласно стандарту ДСТУ 3230-1995 для оценки значений показателей качества используются следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов).

Измерительный метод основан на использовании измерительных и специальных программных средств для получения информации о характеристиках ПО, например определения объема, числа строк кода, операторов, количества ветвей в программе, числа точек входа/ выхода, реактивности и др.

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

Расчетный метод базируется на статистических данных, собранных при проведении испытаний, эксплуатации и сопровождении ПО. Расчетными методами оцениваются показатели надежности, точности, устойчивости, реактивности и др.

Экспертный метод осуществляется группой экспертов - специалистов, компетентных в решении данной задачи или используемом ПО. Их оценка базируется на опыте и интуиции, а не на результатах расчетов и экспериментов. Такая экспертиза обычно проводится путем просмотра программ и сопроводительных документов; для этого устанавливаются контролируемые признаки, которые коррелиро-ваны с одним или несколькими показателями качества и включены в опросные карты экспертов. Метод применяется при оценке таких показателей, как анализируемость, документируемость, структурированность ПО, и способствует всесторонней и качественной оценке созданного продукта.

При оценке значений показателей качества в зависимости от особенностей используемых ими свойств, способов их определения и назначения для каждой метрики качества применяется определенная шкала измерений:

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

Показатели, которые вычисляются с помощью метрических

шкал, называются количественными , а показатели, определяемые с помощью порядковых и классификационных шкал, - качественными.

• 1. Номинальная шкала отражает категории свойств оцениваемого объекта без их упорядочения.
• 2. Порядковая шкала служит для упорядочения характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями.
• 3. Интервальная шкала задает существенные свойства объекта (например, календарная дата).
• 4. Относительная шкала задает некоторое значение относительно выбранной единицы.
• 5. Абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).

Когортный анализ это выделение определенной группы пользователей (когорты) и анализ ее поведения во времени. Пользователей в когорте объединяет совершение действия на определенном промежутке времени.

Пример когортного анализа:

Мы разделили пользователей на три когорты, в зависимости от версии приложения которое они скачали и смотрим какой процент из них продолжает пользоваться приложением через 1, 2, 3, 4, 5 и 6 недель.

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

Когортный анализ дает нам понимание о качестве версий 1, 2 и 3 нашего приложения, объясняет какая из версий лучше удерживает пользователей в приложении. Без разделения на когорты мы бы получили усредненные данные по всем версиям, что бесполезно.

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

Из инструментов мобильной аналитики только KISSMetrics поддерживает когорты по параметрам (версия продукта, канал привлечения), поэтому дальше мы будем рассматривать когорты пользователей скачавших приложений в определенную неделю. Изменения показателей при выходе новой версии можно отследить сопоставив дату выхода с неделей когорты.
Метрики роста и метрики продукта Олег Якубенков из ZeptoLab в своем блоге доносит идею метрик роста против метрик продукта. Большинство компаний отслеживает метрики роста: количество активных пользователей в месяц (MAU) и прибыль с приложения. Проблема в том, что на метрики роста влияет и качество продукта и продвижение приложения. По ним сложно понять улучшают ли продукт наши изменения.

Наглядный пример: команда продвижения привлекает каждый месяц на 5 000 пользователей больше, а продукт менеджер в каждой версии вносит изменения снижающие доход на пользователя. Активные пользователи растут, прибыль с приложения растет, но продукт становится все хуже и только через год они пойдут вниз, хотя уже слишком поздно. Поэтому нужно отслеживать так же метрики продукта.

Метрики продукта это LTV — суммарный доход с пользователя пока он не покинет приложение и CAC — стоимость привлечения пользователя. Олег декомпозирует LTV и приводит пример агреггированного когортного отчета для приложения со встроенными покупками.

Подробнее о метриках из отчета читайте в статье .

Когортный анализ во Flurry и Google Analytics Flurry не поддерживает отчеты для когортного анализа, но все же можно его провести.

Для этого создайте сегменты пользователей, скачавших приложение в разные недели (Manage → Segments → Create new segment). Открываете любой отчет и фильтруете по сегменту, разные когорты сравниваете на разных вкладках браузера. Для анализа во времени, отфильтруйте отчет по нужно неделе. В Google Analytics подход такой же. Создаем Advanched Segment с понедельными Date of First Visit.

Это примерное приближение, полноценный когортный анализ во Flurry или GA не осуществить.

Когортный анализ в KISSMetrics и Mixpanel KISSMetrics и Mixpanel поддерживают когортный анализ. В KISSMetrics он называется ‘Cohort Report’ в Mixpanel ’Retention’.

В обоих системах отчет строится по одному принципу: выбираете событие по времени наступления которого создаются когорты (Show people who did). В большинстве случае это запуск приложения. Второе событие (Then come back and did) это то действие пользователя, которое нам интересно.

Примеры пар событий:

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

KISSMetrics умеет строить когорты по параметрам, например, не неделя установки а первая версия скачанного приложения. А Mixpanel создавать сложные когорты с фильтрацией по параметру (канал привлечения, модель телефона, страна, ...).

Я рекомендую Mixpanel. У KISSMetrics нет библиотеки под Android и возможности отфильтровать когортный отчет по каналу привлечения. Тем более Mixpanel можно использовать бесплатно , разместив их банер в подвале сайта.

И к сожалению, инструменты не позволяют построить отчет с суммой покупок за неделю (для LTV) его придется собирать вручную.
Ежемесячные отчеты по мобильному приложению Рекомендую сразу после прочтения письма придумать отчет по примеру Олега и собрать данные. Составляйте этот отчет раз в месяц и рассылайте руководству и всей команде. Не забудьте отмечать в отчете выход новой версии. Через некоторое время вы заметите зависимость между цифрами и не будете изменять продукт в слепую. Да и просто посчитать CAC и LTV — полезное занятие.
Обязательно прочтите Это письмо — введение в когортный анализ, чтобы разобраться до конца обязательно прочитайте:

• «Когортный анализ. Метрики продукта vs метрики роста .»
• «Когортный анализ в

Когортный анализ - эффективный инструмент продуктовой и маркетинговой аналитики. Даже те, кто знают о его существовании, используют крайне редко. В рамках серии статей «Курс аналитики» об эффективности когортного анализа расскажет аналитик компании ZeptoLab Олег Якубенков .

Давайте попробуем сравнить два автомобиля и узнать, какой из них лучше:

• первый проехал 2 000 км, второй - 12 000 км;
• первым автомобилем пользуются 5 раз в неделю, вторым - 4 раза;
• первый автомобиль в последний месяц в среднем проезжал 10 км, второй - 20;
• в данный конкретный момент первый автомобиль едет на скорости 100 км/ч, а второй автомобиль - на скорости 70км/ч.

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

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

Руководителя продукта, в первую очередь, должны интересовать его «объем» и «плотность», а не его «масса». «Масса» просто констатирует факт, не объясняя, откуда она взялась и как на нее повлиять. Нужно стремиться к тому, чтобы разложить ключевые метрики на составляющие, декомпозировать их, определяя рычаги воздействия на них - основная задачей при работе над продуктом.

В этой деятельности не обойтись без аналитики. Аналитика является обратной связью на действия, глазами в продуктовом мире. Сначала аналитика позволяет понять, где мы находимся, что за продукт сделали, как им пользуются в реальном мире, а затем позволяет увидеть то, как действия, вносимые изменения влияют на продукт. Аналитикой на картинке ниже я называю этапы: Measure, Data, Learn.

Одним из наиболее эффективных инструментов продуктовой аналитики является когортный анализ . Именно о нем сегодня пойдет речь.

Почему метрики роста бессмысленны для аналитики продукта

Давайте рассмотрим следующую модельную ситуацию. Есть продукт, который обладает следующими характеристикам:

• стоимость привлечения пользователя составляет 1$;
• средний доход с одного пользователя составляет 2$ в течение следующих 4 месяцев;
• 30% новых пользователей продолжают пользоваться продуктом спустя месяц (далее доля постепенно снижается до 15%);
• команда продвижения привлечет 10 тыс. новых пользователей в первый месяц после запуска, 15 тыс. во второй, 20 тыс. в третий и так далее;
• продакт-менеджер, который отвечает за развитие продукта, вносит в него изменения каждый месяц. Изменения неудачные, поэтому после каждого из изменений доход с пользователя падает на 0,1$, а доля пользователей, продолжающих использовать продукт падает на 2%.

В компании, где разрабатывается этот продукт, принято следить за месячной аудиторией (MAU или Monthly Active Users) и прибылью каждого из проектов. На основе этих метрик выставляются KPI и оцениваются успехи команды, работающей над продуктом.

Следя за выбранными метриками, спустя первые 9 месяцев руководство было очень довольно результатами нового продукта, в том числе и успехами продакт-менеджера. Но вспомните – наш продакт менеджер каждый месяц портит продукт! При этом метрики роста уверенно идут вверх.

Ниже приведены те же самые графики, но уже за 16 месяцев. На этих графиках мы, наконец, видим первые признаки неудачных изменений продукта. Но лишь спустя 12 месяцев.

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

При правильно построенной аналитике мы бы увидели неудачное влияние обновлений продукта еще в первые недели/месяцы.

Суть когортного анализа

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

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

Обычно группы пользователей (когорты) выделяют на основе недели (месяца), когда пользователи пришли в приложение. Выделив такие группы пользователей, мы следим за ними в течение времени и измеряем ключевые метрики для каждой отдельной когорты. Сравнивая показатели мартовской и майской когорт пользователей, можно объективно сравнивать соответствующие этим периодам времени версии продукта.

Для более глубокой аналитики выделенные когорты необходимо дополнительно сегментировать на основе источника трафика, платформы, страны и других факторов, которые имеют смысл в вашем конкретном продукте.

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

Ключевые метрики продукта - LTV и CAC

Две ключевые метрики, которые в конечном итоге определяют финансовую успешность вашего продукта - это LTV (Life Time Value) и CAC (Customer Acquisition Cost).

LTV - деньги, которые средний пользователь тратит в вашем мобильном приложении за все время его использования. CAC - ваши затраты на привлечение среднего пользователя.

Почему эти две метрики так важны для вашего продукта и как они влияют на ваши бизнес показатели вы можете прочитать в материале « Аналитика SaaS. Критерии жизнеспособности » и в материале «Убийца стартапов: стоимость привлечения клиентов » или посмотреть на Vimeo . В рамках же этой статьи важность этих метрик будет принята по умолчанию, а более подробно будет освещены способы работы с этими метриками.

LTV - это ключевая метрика, отражающая ценность (пользу) вашего продукта для ваших пользователей и клиентов . Именно эта метрика должна стоять во главе угла при работе над продуктом.

LTV - замечательная метрика, но у нее есть один минус - она высокоуровневая. Чтобы понимать, как на нее воздействовать, необходимо ее декомпозировать на более простые и приземленные на продукт метрики.

Декомпозиция LTV на метрики продукта

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

Я обычно отслеживаю путь пользователя в продукте с точки зрения его вовлеченности и монетизации.

Вовлеченность описывается следующими этапами в жизненном цикле пользователя:

1. активация в приложении
2. залипание в приложении (или активность использования)
3. долгосрочный retention (сколько пользователей продолжают использовать продукт спустя месяц, два месяца и так далее после регистрации)

Монетизация же описывается следующей последовательностью этапов жизненного цикла пользователя:

1. активация в приложении
2. увидел продающий экран
3. совершил 1 покупку
4. совершил 2 покупку

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

Активация в приложении (% тех, кто прошел туториал или совершил ключевое целевое действие в приложении, например, зарегистрировался и добавил первых друзей);

• залипание в приложении (% пользователей, который дошли до N уровня или, например, добавили N друзей: число N определяется экспериментальным путем);
• пользователь увидел предложение о покупке (% пользователей, которые увидели предложение о покупке);
• пользователь совершил первую покупку (% покупающих что-либо в приложении, средняя сумма первой покупки);
• пользователь совершил повторную покупку (% совершивших повторную покупку, средняя сумма повторной покупки, среднее количество повторных покупок);
• retention (% пользователей, которые используют приложение спустя месяц/два/три/четыре после регистрации).

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

Метрики продукта и как они влияют на LTV

Рассмотрим описанные выше метрики продукта и то, как они влияют на LTV, на примере абстрактной игры.

Активация в приложении

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

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

Пользователь «залип» в приложении

Пользователь, скорее всего, не будет платить, если он не увлекся игрой. Именно поэтому нам надо отслеживать долю тех, кто играет в приложение постоянно. С этой целью мы измеряем долю тех, кто прошел до N уровня или тех, кто заходил в приложении более 5 раз в течение недели с момента установки.

Обычно метрику для факта залипания определяют опытным путем (примеры подобных метрик для ряда популярных сервисов).

Пользователь увидел предложение о покупке, сделал первую покупку

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

Если экран о продаже видят 10% приходящих пользователей, то это автоматически ограничивает сверху долю пользователей, которые могут сделать первую покупку в нашей игре.

Повторные покупки

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

Retention

Для того, чтобы пользователи имели шанс совершить несколько покупок, они должны продолжать играть в нашу игру в течение длительного времени, а не бросать ее спустя день. Для отслеживания этого явления мы будем измерять retention.

Построение продуктовой аналитики и пример использования когортного анализа

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

Далее необходимо сравнивать показатели вашего продукта для когорт пользователей, сформированных на основе недели, когда они пришли в приложение. Для такой аналитики идеально подходят инструменты Mixpanel и Localytics.

Более сложный, но и наиболее продуктивный подход - использование когортного анализа для продуктовой аналитики. Использование когортного анализа углубит ваше понимание продукта и того, как ваши пользователи используют его во времени.

Будем формировать когорты пользователей на основе недели, когда они пришли в приложение. Для простоты в примере рассмотрены только следующие метрики: CAC, LTV, Ratention, % совершивших первую покупку, % совершивших повторную покупку. Также для простоты когорты не сегментировались ни по каким дополнительным признакам.

Ниже приведена таблица когортного анализа рассматриваемого продукта (можете считать, что это игра или туристическое приложение).

В первую неделю в первую версию нашего приложения пришло 3000 пользователей. На конец «0 недели» 25% из них прошли туториал, но еще никто не заплатил. К концу первой недели еще 5% прошли туториал (то есть всего уже 30%), при этом 1,2% совершили первую покупку. К концу второй недели туториал прошли 34% из рассматриваемой когорты, а первую покупку совершили 1,4%.

Спустя неделю мы выпустили новую версию приложения, где изменили туториал. Как мы видим из таблицы когортного анализа - сработало! К концу четвертой недели уже 47% прошли туториал (ранее лишь 34%). Расширение воронки монетизации на уровне туториала увеличило и долю тех, кто совершил покупку. К сожалению, наши пользователи не совершают повторные покупки, что не позволяет выйти на операционную безубыточность продукта, даже несмотря на то, что команда продвижения смогла существенно снизить CAC (пусть и сократив приток новых пользователей). Тратим на привлечение мы 0,8$, а зарабатываем лишь 0,5$ со среднего пользователя спустя 8 недель.

В третьей версии приложения мы доработали туториал и добавили новые покупки в приложение, увеличив разнообразие. Это позволило нам увеличить долю повторных покупок и сравнять LTV с CAC.

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

В заключении

Самый сложный этап в работе над продуктом возникает тогда, когда первые значения метрик для вашего продукта получены и встают вопросы:

• Полученные значения метрик – это хорошо или плохо?
• Над какой метрикой следует работать в следующей версии приложения в первую очередь?
• Как приоритезировать гипотезы, придуманные для улучшения метрики?

Об этом в следующих материалах.

В этой статье разговор пойдет о метриках в процессе продаж. « Выручка » , « Доля рынка » , « Доля в кошелке заказчика » , « Размер воронки продаж » , « Форма воронки продаж » , « Время утилизации CRM системы » , « Соотношение нового и старого продукта » – думаю, эти слова вы уже не раз слышали.

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

В общем и целом, метрики можно разделить на ряд классов:

1. Первый класс -- Метрики процессов продаж – решения или активности, применимые к конкретной личности. Этот класс является высокоуправляемым . К таким метрикам можно отнести: утилизацию CRM системы, объем звонков, соответствие распределения временных затрат ожидаемому и т.д. В большинстве случаев, такую метрику можно применять вплоть до конкретного продавца в части выдачи ему прямых указаний – «тебе необходимо совершать в день больше исходящих звонков» .
2. Второй класс -- Метрики целей продаж – требуют согласия или действия заказчика (или самого продавца) и косвенно управляемы . К таким относятся: результативность звонков, сумма сделки, доля кошелька, соотношение нового продукта к существующему и т.д. Тут влияние ограничено, то есть мы можем сказать продавцу – «выставляй коммерческие предложения не менее 300 тыс. руб.» , но вот какая доля заказчиков согласится на такие условия -- это вопрос открытый. К этому же классу можно отнести такие метрики, как уровень подготовки продавцов, «время разогрева», текучка продающих кадров и т.д.
3. Третий класс -- Метрики результатов продаж – любой результат, зависящий от многих факторов, который не может быть напрямую управляемым . Выручка, размер воронки, доля рынка, длина цикла сделки и т.д.

Теперь об одной из самых главные проблем. Если задать вопрос среднестатистическому директору по продажам или маркетингу: « какие из этих метрик и для чего необходимо применять ». В ы его поставите в тупик, а ответ будет из серии: «Ну как для чего применять, для того чтоб за продажами следить» . На самом деле, правильный ответ несложный:

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

Изучая опыт различных компаний, я пришел к выводу, что практически в каждой из них под процессом продаж понимаются совершенно разные процессы. Хотя на самом деле, идеальный формальный процесс продаж должен описывать все эти подпроцессы. А метрики должны применяться отдельно для каждой отдельной «роли» в процессе продаж. Невозможно успешно использовать одни и те же метрики для разных типов торгующего персонала.

Разберем подробнее Метрики процессов продаж – это самый важный класс, так как тут мы измеряем то, что происходит, а не то, что уже произошло. И повторюсь, именно этот класс метрик имеет прямое отношение к оперативному управлению продажами. На практике существуют следующие базовые подклассы:

1. Время – как персонал управляет своим рабочим временем и приоритетами. Например, доля завершенных в срок задач или процент времени продавца, уходящего на использование Sales Tools и т.д.
2. Звонки – звонок является единицей коммуникации с клиентом. Типичные метрики: процент успешных звонков, количество звонков за смену.
3. Возможности для продаж (Opportunity – большинство людей говоря об управлении процессом продаж, имеют в виду именно эту область). Сколько у нас лидов? Как мы их генерим? Как квалифицируем? Какой процент успешного закрытия? Какая средняя вероятность закрытия и т.д и т.п.
4. Управление заказчиком (он же Account Management ) – процессы длительного взаимоотношения с заказчиком, по которому уже были успешные закрытые сделки. Тут рассматриваются множества разных возможностей на одном заказчике и сложные сделки в B2B с многоступенчатым процессом принятия решения. Тут примерами могут служить такие метрики, как количество суппортеров в сделке, экономический эффект у заказчика от прошлых продаж, среднее количество одновременно открытых сделок на один аккаунт и т.д.
5. Управление территорией – тут все просто, без географии никуда, все на земле живем. Метрики могут применятся нетривиальные – например, плотность звонков на душу населения по целевой территории.
6. Управление потенциалом торгующего персонала (Он же Sales Force Management ). Процент времени, потраченный на обучение, нагрузка на продавца контролирующих механизмов, затраты на IT в расчете на голову продавца, процент рабочего времени на обучающих мероприятиях. Персонал, мотивация, стимулирование и техническое обеспечение продаж – все тут. Кстати, это один из важнейших пластов, но внимания измерениям по нему обычно уделяется меньше всего.

Начинаем совершенствовать области по принципу от красного к зеленому и от младших ролей к старшим.

Теперь о метриках Целей продаж. Тут у нас следующие подклассы:

1. Ресурсная достаточность . А хватает ли у вас, вообще, людей для исполнения плана продаж? Время, уделенное непосредственно продажам, уровень покрытия рынка, количество заказчиков на одного продавца – вот примеры метрик.
2. Эффективность продавца . Типичные метрики: всякие конверсии – звонок во встречу, встреча в контракт, доля результативных встреч. Из более редких, но полезных – средний уровень скидки на рубль продаж.
3. Продуктовые метрики (Они же продуктовый фокус ). Доля нового\существующего продукта, прямые перекрестные продажи, размер сделки и т.д.
4. Метрики классификации заказчиков (Они же Клиентский фокус ). Сегментация, доля кошелька, уровень возврата.
5. Человеческий капитал . Текучка, время разогрева, уровень навыков.

Следующий шаг -- это увязать процессы с целями. На самом деле, в абсолютном большинстве случаев это несложно, и работает довольно простая матрица влияния процессов на цели:

Как эту матрицу использовать на практике?

• Хотите повышать долю успешно закрытых сделок? Это категория эффективности продавца. А значит, вам в первую очередь нужно ковыряться в процессах управления звонками, управления возможностями и потенциалом торгового персонала.
• Запускаете новый продукт? Не забудьте включить рассказ о нем в сценарий типового звонка, в план управления возможностями.
• Маржа маловата? Внедряем согласование скидок в процесс управления возможностями.

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

В процессе дизайна можно полагаться на пользовательские данные и на результаты экспериментов. Это то, что сейчас называется 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, о которой говорится в статье), которые позволяют сделать количественные выводы для usability тестов. Ну это так, для общей картины;)

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

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

Happiness - Счастье

Помогая гугловым командам с UX метриками, мы заметили, что наши предложения обычно попадают в какую-то из 5 категорий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adoption - Принятие

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

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

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

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

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

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

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

Retention - Удержание

Retention (Удержание): процент пользователей, возвращающихся в продукт. Например: как много активных пользователей в выбранный момент все ещё пользуются продуктом в более поздний момент? Возможно, вам даже больше будет интересна обратная метрика, где удержать пользователей не удалось, - отток или churn.

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

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

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

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

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

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

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

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

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

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

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

Нас часто спрашивают: “Зачем измерять adoption или retention, когда ты просто можешь посчитать уникальных пользователей?”. Безусловно, важно понимать, сколько пользователей к вам приходит за определенный период (например, активные пользователи за 7 дней). Но если вы также измеряете 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 мы могли бы внедрить сигнал “как долго пользователи смотрят видео” как метрику “среднее количество минут, потраченное на просмотр видео, на пользователя в день”.

Специфика сильно зависит от вашей инфраструктуры. Но, как и на предыдущем шаге, есть множество метрик, которые можно вывести из определенного сигнала, - вам надо будет проанализировать данные и решить, какие будут для вас наиболее полезны. Возможно, вам также надо будет нормализовать сырые числа и использовать среднее или проценты, чтобы сделать их более “говорящими”.

Процесс Цели-Сигналы-Метрики должен привести к приоритезации метрик - важно трекать метрики, которые относятся к вашим ключевым целям. Не добавляйте просто “интересные цифры” в ваш список. Помогут ли они вам принять решение? Нужно ли вам трекать их в динамике, или достаточно одного измерения? Фокусируйтесь на метриках, которые относятся к вашим целям, чтобы избежать затрат на их внедрение и засорения дашборда.

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

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать .