Какая будет последовательность действий при снижении метрики?

Последовательность действий при снижении метрики

Это критичный скилл для PM. Неправильный ответ на снижение метрики может привести к неправильным решениям. Я следую четкому алгоритму.

Шаг 1: Проверить, что метрика действительно упала (2-4 часа)

Первое, что нужно сделать: Убедиться, что это не ошибка данных или сезонность.

Проверки:

1. Посмотри на временную шкалу

   • День, неделя, месяц?
   • Например: DAU упал на 5% за один день — может быть, technical issue
   • DAU упал на 2% за неделю — может быть, нормальная флуктуация

2. Проверь разбивку по сегментам

   • Упала метрика для всех пользователей или только для одного сегмента (новые, мобильные, US)?
   • Если упала только для новых пользователей, это не регулярные пользователи теряются
   • Это другой вид problem'а

3. Посмотри на когда метрика начала падать

   • Был ли там deploy / release?
   • Был ли маркетинговый push, который закончился?
   • Может быть, это просто конец сезона (summer — люди в отпусках)

4. Проверь, не статистическая ли это ошибка

   • Достаточно ли sample size?
   • Если N = 100, то 5% флуктуация нормальна
   • Если N = 100K, то 5% падение — это реальная проблема

Пример диагностики: MRR упал на 15% за неделю. Но я вижу:

• Новые подписки упали на 40%
• Retention подписчиков normal
• Churn rate normal
• Вывод: проблема в привлечении новых пользователей, а не в retention

Шаг 2: Выберите метрику (Symptom vs Root Cause)

Это критично. Видимая метрика часто — это symptom, а не корень проблемы.

Уровень 1 (Симптомы):

• DAU, MAU упали
• Конверсия упала
• MRR упал
• Retention упал

Уровень 2 (Причины):

• Упала конверсия потому что?
  • Меньше трафика? (traffic issue)
  • Меньше % конвертирующихся? (product issue)
  • Меньше заказов на конвертирующего? (monetization issue)

Уровень 3 (Root cause):

• Меньше трафика потому что:
  • Упал SEO трафик? (органика)
  • Упал платный трафик? (marketing бюджет или ROI)
  • Упали referrals? (product become less shareable)

Мой подход: 5 Whys

Метрика: DAU упал на 20%

1. Почему DAU упал? → Меньше people opening app
2. Почему меньше people? → Retention упала на 30%
3. Почему retention упала? → Crash на Onboarding screen
4. Почему crash? → Новый deploy сломал location service
5. Почему location service не работает? → iOS permission flow изменилась в iOS 17

Root cause: iOS 17 compatibility issue.

Решение: не "улучшить retention", а "fix crash в location service" или "update на iOS 17".

Шаг 3: Оцени масштаб проблемы (30 минут)

Вопросы:

1. Насколько критично это падение?

   • -1% = нормальная флуктуация, ignore
   • -5% = warning, нужно отслеживать
   • -20% = критично, действуй сейчас

2. На что это влияет в бизнесе?

   • MRR упал на 15% = $50K потеря доходов в месяц → очень критично
   • DAU упал на 5% для одного сегмента (tier-3 города) → менее критично

3. Это быстро распространяется или стабилизировалось?

   • День 1: DAU = 100K
   • День 2: DAU = 95K (падает)
   • День 3: DAU = 93K (падает быстрее)
   • День 4: DAU = 92K (замедляется)
   • День 5: DAU = 92K (стабилизировалось)
   • Вывод: падение замедлилось, может быть не нужно панический response

Матрица prioritization:

Шаг 4: Высказь гипотезы (1-2 часа)

Не сразу ищи решение. Сначала перечисли возможные причины.

Пример: MRR упал на 10% за неделю

Возможные гипотезы (я их перечисляю без оценок):

1. Product-side:

   • Была регрессия / баг после последнего deploy
   • Новая фича работает неправильно
   • UX изменился, люди confusion

2. Market-side:

   • Конкурент запустил лучшее предложение
   • Сезонность (лето, праздники, people spend less)
   • Economic downturn

3. Business-side:

   • Маркетинг stopped investing
   • Sales lost big customer
   • Pricing изменился

4. Technical:

   • Performance degradation (app медленнее, люди уходят)
   • Bugs в payment system
   • Infrastructure issue (downtime, slow load)

