AI 指标归因助手：先拆口径，再让模型解释波动

AI 指标归因助手：先拆口径，再让模型解释波动

一、归因不是让模型自由发挥

AI 数据分析里，最容易被高估的能力是"自动解释指标波动"。把一张日活曲线丢给模型，让它写出"受到节假日、活动、渠道变化影响"，看起来完整，其实经常没有证据。指标归因的核心不是文案，而是口径、维度、时间窗口和可验证假设。

一个可靠的归因助手，应该先知道指标怎么算，再知道有哪些可拆维度，最后才生成解释。

为什么模型生成的"解释"经常看起来有理但经不起推敲？ 因为 LLM 的原理是预测下一个 token，不是做因果推断。你问"上周 GMV 为什么下降 5%"，模型看到历史对话里提到过"节假日"，就会倾向于输出"可能受节假日影响"——这不是分析，是模式匹配。如果上周根本不是节假日，这个解释就是纯编的。指标归因的核心不是"编一个合理的解释"，而是"用可计算的方式分配贡献度"。 贡献度能算出来的部分是硬的（渠道 A 贡献了 60% 的下降），算不出来的部分才交给模型做假设（渠道 A 的投放素材可能改了）。顺序不能反。

二、先建立归因输入

归因输入至少包括指标名称、口径 SQL、当前周期、对比周期、可用维度、异常阈值和业务事件。没有这些上下文，模型只能猜。

metric_root_cause_input:
  metric: paid_conversion_rate
  current_window: "2026-07-03"
  baseline_window: "2026-06-26~2026-07-02"
  dimensions:
    - channel
    - city_tier
    - device
  min_contribution_rate: 0.15

min_contribution_rate 很重要。只有贡献足够大的维度变化，才应该进入候选解释，避免报告里塞满边缘噪声。

三、维度贡献要可计算

def contribution(delta_total, delta_part):
    if abs(delta_total) < 1e-9:
        return 0
    return delta_part / delta_total

归因可以从分组贡献开始：先计算总体指标变化，再计算每个维度取值对变化的贡献。比如整体转化率下降 2 个百分点，其中某渠道贡献 60%，才值得重点分析。

还要区分"占比变化"和"效率变化"。一个渠道转化率没变，但流量占比下降，也会拉低整体转化；另一个渠道流量不变，但转化率下降，则是效率问题。两者对应的行动完全不同。

为什么"占比变化"和"效率变化"对应的行动完全不同？ 占比变化（流量结构变了）对应的是运营动作：渠道 A 的流量少了一半，是投放预算被砍了还是广告被下架了？效率变化（转化率变了）对应的是产品/内容动作：转化率掉了一半，是落地页改版了还是新用户质量下降了？如果一个归因结论把"渠道 A 转化率下降 30%（效率问题）"错误地解释为"渠道 A 流量减少（占比问题）"，运营按结论去查投放预算，查了一整天发现预算根本没变——浪费时间不说，真正的落地页 bug 又拖了一天没修。这就是为什么区分这两类变化是归因分析的"及格线"。

四、AI 应该生成可验证假设

模型适合把计算结果翻译成分析语言，也适合根据历史事件提出假设。但每个假设都要带证据状态：已验证、待验证、缺数据、证据不足。

{
  "finding": "新客渠道 A 对下降贡献最高",
  "evidence": ["channel=A contribution=0.62", "new_user_ratio -8.3%"],
  "hypothesis": "渠道素材或落地页变化影响新客转化",
  "status": "need_event_check"
}

输出时不要写成"由于渠道 A 导致转化下降"，而应写成"渠道 A 解释了主要数值变化，需要继续核对投放素材、落地页和人群定向变更"。这种表述更诚实，也更能推动后续分析。

归因助手还要保留反例。如果某个维度看起来变化明显，但样本量太小，报告里要明确降权。数据分析最怕把小样本波动包装成大结论。

最后，归因结论要能回链到数据明细。读者点击某条结论时，应能看到对应分组、样本量、基准值和计算公式。没有回链的 AI 结论，很难建立信任。

归因助手还应保存"未采纳原因"。有些候选维度贡献低，有些样本量不足，有些与历史事件不匹配，这些信息不一定写进正文，但应该留在分析记录里。下次同类波动出现时，系统可以复用这些判断，减少重复排查。

🚨 踩坑提醒

1. 归因分析不能只看维度贡献，要控制"辛普森悖论"。 经典的翻车案例：整体转化率下降，但拆开渠道一看，每个渠道的转化率都涨了。这是因为流量从高转化渠道流向了低转化渠道——总体在跌、局部在涨，这就是辛普森悖论。如果归因助手只做一维拆解，报告会写成"各渠道表现良好，整体下降原因不明"。必须同时分析流量结构和转化效率的交叉影响，才不会产出这种自相矛盾的结论。

2. min_contribution_rate: 0.15 是经验阈值，但发现 P0 问题时不能过滤。 比如上周 GMV 下降主要是"支付故障导致支付成功率从 99.5% 降到 80%"，这个因素的贡献度可能只有 12%——因为只影响了 2 小时。但 2 小时的支付故障是 P0 事故，不能因为贡献度不到 15% 就不写进报告。做法是给每个维度打标：维度类型=运营|产品|技术|事故，事故型维度不论贡献度多少都要进报告。

3. 归因结论的回链 URL 要带参数过滤，不要只链到看板主页。 "渠道 A 转化率下降 30%"→ 点链接进去应该直接定位到渠道 A、对应时间段、对应指标的详细页面，而不是一个通用的"数据看板"。用户点完要等自己再筛一遍，体验约等于没有回链。URL 参数建议格式：/dashboard/gmv?channel=A&date=2026-07-01~2026-07-07&metric=conversion_rate。

结论

AI 指标归因助手的价值，不是把波动写得像报告，而是把口径、维度贡献和可验证假设串起来。

先拆口径，再让模型解释波动。数据证据站稳了，AI 生成的文字才有意义。