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

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

Выбор правильной метрики для валидации гипотезы - это критический навык Product Manager'а. Неправильная метрика может привести к неправильным решениям и потере ресурсов. Я разработал systematic подход к этому.

Иерархия метрик

То есть существует иерархия важности метрик при проверке гипотезы:

1. Primary Metric (главная метрика)

• Это ОДНА метрика которая напрямую связана с вашей гипотезой
• Должна быть количественная, измеримая, не ambiguous
• Пример: если гипотеза "упрощение checkout увеличит конверсию", то primary metric = conversion rate
• Вторая гипотеза обычно указывает в direction что должна делать метрика (up или down)

2. Secondary Metrics (вспомогательные метрики)

• Показывают полную картину
• Предупреждают о negative side effects
• Пример для checkout: session duration (не должна расти), support tickets (не должны расти)

3. Guardrail Metrics (метрики-страховки)

• Убеждаются что мы не ломаем ничего важного
• Пример: revenue, retention, user satisfaction (NPS)
• Если guardrail метрика падает, даже если primary выросла - это плохо

Как я выбирал metric для каждой гипотезы

Пример 1: "Добавление tutorial улучшит onboarding"

Гипотеза: Tutorial увеличит % пользователей которые завершат onboarding и станут active users

Primary metric: Onboarding completion rate (% новых пользователей которые завершили all required steps)

Secondary metrics:

• Time to complete onboarding (не должно вырасти, ideally падает)
• Tutorial engagement (% юзеров которые в принципе прошли tutorial)
• First action taken (% юзеров которые сделали first meaningful action)

Guardrail metrics:

• Churn в первую неделю (не должно расти)
• DAU (daily active users) через неделю
• Support tickets (особенно complaint типа "не могу понять как...")

Пример 2: "Новый UI дизайн улучшит пользовательский опыт"

Гипотеза: Новый дизайн уменьшит friction при выполнении основных user flows

Primary metric: Task success rate (% пользователей которые успешно выполнили задачу без errors)

Secondary metrics:

• Error rate (errors per session)
• Number of steps to complete (меньше = лучше)
• User satisfaction score (immediate после completing task)

Guardrail metrics:

• Session duration (может вырасти если пользователи более вовлечены, но не резко)
• Bounce rate (не должна расти)
• Time to first action

Пример 3: "Персонализация рекомендаций увеличит engagement"

Гипотеза: Персонализированные рекомендации увеличат % пользователей которые взаимодействуют с рекомендуемым контентом

Primary metric: Click-through rate (CTR) на рекомендации (контролируем impression numbers)

Secondary metrics:

• Conversion rate from recommendation to purchase/favorite
• Time spent on recommended content
• Diversity metrics (не только одинаковый контент)

Guardrail metrics:

• User satisfaction (didn't feel "spammy")
• Engagement with other content (не вытеснили рекомендации другой контент)
• Return rate (пользователи возвращаются)

Как я строил таблицу метрик

Для каждого experiment я создавал таблицу:

Hypothesis: Добавить push notifications увеличит DAU

Primary Metric: DAU (Daily Active Users)
- Current baseline: 100K
- Target: +10% (110K)
- Success criteria: statistically significant at p<0.05
- Measurement: count unique users who opened app on a day

Secondary Metrics:
- Push open rate: 25-35% (shows if push is relevant)
- Session length: 2-3 minutes (not too disrupted)
- Return to app within 7 days: 40% (retention)

Guardrail Metrics:
- Churn rate: should not increase
- Uninstall rate: should not increase
- Negative feedback: %users who report "too many notifications"
- Revenue per user: should not decrease

Критерии для хорошей метрики

Метрика должна быть:

1. Valid (валидна)

• Действительно измеряет то что вы хотите измерить
• Нет correlation vs causation проблемы
• Пример плохой метрики: "среднее количество clicks" если эксперимент добавил кнопку, то clicks автоматически вырастут

2. Sensitive (чувствительна)

• Изменяется когда что-то меняется
• Пример: если гипотеза про мобильный, метрика должна быть мобильная
• Если метрика не moves в тесте, это может значить что она не relevant

3. Actionable (действенна)

• На основе этой метрики можно что-то сделать
• "90% satisfaction" - что дальше?
• "Satisfaction fallen с 95% до 85% в chat feature" - понятно что надо улучшать

4. Directional (чёткое направление)

• Ясно что "хорошо", что "плохо"
• Up is good vs Down is good должно быть clear

5. Learnable (обучающая)

• Если эксперимент fails, метрика должна сказать WHY
• Пример: DAU упала (primary), но clicks на feature выросла (secondary) = может быть баг

Ошибки которые я делал

1. Выбрал слишком много метрик

• Если смотреть на 20 метрик, что-то гарантированно будет выглядеть странно
• Научился: max 3-5 метрик для одного эксперимента

2. Выбрал метрику которая зависит от other factors

• Пример: revenue метрика для 1-недельного эксперимента (может быть noise)
• Научился: убедиться что variation конкретного эксперимента большая enough vs noise

3. Смотрел на данные на пути эксперимента

• Это приводит к false positives (statistical peeking problem)
• Научился: define metrics в advance, запечатать эксперимент, смотреть результаты в конце

4. Ignored guardrails

• Видел что primary metric выросла, но guardrail упал
• Научился: guardrail metrics equally important

Практический процесс

Когда я формулировал гипотезу:

1. Написать гипотезу ясно и специфично
2. Определить primary metric которая напрямую связана
3. Выбрать secondary metrics для контекста
4. Определить guardrails что не должны ломаться
5. Установить baseline (current state)
6. Установить success criteria (какой прирост будет success, p-value, sample size)
7. Запустить эксперимент (минимум 1-2 недели, 100s-1000s users)
8. Анализировать результаты смотря на все метрики insieme

Уровень confidence

Я также определял confidence level нужный для принятия решения:

• Низкий risk decision (small feature, easy to revert): 85% confidence (p<0.15)
• Медиум risk (bigger feature): 90% confidence (p<0.10)
• Высокий risk (major redesign, business critical): 95% confidence (p<0.05)

Это связано с sample size и time нужный для эксперимента.

Итоговое правило

Перед запуском эксперимента я всегда могу ответить на эти вопросы:

1. Какая metric скажет мне что гипотеза верна?
2. Какие side effects должны я контролировать?
3. Что я не допущу случиться (guardrails)?
4. Какой размер effect я ожидаю?
5. Насколько я должен быть confident до принятия решения?

Если я не могу четко ответить на эти вопросы, эксперимент не готов к запуску.