加购到支付，漏掉的不只是用户

这道面试题我给的场景很家常：加购率稳定，加购到支付的转化率一直偏低，运营的方案是做购物车催付弹窗，「用户加了不买，提醒一下就好」，研发排期只要三天。

我会先问一句：加购之后到支付成功，中间到底有几步，每一步用户看到的是什么。

能把这条链路说清楚的人不多。多数人把它想成一条直线——用户犹豫，所以提醒。实际它是一段跨了商品、价格、库存、订单、支付、渠道回调的分布式流程，中间任何一处让用户觉得「和我刚才看到的不一样」，他都会退出，而且不会再回来。

本系列第 2/10 篇 · 上一篇：转化率跌了两个点，先看埋点 · 下一篇：优惠券系统，我等的是「叠加怎么办」

先把「漏」切成能归因的几段

我要求的最小拆分是六段：加购成功 → 进购物车 → 进结算页 → 提交订单 → 拉起支付 → 支付成功并回写。

这六段的分母各不相同，归因也完全不同。加购成功到进购物车掉得多，通常是购物车本身的问题：失效商品堆在顶部、勾选状态没记住、跨端不同步。进购物车到结算页掉得多，常见是凑单门槛、运费突然出现、优惠券不可用。提交订单到支付成功掉得多，就未必是用户意愿了，可能是渠道、风控或回调。

有个细节我会专门追：加购事件在哪些端上报，购物车是本地存还是服务端存。用户在小程序加购、在 App 结算，如果购物车没打通，漏斗上看到的是「加购后流失」，实际是数据没合。这类问题靠催付弹窗永远修不好，反而会在用户已经买完的时候再推一次提醒。

所以我给运营的第一个交付物不是弹窗 PRD，而是一张按上述六段切开、带版本号和端分布的表。表出来之前，不讨论提醒文案。

价格和库存的一致性，是信任问题

我最常在结算页丢单的地方，是「和刚才不一样」。

商品详情页显示券后 199，进结算页变成 219，原因是那张券只能用于指定品类、限时价刚好过期、或者满减门槛按原价算而用户按券后价理解。用户不会去研究规则，他只会认为这个平台在骗人。这类流失的害处不只这一单：下次他会在别处比价后再回来。

库存也一样。商详显示有货，提交时提示库存不足；或者购物车里三件商品，两件下架，页面还让用户去勾选。产品侧该做的不是加一句「以结算页为准」的免责声明，而是把价格和库存的一致性做成可验证的约束：

• 商详、购物车、结算页三处展示的券后价，来自同一次计价请求，超时就明确标「价格已变化，请重新确认」；
• 购物车在用户进入时批量校验一次有效性，失效商品折叠并说明原因，而不是静默灰掉；
• 限时价、优惠券的剩余时间在前台可见，别让用户靠猜；
• 计价结果带版本号，提交订单时重算一次，不一致就停在确认页，不自动按新价下单。

最后一条是我判断候选人有没有碰过真实交易的分水岭。很多方案只讲「展示清晰」，没人讲「提交时重算、越界就停」。价格会变，库存会变，这不是异常，是常态；产品要做的是让变化发生时有确定的处理路径。

提交订单那一步，本质是个状态机

一旦说到「重复点了两下提交」，话题就从交互变成了分布式事务。我不要求电商 PM 会写代码，但至少要说清楚订单的状态从哪来、到哪去、谁负责推进。

状态	进入条件	库存动作	超时后的处理
待支付	提交成功，生成订单号	预占库存，设释放时间	到点释放，订单关闭
支付中	已拉起支付渠道	保持预占	主动查单，不依赖用户操作
已支付	渠道回调验签通过	转为实扣	进入履约
已取消	用户取消 / 超时 / 风控拒绝	释放预占	可恢复商品有效性
异常待处理	回调丢失、状态冲突	不重复扣减	对账任务补偿

这张表里藏着几个必须回答的取舍。库存是下单预占还是支付成功后扣减？前者体验好、有超时释放的复杂度，后者不超卖但会让用户付了钱才发现没货。多数平台选预占，那就要说清楚预占时长、热门商品要不要单独库存桶、超时释放与支付回调撞车时谁赢。

幂等也得提。用户重复点提交、渠道重复回调、上游重试，都会造成重复订单或重复扣库存。请求带唯一键、状态流转只允许单向、回调验签后先查状态再更新，这三条不需要写进 PRD 的正文，但要在验收标准里出现，否则测试只会测「正常下单成功」。

我会追问一句：支付成功但订单状态没更新，用户看到的是「未支付」，你怎么处理。答「让客服处理」的，我基本知道他没跟过一次对账；答「前端先查单接口给确定状态，同时对账任务做补偿，用户侧不暴露中间态，并给出可查询的订单号」的，是踩过坑的。

支付失败不是终点

支付这一跳的漏斗最容易被误读，因为它混了三类完全不同的失败：用户主动放弃、渠道侧失败、我们自己链路的失败。

渠道侧要分银行、分支付方式、分端看成功率，某家渠道某个时段抖动，整体曲线上只表现为「转化略降」。产品能做的是给失败一个可恢复的路径：明确告诉用户是「银行卡限额」还是「系统繁忙」，保留原订单和已锁价格，允许换一种方式继续支付，而不是让用户重新走一遍加购。

掉单补偿则完全是后台产品。回调丢失、验签失败、消息队列积压，都需要主动查单和对账任务兜住，还要防重复支付和重复退款。这些不会出现在原型图上，但会决定「支付成功率」这个指标是不是可信。

我一般会在这里给个约束：所有状态文案不许出现「支付失败，请稍后重试」这种万能句。用户需要知道钱扣没扣、订单还在不在、下一步该做什么。文案是产品在这一段唯一能直接控制的东西，写不好，前面所有工程补偿都白做。

催付该不该做，我放在最后判

回到运营那三天的排期，我不是反对做，是反对把它当第一动作。

真要做，我会要求先说清四件事：触发条件（加购后多久、是否已支付、是否跨端）、频控（一个用户一周最多几次、大促期间是否关闭）、归因（怎么区分被提醒后下单和本来就要下单，最好留一小部分不提醒的对照）、以及护栏指标（卸载率、通知关闭率、投诉量）。

弹窗是最便宜的方案，也是最容易被滥用的一类增长手段。当加购到支付的流失主要来自价格不一致、库存失效、支付掉单时，提醒做得越勤，越像在反复戳一个已经不信任你的用户。

这道题我最后会问一句很具体的：如果三天排期只能改一件事，你改什么。答「弹窗文案 A/B」的，我会在评分表上停一下；答「结算页价格提交时重算并给确认提示，同时把支付掉单的补偿查一遍」的，我会接着问细节，因为这通常意味着他真的挽回过订单，而不只是优化过漏斗。