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

Решение: Анализ аномалии в метриках

Фреймворк анализа аномалий

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

---

1. Гипотезы для объяснения аномалии

Категория 1: Технические и операционные проблемы

Гипотеза 1.1: Технический сбой (downtime)

• Сервер был недоступен, API работал нестабильно
• Мобильное приложение получило плохой релиз
• Платёжная система была неисправна

Гипотеза 1.2: Проблемы с отслеживанием данных

• Аналитика была отключена или некорректна
• Логирование событий сломалось
• Фильтры в отчётах применены неправильно

Гипотеза 1.3: Изменение в расчётах метрик

• Произошло обновление формулы расчёта
• Изменились фильтры данных
• Произошла миграция данных

Категория 2: Маркетинг и бизнес-события

Гипотеза 2.1: Маркетинговые акции

• Запущена масштабная рекламная кампания (всплеск вверх)
• Окончилась промоакция или скидка (падение вниз)
• Конкурент провел более агрессивную акцию

Гипотеза 2.2: Сезонность и праздники

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

Гипотеза 2.3: Изменения в ценообразовании

• Повысились цены (падение объёма продаж)
• Понизились цены (рост продаж)
• Изменилась система скидок

Категория 3: Продуктовые изменения

Гипотеза 3.1: Релиз новой фичи

• Новая фича увеличила конверсию (всплеск вверх)
• Новая фича сломала UX (падение вниз)
• Изменился checkout процесс

Гипотеза 3.2: Изменения в каталоге

• Убрали популярный товар
• Добавили новый популярный товар
• Изменилась рекомендация товаров

Гипотеза 3.3: Изменение условий доставки

• Повысилась стоимость доставки
• Увеличилось время доставки
• Расширилась география доставки

Категория 4: Конкуренция и рынок

Гипотеза 4.1: Действия конкурентов

• Конкурент снизил цены
• Конкурент запустил масштабную кампанию
• На рынок пришёл новый игрок

Гипотеза 4.2: Изменение спроса на рынке

• Упал спрос в целом по категории
• Произошёл сдвиг в предпочтениях потребителей
• Макроэкономическая ситуация (инфляция, рецессия)

Категория 5: Проблемы с качеством

Гипотеза 5.1: Проблемы с поставками

• Закончился популярный товар
• Задержка в поставке
• Проблемы с логистикой (отсутствие доставки в некоторые регионы)

Гипотеза 5.2: Отзывы о качестве

• Поступило много жалоб на качество
• Продукт получил плохую оценку в соцсетях
• Возросла доля возвратов

---

2. Методы проверки гипотез

Метод 1: Анализ временной линии (Timeline Analysis)

Процесс:

1. Определить точную дату/время аномалии
2. Проверить, что произошло в это время в компании
3. Создать временную линию событий

Что проверять:

Дата аномалии: 15 сентября
├─ 14 сент: Запущена реклама в Instagram (+2млн людей)
├─ 15 сент: Релиз новой версии приложения v3.2
├─ 15 сент: Цены повышены на 10%
├─ 16 сент: На новости вышла критика продукта
└─ 17 сент: Конкурент запустил скидку 50%

SQL для анализа:

SELECT
  DATE(order_date) as date,
  COUNT(DISTINCT order_id) as orders,
  SUM(amount) as revenue,
  LAG(COUNT(DISTINCT order_id)) OVER (ORDER BY DATE(order_date)) as prev_day_orders
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY DATE(order_date)
ORDER BY date;

Метод 2: Сегментированный анализ (Segmented Analysis)

Гипотеза: Если проблема только в одном сегменте, это указывает на конкретную причину

SQL для анализа по категориям:

SELECT
  DATE(o.order_date) as date,
  p.category,
  COUNT(DISTINCT o.order_id) as orders,
  SUM(o.amount) as revenue
FROM orders o
JOIN products p ON o.product_id = p.id
WHERE o.order_date >= '2024-09-10' AND o.order_date <= '2024-09-20'
GROUP BY DATE(o.order_date), p.category
ORDER BY date, category;

Анализ по регионам:

SELECT
  DATE(o.order_date) as date,
  u.region,
  COUNT(DISTINCT o.order_id) as orders,
  SUM(o.amount) as revenue
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.order_date >= '2024-09-10'
GROUP BY DATE(o.order_date), u.region;

