监控与异动归因总纲：从四个日常问题到完整的分析闭环

前面八篇文章分别拆开了各个具体方法：Prophet、ARIMA、3-sigma、Delta 法、基尼系数、剔除法、Adtributor、漏斗分析。这一篇回到总纲——这些方法在同一个数据分析体系里各自站在什么位置，以及一个完整的"监控 → 归因 → 行动"闭环长什么样。

一、从四个日常问题说起

数据分析师最常被问到的四个问题：

"最近数据怎么样？"
"今天收入数据为啥涨了？"
"下个月 DAU 能做到多少？"
"上周 DAU 数据为啥跌了？"

这四个问题背后是两类截然不同的能力：

• "最近怎么样 / 下个月能做多少"——描述现状与预测未来，属于指标监控
• "为啥涨了 / 为啥跌了"——解释变化，属于异动归因

不做体系化建设的代价也很具体："涨在哪里不知道，跌在哪里你也不知道"、"查个数据查了一天"、"这个离群点算异常吗？异动时你要及时向我汇报啊"——被动响应、口径混乱、时效低下。监控与归因的本质，就是把这三类抱怨变成一条自动化、有纪律的数据流水线。

而这整条流水线的地基是指标体系：指标全面完整、避免虚荣指标、口径统一、维度可逐级拆解。地基不牢，后面所有方法都无从谈起——归因要拆维度，前提是指标本身定义时就带着可拆解的结构。

二、监控：时间序列异常检测的两条路线

监控的核心技术问题是：这条曲线今天的值，算不算异常？

常见的时间序列异常检测方法分两派：

路线	方法	一句话原理
基于预测	Prophet	可加模型，拆成增长项 + 周期项 + 节假日项
基于预测	ARIMA	用历史值和历史误差的线性组合预测当前值
基于统计	3-sigma	离群值与均值偏差超过 3 倍标准差即异常（概率 0.3%）

两条路线的分野在于基线从哪来：统计方法假设数据平稳，用历史窗口的均值方差当基线；预测方法显式建模趋势和周期，用模型预测值当基线。

这对应异常检测文献里的一组经典区分（Chandola et al., 2009）：点异常（某个值本身离群，3-sigma 擅长）与上下文异常（值本身正常，但相对于当前时间点不应该——周五流量比周一高 50% 是正常周期，不是异常）。业务指标几乎全是带趋势和周期的上下文异常问题，所以实务中的标准组合是：预测模型管基线，统计方法管残差——先扣掉趋势和周期，再对残差用 3-sigma。

监控体系不是越灵敏越好。报警也遵循精确率/召回率的权衡：阈值收得太紧，异常确实都报了，但每天几百条假警报会让真异常淹没在噪音里——这就是 SRE 领域常说的"报警疲劳"（alert fatigue）。一个可用的判断标准：每条报警都应该有人看、有人处理，否则就该调阈值或降级为日报指标。

三、异动归因的思路：先分内外，再定维度，最后量化贡献

异常确认之后，进入异动归因。PPT 里的"异动归因思路"实际上是一张完整的排查地图：先判断异动来自外部还是内部，再对内部原因做维度拆解和贡献量化，同时拉着数据、研发、产品一起确认根因。

1. 外部原因快速排除

先查外部，因为这些原因不需要复杂统计就能验证，且常常比业务动作更早出现：

外部因素	看什么	常见信号
Prophet 节假日项	是否在模型节假日表内	假期/大促/调休被遗漏时，预测基线会失真
舆情监控	百度指数、微博热搜	负面舆情或热点事件带来流量/订单异动
天气	主要城市天气数据	O2O、外卖、出行类指标对天气高度敏感
应用商店	评分、状态、竞品动态	下架、报毒、竞品投放导致新增异常

外部因素验证成本低，先做排除。如果真的是节假日项没配准，调模型比调业务更快；如果是竞品截流，结论会直接影响应对策略。

2. 内部原因：分维度

外部排掉之后，回到内部。内部归因从两个方向入手：

常见维度选择：

• 用户属性：性别、地域、年龄等人口学切片
• 用户价值：大 R、RFM 分层，区分高价值与低价值用户的异动贡献
• 供给：双边/多边市场还要看供给端（商家、司机、内容创作者）变化，需求侧的波动可能根子在供给侧

多维下钻动作：

