数据分析师面试问题

回答框架: 筛选 → 关联 → 分组 → 排序 → 取前五

假设有 customers(customer_id, name) 和 orders(order_id, customer_id, order_date, status, revenue) 两张表。我会先澄清收入是否包含取消或退款订单。通常只应计入已完成订单。 查询筛选过去 30 天且状态为已完成的订单，按客户分组，求收入之和，按降序排列，再取前五名。如果条件更复杂，可以先用 CTE 提取符合条件的订单。 细节包括使用正确的日期列；除非预先汇总，否则不要直接关联到订单明细层级的表；还要确定如何处理并列第五名。如果数据库支持，且需要包含并列客户，应使用排名窗口函数，而非简单的 LIMIT 5。 好的回答还会核对符合条件的收入总额、行数，以及排名靠前的客户是否因订单行意外重复而被高估。

回答框架: 定义同期群 → 定义回访事件 → 左连接 → 汇总

首先明确定义留存。我会把一月同期群定义为注册日期从 1 月 1 日起、到 2 月 1 日前的用户。如果用户在注册后第 7 天发生至少一次有效活跃事件，则计为第 7 天留存；如果公司把七日留存定义为第 1 至第 7 天内回访，则应按那个口径计算。查询前必须先确认。 对于恰好第 7 天的留存，先建立包含 user_id 和 signup_date 的同期群 CTE，再按 user_id 左连接事件表，要求 event_date 等于 signup_date 加 7 天，且 event_name 是有意义的活跃事件。分母是同期群用户去重数，分子是存在匹配事件的用户去重数。 关键是通过左连接保留没有活动的用户。内连接会排除未留存用户，从而虚高留存率。还要用去重 user_id 避免同一用户的多次事件重复计数。 最终指标为留存用户数除以同期群用户数。如面试官要求进一步诊断，可按获客渠道、平台、地区或注册周细分。

回答框架: 按用户对购买记录排序

使用窗口函数按购买时间为每位用户的已完成购买排序。先筛选已完成购买，再使用 row_number() over (partition by user_id order by purchase_at)。行号为 2 的记录就是第二次购买。 筛选顺序很重要。如果取消或退款的购买不应计入，就要在排名前排除。如果两次购买时间戳相同，应增加 order_id 等稳定的次级排序键。 输出可包含 user_id 和 second_purchase_at。如果只要求购买至少两次的用户，返回行号为 2 的记录即可；如果要求列出所有用户，并为没有第二次购买的用户返回空值，则把结果左连接回用户表。 实际面对大表时，在 user_id 和购买时间上建立合适索引，有助于数据库高效执行。

回答框架: 每位用户一行，记录各环节时间戳

我会为每位用户生成一行，并记录各漏斗环节最早发生的时间戳。这样能避免同一用户多次触发相同事件时被重复计算。可以在事件表上用条件汇总，例如 min(case when event_name = signup then event_at end)、邮箱验证对应的最早时间，依此类推。 如果业务要求按顺序完成，应强制检查：邮箱验证发生在注册后，新用户引导发生在验证后，首次购买发生在引导后。如果业务只关心是否完成，不要求顺序，也要明确说明这一假设。 转化指标包括注册到验证、验证到完成引导、完成引导到购买，以及注册到购买的整体转化率。每一步以完成该步的去重用户数为分子、完成上一步的用户数为分母。按平台、获客渠道、设备、地区和注册同期群细分，可找出流失集中在哪。 还要考虑重复事件、跳过步骤的用户、时区边界、机器人或测试账户，以及延迟入库的事件数据。

回答框架: 验证 → 细分 → 漏斗 → 外部因素 → 建议

先验证下降是否真实。检查埋点是否变化、数据管道是否延迟、时区问题、机器人过滤规则、应用版本更新，以及多个仪表板或原始数据表是否都显示下降。 然后按平台、应用版本、地区、获客渠道、用户使用时长、付费与免费用户、设备类型和流量来源细分。全面下降可能意味着埋点、基础设施或广泛的产品问题；局部下降更可能指向某个平台、版本、市场或渠道。 接着检查用户路径：应用打开次数是否下降？登录成功率、首页加载、通知发送或用户进入后的核心行为是否出现问题？如果打开次数稳定但核心活动下降，问题可能在产品内部；如果打开次数下降，则需检查通知、获客、季节性、服务中断或外部事件。 最后根据根因提出行动。如果 iOS 版本更新后日活下降且崩溃率上升，应考虑回滚或紧急修复；如果只有付费获客用户下降，应检查广告投入与归因；如果数据只是延迟，必须先说明这一局限，避免制造不必要的紧急感。

回答框架: 目标 → 核心指标 → 过程指标 → 约束指标 → 细分

