Как вы будете анализировать причины падения ключевой метрики продукта?

Анализ причин падения ключевой метрики: структурный подход

Когда падает ключевая метрика (выручка, активные пользователи, конверсия), нужна систематическая диагностика. Я расскажу, как я бы это делал, используя методику root cause analysis и сегментацию.

Фаза 1: Быстрая проверка (первые 30 минут)

Шаг 1: Убедиться в реальности падения

-- Проверить последние 30 дней с почасовой детализацией
SELECT 
    DATE_TRUNC('hour', created_at) as hour,
    COUNT(DISTINCT user_id) as active_users,
    COUNT(*) as events,
    SUM(amount) as revenue,
    AVG(amount) as avg_order_value
FROM events
WHERE created_at >= CURRENT_DATE - INTERVAL 7 DAY
GROUP BY hour
ORDER BY hour DESC
LIMIT 168  -- Последняя неделя почасовая

-- Проверить по дням за 90 дней
SELECT 
    DATE(created_at) as day,
    COUNT(DISTINCT user_id) as dau,
    COUNT(*) as total_actions,
    SUM(amount) as daily_revenue,
    ROUND(100.0 * (LAG(SUM(amount)) OVER (ORDER BY DATE(created_at)) - SUM(amount)) 
          / LAG(SUM(amount)) OVER (ORDER BY DATE(created_at)), 2) as pct_change
FROM events
WHERE created_at >= CURRENT_DATE - INTERVAL 90 DAY
GROUP BY DATE(created_at)
ORDER BY day DESC
LIMIT 30

Вопросы для себя:

• Когда произошло падение? (час, день, неделя)
• Насколько резкое падение? (на 10% или на 80%?)
• Одновременное ли падение всех метрик или избирательное?

Шаг 2: Проверить техническую сторону

-- Ошибки в системе
SELECT 
    error_code,
    error_message,
    COUNT(*) as count,
    ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER(), 2) as pct
FROM logs
WHERE timestamp >= CURRENT_TIMESTAMP - INTERVAL 24 HOUR
    AND level IN ('ERROR', 'CRITICAL')
GROUP BY error_code, error_message
ORDER BY count DESC

-- Проверить лейтенси API
SELECT 
    endpoint,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY latency_ms) as p50,
    PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency_ms) as p95,
    PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY latency_ms) as p99,
    COUNT(*) as requests
FROM api_logs
WHERE timestamp >= CURRENT_TIMESTAMP - INTERVAL 24 HOUR
GROUP BY endpoint
ORDER BY p99 DESC

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

• Нет ли deployment/релизов вчера?
• Нет ли падения сервисов (скопировать из Datadog/PagerDuty)?
• Нет ли утечки баз данных или недоступности?
• Нет ли changes в payment gateway?

Фаза 2: Сегментация (следующий час)

Падение метрики обычно неоднородно. Раздели по сегментам.

Сегментация по пользовательским когортам

-- Падение по когортам (новые vs старые)
WITH user_cohorts AS (
    SELECT 
        user_id,
        CASE 
            WHEN DATE(MIN(created_at)) >= CURRENT_DATE - INTERVAL 30 DAY THEN 'new_30d'
            WHEN DATE(MIN(created_at)) >= CURRENT_DATE - INTERVAL 90 DAY THEN 'new_90d'
            ELSE 'established'
        END as cohort
    FROM events
    GROUP BY user_id
)
SELECT 
    DATE(e.created_at) as day,
    c.cohort,
    COUNT(DISTINCT e.user_id) as dau,
    SUM(e.amount) as revenue,
    ROUND(100.0 * (
        LAG(SUM(e.amount)) OVER (PARTITION BY c.cohort ORDER BY DATE(e.created_at)) - SUM(e.amount)
    ) / LAG(SUM(e.amount)) OVER (PARTITION BY c.cohort ORDER BY DATE(e.created_at)), 2) as pct_change
FROM events e
JOIN user_cohorts c ON e.user_id = c.user_id
WHERE e.created_at >= CURRENT_DATE - INTERVAL 30 DAY
GROUP BY DATE(e.created_at), c.cohort
ORDER BY day DESC, cohort