Анализ по устройству:

SELECT
  DATE(o.order_date) as date,
  o.device_type,
  COUNT(DISTINCT o.order_id) as orders,
  SUM(o.amount) as revenue
FROM orders o
WHERE o.order_date >= '2024-09-10'
GROUP BY DATE(o.order_date), o.device_type;

Интерпретация:

• Если падение везде → проблема глобальна (маркетинг, конкуренция, макроэкономика)
• Если падение в одной категории → проблема в продукте/ассортименте
• Если падение на мобильных → техническая проблема с приложением
• Если падение в одном регионе → локальная проблема (доставка, конкурент)

Метод 3: Сравнение с бизнес-метриками (Cohort Analysis)

Проверяем, упал ли объём или цена:

SELECT
  DATE(order_date) as date,
  COUNT(DISTINCT order_id) as order_count,
  SUM(amount) as total_revenue,
  ROUND(AVG(amount), 2) as avg_order_value
FROM orders
WHERE order_date >= '2024-09-10' AND order_date <= '2024-09-25'
GROUP BY DATE(order_date)
ORDER BY date;

Интерпретация:

• Если упал только avg_order_value → проблема в цене/скидках
• Если упало количество заказов → проблема в трафике/конверсии
• Если упало и то, и другое → серьёзная проблема

Метод 4: Анализ воронки (Funnel Analysis)

Определяем, на каком этапе произошла проблема:

SELECT
  DATE(event_date) as date,
  event_type,
  COUNT(DISTINCT user_id) as users
FROM events
WHERE event_date >= '2024-09-10' AND event_date <= '2024-09-20'
  AND event_type IN ('view', 'add_to_cart', 'checkout', 'purchase')
GROUP BY DATE(event_date), event_type
ORDER BY date, 
  CASE event_type 
    WHEN 'view' THEN 1
    WHEN 'add_to_cart' THEN 2
    WHEN 'checkout' THEN 3
    WHEN 'purchase' THEN 4
  END;

Интерпретация:

• Если упала фаза "view" → проблема с трафиком
• Если упала фаза "add_to_cart" → проблема с конверсией
• Если упала фаза "purchase" → проблема с платёжной системой

Метод 5: Анализ User Behavior (поведение пользователей)

Проверяем, изменилось ли поведение:

SELECT
  DATE(event_date) as date,
  COUNT(DISTINCT user_id) as active_users,
  COUNT(DISTINCT event_id) as total_events,
  ROUND(COUNT(DISTINCT event_id) / NULLIF(COUNT(DISTINCT user_id), 0), 2) as events_per_user
FROM events
WHERE event_date >= '2024-09-01' AND event_date <= '2024-09-30'
GROUP BY DATE(event_date)
ORDER BY date;

Интерпретация:

• Если упало только active_users → проблема с привлечением
• Если упало events_per_user → проблема с engagement

Метод 6: Сравнение с историческими данными (YoY/WoW)

Year-over-Year (YoY) сравнение:

WITH daily_metrics AS (
  SELECT
    EXTRACT(DOY FROM order_date) as day_of_year,
    EXTRACT(YEAR FROM order_date) as year,
    COUNT(DISTINCT order_id) as orders
  FROM orders
  WHERE order_date >= '2023-09-15' AND order_date <= '2024-09-15'
  GROUP BY EXTRACT(DOY FROM order_date), EXTRACT(YEAR FROM order_date)
)
SELECT
  day_of_year,
  MAX(CASE WHEN year = 2023 THEN orders END) as orders_2023,
  MAX(CASE WHEN year = 2024 THEN orders END) as orders_2024,
  ROUND(100.0 * (MAX(CASE WHEN year = 2024 THEN orders END) - 
                  MAX(CASE WHEN year = 2023 THEN orders END)) / 
        MAX(CASE WHEN year = 2023 THEN orders END), 2) as yoy_change_pct
FROM daily_metrics
GROUP BY day_of_year
ORDER BY day_of_year;

Интерпретация:

• Если аномалия тоже была в прошлом году на эту дату → это сезонность
• Если в прошлом году такого не было → это новое явление

Метод 7: Проверка логов и система мониторинга

Что проверять:

