数据分析师面试遇到「转换率突然下降，你会怎么查」，可以先确认数字算的是谁、哪个行为与多长时间，再核对资料是否完整，接着找出下降集中在哪群使用者、哪段流程，最后提出能验证原因的下一步。如果还没分清付款减少与付款记录漏送，就先建议增加折扣，可能花了成本，却没有处理真正的问题。
以下用一款服务台湾与香港的购票 App 作虚构练习，所有数字、改版情节与回答示例均为原创。产品负责人看到每周购票转换率从 6% 跌到 4%，怀疑最近改版影响成交，希望你在当日下午先说明影响范围与优先处理事项。你的任务是缩小问题范围，说明目前能确定什么，以及下一项查证为何值得优先做。
先把「购票转换率」写成一句可以重算的话
这里先约定：分母是每周曾登入并查看活动详情的不重复使用者；分子是这批人从该周第一次查看活动详情起，二十四小时内至少有一笔购票付款成功的人数。一人即使看过多场活动、买了三次票，也只计一次。这个比率衡量查看活动后是否购票，不直接衡量单一活动页的说服力。
还要补齐日期与例外：两周各取完整七天，以台港共同的 UTC+8 时区划分，让最后一天进入的人也有完整二十四小时。内部测试帐户两期都排除，匿名访客不在本题范围；后续退款另行追踪，不回头把已付款的人删掉。若要衡量最终未退款成交，应另订等待时间及计算方式。
这些设定会实际改变答案。Amplitude 的漏斗分析说明指出，可按不重复使用者或事件总次数计算，而完成步骤还须符合指定顺序与转换时间。因此，不能直接把两张都叫「转换率」的报表拿来比较；先核对它们是否使用同一套定义。
题目给出前周 10,000 人查看、600 人付款，本周 12,000 人查看、480 人付款。初步计算是 600 ÷ 10,000＝6%，以及 480 ÷ 12,000＝4%。下降幅度为 2 个百分点；若以前周为基准，则是相对下降约 33.3%。把两种表述分开，后面的影响估算才不会混淆。
核对原始记录，先分辨漏记与真的少人付款
定义一致之后，先确认本周的观察时间与资料处理都已结束。尚未收到的付款记录，不能直接算成未付款。以 GA4 为例，Google 的资料更新说明提到，处理可能需要二十四至四十八小时，其间报表数字仍可能改变。实际调查应看正在使用的系统与资料流程，不能套用一个固定等待时数。
接着把报表拆回原始记录：活动查看是否重复送出、使用者识别码是否因登入方式改变而拆成两人、付款事件是否改名、资料汇入是否中断。核对时保留使用者识别码、查看时间、付款时间与状态，以及 App 版本。付款重试或单次买多张票都不能重复计人；只有进入本周分母、且在指定时间内成功付款的人，才放进分子。
这个虚构练习追加一项发现：部分新版 App 的成功付款事件改名，旧报表没有纳入。将后端订单与付款记录对照，确认本周实际有 540 位符合定义的使用者付款成功，其中 60 人未出现在原报表中；分母 12,000 人与前周 600 位付款者也已按相同方式核对。
修正后，本周转换率是 540 ÷ 12,000＝4.5%。原先看到的 2 个百分点下降，其中 0.5 个百分点来自漏记；还有 1.5 个百分点需要解释。此时可以请资料维护者修复报表，并标注受影响日期，同时继续调查实际购票变化。找到资料问题，并不代表商业表现就没有问题。
比率下降，也可能有一部分来自使用者组成
确定数字可信后，再把整体拆开。先选和购票行为有合理关系、也能加总回整体的分群，例如新客与旧客。以下把每周首次查看活动前，从未成功购票的人列为新客，其余列为旧客；当周买票后不改分类，避免把成功的新客移到旧客，让结果失真。
| 使用者群体 | 前周查看人数 | 前周付款人数／转换率 | 本周查看人数 | 本周付款人数／转换率 |
|---|---|---|---|---|
| 旧客 | 6,000 | 480／8% | 6,000 | 420／7% |
| 新客 | 4,000 | 120／3% | 6,000 | 120／2% |
| 合计 | 10,000 | 600／6% | 12,000 | 540／4.5% |
新客本来的转换率较低，而本周新客占比从 40% 升到 50%。若暂时沿用前周两群的转换率，把它们套到本周人数，会得到 6,000 × 8%＋6,000 × 3%＝660 人，相当于 5.5%。这显示，单是新旧客比例不同，就能在这个计算中使整体从 6% 降到 5.5%。
但实际只有 540 人付款，比上述 660 人少了 120 人，整体仍差 1 个百分点。新旧客本身的转换率都下降，因此不能只用「新客变多」结束调查。这是固定前周转换率的算术拆解，并非已证明多出的流量或改版造成多少损失，也不能把差额直接称为流失订单或收入。
接下来可按台湾／香港、App 版本与付款方式交叉查看，仍保留每组人数。只有少数人的群体即使跌幅大，也未必能解释整体变化；反过来，占比大的群体只跌一点，也可能值得优先处理。比较的目的，是找到能影响判断的范围，并非把所有栏位排列组合到出现一个极低数字。
沿着使用流程，让每个可能原因都有查证方法
新旧客都有下降，下一步就要把差异放回实际购票流程。对同一批查看者，依序核对选择场次、送出订单、开始付款与付款成功的人数，固定事件顺序及二十四小时范围。若前几步大致稳定，主要落差在开始付款之后，就先查付款路径；这也说明为什么目前还不急着重新设计首页推荐。
同时整理异动时间表，包括 App 发布、事件名称调整、付款供应商变更、票价与手续费、热门场次售罄，以及推广活动开始的时间。每一项都要接上「如果它是原因，应该看到什么」，再找能支持或削弱该解释的记录。
例如，付款流程出错的假设，应对照错误码、失败步骤与版本，并尝试在相同条件下重现；可售票量不足的假设，应查看受影响场次何时售罄，以及使用者是否在选位时离开；新一轮推广带来较多只想浏览的人，则应比较该来源使用者的查看、选位与付款行为，并留意它是否集中在某个市场。
假设练习再提供一条线索：两地部分使用者在新版 App 的银行验证页看到错误，开始付款后的成功比例也下降。这足以优先安排工程查证，但还不能把全站 1.5 个百分点的下降都归给改版。升级新版的人可能和没升级的人不同，同期也可能有不同活动或付款方式；只看「改版后一起下降」仍不足以确定因果。
若能重现错误，就先修复已知故障，再观察受影响路径是否恢复。若无法重现，可比较相同市场、相近新旧客组成及付款方式下的新旧版本，并查更细的时间记录。还要确认使用者真的进入新版银行验证页，不能只看安装版本。这些比较能缩小范围，仍可能漏掉其他差异；需要检验流程设计效果时，再安排合理的随机分组，让新旧流程在可比较的条件下试行。已知会阻止付款的故障，应先处理。
在有限时间内，先处理会改变决定的证据
面试官可能追问：「只有半天，怎么排优先顺序？」可以先完成计算定义、资料完整性确认与后端付款核对，因为这三步会决定问题究竟有多大。确认实际下降后，优先看人数多、跌幅明显且有错误线索的付款路径；较细的城市与推广来源分析可以接续做，不需要等所有图表完成才回报。若核对期间已确认有人持续无法付款，工程也可同步处理故障。
如果被问「这个跌幅有没有统计意义」，先交代比较期间、历史波动与各群人数，再评估差异的不确定性。两周可能包含相同使用者，演出安排与周末活动也可能不同，不能仅因总人数上万就说结论已确定。拆过很多群之后，也不应只挑最差的一群当答案；要看它是否持续出现、能否重现，以及和付款记录是否一致。
对需要立即处理的故障，判断门槛又不同。即使受影响人数还未估准，只要已确认有人因错误无法付款，就能建议先采取范围清楚、可撤回的处理，例如由产品与工程评估暂停相关功能的扩大上线。同时保留原始记录与观察方式，避免处理后反而失去查证线索。
结论要让产品、工程与资料维护者采取行动
完成上述核对后，当日下午的回报就能同时交代下降幅度与工作顺序：「本周实际购票转换率为 4.5%，较前周低 1.5 个百分点。原报表另有 60 位付款者漏记，已交由资料维护者修复。新客占比变高可在固定前周转换率的拆解中解释 0.5 个百分点，剩余差异仍需查证。目前新版银行验证路径有错误线索，建议工程优先重现并评估处理；暂时不能把全站下降都归因于改版。」
接着补上工作安排：资料维护者核对修复后的 540 人能否逐笔对回付款记录；工程确认错误重现条件及可行修正；分析师估算受影响人数，并在下一次完整资料到齐后更新比较；产品负责人依故障范围决定是否暂停扩大。回报时间应配合各项查证可完成的时间与资料更新节奏，不能只写「持续观察」。
最后留下一条改变判断的条件：若银行验证问题修复后，付款步骤已恢复，但新客整体购票仍偏低，就把后续重点转向活动供给与流量来源。这能让团队知道调查尚未结束，也避免下一次更新仍反复展示同一张曲线。
用二十五分钟练习一份可交付的调查摘要
先花五分钟重写购票转换率的定义，确保一位跨日购票、重试付款的使用者也能被正确计数。再用五分钟重算 4%、4.5% 与 5.5% 各代表什么，说明哪个来自报表、哪个来自核对、哪个只是比较基准。接着用十分钟列出三个可能原因，各配一项支持证据、一项相反证据与负责查证的人。
最后五分钟，录下一段九十秒回报。听回放时，检查是否先说目前确认的下降幅度，是否把假设说成结论，以及下一步是否真的能排除其中一种解释。完成后可阅读 产品经理的问题取舍与成效衡量指南，把同一套查证方式换到另一个情境，再练一次。