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

, Блог компании ScrumTrek

Пару недель назад в блоге венчурного фонда Andreessen Horowitz появились две интересные записи, посвященные метрикам стартапов. Первая статья была посвящена 16 метрикам, которые нужно мерить каждому стартапу. Вторая дополняла этот список еще 14-ю метриками.

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

Перечислим их кратко:

Экономические и бизнес-показатели

• Annual Run Rate
• Валовая прибыль

Продуктовые показатели и показатели вовлечённости

• Активные пользователи
• Отток
• Зарегистрированные пользователи
• Количество загрузок

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

К подобным метрикам можно отнести:

1. Количество пользователей. Метрика не дает никакого представления о том, что произошло с продуктом сегодня и насколько это хорошо или плохо, что сегодня к нам пришли 100 человек. Безусловно, охват важен, но без сегментирования и анализа поведения этой аудитории, он не говорит нам абсолютно ни о чем.
2. Выручка. Чаще всего становится продуктовой метрикой, хотя мы можем добиться роста выручки, не меняя продукта вообще, например, регуляруя ценовую политику, проводя рекламные кампании и т.д.
3. Количество скачиваний. Безусловно, скачивания оказывают какое-то влияние на нашу позицию в магазинах мобильных приложений. Но с точки зрения анализа поведения пользователя, лучше попробовать посмотреть конверсии, которые покажут вовлеченность загрузивших приложение пользователей в ваш продукт.
4. Время сесии. Очень сложно оценить качественно эту величину, не производя анализа действий аудитории. Например, нам может показаться, что если время сессии увеличилось с 1 минуты до 5, то это хорошо. Но что если окажется, что 4 из этих 5 минут пользователь пишет обращение в саппорт в форме обратной связи?
5. Like/Share и прочая социальная активность. Пока вы не поймете, сколько тратите на каждый Like/Share и сколько зарабатываете с каждого Like/Share, эти значения не будут вам говорить ровным счетом ни о чем.

Можно ли как-то понять, какие метрики будут полезными?

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

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

Вы можете помочь и перевести немного средств на развитие сайта

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

Из статьи вы узнаете:

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

Когортный анализ в маркетинге и продуктовой аналитике

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

• Первый проехал 2000 км, а второй 12000 км
• Первым автомобилем сейчас пользуются 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 — ваши затраты на привлечение среднего пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Retention

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

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

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

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

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

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

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

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

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

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

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

В заключении

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

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

Об этих вопросах я напишу в другой статье. Если вы хотите не пропускать новые материалы, то .

Основные идеи статьи

• метрики роста не подходят для построения аналитики продукта, так как на них влияет не только продукт, но и маркетинг/продвижение
• две ключевые метрики продукта — LTV и CAC
• LTV — высокоуровневая метрика, поэтому ее следует декомпозировать на метрики продукта, привязанные к ключевым этапам жизненного цикла пользователя в приложении
• суть когортного анализа состоит в том, чтобы отслеживать ключевые метрики каждой отдельной когорты во времени
• когортный анализ позволяет объективно сравнивать разные версии продукта и оценивать влияние изменений на продукт

P.S. Если вы хотите научиться управлять продуктом на основе аналитики и данных, то (новый образовательный продукт от Go Practice) вам в этом поможет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когортный анализ - эффективный инструмент продуктовой и маркетинговой аналитики. Даже те, кто знают о его существовании, используют крайне редко. В рамках серии статей «Курс аналитики» об эффективности когортного анализа расскажет аналитик компании 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. Человеческий капитал . Текучка, время разогрева, уровень навыков.

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

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

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