metric-diagnostics

Скилл metric-diagnostics помогает выяснить, почему метрика изменилась, отличается от ожидания или расходится между поверхностями. Его задача — не придумать правдоподобную причину по одному графику, а воспроизвести метрику, определить корректное сравнение, измерить движение, проверить возможные драйверы и разделить подтверждённое, вероятное и нерешённое. В начале формулируются бизнес-смысл метрики, период и baseline, популяция, grain, владелец определения и конкретный диагностический вопрос: движение, концентрация, инцидент, регрессия или reconciliation. Если отсутствующий ввод materially меняет рамку анализа, скилл предлагает уточнить его; иначе фиксирует разумное допущение и продолжает. Источники сначала исследуются широко, но semantic layer используется только как карта, а не как граница поиска. Для каждого подходящего structured-data источника проверяются актуальные схемы, таблицы, views, модели и определения метрик. Если несколько источников перекрываются или расходятся, сравниваются владелец, свежесть, определение, grain, покрытие и прямота связи с вопросом. Более слабый источник не считается эквивалентом нужного source of truth. Если обязательный источник недоступен, этот путь останавливается; optional enrichment можно продолжить, но пробел должен быть явно обозначен. До вывода причин проверяются фильтры, join-логика, агрегация, numerator и denominator, исключения, freshness, lineage и возможные изменения схемы. Сначала устанавливается сам паттерн: размер, время начала, пик, восстановление, область действия и форма распределения. Искать причины до проверки размера и scope нельзя. Затем выбирается минимальный набор срезов, который может объяснить движение или повысить уверенность; при необходимости восстанавливаются бизнес-группировки вроде семейства моделей, сегмента, региона, когорты или иерархии продукта, даже если первая таблица их не показывает. Для additive-метрик полезно считать долю вклада, для rate — отдельно проверять numerator и denominator, а в reconciliation выравнивать определения, grain, фильтры и остаток. Драйверы должны быть количественно сопоставлены с базой и проверены на нужном сравнении, а не просто перечислены. Важная часть диагностики — отличать composition effect от изменения внутри сегмента и учитывать измерительные проблемы: неполные свежие данные, дубликаты, сдвиг denominator, logging change, outlier или конфликт источников могут выглядеть как бизнес-движение. В выводе отдельно указываются наблюдаемый паттерн, сильнейшее объяснение, размер вклада, уверенность, практическое следствие и следующий шаг. Временная близость события сама по себе не доказывает причинность, поэтому гипотеза должна быть помечена как гипотеза, если прямой проверки нет. Skill рекомендует передавать содержательную диагностику в build-report, если пользователь явно не отказался от артефакта; при необходимости используются отдельные навыки для business context, data quality, визуализации, валидации или последующего product decision.