访问量上升却没有收入，或付款很多却很少核销，都需要拆开漏斗观察。单一成交额无法解释问题。
本文使用团购业务的虚构订单与关系数据模型，伪代码不连接真实支付。团购把用户购买、平台收款、商家履约与结算连接起来。下单、支付、成团、消费和退款必须保留各自状态，不能用一个布尔字段表达整个生命周期。
1. 从现象推到机制
浏览到下单反映选择与信任，下单到支付还受价格和通道影响，支付到核销则连接真实履约。每一步的分母要稳定，渠道、人群和时间窗口要一致。退款率还需按成熟订单批次观察，不能拿刚卖出的订单稀释。
图中的四个节点分别表示触达浏览、订单支付、真实核销、分层分析。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先用固定时间段的匿名事件，按用户或订单约定去重。把事件发生时间和数据采集时间分开，避免迟到日志改变历史口径。
1
2
3
browse -> create_order -> paid -> redeemed
payment_rate = paid_orders / created_orders
redemption_rate = redeemed_vouchers / eligible_paid_vouchers
先列业务事件与允许的状态迁移，再用少量匿名订单演算。涉及金额的地方保存成交快照，涉及并发的地方使用数据库约束，外部支付行为按支付协议另行实现。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 新渠道带来大量浏览 | 不一定提高最终支付转化 |
| 支付成功而核销率低 | 应检查使用条件与履约困难 |
| 重复上报支付事件 | 不能重复计入成交 |
对照 1：新渠道带来大量浏览
不一定提高最终支付转化。观察时记录同渠道的各阶段人数与订单数。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：支付成功而核销率低
应检查使用条件与履约困难。观察时记录支付批次的后续消费结果。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：重复上报支付事件
不能重复计入成交。观察时记录事件唯一键与订单身份。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
漏斗用于发现应进一步调查的环节，不能仅凭相关性确认原因。价格、季节与门店容量变化都可能同时影响多个阶段。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“重复上报支付事件”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