Вопросы:

• Падает у всех когорт или у конкретной? (может быть проблема с акквизицией)
• Падают новые пользователи или старые? (указывает на чёрн выбытие)

Сегментация по географии и девайсам

-- Падение по странам и платформам
SELECT 
    DATE(e.created_at) as day,
    u.country,
    u.platform,
    COUNT(DISTINCT e.user_id) as users,
    SUM(e.amount) as revenue,
    COUNT(*) as actions
FROM events e
JOIN users u ON e.user_id = u.user_id
WHERE e.created_at >= CURRENT_DATE - INTERVAL 30 DAY
GROUP BY DATE(e.created_at), u.country, u.platform
ORDER BY day DESC, revenue DESC

Вопросы:

• Падение глобальное или географически ограниченное?
• Проблема с мобилой или вебом? (указывает на платформе-зависимую причину)

Сегментация по продукту

-- Какие категории/продукты упали?
SELECT 
    DATE(e.created_at) as day,
    p.category,
    p.product_id,
    p.product_name,
    COUNT(DISTINCT e.user_id) as unique_buyers,
    SUM(e.amount) as revenue,
    COUNT(e.id) as orders,
    ROUND(100.0 * (
        LAG(SUM(e.amount)) OVER (PARTITION BY p.product_id ORDER BY DATE(e.created_at)) - SUM(e.amount)
    ) / LAG(SUM(e.amount)) OVER (PARTITION BY p.product_id ORDER BY DATE(e.created_at)), 2) as pct_change
FROM events e
JOIN products p ON e.product_id = p.product_id
WHERE e.created_at >= CURRENT_DATE - INTERVAL 30 DAY
GROUP BY DATE(e.created_at), p.category, p.product_id, p.product_name
HAVING SUM(e.amount) > 0
ORDER BY day DESC, revenue DESC

Вопросы:

• Упали все категории или конкретная?
• Это выглядит как проблема спроса или техническая проблема?

Фаза 3: Декомпозиция метрики (второй-третий час)

Разложи метрику на компоненты. Например, DAU = Sessions * Conversion.

-- Декомпозиция на компоненты
SELECT 
    DATE(created_at) as day,
    COUNT(DISTINCT user_id) as dau,  -- Активные пользователи
    COUNT(DISTINCT session_id) as sessions,  -- Сессии
    ROUND(COUNT(DISTINCT session_id) * 1.0 / COUNT(DISTINCT user_id), 2) as sessions_per_user,
    COUNT(CASE WHEN action_type = 'purchase' THEN 1 END) as purchases,  -- Покупки
    ROUND(100.0 * COUNT(CASE WHEN action_type = 'purchase' THEN 1 END) / COUNT(*), 2) as conversion_pct,
    SUM(CASE WHEN action_type = 'purchase' THEN amount ELSE 0 END) as revenue,
    ROUND(SUM(CASE WHEN action_type = 'purchase' THEN amount ELSE 0 END) * 1.0 / COUNT(CASE WHEN action_type = 'purchase' THEN 1 END), 2) as avg_order_value
FROM events
WHERE created_at >= CURRENT_DATE - INTERVAL 30 DAY
GROUP BY DATE(created_at)
ORDER BY day DESC

Анализ компонентов:

Если падает Revenue, это может быть из-за:

• DAU падает — проблема с акквизицией/удержанием
• Conversion падает — проблема с AARRR (продукт/UX)
• AOV падает — проблема с монетизацией или выбором товара

Фаза 4: Гипотезы и проверка

На основе сегментации выдвигаю гипотезы:

Гипотеза 1: Проблема акквизиции

