Question 1

DAU 昨天突然跌了 10%，你怎么排查？

Accepted Answer

我的第一步永远是排除数据本身的问题：埋点有没有改、上报链路是否丢数、口径有没有变更——我遇到的「DAU 暴跌」里小一半最后是数据问题。确认数据可信后按维度拆解：平台/渠道/地区/版本逐一切，找到跌幅集中的细分。我处理过一次真实案例：拆到最后发现只有 Android 某渠道包跌了 40%，关联事件后确认是前一天该商店下架了我们的包。最后结论要可复验：我会给出验证方法——如果是下架导致，恢复上架后该细分应回升，且其他细分不受影响，而不是讲一个听起来合理的故事就收工。

Question 2

怎么设计一个 AB 实验来验证新功能有效？

Accepted Answer

我会按四步设计：先定随机单元，用户级功能按用户随机，避免同一人跨组污染；再估样本量，用基线转化率和最小可检测效应（MDE）反推，而不是跑到显著就停；实验周期覆盖完整业务周期（至少两周，含周末效应）；指标预先注册，主指标、护栏指标上线前写死。我还会主动报三个坑：新奇效应——前几天的提升可能是尝鲜，要看指标随时间的衰减曲线；辛普森悖论——分组流量占比不均时总体结论可能反转，所以分层看；以及局部优化——入口指标涨了但全局转化没变，所以护栏里必须有全局指标。曾有一次实验前三天显著为正，我坚持跑满周期后效应归零——避免了一次错误发布。

Question 3

写一条 SQL：求每个用户最近一次下单的金额

Accepted Answer

我的首选是窗口函数：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) 标号，外层取 rn=1，一次扫表就能拿到每个用户最近一单的完整行。另一种写法是先 GROUP BY user_id 取 MAX(order_time) 再 join 回原表：它的问题一是同一用户同一时刻多单会出重复行，二是多一次 join 的开销；优点是在没有窗口函数的老引擎里也能跑。如果面试官追问并列第一的处理，我会补充 ROW_NUMBER 与 RANK 的差异和 tie-breaker（再加 order_id 降序）。实际工作里我还会确认 (user_id, order_time) 有没有索引——写对和跑得动是两件事。

Question 4

活动带来转化提升，怎么判断是活动的功劳？

Accepted Answer

核心是回答反事实问题：没有这个活动，转化会怎样。最可信的是事前留对照组——活动对 90% 用户开放、10% 作为 holdout，两组差异就是净效应。如果活动已全量上线没留对照，我退而用准实验方法：断点看活动上线前后转化率是否跳变，或用未覆盖活动的城市/平台做 DID。同时必须剥离混杂：季节性用去年同期对比、自然增长用活动前趋势外推、同期其他动作逐一排查上线日历。我处理过一次「活动带来 20% 提升」的归因：拆完发现同期有渠道投放加量，真实净效应只有 7%——这直接改变了下一期活动的预算分配。

Question 5

给一个新业务从零搭指标体系，你怎么做？

Accepted Answer

我从业务模式而不是指标清单出发：先回答「这个业务靠什么赚钱/创造价值」，定出北极星指标——比如订阅制 SaaS 是活跃付费席位数而不是注册量。然后沿用户旅程拆过程指标：获客→激活→留存→变现→推荐，每段选 1-2 个可行动的指标，再配护栏（客诉、性能、成本）。落地环节我坚持两件事：每个指标写定义文档——口径、分母分子、去重规则、数据源，避免同名不同义；指标数量克制，首版不超过 15 个，宁可少而准。我给一个新社区业务搭体系时，就因为发现运营和财务对「活跃」的口径差了三倍，先统一定义再建看板——否则体系越全，争议越多。

Question 6

业务方拿着一个相关性结论要做决策，你怎么回应?

Accepted Answer

我不会直接否定——先肯定发现的价值：相关性是好线索，值得认真对待。但我会用一个业务方能秒懂的例子说明风险：「用了优惠券的用户复购率高一倍」不等于券有效——领券的本来就是高意愿用户，把券发给所有人未必有同样效果。然后给低成本的验证路径，而不是把问题留在原地：如果决策可逆且代价小，小流量先试；如果代价大，设计一个快速 AB 或找历史自然实验先验因果。我的经验是给出「两周内能拿到因果证据」的具体方案后，业务方几乎都愿意等——他们要的不是马上行动，是确定性。

Question 7

你做过影响业务决策的分析吗？讲一个

Accepted Answer

讲一个改变了原计划的：公司原准备把获客预算继续加到投放上，因为新客数一直在涨。我做了一个分层留存分析：把新客按渠道拆开看 30 日留存和回本周期，发现增量主要来自某低质渠道，留存只有其他渠道的三分之一，按 LTV 算永远回不了本；而老客流失里有 40% 集中在支付失败后未重试。说服过程我没有只交报告，而是把两个方案的预期 ROI 算给决策会：同样预算修支付重试链路的回报是加投的四倍。最终预算转向，上线支付重试后月流失率降了 2.3pp，回验结果与测算基本一致。分析的价值不在报告多厚，在有没有改变决策。

Question 8

Python/R 在你的分析流程里怎么用？

Accepted Answer

我的分工很明确：取数和重型聚合用 SQL 在仓内完成，减少数据搬运；Python 接手后续——pandas 做清洗、异常值处理和特征构造，scipy/statsmodels 做显著性检验，matplotlib 出图。工程化的例子：我们每周要出一份分渠道的经营周报，手工做要小半天且经常拼错口径。我把它写成参数化的 Python 脚本：SQL 模板取数、pandas 按统一口径聚合、自动渲染图表并推送到群，交接给定时任务后每周零人工、口径零争议，一年省下的时间我拿去做了两个专项分析。我的原则是：同一份分析要交付三次以上，就必须脚本化。

数据分析师高频面试题：8 道必考题与作答要点