Метрика упала: фреймворк диагностики за 6 шагов

«DAU упал на 12% за неделю. Что будешь делать?» — на этот вопрос нужно отвечать не гипотезами вроде «наверное, маркетинг отключил рекламу», а структурой. Правильный ответ всегда начинается с одного: сначала проверь, реально ли упала метрика, а не сломался ли подсчёт. Дальше идёт воронка диагностики: данные → сегменты → сезонность → парадокс Симпсона → внешние факторы → действие. Этот пост разбирает каждый шаг с SQL-срезами, которые можно показать прямо на собеседовании. Если пройти их по порядку, вы либо находите причину, либо честно сужаете её до конкретного сегмента — и то, и другое сильнее панического перебора версий.

Почему «метрика упала» — главный вопрос продуктового собеса

Этот кейс встречается на собесах аналитика чаще любого SQL-запроса. Причина простая: он проверяет не знание синтаксиса, а мышление. Интервьюер смотрит, идёте ли вы от данных к выводам или сразу прыгаете к красивой бизнес-гипотезе. Хороший аналитик за 2 минуты декомпозирует падение, а не выдаёт 10 случайных причин.

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

Разбор похожих кейсов есть в разделе вопросы с собесов, а потренироваться в формате реального диалога можно через AI мок-интервью.

С чего начать диагностику падения метрики?

Не с гипотез. Первые два вопроса всегда технические:

• Реально ли упала метрика или сломался её подсчёт?
• Когда именно началось падение — резко или постепенно?

Резкий обрыв (метрика упала с обрыва в один день) почти всегда означает технический сбой: сломался ETL, поменялась схема событий, отвалился трекинг, выкатили баг. Плавное снижение в течение недель — это уже про продукт, рынок или сезонность.

Базовый чеклист по порядку:

Дальше разбираем каждый шаг.

Как проверить, что проблема не в самих данных?

Это первый и самый недооценённый шаг. В 30-40% реальных «падений» метрика на самом деле не падала — сломался её подсчёт. Прежде чем звать продакта, проверьте пайплайн.

Что искать: пропуски событий в отдельные дни, задвоение строк, изменение схемы (переименовали поле event_name), сдвиг таймзоны, поздно приехавшие данные (late-arriving events).

Срез «события по дням» — мгновенно видно дыру в логе:

SELECT
    DATE(event_time)              AS day,
    COUNT(*)                      AS events,
    COUNT(DISTINCT user_id)       AS users,
    COUNT(*) * 1.0
        / NULLIF(COUNT(DISTINCT user_id), 0) AS events_per_user
FROM events
WHERE event_time >= CURRENT_DATE - INTERVAL '21 days'
GROUP BY DATE(event_time)
ORDER BY day;

Если в один из дней events резко проваливается, а events_per_user остаётся прежним — это потеря данных, а не пользователей. Если users стабилен, но events_per_user упал вдвое — отвалилась часть трекинга событий.

Проверка на дубли (раздутая метрика — тоже «аномалия»):

SELECT event_id, COUNT(*) AS cnt
FROM events
WHERE event_time >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY event_id
HAVING COUNT(*) > 1
LIMIT 20;

Только убедившись, что данные чистые, идём в продукт. Отработать такие срезы на живой базе можно в SQL-тренажёре, а сам подход к свежести данных разобран в метриках.

Как сегментировать падение, чтобы найти причину?

Если данные целы, метрика — это всегда сумма по сегментам. Падение редко равномерно по всем. Задача: найти сегмент, где провал максимальный, потому что он и есть точка входа в причину.

Режьте по очереди:

• Платформа: iOS / Android / Web — упало везде или только на одной?
• Гео: страна, регион — глобально или локально?
• Версия приложения: новый релиз ломает что-то у части пользователей?
• Источник трафика: organic / paid / referral — отключили рекламный канал?
• Новые vs вернувшиеся: упал приток или удержание?

SQL-срез DAU по платформам с сравнением двух недель:

SELECT
    platform,
    SUM(CASE WHEN day >= CURRENT_DATE - INTERVAL '7 days'
             THEN dau ELSE 0 END) AS dau_this_week,
    SUM(CASE WHEN day <  CURRENT_DATE - INTERVAL '7 days'
              AND day >= CURRENT_DATE - INTERVAL '14 days'
             THEN dau ELSE 0 END) AS dau_prev_week
FROM (
    SELECT DATE(event_time) AS day,
           platform,
           COUNT(DISTINCT user_id) AS dau
    FROM events
    WHERE event_time >= CURRENT_DATE - INTERVAL '14 days'
    GROUP BY DATE(event_time), platform
) t
GROUP BY platform
ORDER BY dau_this_week;

Считаем процент изменения: Изменение = (текущая неделя − прошлая) / прошлая × 100%. Если на iOS −40%, а на Android −2% — вы уже знаете, где копать. Логика «нашёл худший сегмент → углубляйся в него» работает рекурсивно: внутри iOS режьте по версиям, внутри версии — по экранам.

Что такое сезонность и как её исключить?

Половина мнимых падений — это сезонность. DAU всегда ниже в выходные у B2B-продукта и выше у развлекательного. Если сравнивать вторник с воскресеньем, «падение» окажется обычным циклом.

Три уровня сезонности, которые надо исключить:

• Недельная: будни vs выходные. Сравнивайте день с тем же днём недели прошлой недели (WoW по дню), а не с вчера.
• Годовая (YoY): январь после новогодних праздников всегда проседает. Сравнивайте с тем же периодом год назад.
• Календарные события: праздники, длинные выходные, конец/начало месяца для платёжных метрик.

Срез «тот же день недели за 4 недели» убирает недельный шум:

