滴滴数据分析师三面：留存率 SQL、异动归因与新城市需求测算

《面试题目》

一面

1. 请做一下自我介绍。
2. 介绍一下你的项目。
3. 介绍一下你项目中设置的具体步骤。
4. 异动分析怎么做？
5. SQL 题：计算 1—7 日的留存率，即当天登录后在接下来一周内登录过的人占当天登录用户的比例。
6. 如果这个留存率增加 30%，你会怎么分析？怎么判断主要因素？怎么确定样本量？

二面

7. 介绍一下你的实习经历，最有成就感的事情是什么？
8. 你喜欢什么样的工作氛围？
9. 异动分析：订单呼叫量下降，怎么归因？
10. 为什么选择这个行业？
11. 你觉得自己做数据分析师有什么优势？
12. 3—5 年内希望自己在这个行业成为一个什么样的人？

三面

13. 请做一下自我介绍。
14. 介绍一下归因分析。
15. 深挖实习：遇到的困难是什么？如何解决？
16. 怎么估计一个新城市的业务需求量？
17. 怎么判断能不能在一个新城市开展业务？
18. 指标体系你了解哪些？
19. 目前有其他 offer 吗？

《参考解析》

留存率 SQL：先定义清楚口径再写语句

这道题的第一关不是 SQL 语法，而是口径。要问清楚三件事：留存的分母是当天新用户还是当天活跃用户（新用户看次日/7 日留存，活跃用户看回访率，两者含义完全不同）、留存窗口是「接下来一周内任意一天登录」还是「第 7 天当天登录」（前者是周留存，后者是精确第 7 天留存），以及去重是按用户还是按设备。以「当天登录、且之后 7 天内再次登录过」为例，标准写法是拿当日活跃用户做左连接、在条件里限定回访日期落在 [当天, 当天+6] 区间，用 COUNT(DISTINCT) 或 EXISTS 保证一个用户只算一次，再按日期分组求比例：

SELECT a.dt,
       COUNT(DISTINCT a.uid) AS base_users,
       COUNT(DISTINCT b.uid) AS retained_users,
       COUNT(DISTINCT b.uid) * 1.0 / COUNT(DISTINCT a.uid) AS retain_rate
FROM (SELECT uid, DATE(login_time) AS dt FROM login_log GROUP BY 1, 2) a
LEFT JOIN (SELECT uid, DATE(login_time) AS dt FROM login_log GROUP BY 1, 2) b
       ON a.uid = b.uid
      AND b.dt > a.dt AND b.dt <= DATE_ADD(a.dt, INTERVAL 6 DAY)
GROUP BY a.dt;

真正的加分点在后面几句话：日期要按业务时区而不是 UTC 切，大表上先聚合到「用户-日」粒度再连接能省一个量级的开销，留存曲线要按渠道/城市/新老客分层看，否则总体留存一动你根本不知道为什么动。

「留存率涨了 30%，怎么分析」：先证伪，再定位，最后确认显著性

这题的正确顺序是四步。第一步确认口径与数据质量：是不是统计逻辑改了（留存定义、时区、去重方式、新老用户口径）、埋点或登录链路有没有故障、有没有把测试用户或异常流量算进来——如果口径变了，30% 可能只是数字游戏。第二步拆维度定位：时间上按天看是突变还是渐变（突变对应一次上线或活动，渐变对应用户结构变化）；用户上按渠道来源、新老客、城市、机型、版本拆；行为上按登录路径与频次拆，看是「更多人登录一次」还是「核心用户登录更频繁」。第三步验证解释并排除混淆：如果刚好叠加大促、节假日或一次版本更新，要用同期对照（不涉及的渠道/城市作为对照组）或 DID 之类的方法把自然波动剥离，同时警惕辛普森悖论——各分层都在跌、总体却在涨。第四步给结论和动作：说清是「真实业务改善」还是「口径/流量结构造成的假象」，并给出后续监控指标。追问「怎么确定样本量」时，要提统计功效：先定显著性水平（一般 0.05）与功效（0.8），估计指标基线值和方差，设定你想检测的最小提升幅度（MDE），据此算每组所需样本量；同时明确分析单元（用户还是订单）、是否互斥分流、有多少个指标要做多重比较校正，以及实验时长至少覆盖一个完整周以抹平周期性。

异动归因：订单呼叫量下降怎么拆

滴滴这道题几乎是送分的经典题，答成「拆维度 + 找证据 + 排除自身」就赢了。先明确指标定义与口径（呼叫量是发单量还是成单量、是否含取消），再看是哪个盘子掉的：分城市/区域、分时段、分产品线（快车、专车、拼车）、分入口（App、小程序、企业版）、分用户（新老客、活跃频次）。常见原因按影响面排序：供给侧（运力不足、司机端活动下线、时长与合规检查导致司机减少）会造成「想叫车叫不到」，表现为呼叫量下降同时成交率下降、排队时长上升；需求侧（天气、节假日、竞品补贴活动、城市管控）表现为整体一致下滑；自身变更（发版 Bug、入口改版、补贴策略调整、定价变化）表现为特定版本或渠道骤降，通常时间点非常整齐；数据侧（埋点上报失败、统计口径与任务调度异常）则会出现跨维度同步下降、但成交与 GMV 滞后指标不匹配的怪象。做法上用「先看时间点对齐什么事件、再自上而下逐层下钻、最后用对照区域验证」这条线，并且永远先把「我们自己近期做了什么」排在最前面——这是最容易也最该先排除的一路。输出要落到「结论 + 置信度 + 建议动作（补运力还是修埋点）」。

新城市业务需求量测算、指标体系与软性问题

估算新城市的需求量，走两条路互相验证。自下而上：目标城市的人口与结构（通勤人口、就业密度、机动车与驾照保有量、大学与商圈分布）→ 场景渗透率与使用频次 → 乘以客单价得到规模，关键中间变量必须给出依据（对标城市的人均单量、本地竞品的可见供给密度）。自上而下：找一个人口或经济水平相近、业务已成熟的城市做类比，按人口/经济体量折算，并用出行距离分布、公交与地铁客流做交叉校验。判断「能不能开展业务」则是测算之外的判断题：供给侧能不能起量（司机招募成本、牌照与合规、运力密度是否足以保证应答率）、竞争强度（本地已有玩家的补贴力度与用户心智）、单位经济模型（单均毛利能否覆盖补贴、调度与客服成本）、进入节奏（先打一个区还是全城铺开），最后给出「试点 → 验证核心指标 → 再扩张」的评估方案。指标体系那题按结构答最清楚：北极星指标（如完单量/GMV）+ 分层拆解（规模 = 用户数 × 频次 × 转化，效率 = 应答率、时长、取消率，体验 = 投诉率、评分，成本与安全指标各一组），再补充 OSM/UJM 或 AARRR 这类框架，说明指标要能追溯到业务动作、不能相互代替。二面三面的软性问题（最有成就感的事、喜欢的工作氛围、为什么选这个行业、数据分析师的优势、3—5 年规划、是否有其他 offer）没有标准答案，唯一要守的是「用证据说话 + 与岗位方向自洽」：优势要落到具体能力（业务理解、把模糊问题拆成可验证假设、SQL/实验设计/看板自动化），职业规划要给出「先精通一类业务的分析 → 再往策略/增长方向走」的路径，别只说「希望成为资深分析师」。