-- Новые пользователи и их качество
SELECT 
    DATE(u.created_at) as cohort_date,
    COUNT(*) as new_users,
    SUM(CASE WHEN u.created_at >= CURRENT_DATE - INTERVAL 1 DAY THEN 1 ELSE 0 END) as d0_active,
    SUM(CASE WHEN u.created_at >= CURRENT_DATE - INTERVAL 7 DAY THEN 1 ELSE 0 END) as d7_active,
    ROUND(100.0 * SUM(CASE WHEN u.created_at >= CURRENT_DATE - INTERVAL 7 DAY THEN 1 ELSE 0 END) / COUNT(*), 2) as retention_d7,
    SUM(CASE WHEN p.user_id IS NOT NULL THEN 1 ELSE 0 END) as users_with_purchase,
    ROUND(100.0 * SUM(CASE WHEN p.user_id IS NOT NULL THEN 1 ELSE 0 END) / COUNT(*), 2) as conversion_pct
FROM users u
LEFT JOIN payments p ON u.user_id = p.user_id AND p.created_at < CURRENT_DATE
WHERE u.created_at >= CURRENT_DATE - INTERVAL 90 DAY
GROUP BY DATE(u.created_at)
ORDER BY cohort_date DESC

Гипотеза 2: Проблема удержания (churn)

-- Активные пользователи по дням жизни
SELECT 
    DATE(e.created_at) as day,
    DATEDIFF(day, u.created_at, e.created_at) as day_of_life,
    COUNT(DISTINCT e.user_id) as active_users,
    SUM(e.amount) as revenue
FROM events e
JOIN users u ON e.user_id = u.user_id
WHERE e.created_at >= CURRENT_DATE - INTERVAL 30 DAY
    AND DATEDIFF(day, u.created_at, e.created_at) <= 90
GROUP BY DATE(e.created_at), DATEDIFF(day, u.created_at, e.created_at)
ORDER BY day DESC, day_of_life

Гипотеза 3: Изменение поведения пользователей

-- Сравнение поведения неделя на неделю
WITH week1 AS (
    SELECT 
        user_id,
        COUNT(*) as actions,
        SUM(amount) as spent,
        COUNT(DISTINCT session_id) as sessions
    FROM events
    WHERE created_at >= CURRENT_DATE - INTERVAL 7 DAY
        AND created_at < CURRENT_DATE - INTERVAL 1 DAY
    GROUP BY user_id
),
week2 AS (
    SELECT 
        user_id,
        COUNT(*) as actions,
        SUM(amount) as spent,
        COUNT(DISTINCT session_id) as sessions
    FROM events
    WHERE created_at >= CURRENT_DATE - INTERVAL 14 DAY
        AND created_at < CURRENT_DATE - INTERVAL 7 DAY
    GROUP BY user_id
)
SELECT 
    CASE 
        WHEN w2.user_id IS NULL THEN 'churned'
        WHEN w1.user_id IS NULL THEN 'new'
        WHEN w1.spent > w2.spent * 1.5 THEN 'decreased_spending'
        WHEN w1.spent < w2.spent * 0.67 THEN 'increased_spending'
        ELSE 'stable'
    END as behavior,
    COUNT(*) as users
FROM week2 w2
FULL OUTER JOIN week1 w1 ON w2.user_id = w1.user_id
GROUP BY behavior

Фаза 5: Deep Dive (если не найдено)

Если сегментация не показала четкую картину:

1. Проверить feature flags — может ли быть случайный rollout?
2. Проверить маркетинговые кампании — было ли снижение spend?
3. Проверить экономические факторы — выходные, праздники, сезонность?
4. Проверить конкурентов — они запустили что-то мощное?

Шаблон для документирования

Метрика: Revenue (-15% YoY)
Дата обнаружения: 2026-03-26
Начало падения: 2026-03-24

Анализ:
- Техническое состояние: Нормально (no errors, low latency)
- Географическое распределение: Падение глобальное (US -12%, EU -18%, APAC -10%)
- По платформам: Мобиль -20%, Веб -8% (указывает на мобильную проблему)
- По продуктам: Упали top-3 категории (-22%, -18%, -14%)
- По когортам: Равномерное падение (старые и новые пользователи)

Вероятная причина: Payment gateway issue на мобиле (задержка 3-5 сек)

Рекомендация: Проверить интеграцию платежей на iOS

Главное правило

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