Как методологически учить младшего аналитика диагностировать внезапное падение ключевой метрики через последовательную декомпозицию SQL-запросов, а не через угадывание причины?

Короткий ответ

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

Как это работает подробнее

Полезно заставлять аналитика перед каждым запросом записывать: наблюдение, гипотезу, ожидаемый результат и решение для каждого исхода. Так SQL становится инструментом проверки, а не генератором случайных срезов.

Декомпозиция должна сохранять арифметическую связь с верхнеуровневой метрикой: например, выручка равна числу заказов, умноженному на средний чек, а сумма сегментов должна сходиться с общим итогом.

Пример кода

metric_drop_by_segment.sqlКопировать

WITH daily AS (
  SELECT event_date, platform, traffic_source,
         COUNT(DISTINCT order_id) AS orders,
         SUM(revenue) AS revenue
  FROM fact_orders
  WHERE event_date >= CURRENT_DATE - INTERVAL '14 days'
  GROUP BY event_date, platform, traffic_source
)
SELECT event_date, platform, traffic_source, orders, revenue,
       revenue / NULLIF(orders, 0) AS average_check
FROM daily
ORDER BY event_date, platform, traffic_source;

Что использовать на практике

• Начните с простого. Проверьте полноту загрузки, календарь, изменение определения и известные релизы.
• Сужайте пространство. Найдите сегмент, дату и компоненту, которые объясняют основную часть отклонения.
• Сохраняйте журнал гипотез. Он показывает, что уже исключено, и позволяет другому аналитику продолжить расследование.

Подводные камни

• Сразу обвинять трекинг. Сезонность, задержка загрузки и изменение состава трафика часто проще и вероятнее.
• Менять несколько измерений одновременно. Такой запрос не показывает, какая гипотеза сработала.
• Не проверять знаменатель. Падение ratio-метрики может быть вызвано ростом знаменателя, а не снижением числителя.