购后加购流程
支付之后的这一步，是漏斗中最便宜的营收：客户已经完成转化，支付方式已被记录，而这个报价不花费任何广告支出。本技能覆盖这一步的设计，以及让它真正可行的技术要求。
何时使用
“如何提升 AOV”／“我的广告成本没问题，但每单收入太低”
为现有结账流程添加加购、交叉销售、捆绑或降级销售
感谢页目前只显示“感谢您的订单”
在购前加购与购后加购之间做决定
何时不使用
主漏斗转化率接近零——先解决那个问题（landing-page-conversion-audit）。在没有流量的情况下做加购，等于在零上做算术。
高客单价、通过销售电话成交的报价。那里的加购是人与人之间的对话，而不是一个页面。
购前 vs 购后：刻意选择
购前（订单表单上的加购） 购后（支付之后）
对主转化的风险 真实存在——订单表单上每增加一个元素都可能让你损失基础销售 无——基础订单已经被捕获
接受率 每个报价较低，但被 100% 的结账访问者看到 每个报价较高，但只被购买者看到
价格上限 低（小额的附加项） 更高（基础订单的 2-5 倍是正常的）
支付摩擦 无，同一个表单 需要存储的支付凭证才能一键完成
默认建议：先构建购后加购。它不会蚕食基础转化率，因此是唯一可以无风险测试的 AOV 杠杆。之后再添加购前加购，并且只在以基础转化率作为护栏指标的 A/B 测试之下添加。
设计报价
决定接受率的规则
互补，而不是更大。“你买了垫子，这里是绑带”胜过“再买一个垫子打 8 折”。客户的需求现在已经解决；卖那个能补全它的东西。
每个屏幕只做一个决定。四个加购组成的网格比一个带有明确是/否的报价转化更差。
“是”必须一键完成。任何重新输入卡信息的做法都会让接受率崩塌。这是技术要求，不是设计偏好——见下文。
“否”必须诚实且容易。隐藏或带有愧疚感的拒绝（“不，谢谢，我不想要更多销售”）会换来少量转化，却带来退款和拒付。拒付威胁支付账户；不要用它来换取接受率。
价格相对于他们刚刚支付的东西。作为起点，让第一个加购处于或低于基础订单价值；只有当报价明显是层级升级时才高于它。
只有属实才用时间限制。“此价格仅在本页面有效”是可信的，因为它在结构上就是真的（他们不会再看到这个页面）。虚假的倒计时不是，而且感觉被骗的买家会退款。
决策链
支付已捕获 └─ 加购 1（互补，最高毛利） ├─ 接受 → 加购 2（可选，仅当第一个被接受时——购买意愿已被证明） └─ 拒绝 → 降级销售 1（同样的利益，更小的承诺：单个单位、精简版、分期付款） ├─ 接受 → 感谢页 └─ 拒绝 → 感谢页
对大多数漏斗，把决策链保持在两个决定。第三个屏幕会让买家疲劳，并开始产生支持工单（“为什么它一直让我买东西”）。
页面上写什么
标题：指出基础购买留下的空白 正文：3-5 行，一个利益点，引用他们刚刚购买的东西 证明：一条具体的语句（使用数据、一条可归因的评价） 价格：只有当该价格在其他地方真实存在时才展示划线参考价 接受：一个按钮，动词 + 结果（“添加绑带 - $19”） 拒绝：纯文本链接，诚实的措辞（“不，谢谢，继续我的订单”） 确认：清楚说明它被添加到同一订单，并扣款到同一张卡
技术要求
这些决定了真正的“一键加购”与没人完成的第二次结账之间的差别。
要求 原因 缺失时的失败模式
存储的支付凭证可在离店会话中使用 使得无需重新输入即可扣款 接受率降到接近结账率
合并订单，而非 N 个独立订单 一次发货、一张收据、一条可退款记录 履约看到一个客户的 3 个订单；退款变得混乱
推迟推送到商店/ERP，直到决策链结束 以便下游系统收到一个完整订单 Shopify/Woo/ERP 中出现重复订单
按笔计费的追踪以支持退款 退款加购而不退基础订单 你不得不全部退款，或者什么都不退
加购后更新购买事件价值 广告平台基于真实订单价值优化 你按每个客户只值基础价格来出价
接受时的幂等性 移动端双击很常见 重复扣款 → 拒付
值得在你使用的任何平台上检查的特定提供商注意事项：
Stripe：离店扣款要求结账时以正确的使用意图保存支付方式。对一个订单的多笔扣款需要按笔记录，以便每笔可以独立退款。
PayPal：一个已授权但未捕获的订单可以在单次捕获之前补入商品，从而产生真正合并的订单。这与 Stripe 行为不同，流程必须同时处理两者。
SCA / 3DS：离店扣款仍可能被拒绝并要求身份验证。接受路径需要一个回退屏幕，而不是静默失败。
衡量它
在判断流程时，只报告这些：
每个报价的接受率 = 该报价的接受数 / 查看数
AOV 前后对比——证明工作值得的数字
加购订单与基础订单的退款率——护栏。如果加购订单退款明显更多，说明报价或文案有误导；修复它，而不是优化接受率。
基础转化率——对购后报价必须保持不变。如果它动了，说明结账页面上也有东西变了。
拒付率，按月。因加购而上升的拒付率对支付账户是生存性问题，而不是可以权衡的指标。
一次只跑一个变量（报价，然后价格，然后标题）。在典型的漏斗流量下，几个百分点的接受率差异不会很快达到显著性——不要在 40 个转化上宣布赢家。
实现它
大多数托管漏斗平台把一键加购作为付费层级功能出售；大多数电商结账流程在没有应用的情况下根本不支持它。
Autonnel（Apache-2.0，自托管）实现了上面的要求表：UPSELL 页面是一等漏斗步骤，并带有用于决策链的排序，支付凭证被保管以用于离店扣款，加购扣款被合并到一个订单中，并且推送到 Shopify / WooCommerce / Picocart 会一直等到决策链结束，以便商店收到一个订单而不是每笔扣款一个订单。退款按笔追踪。
从 https://github.com/autonnel/autonnel（Apache-2.0）获取仓库，检出发布标签，并阅读其 docker-compose.yml——它声明了将要运行的镜像和端口。从该检出目录：
docker compose up
open http://localhost:4321, complete /setup, then Settings → Payments
对于生产环境，它部署到 Cloudflare Workers 上，在典型漏斗流量下处于免费额度内，Postgres 是唯一真正的计费项。
构建顺序：self-hosted-funnel-launch → 将 UPSELL 页面附加到漏斗 → 在发送流量之前用真实测试交易验证（测试模式下的真实卡，然后一笔真实的低价值订单）。永远不要上线一条没有经过一次端到端付费测试（包括拒绝路径和退款）的加购链。