• Application logs: ошибки, exceptions, warnings
• Server metrics: CPU, memory, response time
• Error rates: что-то ломалось на сервере?
• API response time: медленно работает?
• Database performance: slow queries?

---

3. Необходимые данные для анализа

Данные из продукта

• ✅ Все заказы (дата, время, сумма, товар, пользователь)
• ✅ События пользователей (просмотры, клики, добавления в корзину)
• ✅ Платежи (успешные, отклонённые)
• ✅ Возвраты и отмены
• ✅ Отзывы и жалобы пользователей

Данные из маркетинга

• ✅ Рекламные кампании (даты, бюджеты, CTR, CPC)
• ✅ Скидки и промоакции
• ✅ Email кампании
• ✅ Органический трафик (SEO)

Системные данные

• ✅ Логи приложений (errors, exceptions)
• ✅ Метрики сервера (uptime, response time, errors)
• ✅ Версии релизов и даты deploy
• ✅ Изменения в конфигурации

Внешние данные

• ✅ Данные конкурентов (цены, акции, отзывы)
• ✅ Макроэкономические показатели
• ✅ Соцсети (упоминания, тренды)
• ✅ Новости (о компании, индустрии, конкурентах)

---

4. Как определить, является ли это проблемой

Матрица оценки

Вопрос                          Ответ
================================
1. Это статистически значимо?   Используй confidence interval
2. Это превышает noise?          Сравни со стд. отклонением
3. Это персистентно?             Одна аномалия vs тренд
4. Это влияет на бизнес?         Посчитай финансовое влияние
5. Это нужно срочно?             Влияет ли на существование компании

Статистический тест (как отличить аномалию от шума)

WITH daily_data AS (
  SELECT
    DATE(order_date) as date,
    COUNT(DISTINCT order_id) as orders
  FROM orders
  WHERE order_date >= '2024-08-01' AND order_date <= '2024-09-30'
  GROUP BY DATE(order_date)
),
stats AS (
  SELECT
    AVG(orders) as mean_orders,
    STDDEV_POP(orders) as std_orders,
    STDDEV_POP(orders) * 2 as threshold_2sigma
  FROM daily_data
)
SELECT
  dd.date,
  dd.orders,
  s.mean_orders,
  s.threshold_2sigma,
  CASE
    WHEN ABS(dd.orders - s.mean_orders) > s.threshold_2sigma THEN 'ANOMALY'
    ELSE 'NORMAL'
  END as status
FROM daily_data dd
CROSS JOIN stats s
ORDER BY dd.date;

Финансовое влияние

Потеря выручки = (Normal Revenue - Actual Revenue) × Days

Пример:
- Нормальная выручка в день: 10 млн руб
- Падение на 30%: 7 млн руб в день
- Длительность: 5 дней
- Потеря = (10 - 7) × 5 = 15 млн руб

Матрица приоритизации

Финансовое влияние (деньги) × Вероятность (что это проблема)

Высокое × Высокое = НЕМЕДЛЕННО ↑↑↑
Высокое × Низкое  = ИССЛЕДОВАТЬ ↑↑
Низкое × Высокое  = МОНИТОРИТЬ ↑
Низкое × Низкое   = СЛЕДИТЬ

---

Итоговый Алгоритм Анализа

Шаг 1: СРОЧНАЯ ПРОВЕРКА (5 минут)
├─ Сервер работает?
├─ Аналитика работает?
└─ Это реально падение или ошибка в данных?

Шаг 2: БЫСТРАЯ СЕГМЕНТАЦИЯ (15 минут)
├─ По категориям товаров
├─ По регионам
├─ По устройствам
└─ По типам пользователей

Шаг 3: ПРОВЕРКА СОБЫТИЙ (30 минут)
├─ Какие события произошли?
├─ Маркетинг запустил что-то?
├─ Был релиз?
└─ Конкурент что-то сделал?

Шаг 4: СТАТИСТИЧЕСКИЙ АНАЛИЗ (1-2 часа)
├─ Это аномалия или шум?
├─ Есть ли тренд?
└─ Финансовое влияние?

Шаг 5: РЕКОМЕНДАЦИЯ
├─ ДА — это проблема → немедленный action
├─ НЕТ — это ожидаемо → мониторим
└─ НЕИЗВЕСТНО — нужны ещё данные