SELECT
    EXTRACT(DOW FROM day)          AS weekday,   -- 0=вс ... 6=сб
    AVG(dau)                       AS avg_dau,
    MAX(CASE WHEN day >= CURRENT_DATE - INTERVAL '7 days'
             THEN dau END)         AS dau_last
FROM (
    SELECT DATE(event_time) AS day,
           COUNT(DISTINCT user_id) AS dau
    FROM events
    WHERE event_time >= CURRENT_DATE - INTERVAL '35 days'
    GROUP BY DATE(event_time)
) d
GROUP BY EXTRACT(DOW FROM day)
ORDER BY weekday;

Если dau_last для каждого дня недели близок к avg_dau за 4 недели — никакого падения нет, вы поймали выходные. Правило простое: никогда не сравнивайте «сегодня с вчера», сравнивайте с тем же днём недели или применяйте скользящее среднее за 7 дней.

Что такое парадокс Симпсона и почему он ломает метрики?

Парадокс Симпсона — это когда общая метрика падает, хотя в каждом отдельном сегменте она растёт или стоит на месте. Причина не в качестве, а в изменении структуры (mix-shift): доли сегментов сдвинулись.

Классический пример. Конверсия в покупку:

Конверсия выросла в обоих каналах, но общая упала с 7.2% до 4.9%. Почему? Доля дешёвого paid-трафика с низкой конверсией выросла с 17% до 75%. Метрика «упала» из-за притока низкоконверсионного сегмента, а не из-за ухудшения продукта.

SQL, который вскрывает mix-shift — конверсия и доля каждого сегмента:

SELECT
    source,
    COUNT(*)                                  AS users,
    SUM(converted)                            AS buyers,
    ROUND(100.0 * SUM(converted) / COUNT(*), 1) AS conv_pct,
    ROUND(100.0 * COUNT(*)
        / SUM(COUNT(*)) OVER (), 1)           AS share_pct
FROM sessions
WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY source
ORDER BY users DESC;

Сравните share_pct с прошлым периодом. Если доли резко сдвинулись — это Симпсон, и «падение» агрегата вводит в заблуждение. Вывод для интервьюера звучит сильно: «общая конверсия упала из-за смены структуры трафика, продуктовая конверсия в сегментах не ухудшилась». Подобные mix-shift кейсы разобраны в разделе кейсы.

Какие внешние факторы проверить в последнюю очередь?

Когда данные чисты, сегменты разрезаны, сезонность исключена и Симпсона нет — пора смотреть наружу. Эти факторы проверяют последними, потому что их нельзя достать из своей базы одним запросом, и легко скатиться в недоказуемые гипотезы.

Чеклист внешних причин:

• Свои релизы: что выкатили в дни падения? Сверьте дату провала с changelog. Самый частый виновник.
• Маркетинг: отключили платный канал, закончился бюджет, сменилась атрибуция.
• A/B-тесты: запущенный эксперимент с негативным вариантом тянет агрегат вниз.
• Конкуренты и рынок: акция у конкурента, сезон распродаж, общий спад спроса.
• Технические сбои у партнёров: упал платёжный шлюз, эквайринг, SMS-провайдер для логина.
• Внешние события: новости, регуляторика, блокировки, погода (для доставки/такси).

Главное правило этого шага: сопоставляйте дату начала падения с таймлайном событий. Если падение началось 14-го числа, а релиз выкатили 14-го — это не совпадение, проверяйте релиз первым. Откат релиза и повторный замер метрики — самый быстрый способ подтвердить гипотезу.

Как собрать фреймворк в один ответ на собесе?

На кейсе «метрика упала» произнесите вслух структуру, прежде чем считать. Это и есть сигнал зрелости. Скелет ответа:

• Уточняю вопросами: какая метрика, на сколько, за какой период, резко или плавно, какая бизнес-цель.
• Проверяю данные: не сломался ли подсчёт — целостность лога, дубли, схема, late-arriving events.
• Режу на сегменты: платформа, гео, версия, источник, новые/вернувшиеся — ищу, где провал максимален.
• Исключаю сезонность: сравниваю с тем же днём недели, YoY, проверяю праздники.
• Проверяю Симпсона: не сдвинулась ли структура сегментов (mix-shift).
• Смотрю внешние факторы: релизы, маркетинг, A/B, конкуренты — сопоставляю с таймлайном.
• Формулирую гипотезу и проверку: что замерить, как подтвердить, какое действие предложить.

Шпаргалка-вывод, какой инструмент решает шаг:

Этот фреймворк универсален: подставьте вместо DAU выручку, конверсию, retention или средний чек — последовательность шагов не меняется.

Что запомнить

• Сначала проверь, реально ли упала метрика или сломался подсчёт — это первый шаг, не последний.
• Резкое падение → технический сбой; плавное → продукт, рынок, сезонность.
• Метрика — сумма по сегментам: ищи сегмент с максимальным провалом и углубляйся в него.
• Не сравнивай «сегодня с вчера» — сравнивай с тем же днём недели или бери 7-дневное скользящее среднее.
• Парадокс Симпсона: общая метрика может падать, пока во всех сегментах всё растёт — виноват сдвиг структуры.
• Внешние факторы проверяй последними и всегда сопоставляй с таймлайном релизов.
• На собесе структура ответа важнее, чем угадать настоящую причину.

Потренируйся бесплатно: разбери продуктовые кейсы с падением метрик, прогони SQL-срезы из этого поста в SQL-тренажёре и отработай защиту фреймворка вслух в AI мок-интервью. Если идёшь на собес — пройди тестовые задания и курс SQL с нуля, чтобы срезы по сегментам писались на автомате.