先明确目标。推荐功能可能希望改善内容发现、参与度、转化、留存或客单价。核心指标应反映预期用户价值，而不只是点击量。例如，对电商推荐，可用每名活跃用户通过推荐商品产生的购买或加入购物车次数。 过程指标包括推荐曝光、点击率、加购率、转化率、每次会话收入、覆盖率和多样性。约束指标包括退货、退款、低质量点击、页面延迟、用户投诉，以及对自然发现商品的蚕食。 应按新老用户、品类、设备、流量来源和推荐展示位置细分。模型可能改善平均表现，却伤害新用户体验或长尾商品的发现。 如条件允许，我会用 A/B 测试评估功能，并长期监控留存与复购。如果只是短期点击上涨，却把用户引向不相关或满意度低的商品，不能算成功。

回答框架: 把收入拆解为流量、转化率、客单价、产品组合、价格和留存

收入通常可近似看作流量乘以转化率再乘以平均订单金额，此外还受产品组合、定价、复购和退款影响。如果收入上升但转化率下降，可能有多种解释。 流量可能增长到足以抵消较低的转化率；价格调整、套餐组合、企业客户、更大的购物车或产品组合向高价商品倾斜，也可能提高客单价。公司还可能减少了低意向流量，虽然转化率下降，却带来价值更高的购买。收入或转化率的埋点变化也值得检查。 我会按渠道、产品、地区、新老用户、客户层级和设备细分，再将收入拆为会话数、转化率、客单价、退款率及复购。还应检查转化率的分母是会话、用户还是访客，因为口径变化会造成误导。 建议取决于增长质量。如果收入来自更健康的高价值客户，转化率略低可能可以接受；如果增长只是一次性涨价，而新客户转化持续走弱，就可能威胁未来增长。

回答框架: 受众 → 决策 → 指标 → 细分 → 提醒

先明确受众及其决策需求。高管需要从整体了解增长、留存、变现和风险，不需要在首屏看到每个运营细节。 顶层指标可包括月经常性收入、净收入留存率、总收入留存率、新增 MRR、扩张 MRR、缩减 MRR、流失 MRR、活跃客户数、试用转付费率、每用户平均收入、可获得时的获客成本回本期，以及预测与目标的差异。 有用的细分维度包括客户群、获客渠道、套餐、地区、公司规模、注册月份同期群，以及销售辅助和自助购买。图表可展示趋势、同期群留存、MRR 变动桥图、流失原因和目标差异。 设计上应提供指标定义、数据更新时间、筛选条件、负责人和提醒阈值。避免虚荣指标，也不要在没有明确标签的情况下混用用户数与收入。仪表板应回答：我们是否在增长、原因是什么、风险在哪里，以及管理层接下来应调查什么？

回答框架: 澄清决策 → 解释风险 → 提出更合适的展示方式

我会先弄清他们希望借助图表作什么决定。有时相关方提出某种图表，是因为心里已有叙述方向，但真正需要的是业务问题的答案。 然后清楚且不带防御情绪地解释风险。例如，累计收入图总是向上，可能掩盖近期放缓；分类过多的饼图难以比较差异；没有置信区间的图表可能显得比实际更精确；不区分流量结构的转化率也可能误导。 我会推荐更准确地回答同一问题的替代展示，如趋势图、同期群图、漏斗、分布图、细分条形图或指标拆解。如果对方仍需要原图，可以附上限制说明，但不会把误导性分析当成我的建议。 目标是维护信任。分析师既要提供帮助，也要对分析的严谨性负责。

回答框架: 摸清数据 → 标准化 → 验证 → 记录

先检查数据概况：行数、列名、缺失值、重复记录、数据类型、不可能的数值、日期格式和异常值。做任何转换前，我会保留原始副本。 接着标准化字段：去掉多余空格、统一大小写、解析日期、换算货币或单位、必要时拆分合并字段，并将不一致的类别名称映射到统一列表。去重前，必须先定义业务主键。 然后用可信来源核对总量。例如，收入总额应与财务导出一致，订单数应与源系统吻合，日期范围应完整。我会检查空值率、去重计数和类别值。 最后记录所有转换。用于决策的电子表格应明确展示假设，分开存放原始与清洗后的数据，并避免无法追溯的隐藏手工修改。

回答框架: 快速探索与受控计算

数据透视表适合快速探索、分组、按维度切分与汇总数据。当问题涉及按类别查看总额、计数、平均值或趋势，且相关方希望交互筛选时，它很有用。 公式分析更适合自定义、多步骤、可审查或需要精确控制的逻辑，例如同期群计算、瀑布模型、加权评分、例外标记、对账检查，或为预测提供输入。 实际工作中，我通常两者并用：先用数据透视表快速发现模式，再用公式或更清晰的模型形成最终结论。对周期性报告，我更倾向于可复现的查询或商业智能数据管道，而不是脆弱的手工表格。

回答框架: 假设 → 随机分组 → 指标 → 约束指标 → 决策

假设是：新结账页面减少操作阻力，提高购买完成率，且不会带来负面的后续影响。 先确认实验设置：随机分组单位、样本量、持续时间、曝光记录、参与资格，以及用户跨会话是否始终看到同一版本。如果按会话而非用户随机分组，回访用户可能造成实验污染。 核心指标是从开始结账到完成购买的转化率。辅助指标包括支付失败率、结账耗时、平均订单金额、附加商品购买率和回访。约束指标包括退款、拒付、支持工单、页面延迟、错误率和客户投诉。 分析既要看统计显著性，也要看实际业务意义。微小提升可能不足以抵消工程复杂度。细分结果可显示移动端改善、桌面端变差，但不要对噪声很大的小群体过度反应。 如果核心指标有实质改善，约束指标健康，埋点可信，且效果贯穿整个测试期，我会建议上线。