5. Data:

   • Может быть, это просто статистическая ошибка
   • Может быть, changed how we count MRR

Шаг 5: Проверь гипотезы (2-8 часов)

Для каждой гипотезы:

Гипотеза 1: Баг в product

• Посмотри changelog, что было в последнем deploy
• Есть ли error tracking signals (Sentry, etc)?
• Есть ли reported issues в support?
• Спроси engineering lead: "Видишь ли ты что-то?"

Гипотеза 2: Сезонность / market

• Посмотри прошлые годы: была ли аналогичная падение в этот период?
• Есть ли новости о конкурентах или market?
• Есть ли праздники / vacation season?

Гипотеза 3: Business change

• Спроси Sales team: потеряли ли вы customer'ов?
• Есть ли большая deal, который они теряли?
• Что с marketing spend?

Гипотеза 4: Technical

• Посмотри Application Performance Monitoring (APM)
• Page load time, error rates выросли?
• Были ли downtime'ы?
• Спроси DevOps team

Гипотеза 5: Data error

• Проверь data pipeline
• Есть ли changed в как мы считаем метрику?
• Есть ли duplicates или missing data?

Быстрый тест (15 минут): Я открываю app сам и смотрю:

• Работает ли? Нет crashes?
• UI нормально отображается?
• Transactions работают?
• Если вижу obvious проблему — это быстро решается

Шаг 6: Determine root cause и prioritize (1 час)

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

Пример: MRR упал потому что:

• Новые подписки упали на 40% (не retention issue)
• Это совпал с днем, когда мы запустили новый UI
• Support получил 200+ complaints: "новый UI confusing"
• Analytics показывают: 60% людей уходит после новой onboarding

Root cause: UX в новом интерфейсе confusing.

Шаг 7: Определить тип solution (30 минут)

Решение зависит от типа проблемы:

Шаг 8: Communicate & Act (Immediate)

Немедленное общение:

1. Inform leadership — CEO, Board нужно знать

   • Метрика упала X%
   • Root cause это Y
   • Мы делаем Z
   • ETA для recovery

2. Inform team — Engineering, Design, Support

   • Вот что случилось
   • Вот как мы это фиксим
   • Вот что нужно做

3. Inform customers (если публично)

   • Если есть bug: "Мы это зафиксили"
   • Если есть service issue: "We're working on it"
   • Be transparent, но не паничь

Действие зависит от типа:

• Bug → Revert / hotfix (часы)
• UX problem → A/B test быстро (дни)
• Strategy issue → Plan session (недели)

Реальный пример из моей практики

Проблема: Retention месяц 2 упал с 35% на 25% (28% падение)

Шаг 1: Verify

• Это не one day спайк, это consistent за неделю
• Статистически significant (N = 50K users)

Шаг 2: Segment

• Новые пользователи: retention -30%
• Existing пользователи: retention normal
• Вывод: проблема в onboarding

Шаг 3: Scale

• 10% от MAU не возвращаются (это $50K ARR в месяц)
• Fast-falling: день 1 = 35%, день 7 = 25%
• CRITICAL

Шаг 4-5: Hypotheses & Test

• Может быть, новый onboarding слишком долгий?
• Может быть, tutorials confusing?
• Может быть, пользователи не находят key feature?
• Может быть, new paywall too aggressive?

Шаг 6: Root cause (после анализа)

• Посмотрел analytics: 70% пользователей quitting на день 3, на шаге "выбрать пакет"
• Новый UX paywall был слишком aggressive
• Old paywall: soft suggestion на день 7
• New paywall: hard requirement на день 3

Шаг 7: Solution

• Быстро откатить paywall на день 7
• A/B test (hard paywall vs soft paywall)
• Если soft paywall лучше, кепи it

Шаг 8: Result

• Reverted paywall
• Retention тут же вернулась на 35%
• A/B test потом показал: soft paywall лучше на 18% retention
• Revenue даже выросла (потому что больше люди в paid tier)

Ключевые правила

1. Не паничь — большинство падений имеют simple explanations
2. Verify first — убедиться что это реальная проблема
3. Find root cause — не лечи симптомы
4. Communicate — скажи всем что случилось
5. Act fast — если critical, действи в часы
6. Learn — после fix, поймешь как avoid в future

Этот процесс я применю для любой метрики (DAU, MRR, Churn, NPS и т.д.). Ключ — это систематичность и отсутствие паники.