产品指标突然下跌，怎么用AI先排除数据错误再找业务原因？

新版本上线后的第二天，激活率从 42% 变成 29%。产品群里很快出现两个建议：立即回滚，或者给新用户加引导。问题是，如果某个关键事件从昨晚开始漏报，这两个动作都会解决错误的问题。

面对突然下跌，顺序比速度更重要。先证明数字能够比较，再讨论用户为什么变了。本文中的百分比仅用于演示诊断方法。

先冻结一个可重算的问题

写清指标名称、当前值、对比值、时间范围、统计时区、用户范围和指标公式。“激活率下降”至少要展开成分子是什么事件、分母是哪批用户、在多长窗口内完成才算激活。若版本上线同时修改了激活定义，前后数字不能直接比较。

还要确认下降发生在哪个时间点，是瞬间断崖、逐日走低，还是某天低点后恢复。瞬间变化更像数据或系统事件，缓慢变化才更可能来自行为、渠道或季节性，但这只是排查优先级，不是结论。

validate-data 会检查数据来源、时间新鲜度、缺失和重复、过滤条件、连接关系、分母、周期对齐与图表表达。可以先让它把当前分析评为“可分享”“需带限制说明”或“需要修改”，并列出阻塞项。

第一道门是采集：客户端、服务端和数仓的事件量是否同时下降。第二道是定义：事件名、属性或版本过滤是否改变。第三道是完整性：是否有延迟分区、空值、重复和丢失平台。第四道是计算：连接是否把行数放大，分母是否换了。第五道是可比性：今天是否只统计了半天，却拿整天数据比较。

从异常前后各抽取几名用户，沿注册、关键操作、激活事件和入库记录逐步追踪。再用另一种计算路径重算同一指标，例如从原始事件统计与仪表盘结果互相验证。汇总表看起来合理，不代表底层链路正确。

如果原始事件存在但报表没有，继续查转换与查询；如果客户端有操作而服务端未收到，查上报；如果各层数据一致，才进入业务诊断。把这段检查结果保存在分析记录里，免得几天后又重复争论。

Metrics Review 建议从北极星指标、一级健康指标和诊断指标逐层下钻，并比较当前值、历史趋势、目标和用户分群。不要一次切十几个维度。先选最能区分假设的三四个维度，例如版本、平台、渠道、新老用户或地区。

若只有最新版 Android 用户下降，优先调查版本流程；若某个投放渠道的新用户下降，可能是流量质量或落地承诺改变；若所有群体同时下降，再对照故障、节假日、价格和全局体验。总体平均可能掩盖一个群体明显变差、另一个群体改善的情况。

“用户不喜欢新功能”无法直接验证。更好的写法是：新版将权限请求提前，导致首次会话在该步骤退出，从而降低七日激活；验证方法是比较新旧版本该步骤的到达率、拒绝率和后续激活。每个假设都要有支持信号、反例和下一项数据。

相关性仍不能直接证明因果。若需要决定是否回滚，可以先做版本对照、灰度回退或小范围实验，同时设置明确的成功指标和停止条件。

记录应包含问题定义、数据质量检查、通过与未通过项、影响分群、主要假设、验证动作、负责人和截止时间。若数据仍不完整，就把结论标为暂定，并说明哪些决策暂时不能做。

AI 能把大量检查清单、趋势和分群组织起来，也能提醒平均数、连接放大和周期不完整等陷阱。可靠结论要有可重算的数据和能被证伪的验证支撑。最先听起来合理的故事，只能暂时放在假设栏里。