1. 定位环节：用指标树找到异常发生在哪个环节
2. 逐级下钻：对锁定环节按维度一层层切下去，如 渠道 → 版本 → 机型

以阅读 PV 下降为例，链路就是一棵乘法指标树：

先判断是"来的人少了"、"看了的人少了"还是"看得少了"，再对锁定的因子按渠道、机型、版本、网络类型继续下钻。

这套"拆因子、切维度"的手法在财务领域有个百年先驱——杜邦分析法（DuPont, 1919）：ROE = 净利率 × 资产周转率 × 权益乘数。多维拆解本质上就是业务指标版的杜邦分析。

3. 内部原因：量化贡献

找到嫌疑维度后，用对应算法算贡献度。方法只看指标的数学结构：

指标类型	代表指标	方法
加法指标（量值）	DAU、收入	Delta 法、基尼系数法
除法指标（比率值）	留存率、人均收入	剔除法、加权分解
乘法指标	PV = DAU × 渗透率 × 人均条数	取对数 log 转化成加法指标
自动化综合	任意	Adtributor 法（EP + S）

两类方法的分工：基尼系数/Adtributor 解决"先看哪个维度"，Delta/剔除法/对数分解解决"这个维度贡献了多少"。实际工作中组合使用：先用基尼系数锁定维度，再用 Delta 法算该维度下各分组的贡献。

4. 内部原因：干系人确认

统计归因给出的是嫌疑对象，真正根因要靠干系人确认：

干系人	排查重点	典型根因
数据	数据上报、数仓、数据口径	埋点漏报、ETL 延迟、口径变更
研发	bug、anr、crash	版本 bug、启动崩溃、接口超时
产品	策略调整、AB 放量、配置调整	推荐算法改动、功能开关放量、运营配置错误

数据分析不能止于"华为机型转化率骤降"，要进一步确认：是版本 bug？是 AB 实验放量？还是渠道包被误替换？这一步从统计事实跳到业务事实，是归因工作真正产生闭环价值的地方。

5. 把思路串成一句话

**多维拆解定位"哪里变了"，量化贡献回答"变了多少、谁是大头"，干系人确认"为什么会变"。**只做拆解不算贡献，汇报只能讲"可能是渠道 A 的问题"；只做贡献不做确认，数字只是数字。

四、完整闭环：体系 → 监控 → 归因 → 行动

把三块串起来，就是这套方法论的全景：

指标体系（地基）
   │  指标全面、口径统一、维度可拆解
   ▼
指标监控（发现）
   │  Prophet/ARIMA 管基线，3-sigma 管残差
   │  报警有人看、可处理，警惕报警疲劳
   ▼
异动归因（解释）
   │  多维拆解定位环节和人群 → 量化贡献排优先级
   ▼
行动与验证（闭环）
   │  漏斗分析细拆流失环节 → 优化方案 → AB 实验回收效果
   └────── 结果回流指标体系，进入下一轮监控

三个容易被忽视的闭环纪律：

1. 归因的输出是假设，不是结论。数据分析锁定"华为机型转化率骤降"是统计事实，但原因（机型适配 bug？系统版本发布？）需要工程排查确认。把统计归因直接当业务结论，是归因工作最大的滥用。
2. 每轮归因沉淀进指标体系。某次大促导致的基线异常，下次就该进节假日表；某类渠道结构性下滑，就该单独建监控。体系不是一次性搭好的，是被一轮轮异动喂出来的。
3. 验证必须用实验。优化上线后的效果回收用 AB 实验而不是前后对比——异动归因解释了"为什么变"，但只有实验能证明"你的动作有效"。

从"查个数据查了一天"到"异常自动报警、归因半页结论、实验当天上线"，中间差的不是某个算法，而是这条链路上每一环的纪律。方法各有适用边界（前面各篇已逐一拆解），但闭环本身，是所有数据分析团队的通用基建。

参考资料

1. Chandola, V., Banerjee, A. & Kumar, V. (2009). Anomaly Detection: A Survey. ACM Computing Surveys
2. Brown, D. (2019). Building Secure and Reliable Systems. Google, Ch. 8 Alerting（报警疲劳与可操作性）
3. American Management Association (1923). DuPont System of Financial Control. 杜邦分析法的早期记载
4. Taylor, S. & Letham, B. (2017). Forecasting at Scale. Prophet 原论文
5. Box, G. & Jenkins, G. (1970). Time Series Analysis. ARIMA 方法出处