核心指标突然掉了 30%，你们团队的「归因拆解」流程长什么样？

背景

做了 8 年算法，最近一年主要精力在指标体系与数据看板上。有一个场景我在不同团队看到过太多次：某天早上核心指标（GMV、DAU、支付成功率、任务完成率）突然掉了一截，老板第一句是「为什么」，然后整个群开始炸。但真正能在一小时内给出「掉在哪一层、哪个环节、谁去查」的团队，我见得一只手数得过来。多数团队的真实动作是：数据同学被拉去写 ad-hoc SQL，产品凭直觉猜，研发翻日志，三天后复盘发现其实只是埋点发了个坏版本。

常见分歧 / 几种做法

我观察到至少四种流派：

1. 指标树派：北极星往下拆成 3–4 层（用户 → 行为 → 结果），每层有 owner，掉哪层查哪层。优点是结构清晰、责任明确；缺点是拆到第三层经常拆不动，且「拆法」本身会随业务变，维护成本高。
2. 维度下钻派：不做指标树，直接按地域 / 版本 / 渠道 / 新老用户 / 设备几套维度交叉，看哪个格子贡献了最大的 delta。优点是快、不依赖前置建模；缺点是维度爆炸，容易在噪声里捞到假信号（多重比较问题）。
3. 规则告警派：预先写好一套「异常检测 + 自动归因」规则（比如同比环比、CUSUM、3σ），触发后自动推送 top-3 候选原因。优点是响应快；缺点是规则维护成本不低，且业务方对「机器猜的原因」信任度有限。
4. ad-hoc SQL 派：没有体系，全靠数据同学现场写 SQL。优点是灵活；缺点是同一问题三个人写三个数，最后变成「口径之争」。

我的倾向与理由

我个人偏向「维度下钻为主 + 指标树为辅」：日常用维度下钻快速定位（因为维度是稳定资产，指标树是易变资产）；只在季度 OKR 对齐时才维护一次指标树，且只到第二层。原因有三：

• 维度是「事实」，指标树是「解释」；归因场景需要的是事实，不是解释。
• 指标树维护成本被严重低估，业务每变一次就要重拆，最后往往烂尾成一张没人看的图。
• 自动归因规则在样本量小的场景（B 端、低频业务）误报率很高，不如让人看原始分布。

当然这只是我的一面之词。

想听大家聊聊

• 你们团队核心指标异动时，SOP 是什么？有没有真的在用的文档，还是全靠口口相传？
• 指标树你们维护到几层？多久重拆一次？烂尾率高吗？
• 维度下钻时怎么控制多重比较的假阳性？有没有用 Bonferroni、FDR 之类的？
• 埋点 / 数据质量问题导致的「假异动」，你们是怎么和真实业务波动区分的？有没有踩过坑？
• 小团队（<5 个数据同学）和大团队（>20 人）在这件事上的做法差异有多大？

欢迎带具体案例来聊，越具体越好。