Разбор продуктовых метрик
Анализирует продуктовые метрики и тренды, сравнивает с целями и собирает карту показателей с выводами и рекомендуемыми действиями.
- Что делает
- Анализирует продуктовые метрики и тренды, сравнивает с целями и собирает карту показателей с выводами и рекомендуемыми действиями.
- Когда брать
- При недельном, месячном или квартальном разборе метрик, расследовании внезапного скачка или падения и сравнении показателей с целями.
- Пример запроса
- Разбери метрики продукта за прошлый месяц: что выросло, что упало и почему.
- Работает лучше с
- продуктовая аналитика
Входит в плагин product-management. В Cowork и Claude Code можно поставить плагин целиком.
Как включить
- Нажмите «Скачать на русском» и сохраните архив.
- В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
- Включите скилл переключателем.
Для терминала
Распакуйте архив и положите папку metrics-review в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.
Текст
---
name: metrics-review
description: Разбирает и анализирует продуктовые метрики: анализ динамики и выводы, по которым можно действовать. Используй при еженедельном, ежемесячном или квартальном разборе метрик, при расследовании внезапного скачка или падения, при сравнении показателей с целями или когда нужно превратить сырые цифры в карту показателей с рекомендуемыми действиями.
argument-hint: "<time period or metric focus>"
---
Разбор метрик
Если встретишь незнакомые подстановки или понадобится узнать, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).
Разберись в продуктовых метриках, выяви тренды и сформулируй выводы, по которым можно действовать.
Использование
/metrics-review $ARGUMENTS
Рабочий процесс
1. Собери данные по метрикам
Если подключена ~~product analytics:
- Подтяни ключевые продуктовые метрики за нужный период
- Получи данные для сравнения (предыдущий период, тот же период прошлого года, цели)
- Подтяни разбивку по сегментам, если она доступна
Если инструмент аналитики не подключён, попроси пользователя дать:
- Метрики и их значения (вставить таблицу, скриншот или описать)
- Данные для сравнения (предыдущий период, цели)
- Контекст недавних изменений (запуски, инциденты, сезонность)
Спроси пользователя:
- За какой период делать разбор? (прошлая неделя, прошлый месяц, прошлый квартал)
- На каких метриках сосредоточиться? Или разобрать весь набор продуктовых метрик?
- Есть ли конкретные цели, с которыми нужно сравнивать?
- Известны ли события, которые могут объяснить изменения (запуски, сбои, маркетинговые кампании, сезонность)?
2. Упорядочи метрики
Структурируй разбор по иерархии метрик: наверху ключевая метрика (North Star), затем индикаторы здоровья L1 (привлечение, активация, вовлечённость, удержание, выручка, удовлетворённость) и диагностические метрики L2 для детализации. Полные определения смотри ниже в разделе Иерархия продуктовых метрик.
Если у пользователя не определена иерархия метрик, помоги ему определить ключевую метрику (North Star) и основные метрики L1, прежде чем продолжать.
3. Проанализируй тренды
По каждой ключевой метрике:
- Текущее значение: чему равна метрика сегодня?
- Тренд: растёт, падает или стоит на месте по сравнению с предыдущим периодом? За какой отрезок времени?
- Относительно цели: как она соотносится с целью?
- Скорость изменения: тренд ускоряется или замедляется?
- Аномалии: есть ли внезапные изменения, скачки или падения?
Найди корреляции:
- Совпадают ли изменения одной метрики с изменениями другой?
- Есть ли опережающие индикаторы, которые предсказывают изменения запаздывающих метрик?
- Показывает ли разбивка по сегментам, что общий тренд определяется конкретной когортой?
4. Составь разбор
Резюме
2–3 предложения: общее здоровье продукта, самые заметные изменения, главное, на что стоит обратить внимание.
Карта показателей
Табличный формат для быстрого просмотра:
| Метрика | Сейчас | Раньше | Изменение | Цель | Статус |
|---|---|---|---|---|---|
| [Метрика] | [Значение] | [Значение] | [+/- %] | [Цель] | [По плану / Под риском / Не достигнута] |
Анализ трендов
По каждой метрике, которую стоит обсудить:
- Что произошло и насколько значительно изменение
- Почему это, вероятно, произошло (причина по известным событиям, связанным метрикам, анализу сегментов)
- Это разовое событие или устойчивый тренд
Светлые пятна
Что идёт хорошо:
- Метрики, которые опережают цели
- Положительные тренды, которые нужно поддерживать
- Сегменты или функции с сильными показателями
Зоны беспокойства
Что требует внимания:
- Метрики, не достигающие целей или идущие вниз
- Ранние предупреждающие сигналы, пока они не стали проблемами
- Метрики, по которым нам не хватает видимости или понимания
Рекомендуемые действия
Конкретные следующие шаги на основе анализа:
- Расследования (глубже разобрать тревожный тренд)
- Эксперименты (проверить гипотезы о том, что могло бы улучшить метрику)
- Вложения (усилить то, что работает)
- Оповещения (внимательнее следить за метрикой)
Контекст и оговорки
- Известные проблемы с качеством данных
- События, влияющие на сопоставимость (сбои, праздники, запуски)
- Метрики, которые нам стоило бы отслеживать, но пока не отслеживаем
5. Дальнейшие шаги
После составления разбора:
- Спроси, нужно ли глубже изучить какую-то метрику
- Предложи подготовить спецификацию дашборда для постоянного мониторинга
- Предложи подготовить предложения по экспериментам для зон беспокойства
- Предложи настроить шаблон разбора метрик для регулярного использования
Иерархия продуктовых метрик
Ключевая метрика (North Star)
Единственная метрика, которая лучше всего отражает основную ценность, которую продукт даёт пользователям. Она должна быть:
- Согласована с ценностью: меняется, когда пользователи получают от продукта больше пользы
- Опережающей: предсказывает долгосрочный успех бизнеса (выручка, удержание)
- Управляемой: продуктовая команда может влиять на неё своей работой
- Понятной: каждый в компании понимает, что она значит и почему важна
Примеры по типам продуктов:
- Инструмент для совместной работы: недельное число активных команд, в которых участвуют 3 и более человек
- Маркетплейс: недельное число завершённых транзакций
- SaaS-платформа: недельное число активных пользователей, завершивших основной рабочий процесс
- Контент-платформа: недельное время активного чтения или просмотра
- Инструмент для разработчиков: недельное число развёртываний с использованием инструмента
Метрики L1 (индикаторы здоровья)
5–7 метрик, которые вместе рисуют полную картину здоровья продукта. Они соответствуют ключевым этапам жизненного цикла пользователя:
Привлечение: находят ли продукт новые пользователи?
- Новые регистрации или старты пробного периода (объём и тренд)
- Конверсия в регистрацию (посетители в регистрации)
- Набор каналов (откуда приходят новые пользователи)
- Стоимость привлечения (для платных каналов)
Активация: доходят ли новые пользователи до момента ценности?
- Доля активации: % новых пользователей, выполнивших ключевое действие, которое предсказывает удержание
- Время до активации: сколько проходит от регистрации до активации
- Доля завершивших настройку: % тех, кто прошёл шаги адаптации
- Первый момент ценности: когда пользователи впервые ощущают основную ценность продукта
Вовлечённость: получают ли активные пользователи пользу?
- DAU / WAU / MAU: активные пользователи за разные периоды
- Соотношение DAU/MAU (липкость): какая доля месячных пользователей возвращается ежедневно
- Частота основного действия: как часто пользователи делают самое важное
- Глубина сессии: сколько пользователи делают за одну сессию
- Освоение функций: % пользователей, использующих ключевые функции
Удержание: возвращаются ли пользователи?
- Удержание D1, D7, D30: % пользователей, вернувшихся через 1 день, 7 дней, 30 дней
- Кривые удержания по когортам: как удержание меняется для каждой когорты регистраций
- Доля оттока: % пользователей или выручки, потерянных за период
- Доля возвращений: % ушедших пользователей, которые вернулись
Монетизация: превращается ли ценность в выручку?
- Конверсия: из бесплатных в платные (для модели freemium)
- MRR / ARR: ежемесячная или годовая регулярная выручка
- ARPU / ARPA: средняя выручка на пользователя или клиента
- Выручка от расширения: рост выручки от существующих клиентов
- Чистое удержание выручки (net revenue retention): удержание выручки с учётом расширения и сокращения
Удовлетворённость: что пользователи думают о продукте?
- NPS: индекс потребительской лояльности (Net Promoter Score)
- CSAT: индекс удовлетворённости клиентов
- Число обращений в поддержку и время их решения
- Оценки в магазинах приложений и тональность отзывов
Метрики L2 (диагностические)
Детальные метрики, которые используются, чтобы разбираться в изменениях метрик L1:
- Конверсия воронки на каждом шаге
- Использование и освоение на уровне функций
- Разбивки по сегментам (по тарифу, размеру компании, географии, роли пользователя)
- Показатели производительности (время загрузки страницы, доля ошибок, задержка API)
- Вовлечённость по типам контента (какие функции, страницы или типы контента вовлекают лучше)
Распространённые продуктовые метрики
DAU / WAU / MAU
Что они измеряют: уникальных пользователей, которые совершают квалифицирующее действие за день, неделю или месяц.
Ключевые решения:
- Что считать «активным»? Вход? Просмотр страницы? Основное действие? Определи это тщательно — разные определения рассказывают разные истории.
- Какой период важнее всего? DAU — для продуктов ежедневного использования (мессенджеры, почта). WAU — для продуктов еженедельного использования (управление проектами). MAU — для менее частых продуктов (налоговые программы, бронирование поездок).
Как их использовать:
- Соотношение DAU/MAU (липкость): значения выше 0,5 говорят о ежедневной привычке. Ниже 0,2 — о редком использовании.
- Тренд важнее абсолютного числа. Растёт ли активное использование, стоит на месте или падает?
- Сегментируй по типу пользователей. Активные и случайные пользователи ведут себя совершенно по-разному.
Удержание
Что оно измеряет: из пользователей, начавших в периоде X, какой процент остаётся активным в периоде Y?
Распространённые периоды удержания:
- D1 (на следующий день): был ли первый опыт достаточно хорош, чтобы вернуться?
- D7 (через неделю): сформировал ли пользователь привычку?
- D30 (через месяц): удержан ли пользователь надолго?
- D90 (через три месяца): это устойчивый пользователь?
Как использовать удержание:
- Стройте кривые удержания по когортам. Ищи: резкое падение в начале (проблема активации), устойчивое снижение (проблема вовлечённости) или выход на плато (хорошо — у тебя есть стабильная удержанная база).
- Сравнивай когорты во времени. Удерживаются ли новые когорты лучше старых? Это значит, что улучшения продукта работают.
- Сегментируй удержание по поведению при активации. Пользователи, прошедшие адаптацию, и не прошедшие. Пользователи, которые использовали функцию X, и не использовавшие.
Конверсия
Что она измеряет: % пользователей, переходящих с одного этапа на следующий.
Распространённые конверсионные воронки:
- Посетитель в регистрацию
- Регистрация в активацию (ключевой момент ценности)
- Из бесплатных в платные (конверсия пробного периода)
- Из пробного периода в платную подписку
- С месячного на годовой тариф
Как использовать конверсию:
- Опиши всю воронку и измерь конверсию на каждом шаге
- Найди самые крупные точки потерь — это твои самые эффективные возможности для улучшения
- Сегментируй конверсию по источнику, тарифу, типу пользователя. Разные сегменты конвертируются очень по-разному.
- Отслеживай конверсию во времени. Улучшается ли она по мере доработки опыта?
Активация
Что она измеряет: % новых пользователей, которые доходят до момента, когда впервые ощущают основную ценность продукта.
Как определить активацию:
- Сравни удержанных и ушедших пользователей. Какие действия совершили удержанные, а ушедшие — нет?
- Событие активации должно сильно предсказывать долгосрочное удержание
- Его должно быть возможно достичь в первой сессии или в первые несколько дней
- Примеры: создал первый проект, пригласил коллегу, завершил первый рабочий процесс, подключил интеграцию
Как использовать активацию:
- Отслеживай долю активации для каждой когорты регистраций
- Измеряй время до активации — быстрее почти всегда лучше
- Строй потоки адаптации, которые ведут пользователей к моменту активации
- Проводи A/B-тесты потоков активации и оценивай влияние на удержание, а не только на долю активации
Рамки постановки целей
OKR (цели и ключевые результаты)
Цели (Objectives): качественные, вдохновляющие цели, описывающие, чего вы хотите добиться.
- Вдохновляющие и запоминающиеся
- Ограничены по времени (квартал или год)
- Задают направление, а не конкретную метрику
Ключевые результаты (Key Results): количественные измерители того, достигнута ли цель.
- Конкретные и измеримые
- Ограничены по времени и имеют чёткую цель
- Основаны на результате, а не на объёме выполненной работы
- 2–4 ключевых результата на одну цель
Пример:
Цель: сделать наш продукт незаменимым в ежедневных рабочих процессах
Ключевые результаты:
- Повысить соотношение DAU/MAU с 0,35 до 0,50
- Повысить удержание D30 для новых пользователей с 40% до 55%
- 3 основных рабочих процесса с долей выполнения задач >80%
Лучшие практики OKR
- Ставь амбициозные, но достижимые OKR. Для «растяжных» OKR целевой уровень выполнения — 70%.
- Ключевые результаты должны измерять итоги (поведение пользователей, бизнес-результаты), а не объём выполненной работы (выпущенные функции, завершённые задачи).
- Не заводи слишком много OKR. 2–3 цели по 2–4 ключевых результата хватит с запасом.
- OKR должны быть некомфортными. Если ты уверен, что достигнешь всех, они недостаточно амбициозны.
- Пересматривай OKR в середине периода. Перераспредели усилия, если какие-то ключевые результаты явно отстают.
- Честно оценивай OKR в конце периода. 0,0–0,3 = провал, 0,4–0,6 = прогресс, 0,7–1,0 = достигнуто.
Постановка целевых значений метрик
- Исходный уровень: чему равно текущее значение? Нужен надёжный исходный уровень, прежде чем ставить цель.
- Эталон: чего достигают сопоставимые продукты? Отраслевые эталоны дают контекст.
- Траектория: каков текущий тренд? Если метрика уже растёт на 5% в месяц, цель в 6% не амбициозна.
- Усилия: сколько вложений стоит за этим? Более крупные ставки оправдывают более амбициозные цели.
- Уверенность: насколько ты уверен в достижении цели? Задай «обязательство» (высокая уверенность) и «растяжку» (амбициозная цель).
Периодичность разбора метрик
Еженедельная проверка метрик
Цель: быстро замечать проблемы, следить за экспериментами, держать руку на пульсе здоровья продукта. Длительность: 15–30 минут. Участники: менеджер продукта, возможно, технический руководитель.
Что разбирать:
- Ключевая метрика (North Star): текущее значение, изменение к прошлой неделе
- Ключевые метрики L1: любые заметные движения
- Активные эксперименты: результаты и статистическая значимость
- Аномалии: любые неожиданные скачки или падения
- Оповещения: всё, что сработало в системе мониторинга
Действие: если что-то выглядит не так, расследуй. Иначе отметь и иди дальше.
Ежемесячный разбор метрик
Цель: более глубокий анализ трендов, прогресса по целям, стратегических выводов. Длительность: 30–60 минут. Участники: продуктовая команда, ключевые заинтересованные лица.
Что разбирать:
- Полная карта показателей L1 с трендами месяц к месяцу
- Прогресс относительно квартальных целей OKR
- Анализ когорт: показывают ли новые когорты результаты лучше?
- Освоение функций: как работают недавние запуски?
- Анализ сегментов: есть ли расхождения между сегментами пользователей?
Действие: определи 1–3 направления для расследования или вложений. Обнови приоритеты, если метрики открыли новую информацию.
Квартальный бизнес-обзор
Цель: стратегическая оценка эффективности продукта, постановка целей на следующий квартал. Длительность: 60–90 минут. Участники: продукт, разработка, дизайн, руководство.
Что разбирать:
- Оценка OKR за квартал
- Анализ трендов по всем метрикам L1 за квартал
- Сравнения год к году
- Конкурентный контекст: изменения рынка и ходы конкурентов
- Что сработало, а что нет
Действие: поставь OKR на следующий квартал. Скорректируй продуктовую стратегию по тому, что показывают данные.
Принципы проектирования дашбордов
Эффективные продуктовые дашборды
Хороший дашборд с первого взгляда отвечает на вопрос «Как дела у продукта?».
Принципы:
- Начинай с вопроса, а не с данных. Какие решения поддерживает этот дашборд? Проектируй от решения.
- Иерархия информации. Самая важная метрика должна быть самой заметной. Ключевая метрика (North Star) наверху, затем метрики L1, метрики L2 доступны при детализации.
- Контекст важнее чисел. Число без контекста бессмысленно. Всегда показывай: текущее значение, сравнение (предыдущий период, цель, эталон), направление тренда.
- Меньше метрик — больше понимания. Дашборд с 50 метриками никому не помогает. Сосредоточься на 5–10 важных. Всё остальное — в подробный отчёт.
- Единые периоды времени. Используй один и тот же период для всех метрик на дашборде. Смешение дневных и месячных метрик создаёт путаницу.
- Визуальные индикаторы статуса. Используй цвет, чтобы показать состояние с первого взгляда:
- Зелёный: по плану или улучшается
- Жёлтый: требует внимания или стоит на месте
- Красный: вне плана или ухудшается
- Применимость на практике. Каждая метрика на дашборде должна быть той, на которую команда может влиять. Если с ней нельзя ничего сделать, ей не место на продуктовом дашборде.
Макет дашборда
Верхняя строка: ключевая метрика (North Star) с линией тренда и целью.
Вторая строка: карта показателей L1 — текущее значение, изменение, цель, статус по каждой ключевой метрике.
Третья строка: ключевые воронки или метрики конверсии — наглядная воронка с потерями на каждом этапе.
Четвёртая строка: недавние эксперименты и запуски — активные A/B-тесты, недавно запущенные функции с ранними метриками.
Низ / детализация: метрики L2, разбивки по сегментам и подробные временные ряды для расследований.
Антипаттерны дашбордов
- «Показушные» метрики (vanity metrics): метрики, которые всегда растут, но не показывают здоровье (всего регистраций за всё время, всего просмотров страниц)
- Слишком много метрик: дашборды, которые нужно прокручивать. Если не помещается на один экран, сократи метрики.
- Нет сравнения: голые числа без контекста (текущее значение без предыдущего периода или цели)
- Устаревшие дашборды: метрики, которые не обновлялись и не разбирались месяцами
- Дашборды объёма работы: измеряют активность команды (закрытые тикеты, влитые изменения кода) вместо результатов для пользователей и бизнеса
- Один дашборд для всех аудиторий: руководителям, менеджерам продукта и инженерам нужны разные представления. Один размер не подходит всем.
Оповещения
Настраивай оповещения для метрик, которые требуют немедленного внимания:
- Пороговые оповещения: метрика падает ниже критического порога или поднимается выше него (доля ошибок > 1%, конверсия < 5%)
- Оповещения о тренде: метрика устойчиво снижается в течение нескольких дней или недель
- Оповещения об аномалиях: метрика значительно отклоняется от ожидаемого диапазона
Гигиена оповещений:
- Каждое оповещение должно подразумевать действие. Если ты ничего не можешь с этим сделать, не оповещай.
- Регулярно пересматривай и настраивай оповещения. При слишком большом числе ложных срабатываний люди начинают игнорировать все оповещения.
- Определи владельца каждого оповещения. Кто реагирует, когда оно срабатывает?
- Задай подходящие уровни серьёзности. Не всё — P0.
Формат результата
Для карты показателей используй таблицы. Используй понятные индикаторы статуса. Резюме делай сжатым — читатель должен уловить суть за 30 секунд.
Советы
- Начинай с «ну и что» — что самое важное в этом разборе метрик? С него и начинай.
- Абсолютные числа без контекста бесполезны. Всегда показывай сравнения (с предыдущим периодом, с целью, с эталоном).
- Осторожнее с определением причин. Корреляция — не причинность. Если метрика сдвинулась, признавай неопределённость в том, почему.
- Анализ сегментов часто показывает, что общая метрика скрывает важные различия. Ровное общее число может скрывать рост одного сегмента и сокращение другого.
- Не все движения метрик имеют значение. Небольшие колебания — шум. Сосредотачивай внимание на значимых изменениях.
- Если метрика не достигает цели, не просто сообщай о промахе — рекомендуй, что с этим делать.
- Разбор метрик должен вести к решениям. Если он не приводит хотя бы к одному действию, он был бесполезен.
Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills/metrics-review, лицензия Apache-2.0. Изменения: перевод на русский язык.
Оригинал на английском
--- name: metrics-review description: Review and analyze product metrics with trend analysis and actionable insights. Use when running a weekly, monthly, or quarterly metrics review, investigating a sudden spike or drop, comparing performance against targets, or turning raw numbers into a scorecard with recommended actions. argument-hint: "<time period or metric focus>" --- # Metrics Review > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Review and analyze product metrics, identify trends, and surface actionable insights. ## Usage ``` /metrics-review $ARGUMENTS ``` ## Workflow ### 1. Gather Metrics Data If **~~product analytics** is connected: - Pull key product metrics for the relevant time period - Get comparison data (previous period, same period last year, targets) - Pull segment breakdowns if available If no analytics tool is connected, ask the user to provide: - The metrics and their values (paste a table, screenshot, or describe) - Comparison data (previous period, targets) - Any context on recent changes (launches, incidents, seasonality) Ask the user: - What time period to review? (last week, last month, last quarter) - What metrics to focus on? Or should we review the full product metrics suite? - Are there specific targets or goals to compare against? - Any known events that might explain changes (launches, outages, marketing campaigns, seasonality)? ### 2. Organize the Metrics Structure the review using a metrics hierarchy: North Star metric at the top, L1 health indicators (acquisition, activation, engagement, retention, revenue, satisfaction), and L2 diagnostic metrics for drill-down. See **Product Metrics Hierarchy** below for full definitions. If the user has not defined their metrics hierarchy, help them identify their North Star and key L1 metrics before proceeding. ### 3. Analyze Trends For each key metric: - **Current value**: What is the metric today? - **Trend**: Up, down, or flat compared to previous period? Over what timeframe? - **vs Target**: How does it compare to the goal or target? - **Rate of change**: Is the trend accelerating or decelerating? - **Anomalies**: Any sudden changes, spikes, or drops? Identify correlations: - Do changes in one metric correlate with changes in another? - Are there leading indicators that predict lagging metric changes? - Do segment breakdowns reveal that an aggregate trend is driven by a specific cohort? ### 4. Generate the Review #### Summary 2-3 sentences: overall product health, most notable changes, key callout. #### Metric Scorecard Table format for quick scanning: | Metric | Current | Previous | Change | Target | Status | |--------|---------|----------|--------|--------|--------| | [Metric] | [Value] | [Value] | [+/- %] | [Target] | [On track / At risk / Miss] | #### Trend Analysis For each metric worth discussing: - What happened and how significant is the change - Why it likely happened (attribution based on known events, correlated metrics, segment analysis) - Whether this is a one-time event or a sustained trend #### Bright Spots What is going well: - Metrics beating targets - Positive trends to sustain - Segments or features showing strong performance #### Areas of Concern What needs attention: - Metrics missing targets or trending negatively - Early warning signals before they become problems - Metrics where we lack visibility or understanding #### Recommended Actions Specific next steps based on the analysis: - Investigations to run (dig deeper into a concerning trend) - Experiments to launch (test hypotheses about what could improve a metric) - Investments to make (double down on what is working) - Alerts to set (monitor a metric more closely) #### Context and Caveats - Known data quality issues - Events that affect comparability (outages, holidays, launches) - Metrics we should be tracking but are not yet ### 5. Follow Up After generating the review: - Ask if any metric needs deeper investigation - Offer to create a dashboard spec for ongoing monitoring - Offer to draft experiment proposals for areas of concern - Offer to set up a metrics review template for recurring use ## Product Metrics Hierarchy ### North Star Metric The single metric that best captures the core value your product delivers to users. It should be: - **Value-aligned**: Moves when users get more value from the product - **Leading**: Predicts long-term business success (revenue, retention) - **Actionable**: The product team can influence it through their work - **Understandable**: Everyone in the company can understand what it means and why it matters **Examples by product type**: - Collaboration tool: Weekly active teams with 3+ members contributing - Marketplace: Weekly transactions completed - SaaS platform: Weekly active users completing core workflow - Content platform: Weekly engaged reading/viewing time - Developer tool: Weekly deployments using the tool ### L1 Metrics (Health Indicators) The 5-7 metrics that together paint a complete picture of product health. These map to the key stages of the user lifecycle: **Acquisition**: Are new users finding the product? - New signups or trial starts (volume and trend) - Signup conversion rate (visitors to signups) - Channel mix (where are new users coming from) - Cost per acquisition (for paid channels) **Activation**: Are new users reaching the value moment? - Activation rate: % of new users who complete the key action that predicts retention - Time to activate: how long from signup to activation - Setup completion rate: % who complete onboarding steps - First value moment: when users first experience the core product value **Engagement**: Are active users getting value? - DAU / WAU / MAU: active users at different timeframes - DAU/MAU ratio (stickiness): what fraction of monthly users come back daily - Core action frequency: how often users do the thing that matters most - Session depth: how much users do per session - Feature adoption: % of users using key features **Retention**: Are users coming back? - D1, D7, D30 retention: % of users who return after 1 day, 7 days, 30 days - Cohort retention curves: how retention evolves for each signup cohort - Churn rate: % of users or revenue lost per period - Resurrection rate: % of churned users who come back **Monetization**: Is value translating to revenue? - Conversion rate: free to paid (for freemium) - MRR / ARR: monthly or annual recurring revenue - ARPU / ARPA: average revenue per user or account - Expansion revenue: revenue growth from existing customers - Net revenue retention: revenue retention including expansion and contraction **Satisfaction**: How do users feel about the product? - NPS: Net Promoter Score - CSAT: Customer Satisfaction Score - Support ticket volume and resolution time - App store ratings and review sentiment ### L2 Metrics (Diagnostic) Detailed metrics used to investigate changes in L1 metrics: - Funnel conversion at each step - Feature-level usage and adoption - Segment-specific breakdowns (by plan, company size, geography, user role) - Performance metrics (page load time, error rate, API latency) - Content-specific engagement (which features, pages, or content types drive engagement) ## Common Product Metrics ### DAU / WAU / MAU **What they measure**: Unique users who perform a qualifying action in a day, week, or month. **Key decisions**: - What counts as "active"? A login? A page view? A core action? Define this carefully — different definitions tell different stories. - Which timeframe matters most? DAU for daily-use products (messaging, email). WAU for weekly-use products (project management). MAU for less frequent products (tax software, travel booking). **How to use them**: - DAU/MAU ratio (stickiness): values above 0.5 indicate a daily habit. Below 0.2 suggests infrequent usage. - Trend matters more than absolute number. Is active usage growing, flat, or declining? - Segment by user type. Power users and casual users behave very differently. ### Retention **What it measures**: Of users who started in period X, what % are still active in period Y? **Common retention timeframes**: - D1 (next day): Was the first experience good enough to come back? - D7 (one week): Did the user establish a habit? - D30 (one month): Is the user retained long-term? - D90 (three months): Is this a durable user? **How to use retention**: - Plot retention curves by cohort. Look for: initial drop-off (activation problem), steady decline (engagement problem), or flattening (good — you have a stable retained base). - Compare cohorts over time. Are newer cohorts retaining better than older ones? That means product improvements are working. - Segment retention by activation behavior. Users who completed onboarding vs those who did not. Users who used feature X vs those who did not. ### Conversion **What it measures**: % of users who move from one stage to the next. **Common conversion funnels**: - Visitor to signup - Signup to activation (key value moment) - Free to paid (trial conversion) - Trial to paid subscription - Monthly to annual plan **How to use conversion**: - Map the full funnel and measure conversion at each step - Identify the biggest drop-off points — these are your highest-leverage improvement opportunities - Segment conversion by source, plan, user type. Different segments convert very differently. - Track conversion over time. Is it improving as you iterate on the experience? ### Activation **What it measures**: % of new users who reach the moment where they first experience the product's core value. **Defining activation**: - Look at retained users vs churned users. What actions did retained users take that churned users did not? - The activation event should be strongly predictive of long-term retention - It should be achievable within the first session or first few days - Examples: created first project, invited a teammate, completed first workflow, connected an integration **How to use activation**: - Track activation rate for every signup cohort - Measure time to activate — faster is almost always better - Build onboarding flows that guide users to the activation moment - A/B test activation flows and measure impact on retention, not just activation rate ## Goal Setting Frameworks ### OKRs (Objectives and Key Results) **Objectives**: Qualitative, aspirational goals that describe what you want to achieve. - Inspiring and memorable - Time-bound (quarterly or annually) - Directional, not metric-specific **Key Results**: Quantitative measures that tell you if you achieved the objective. - Specific and measurable - Time-bound with a clear target - Outcome-based, not output-based - 2-4 Key Results per Objective **Example**: ``` Objective: Make our product indispensable for daily workflows Key Results: - Increase DAU/MAU ratio from 0.35 to 0.50 - Increase D30 retention for new users from 40% to 55% - 3 core workflows with >80% task completion rate ``` ### OKR Best Practices - Set OKRs that are ambitious but achievable. 70% completion is the target for stretch OKRs. - Key Results should measure outcomes (user behavior, business results), not outputs (features shipped, tasks completed). - Do not have too many OKRs. 2-3 objectives with 2-4 KRs each is plenty. - OKRs should be uncomfortable. If you are confident you will hit all of them, they are not ambitious enough. - Review OKRs at mid-period. Adjust effort allocation if some KRs are clearly off track. - Grade OKRs honestly at end of period. 0.0-0.3 = missed, 0.4-0.6 = progress, 0.7-1.0 = achieved. ### Setting Metric Targets - **Baseline**: What is the current value? You need a reliable baseline before setting a target. - **Benchmark**: What do comparable products achieve? Industry benchmarks provide context. - **Trajectory**: What is the current trend? If the metric is already improving at 5% per month, a 6% target is not ambitious. - **Effort**: How much investment are you putting behind this? Bigger bets warrant more ambitious targets. - **Confidence**: How confident are you in hitting the target? Set a "commit" (high confidence) and a "stretch" (ambitious). ## Metric Review Cadences ### Weekly Metrics Check **Purpose**: Catch issues quickly, monitor experiments, stay in touch with product health. **Duration**: 15-30 minutes. **Attendees**: Product manager, maybe engineering lead. **What to review**: - North Star metric: current value, week-over-week change - Key L1 metrics: any notable movements - Active experiments: results and statistical significance - Anomalies: any unexpected spikes or drops - Alerts: anything that triggered a monitoring alert **Action**: If something looks off, investigate. Otherwise, note it and move on. ### Monthly Metrics Review **Purpose**: Deeper analysis of trends, progress against goals, strategic implications. **Duration**: 30-60 minutes. **Attendees**: Product team, key stakeholders. **What to review**: - Full L1 metric scorecard with month-over-month trends - Progress against quarterly OKR targets - Cohort analysis: are newer cohorts performing better? - Feature adoption: how are recent launches performing? - Segment analysis: any divergence between user segments? **Action**: Identify 1-3 areas to investigate or invest in. Update priorities if metrics reveal new information. ### Quarterly Business Review **Purpose**: Strategic assessment of product performance, goal-setting for next quarter. **Duration**: 60-90 minutes. **Attendees**: Product, engineering, design, leadership. **What to review**: - OKR scoring for the quarter - Trend analysis for all L1 metrics over the quarter - Year-over-year comparisons - Competitive context: market changes and competitor movements - What worked and what did not **Action**: Set OKRs for next quarter. Adjust product strategy based on what the data shows. ## Dashboard Design Principles ### Effective Product Dashboards A good dashboard answers the question "How is the product doing?" at a glance. **Principles**: 1. **Start with the question, not the data**. What decisions does this dashboard support? Design backwards from the decision. 2. **Hierarchy of information**. The most important metric should be the most visually prominent. North Star at the top, L1 metrics next, L2 metrics available on drill-down. 3. **Context over numbers**. A number without context is meaningless. Always show: current value, comparison (previous period, target, benchmark), trend direction. 4. **Fewer metrics, more insight**. A dashboard with 50 metrics helps no one. Focus on 5-10 that matter. Put everything else in a detailed report. 5. **Consistent time periods**. Use the same time period for all metrics on a dashboard. Mixing daily and monthly metrics creates confusion. 6. **Visual status indicators**. Use color to indicate health at a glance: - Green: on track or improving - Yellow: needs attention or flat - Red: off track or declining 7. **Actionability**. Every metric on the dashboard should be something the team can influence. If you cannot act on it, it does not belong on the product dashboard. ### Dashboard Layout **Top row**: North Star metric with trend line and target. **Second row**: L1 metrics scorecard — current value, change, target, status for each key metric. **Third row**: Key funnels or conversion metrics — visual funnel showing drop-off at each stage. **Fourth row**: Recent experiments and launches — active A/B tests, recent feature launches with early metrics. **Bottom / drill-down**: L2 metrics, segment breakdowns, and detailed time series for investigation. ### Dashboard Anti-Patterns - **Vanity metrics**: Metrics that always go up but do not indicate health (total signups ever, total page views) - **Too many metrics**: Dashboards that require scrolling to see. If it does not fit on one screen, cut metrics. - **No comparison**: Raw numbers without context (current value with no previous period or target) - **Stale dashboards**: Metrics that have not been updated or reviewed in months - **Output dashboards**: Measuring team activity (tickets closed, PRs merged) instead of user and business outcomes - **One dashboard for all audiences**: Executives, PMs, and engineers need different views. One size does not fit all. ### Alerting Set alerts for metrics that require immediate attention: - **Threshold alerts**: Metric drops below or rises above a critical threshold (error rate > 1%, conversion < 5%) - **Trend alerts**: Metric shows sustained decline over multiple days/weeks - **Anomaly alerts**: Metric deviates significantly from expected range **Alert hygiene**: - Every alert should be actionable. If you cannot do anything about it, do not alert on it. - Review and tune alerts regularly. Too many false positives and people ignore all alerts. - Define an owner for each alert. Who responds when it fires? - Set appropriate severity levels. Not everything is P0. ## Output Format Use tables for the scorecard. Use clear status indicators. Keep the summary tight — the reader should get the essential story in 30 seconds. ## Tips - Start with the "so what" — what is the most important thing in this metrics review? Lead with that. - Absolute numbers without context are useless. Always show comparisons (vs previous period, vs target, vs benchmark). - Be careful about attribution. Correlation is not causation. If a metric moved, acknowledge uncertainty about why. - Segment analysis often reveals that an aggregate metric masks important differences. A flat overall number might hide one segment growing and another shrinking. - Not all metric movements matter. Small fluctuations are noise. Focus attention on meaningful changes. - If a metric is missing its target, do not just report the miss — recommend what to do about it. - Metrics reviews should drive decisions. If the review does not lead to at least one action, it was not useful.
Источник: anthropics/knowledge-work-plugins / product-management / metrics-review ↗. Ссылка проверена 2026-10-10.