Разбор падения метрики
Класс кейсов «почему X упал на 20%» — артефакт или реальность, порядок срезов, mix shift и внешние шоки.
15 вопросов
JuniorДизайнОчень частоДашборд показывает падение ключевой метрики на 20% за ночь, команда хочет фикс. Прежде чем выдвинуть хоть одну гипотезу, что вы проверите первым и почему именно в таком порядке? У вас минуты, и нельзя проверить всё сразу.
Дашборд показывает падение ключевой метрики на 20% за ночь, команда хочет фикс. Прежде чем выдвинуть хоть одну гипотезу, что вы проверите первым и почему именно в таком порядке? У вас минуты, и нельзя проверить всё сразу.
Сначала исключите артефакт данных: определение не менялось, счётчики и логирование срабатывают, вчерашние данные полностью загружены. Поломки пайплайна и логирования — самая частая и дешёвая причина; исключить их до продуктовой гипотезы значит не гоняться за призраком.
Типичные ошибки
- ✗Прыгать к гипотезе или фиксу до валидации данных
- ✗Проверять сегменты и релизы до подтверждения реальности числа
- ✗Считать ночное движение слишком большим для артефакта
Уточняющие вопросы
- →Как отличить сломанный счётчик от реального падения?
- →Какая проверка данных даёт больше всего уверенности за меньшее время?
MiddleДизайнОчень частоDAU упал на 20% за ночь без известного релиза. Прежде чем браться за продуктовые гипотезы, как отделить настоящее падение от артефакта логирования или трекинга? Назовите конкретные проверки и какой результат убедит вас, что падение реально.
DAU упал на 20% за ночь без известного релиза. Прежде чем браться за продуктовые гипотезы, как отделить настоящее падение от артефакта логирования или трекинга? Назовите конкретные проверки и какой результат убедит вас, что падение реально.
Сверьте метрику с независимым источником, не разделяющим путь логирования — серверные логи, платежи или счётчик событий на бэкенде. Если и там падение, оно реально; если упала только трекинговая метрика, подозревайте сломанный SDK, тег или пайплайн. И проверьте полноту загрузки дня.
Типичные ошибки
- ✗Доверять одному трекинговому источнику вместо независимой сверки
- ✗Считать трекинг исправным, раз релиза не было
- ✗Путать воспроизводимость запроса с подтверждённым реальным падением
Уточняющие вопросы
- →Какому независимому источнику вы доверитесь больше и почему?
- →Как частичный сбой SDK выглядит против полного?
MiddleДизайнОчень частоОбщая конверсия упала на 20%, но при срезе по любому отдельному измерению ставка в каждом сегменте плоская или даже выросла. Как такое возможно и как найти стоящий за этим mix shift?
Общая конверсия упала на 20%, но при срезе по любому отдельному измерению ставка в каждом сегменте плоская или даже выросла. Как такое возможно и как найти стоящий за этим mix shift?
Общая ставка — взвешенное среднее ставок по сегментам, поэтому она может упасть, пока каждый сегмент держится, если mix сместился к хуже конвертящим сегментам. Найдите это, сравнив долю каждого сегмента до и после, и пересчитав итог на старом mix; если он ровный, сдвинулся mix.
Типичные ошибки
- ✗Верить, что итог не может двигаться, пока каждый сегмент держится
- ✗Игнорировать, как изменилась доля каждого сегмента в mix
- ✗Отчитываться простым средним сегментов как истинным итогом
Уточняющие вопросы
- →Как ловушка агрегации, известная как парадокс Симпсона, порождает это?
- →Как количественно оценить, какую часть падения объясняет mix?
JuniorДизайнЧастоСтейкхолдер пишет «конверсия упала» и просит разобраться. Прежде чем открыть хоть один запрос, что вы у него уточните — и что превращает пугающую цифру в настоящую аномалию, которую стоит расследовать?
Стейкхолдер пишет «конверсия упала» и просит разобраться. Прежде чем открыть хоть один запрос, что вы у него уточните — и что превращает пугающую цифру в настоящую аномалию, которую стоит расследовать?
Оцените масштаб до работы с данными: какая именно метрика, за какое окно, относительно какой базовой линии и насколько велико в абсолюте. Движение — аномалия, только если превышает нормальную дневную и недельную вариацию: колебание в 2% внутри шума или рутинный провал выходных ожидаем.
Типичные ошибки
- ✗Расследовать до подтверждения, что изменение превышает нормальную вариацию
- ✗Не зафиксировать точную метрику, окно и базовую линию
- ✗Считать любой сообщённый провал подтверждённым инцидентом
Уточняющие вопросы
- →Как задать порог для того, что считается аномалией?
- →Как недельные и сезонные паттерны меняют этот порог?
JuniorДизайнЧастоВы подтвердили, что падение метрики реально, и теперь надо его локализовать. Нельзя резать сразу по всем измерениям — как выбрать, какие срезы делать и в каком порядке, чтобы найти, где живёт падение?
Вы подтвердили, что падение метрики реально, и теперь надо его локализовать. Нельзя резать сразу по всем измерениям — как выбрать, какие срезы делать и в каком порядке, чтобы найти, где живёт падение?
Режьте по одному измерению за раз, в порядке вероятности: платформа и версия, затем источник, география и шаг воронки. После каждого среза спрашивайте, сидит ли падение в одном срезе или размазано — концентрация указывает на конкретную причину, разброс на глобальное.
Типичные ошибки
- ✗Резать сразу по всем измерениям вместо одного за раз
- ✗Не спрашивать, сконцентрировано падение или размазано
- ✗Начинать с крошечных сегментов до срезов верхнего уровня
Уточняющие вопросы
- →Как концентрация против равномерного разброса меняет следующий шаг?
- →Что проверите, если ни один срез не объясняет падение?
MiddleДизайнЧастоОдин инцидент — резкий обрыв в 14:00 в конкретный день; другой — плавное сползание за 3 недели. Считая оба реальными, что каждая форма говорит о вероятной причине и как она меняет то, куда вы смотрите в первую очередь?
Один инцидент — резкий обрыв в 14:00 в конкретный день; другой — плавное сползание за 3 недели. Считая оба реальными, что каждая форма говорит о вероятной причине и как она меняет то, куда вы смотрите в первую очередь?
Резкий обрыв на отметке времени указывает на дискретное событие — деплой, смену цены, поломку трекинга — сверяйте с журналом изменений на ту минуту. Плавное сползание — постепенная сила: сезонность, распад когорт, потеря данных — сравнивайте когорты по неделям.
Типичные ошибки
- ✗Считать форму несущественной для вероятной причины
- ✗Приравнивать обрыв к артефакту, а сползание — к реальному спаду
- ✗Сверять плавное сползание с минутой одного деплоя
Уточняющие вопросы
- →Какую форму создаст медленно раскатываемый релиз?
- →Как выглядел бы частичный сбой, который сам восстановился?
MiddleДебаггингЧастоДашборд показывает вчерашние заказы на 90% ниже. Найдите и исправьте ошибку запроса, из-за которой падение ложное.
Дашборд показывает вчерашние заказы на 90% ниже. Найдите и исправьте ошибку запроса, из-за которой падение ложное.
Падение — артефакт полноты данных: вчерашняя партиция ещё грузится, поэтому COUNT видит лишь приземлившиеся строки. Подтвердите за секунды по статусу загрузки. Почините плитку, отбрасывая день, чья партиция не помечена полной: JOIN к _load_status и фильтр по is_complete.
Типичные ошибки
- ✗Считать неполную партицию реальным обвалом
- ✗Расширять окно вместо защиты по полноте
- ✗Винить дедупликацию вместо свежести данных
Уточняющие вопросы
- →Какая одна проверка подтвердит полноту партиции меньше чем за минуту?
- →Как в следующий раз не дать этому поднять тревогу у команды?
MiddleДебаггингЧастоЗапрос «до/после» утверждает, что релиз вызвал падение DAU на 20%. Найдите и исправьте изъян в доказательстве причинности.
Запрос «до/после» утверждает, что релиз вызвал падение DAU на 20%. Найдите и исправьте изъян в доказательстве причинности.
Разбиение до/после смешивает релиз со всем остальным, что двигалось на неделе — праздником и маркетинговым всплеском — поэтому меньшее число «после» это корреляция, а не причина. Раз раскатка постепенная по версии, сравнивайте обновившихся против ещё не обновившихся в те же дни.
Открыть задачу →Типичные ошибки
- ✗Читать разрыв до/после как причинность несмотря на совпавшие изменения
- ✗Править размер окна вместо добавления контрфактической группы
- ✗Резать то же сравнение до/после вместо сравнения когорт
Уточняющие вопросы
- →Как поэтапная раскатка позволит оценить эффект релиза напрямую?
- →Что проверите, если все пользователи обновились в один день?
MiddleДизайнЧастоВыручка упала на 15% за месяц, а число заказов не изменилось. Разложите выручку на мультипликативные драйверы и объясните, как найти, какой драйвер сдвинулся и где.
Выручка упала на 15% за месяц, а число заказов не изменилось. Разложите выручку на мультипликативные драйверы и объясните, как найти, какой драйвер сдвинулся и где.
Выручка = заказы × средний чек (AOV), а AOV = позиций в заказе × цена. Раз заказы ровные, падение сидит в AOV — раскладывайте: сжалась корзина или упала цена? Затем режьте этот драйвер по категории и сегменту. Разложение называет фактор; срез находит где.
Типичные ошибки
- ✗Считать, что выручка и заказы обязаны двигаться вместе
- ✗Коррелировать с событиями вместо разложения метрики
- ✗Гоняться за привлечением, когда число заказов ровное
Уточняющие вопросы
- →Как сдвиг mix категорий проявится в этом разложении?
- →Что если цена выросла, а корзина сжалась — как их свести?
MiddleДизайнЧастоМетрика проседает каждую субботу и восстанавливается в понедельник. Кто-то каждые выходные объявляет инцидент. Как задать базовую линию, которая ловит реальные проблемы и не поднимает ложную тревогу на недельный паттерн?
Метрика проседает каждую субботу и восстанавливается в понедельник. Кто-то каждые выходные объявляет инцидент. Как задать базовую линию, которая ловит реальные проблемы и не поднимает ложную тревогу на недельный паттерн?
Сравнивайте подобное с подобным: базируйте день на том же дне недели, а не на вчерашнем, чтобы сезонность сокращалась. Задайте уровень по прошлым тем же дням и алертите, только когда отклонение превышает норму и держится дольше замера. Так ловится суббота, аномальная для субботы.
Типичные ошибки
- ✗Базировать на предыдущем дне вместо того же дня недели
- ✗Использовать фиксированную процентную полосу на каждый день недели
- ✗Выбрасывать выходные вместо моделирования цикла
Уточняющие вопросы
- →Как обработать праздники, сдвигающие недельный паттерн?
- →Как долго нарушение должно держаться до алерта?
MiddleДизайнЧастоПосле срезов всё падение на 20% сконцентрировано на Android 12 в одной стране и больше нигде. Что вы заключаете, что делаете дальше и чего вы всё ещё не знаете только из этого факта?
После срезов всё падение на 20% сконцентрировано на Android 12 в одной стране и больше нигде. Что вы заключаете, что делаете дальше и чего вы всё ещё не знаете только из этого факта?
Концентрация в одной ячейке платформа-страна локализует причину, но не называет её — это краш сборки, сломанный SDK, сбой региона или проблема оплаты. Дальше проверьте частоту крашей, охват версий и здоровье логирования для ячейки. Отличить реальную потерю от поломки трекинга пока нельзя.
Типичные ошибки
- ✗Прыгать от локализованной ячейки сразу к подтверждённому багу кода
- ✗Отбрасывать сигнал сконцентрированного сегмента как шум
- ✗Считать, что локализованная причина не может быть поломкой трекинга
Уточняющие вопросы
- →Какая одна проверка лучше отделит краш от поломки SDK здесь?
- →Как подтвердить, что пользователи пропали, а не просто не трекаются?
MiddleДизайнЧастоКонверсия упала на 5% сразу после того, как маркетинг удвоил бюджет на верх воронки. Кто-то говорит о регрессе продукта; вы подозреваете сдвиг качества трафика (mix shift). Как доказать, что именно?
Конверсия упала на 5% сразу после того, как маркетинг удвоил бюджет на верх воронки. Кто-то говорит о регрессе продукта; вы подозреваете сдвиг качества трафика (mix shift). Как доказать, что именно?
Разбейте конверсию по каналу и по новым-против-вернувшихся, сравнивайте внутри когорт. Mix shift даёт ровные ставки по каналам, пока смесь кренится к низкоинтентному трафику; регресс даёт падение ставок и внутри когорт. Пересчитайте на mix до роста бюджета — вернулся к базе, сдвинулся mix.
Типичные ошибки
- ✗Читать совпадение по времени как доказательство, что это кампания
- ✗Считать, что рост бюджета всегда должен поднимать конверсию
- ✗Давать каналам равный вес вместо фиксации реального mix
Уточняющие вопросы
- →Как оценить долю падения, приходящуюся на mix?
- →Какой результат внутри когорты склонит вас к продуктовой причине?
SeniorДизайнЧастоМетрика выросла на 25% за ночь, и все празднуют. Почему расследование идентично падению и чем на практике чаще всего оказывается необъяснимый ночной скачок?
Метрика выросла на 25% за ночь, и все празднуют. Почему расследование идентично падению и чем на практике чаще всего оказывается необъяснимый ночной скачок?
Скачок — такая же аномалия, поэтому проверки те же: сначала исключите артефакт — задвоенные события, повторный прогон, смену определения, ботов — затем локализуйте по сегментам. Необъяснимый ночной рост обычно не рост, а инструментирование: дублирующее логирование или боты.
Типичные ошибки
- ✗Аудировать падения, но принимать скачки без проверки
- ✗Считать, что артефакты только занижают и никогда не завышают
- ✗Приписывать скачок последней фиче до проверок
Уточняющие вопросы
- →Какой баг задвоения чаще всего завышает счётчик событий?
- →Как бот-трафик проявится в ваших срезах по сегментам?
SeniorДебаггингИногдаАлерт аномалий сработал 40 раз за месяц, 38 из них — шум. Переделайте правило детекции, чтобы команда снова ему доверяла.
Алерт аномалий сработал 40 раз за месяц, 38 из них — шум. Переделайте правило детекции, чтобы команда снова ему доверяла.
Замените порог по одной точке сезонным, робастным, устойчивым правилом: базируйте на прошлых тех же днях недели, а не на одной точке 7 дней назад. Помечайте, только когда отклонение превышает робастный разброс в несколько MAD, держится дольше интервала и бьёт минимальный эффект.
Открыть задачу →Типичные ошибки
- ✗Ослаблять порог вместо добавления сезонности и устойчивости
- ✗Сравнивать с одной опорной точкой вместо распределения
- ✗Срабатывать на один замер без минимального абсолютного эффекта
Уточняющие вопросы
- →Как настроить пороги устойчивости и минимального эффекта?
- →Как не дать правилу пропустить медленный реальный спад?
SeniorДизайнИногдаМетрика реально упала, присутствует во всех сегментах, и ничего не выкатывали. Руководство хочет свалить на конкурента или праздник. Как приписать это внешнему фактору, не отделываясь общими словами?
Метрика реально упала, присутствует во всех сегментах, и ничего не выкатывали. Руководство хочет свалить на конкурента или праздник. Как приписать это внешнему фактору, не отделываясь общими словами?
Относитесь к внешнему объяснению как к гипотезе, требующей доказательств. Сначала исчерпайте внутренние причины и подтвердите реальность падения. Затем потребуйте, чтобы фактор предсказывал время, сегменты и величину. Атрибутируйте только при держащемся незатронутом контроле.
Типичные ошибки
- ✗Скатываться к внешней причине по исключению
- ✗Принимать близость по времени за атрибуцию
- ✗Пропускать сравнение с незатронутым контролем
Уточняющие вопросы
- →Что делает хорошим контрольный регион или сопоставимую метрику здесь?
- →Как оценить размер внешнего эффекта после атрибуции?
