考察点
这道题出自滴滴 AI 相关业务的暑期实习面，一面二面都可能问。它是产品经理面试里最经典的分析题，但放在滴滴的语境下有特殊性：出行是双边市场，一个指标异动可能是乘客侧、司机侧、供需匹配、外部环境（天气、油价、竞对补贴）任何一端的问题，维度错了全白搭。面试官想看的不是框架背诵，而是你的排查顺序是否合理——先确认数据没出错，再定位到具体维度，最后才谈业务解释，以及你能不能把分析落到可执行的后续动作上。追问会往「拆不出原因怎么办」「多个因素叠加怎么归因」「多久要出结论」走。
参考答案
第零步：先确认异动是真的
接到「完单量昨天跌了 15%」这种告警，我的第一反应不是分析业务，是排除数据本身的问题。三类常见假异动：一是统计口径或埋点变更——前一天刚发过版本，埋点改了、看板的计算逻辑调了，数字立刻「异动」，所以先问数仓和数据侧同学有没有变更记录；二是数据延迟或回流问题，离线报表没跑完就被当成了下跌；三是参照系问题——同比环比用错了基准，比如上周同一天是节假日。这一步花十分钟，能拦掉大概两三成的「异动」。确认是真异动之后，再看量级和形态：是断崖式（通常是系统故障或版本发布）还是缓坡式（通常是业务或环境因素），形态本身就是第一条线索。
第一步：按业务结构拆维度定位
确认是真的之后，开始拆。拆的逻辑跟着业务结构走，出行场景我的拆解顺序是：先拆城市/区域——全国性下跌和单一城市下跌是完全不同的两件事，单城市问题大概率是本地因素（天气、交管、竞对动作）；再拆时段——只有早晚高峰跌，指向运力；全天均匀跌，指向需求；再拆用户分层——新客跌可能是拉新渠道出了问题，老客跌可能是体验或价格；然后拆产品链路漏斗——从打开 App、发单、应答、接驾到完单，看下跌集中在漏斗的哪一环。漏斗定位特别关键：发单量没跌但应答率崩了，那是供给侧的事；发单量就跌了，往需求和入口侧查。
在滴滴这种双边市场里，还要多看一层供需联动：乘客等太久取消，是因为司机少；司机少可能因为补贴退坡，也可能因为乘客少导致司机觉得没单不出来了——供需是互相踩踏的，单看一侧会误判。
第二步：内部动作和外部环境对时间线
维度定位到「华东某城晚高峰应答率下跌」这个颗粒度之后，拉一张时间线对表。内部侧：最近有没有发版（新策略上线、派单算法调整）、有没有运营动作（补贴退坡、价格调整）、有没有已知故障。外部侧：天气（暴雨天供需会剧烈波动）、节假日、竞对补贴战、本地大事件（演唱会散场的异常高峰）。我的习惯是维护一张「变更日历」，所有产品、运营、算法的上线动作都登记在案，异动分析时第一件事就是拿异动起点去对变更日历——经验上，超过一半的异动能对上某个时间点精确吻合的内部变更。
第三步：归因到可执行的结论
定位之后要给结论，而合格的结论必须带动作。几种典型归宿：对上内部变更的，小流量回滚验证，因果关系用 AB 说话而不是「时间吻合就是元凶」；对上外部因素的，评估要不要响应（竞对补贴要不要跟、恶劣天气要不要启动动态调价预案）；拆到最后是多因素叠加的，按贡献度排序逐个验证，别指望一次全归因。还有一种常见结果是「查不出单一原因」——数据拆到最细、变更日历也对不上，这时候诚实地说「目前没有证据指向单一原因，我的假设排序是 ABC，接下来用 XYZ 三个小实验验证」，比硬编一个故事专业得多。
复盘沉淀：每次异动都是资产
异动处理完我会补两件事：这次异动的排查路径整理成 runbook 存档，下次同类异动半小时内能跑完；以及反推监控体系的漏洞——这个异动为什么是用户先反馈而不是告警先发现？哪个中间指标（比如应答率比完单量更早预警）应该加进告警？好的异动分析能力不是临场聪明，是每次事后都把系统加厚一层。
可能的追问
- 多个因素叠加怎么归因？ 答：优先做减法——能回滚的变更先回滚一个看恢复程度，用准实验把单因素的贡献隔离出来；无法回滚的用同期未受影响的城市做对照组（双重差分的思路），没有干净对照就承认归因只能到「相关性」级别。
- 异动分析多久要出结论？ 答：分级。断崖式异动（影响收入或安全）两小时内给初步判断和止血动作，哪怕是「先回滚再细查」；缓坡式的一到两天出完整归因。止血和归因分开汇报，先控损再找真相。
- 怎么防止「拿着结论找证据」？ 答：两个纪律。一是假设清单在拆数据之前写好，避免看到什么解释什么；二是每个假设都问「如果这个假设成立，我还应该在数据里看到什么」，看不到就降级或放弃。对不上的证据比对的上的更有价值。