回答框架: 检查检验能力 → 观察方向 → 评估成本 → 决定

结果未达到统计显著性，并不自动意味着功能完全没有效果。先检查实验是否有足够的统计检验能力，能否检测出有业务意义的效果。如果样本量过小或指标噪声大，结果可能只是无法判断。 再看效果大小和置信区间。如果区间同时包含有意义的正面和负面影响，结论仍不确定；如果区间紧密围绕零，说明该功能对这个指标可能影响很小。 然后考虑成本和战略价值。如果功能维护成本高却看不到可衡量收益，不应上线，或应回滚；如果它战略上重要、风险低，或改善了定性的用户体验，可以考虑迭代或改用更合适的指标。 我会把结论总结为：测试了什么、观察到什么、结论有多可信、有哪些局限，以及推荐什么决定。

回答框架: 定义 → 来源 → 筛选 → 粒度 → 时间 → 对账

先比较指标定义。一张仪表板可能显示总收入，另一张显示扣除退款、折扣、税费或拒付后的净收入。确认收入的时点也可能不同：下单、付款、发货或开票日期。 再比较数据来源、筛选条件和粒度。一张可能排除测试账户、取消订单、内部用户、企业客户账单或某些地区；另一张可能错误关联订单明细，导致收入重复计算。还要检查时区及数据更新时间。 我会从可信来源开始逐项对账：以仪表板 A 的收入为起点，逐步加减差异，直到与仪表板 B 一致。每项差异都应有明确原因。 最终产出不应只是“仪表板 A 错了”，而应包含修正后的定义、指标负责人、权威数据源，以及防止今后再出现混淆的方案。

回答框架: 量化缺失 → 诊断原因 → 选择处理方式 → 披露影响

先量化缺失情况：哪些字段缺失、涉及多少行、占比多少，以及是否随用户群、时间、来源或平台而变化。数据缺失不一定是随机的。 然后查明原因。可能是用户可选输入、埋点故障、数据延迟入库、集成问题、隐私限制，也可能是该字段本来就不适用。处理方式取决于原因。 选项包括排除行、估算填补、设立“未知”类别、从其他来源补齐，或调整分析范围。我不会盲目把缺失值填为零，因为零和未知的含义不同。 最后披露影响，说明缺失数据如何影响结论可信度，以及在合理的不同假设下建议是否改变。

回答框架: 决策 → 分析 → 洞察 → 建议 → 影响

选择一个分析明显影响了决策的经历。先交代待作出的业务决定，例如上线、定价、营销投入、产品变更、运营或优先级。 然后用通俗语言解释分析：用了什么数据、哪个指标最重要、看了哪些细分群体、发现了什么意外之处？不要把整段回答都花在工具上。面试官更想知道你的工作如何改变了团队的认识。 接着说明建议和影响。例如，分析发现某活动总体看似盈利，但在某个渠道亏损，于是团队转移预算、提高投资回报率；又或者某功能增加了点击却降低留存，团队因此回滚。 有力的回答还要说明局限及相关方沟通：你如何处理不确定性，又如何让建议易于理解。

回答框架: 澄清紧迫性 → 给出初步判断 → 说明局限 → 安排后续验证

先澄清需要作什么决定、何时作出。如果决策风险低，初步判断也许足够；如果涉及收入、客户、合规或战略，就必须提高质量标准。 然后说明目前能回答什么、不能回答什么。我可能给出有明确限制说明的初步看法：“根据现有数据，趋势似乎在走弱，但 Android 用户的埋点不完整，因此我暂时不建议据此作最终上线决定。” 我会把眼下的答复与后续计划分开。眼下提供目前最可靠的估计和可信程度；后续列明数据清洗、验证检查、与权威来源对账，以及何时能给出更可靠的答案。 这样既不阻碍相关方推进，也维护了分析严谨性。最糟糕的是快速给出一个自信却错误的数字。

回答框架: 影响 → 紧迫性 → 工作量 → 依赖 → 相关方对齐

我会根据业务影响、紧迫性、工作量、依赖关系，以及分析是否支持不可逆或高风险的决定来排序。明天就要作出的上线决定，通常优先于锦上添花的仪表板优化。 我还会澄清每项请求支持什么决策。如果没有明确决策或负责人，可能需要先完善问题定义。对反复出现的请求，我会寻找自动化机会，避免团队长期困在手工报告里。 当优先级冲突时，我会明确说明取舍：“今天我可以完成客户流失分析，或者更新仪表板，但无法同时完成。鉴于流失分析会影响本周的留存计划，我建议先做它。” 优秀分析师不会按收到请求的顺序全部接受，而是帮助组织把分析时间用在能够改变决策的地方。