用户付完钱看到的那一页，你当它是句号，它其实是整笔订单里最容易出事的一分钟

摘要：下单成功那一页，多数站只把订单号和金额重排一遍就收工。可这一分钟同时是用户注意力最高、而他手上信息最少的时刻。这篇把它拆成三件事：付款成功四个字在跨境场景里常常还不成立，欧盟法律认的那份确认压根不在这一页上，六个能往上加的模块兑现周期差着好几个数量级，却被多数团队排进了同一张周报。文末给出页面与邮件的分工表、一份上线自查清单和四周落地顺序。

付款成功那四个字，你的系统凭什么这么确定？

这一节先把地基挖开：确认在你的系统里指的是我们收到了，在用户心里指的是这事成了，两者中间常常隔着好几天。

收到订单和收到钱，中间还隔着一个状态机

先说一件容易被忽略的事。你的确认页是在什么时刻被渲染出来的？多数站的答案是：支付网关回调过来、订单落库、跳转，一气呵成。但这条链路里，网关回给你的那个信号，含义并不是钱已经到账。

Stripe在PaymentIntent与SetupIntent的生命周期说明里把这件事写得很直白。一笔支付要依次经过requires_payment_method、requires_confirmation、requires_action、processing几个状态，最后才到succeeded。文档里对succeeded的描述是：资金已经在你的账户里，你可以放心履约。

反过来读这句话就有意思了。在succeeded之前的任何一个状态，官方的意思都是别急着履约。而你的确认页，通常是在processing甚至requires_action的时候就已经渲染出去了。

异步支付方式那几天，页面上写的是什么

卡组织的授权是秒级的，所以做惯了信用卡的团队会觉得上面那段是抬杠。跨境不一样。

Stripe那份文档里对processing状态的说明专门点了一句：当支付走的是银行借记这类异步方式时，处理过程可能要花上几天。荷兰的iDEAL、德国的SEPA直接借记、巴西的Boleto、日本的便利店付款，都属于这一类。

Boleto尤其典型。用户在你的结账页点完提交，系统生成的是一张付款单，他得拿着这张单子去银行或者便利店把钱交掉，有效期通常一到三天。这个时候你的确认页上如果写着付款成功，那这四个字的准确含义是：我们已经给你打印了一张账单，请拿好，慢走不送。

本地支付方式该怎么按市场配，我在独立站支付方式怎么配那篇里按国别拆过一轮。这里只强调一点：每接入一种异步支付方式，你的确认页就多了一种需要单独写文案的状态，而不是多了一个支付图标。

库存、地址、风控：三种在确认之后才会翻车的情形

钱的问题之外，还有三处会在确认页渲染完之后才暴露。

第一处是库存。超卖在并发下单的场景里是常态而不是意外，尤其是多渠道同时卖同一批货的时候。这块的机制和防法我在库存管理与防超卖那篇里写过，这里只关心一件事：超卖被发现的时刻，几乎总是在确认页之后。

第二处是地址。地址校验通过不等于地址可达。偏远地区附加费、快递公司不派送的邮编、公寓楼没有门牌号，这些要等到面单生成或者头程交运的时候才会冒出来。

第三处是风控。3DS认证通过之后，收单行和你自己的反欺诈规则还可能各来一轮。高风险订单被人工审核挂起几个小时是常规操作，而用户看到的页面上写着的是订单已确认。3DS 2这套规则怎么影响拒付率，3DS 2新规那篇里有更细的拆解。

分级文案怎么写才既不吓人也不撒谎

知道了上面这些，问题就变成了：页面上到底该写什么。写订单已确认是撒谎，写订单待确认是自己吓自己，两头都不对。

可用的解法是把这句话拆成两层：上面一层写你确定的事，下面一层写还没定的事和什么时候会定。

这张表看着啰嗦，但它替你挡掉的是最难处理的那一类客诉：不是货没到，而是你说过的话后来不算数了。

这跟后台那套订单状态不是一回事

有人看到这里会说，我的系统里本来就有一整套订单状态。没错，但那套东西是给运营看的。

Magento把它拆成state和status两层，前者是系统内部的流转骨架，后者是可以自定义的展示标签，这两者的分工我在订单状态自定义那篇里专门写过。WooCommerce那边的on-hold、pending payment、processing同理，具体流转见订单工作流那篇。

后台状态和确认页文案是两套词表，中间需要一张映射。直接把processing翻译成处理中扔到页面上，用户读到的是一个不知道要处理多久、也不知道处理什么的黑箱。这个坑和把承运商原始轨迹原样贴给买家是同一类错误，只不过那个错误发生在下单之后的几天，这个发生在下单之后的几秒。

取消和改地址的那个窗口，比你想的值钱

确认页有一个别处都没有的属性：这是用户对自己刚填的东西记忆最清楚的时刻。地址写错了、数量点多了、忘了用优惠码，全在这一分钟里被想起来。

可多数站在这一刻什么都不给，用户只能去发工单。等工单被人看到，货已经进了拣货队列。

Baymard在关于取消申请中这个订单状态的研究里给了一个具体的数字：测试中有42%试图取消订单的用户，被提交之后那句含糊的提示搞懵了，比如我们会尽力帮你取消。这些人里的大部分转头就去找了客服。他们建议的替代写法是给出确切的等待时间和下一步，例如你会在一到两小时内收到一封邮件，告诉你订单是否已取消。

更好的做法是往前一步：在确认页上开一个自助窗口，允许改配送地址、取消整单、追加商品，窗口时长和仓库的拣货批次对齐。这个窗口的价值在跨境场景里被严重低估，因为一个错误的跨境地址，代价是一次头程运费加一次退运，而不是一张同城面单。

跨境多一层：清关资料缺一项，订单会在你看不见的地方停住

最后一种不确定只在跨境出现。有些目的国要求收件人提供额外的身份或税务标识才能清关：巴西要CPF，韩国要个人通关编码，俄罗斯部分渠道要护照号，欧盟的低值货物如果走IOSS还得对上税号。

这些字段大多不在结账表单里，得靠后续补收。而确认页是唯一一个用户还在屏幕前、还有耐心的时刻。等到货物卡在目的国海关再发邮件补件，往往要等三五天才有人回。

把这件事写进确认页，不需要什么技术含量：判断目的国在你的清单里，就在页面上多加一个区块，说明还差哪一项、为什么要、不填会怎样。这一个区块能省下来的清关滞留工单，比页面上那六个花哨模块加起来都多。

这一页和跟踪页，是同一件事的两半还是两件事？

两个页面在架构图上挨着，可它们回答的问题、失效的方式和该不该被收录，几乎没有一处相同。

一秒钟的页面和几天的页面

这两个页面在信息架构图上挨着，很多团队索性把它们当成一件事的前后两半。真做起来才发现，它们几乎没有一处是相同的。

确认页的生命周期以秒计。用户看它的时间中位数通常不超过一分钟，看完就关，绝大多数人再也不会回来。它的入口只有一个，就是结账提交之后那次重定向。

跟踪页的生命周期以周计。跨境小包从下单到签收动辄十来天，这十来天里用户会反复回来，每天一次的不算稀奇。它的入口散落在邮件、短信和浏览器书签里。这两页各自该长什么样，跟踪页那六项关键信息那篇写的是后者，这一篇写的是前者。

用户在这两处问的问题不一样

把两页的用户提问列出来，差别就很刺眼了。

在确认页上，人脑里转的是：成了吗？扣了多少？地址填对没？什么时候发？发票在哪？想改还来得及吗？六个问题全部指向刚刚过去的那三十秒。

在跟踪页上，转的是另外六个：到哪了？为什么三天没动？还要几天？要不要交税？我不在家怎么办？签收之后不满意找谁？六个问题全部指向未来。

一个回望，一个前瞻。用同一套模块去回答这两组问题，结果就是两边都答得半吊子。

一个是易失的，一个是要反复回来的

确认页有个特别容易被忽视的技术属性：它是易失的。

刷新可能触发重复提交警告，返回会被浏览器拦，关掉之后地址栏里那串带令牌的地址就再也找不回来了。也就是说，你精心堆在这一页上的所有内容，有效期只有用户不关标签页的那几分钟。

跟踪页恰恰相反，它必须能被反复打开，所以它的地址得稳定、得能存进书签、得允许免登录用订单号加邮箱查询。两页在这一点上的要求正好相反，共用一套地址方案必然有一边受委屈。

还有第三个地方，也在讲同一笔订单

把这两页摆一起还漏了一个角色：账户中心里的订单详情页。

它的属性介于两者之间，需要登录、地址稳定、内容会随订单状态一直更新，理论上它才是那笔订单的长期归档地。Magento那套账户面板包含哪些区块、地址簿和重新下单怎么配，属于另一个话题，这里先放一放。

问题是跨境站有相当比例的订单来自游客结账，这些人压根没有账户中心，而强制注册本身正是结账放弃率那篇里排在前面的成因之一。于是同一笔订单在三个地方各有一份表述，其中一份对一半用户不存在。想清楚这三处各自负责什么，比给确认页多加两个模块要紧得多。

更新频率决定了它们该由谁来渲染

确认页的数据在渲染完那一刻就基本冻结了，之后的变化都属于异常。跟踪页的数据每天都在变，而且变的那部分不在你的数据库里，在承运商那边。

这个差别直接决定了工程方案。确认页可以整页服务端渲染、一次成型；跟踪页得走异步拉取加缓存，还得处理上游接口超时的兜底。把两页塞进同一个模板，往往是给确认页强行加了一层它根本不需要的异步逻辑，然后在弱网环境下白屏。

别把两页合成一页，也别让它们互相顶替

实操里最常见的两种做法都不对。

一种是把确认页做成跟踪页的入口，页面上只有一句订单已提交加一个查看物流按钮。问题在于下单那一刻根本没有物流可查，用户点进去看到的是一片空白，第一印象就是这家店的系统不太行。

另一种是把跟踪页的全部内容前置到确认页，包括那些还不存在的字段，于是页面上出现一排等待更新的灰色占位。占位符是设计稿里最无害的元素，也是线上最劝退的元素之一。

正确的关系是接力：确认页负责把这一刻能说清的话说清，并明确告诉用户下一次收到消息是什么时候、从哪个渠道来。至于跟踪页，等到真有轨迹了再把人请过去。

还有个更细的分工。确认页该写的是这一单会怎么走，比如我们从深圳仓发，走的是邮政小包，正常两周左右到，中间有几天不会有轨迹更新。跟踪页该写的是这一单现在走到哪了。前者是承诺，后者是实况，承诺可以在下单那一刻就给全，实况给不了。

把这条分工反过来做的站也不少见：确认页上什么都不说，指望轨迹自己会说话。轨迹是不会说话的，它只会吐出一串代码和地名。

八个维度上的差别，一张表看完

可索引性上的差别，最容易被一刀切做坏

这两页在搜索引擎面前的处境也不一样，而它们常被同一条规则一起处理掉。

带订单号的页面必须挡在索引之外，这一点没有争议。可很多站的做法是直接对整个订单目录下noindex，顺手把免登录查询的那个入口页也一起挡了。那个入口页上没有任何一笔具体订单，它只是一个填订单号和邮箱的表单，本来应该被收录，因为品牌词加查询这类搜索量是实打实存在的。

确认页这边情况不同：它没有一个对应的公共入口页，因为下单这个动作不可能匿名复现。所以确认页的正确处理是整页挡住，不留例外，而它承担的公共信息职责得挪到别处去。挪到哪儿，后面那一节会专门讲。

两页之间那条唯一必须共用的口径

说完区别，也得说一处必须一致的地方：预计送达时间。

确认页上写的那个日期，和三天后跟踪页上写的那个日期，如果不一样，用户不会认为是物流出了变化，只会认为你在两个地方说了两套话。跨境本来就有清关这个不可控段，口径再打架，信任就没了。

做法很土但有效：把时效计算收到一个服务里，两个页面都调它，谁都不许自己算。改一次美国线的时效只用动一个地方，超过一个地方，就迟早会漏。

法律眼里的那份确认，根本不在这一页上

全篇最硬的一块：一个跨境卖家大多没听过、欧盟法院却在十几年前就判过的词。

持久介质这个词，是从哪儿冒出来的

做跨境的团队对欧盟消费者法的印象，一般停留在十四天无理由退货。其实同一部法里还有一条，跟确认页的关系更直接，却几乎没人提。

消费者权利指令2011/83/EU第8条第7款规定：远程合同订立之后，商家必须在合理时间内、且最迟不晚于交付货物之时，以持久介质向消费者提供该合同的确认。这份确认还得包含第6条第1款要求的全部信息，除非那些信息此前已经以持久介质给过一次了。

注意这句话里的动词。它说的不是展示，不是让消费者可以查看，而是提供，且必须提供在持久介质上。这两个字是整条规定的重心。

三个要素，一条条对着量

持久介质不是一个模糊的说法，同一部指令的第2条第10款给了它一个精确定义：任何一种工具，只要能让消费者或商家存下寄给他本人的信息，能在此后一段与该信息用途相称的时间里被再次调取，并且允许所存信息被原样重现。

拆开就是三条硬指标。

第一条是寄给他本人的。泛泛挂在网上给所有人看的内容不算，得是定向送到这个人手上的那一份。

第二条是日后可查，而且时限得跟信息本身的用途相称。撤回权是十四天，那这份东西至少得撑过十四天。

第三条是能原样重现。这一条最狠，它排除的是内容可以被单方面改动的载体。你数据库里那条订单记录能不能算？如果你今天改一句配送说明、明天调一次退货规则，用户下个月打开看到的和当初那份就不是同一个东西了。

判决里的那家公司，做法跟你现在一模一样

光看定义还有辩解空间。欧盟法院在2012年判过一个案子，把这条路堵死了。

C-49/11号案件Content Services的事实部分，今天读起来会让不少跨境卖家心里一紧：消费者在下单前，只能通过点击一个链接跳到商家网站的某个板块，才看得到撤回权的说明；下单之后收到一封邮件，这封邮件里同样不含撤回权的内容，只有一个指回该网站的链接。

法院的结论是，这种做法不满足要求。理由写得很直接：这样一来，相关信息既没有被商家给出，也没有被消费者收到；而这样一个网站，不能被视为持久介质。

把判决里那句话翻译成产品语言就是：在邮件里放一个跳回站上的链接，法律上等于什么都没发。这是很多站现在正在做的事，包括那些邮件模板做得相当漂亮的站。

邮件正文、邮件附件、邮件里的链接，是三种不同的东西

顺着三条指标把常见的几种做法过一遍，结论就清楚了。

这张表还顺带解释了一件事：为什么正经的欧洲电商发确认邮件时，正文长得像一份合同，还额外挂一个PDF。那不是他们爱折腾，是那份东西必须自己站得住。

那份确认里到底该装哪些内容

既然邮件那一份是法定的，就得知道它至少要写全什么。指令第8条第7款指向的是第6条第1款那张清单，落到实操上大致是这么几块：

• 商品或服务的主要特征，以及本单的具体规格
• 商家的身份、注册地址、能联系上的电话与邮箱
• 含税总价，以及所有运费、手续费和其他附加费用
• 付款方式、配送安排与履行期限
• 撤回权的条件、期限与行使方式，以及那份标准撤回表格
• 退货运费由谁承担，如果由消费者承担还得说明大致金额
• 法定的商品符合性保证，以及售后与商业保证的存在情况
• 争议解决与投诉受理的途径

撤回期从哪一天开始算，这一条在讲礼品订单那次已经拆过一轮，这里不重复；用户真的行使了撤回权之后，退款在系统里怎么落地，可以看退款与退货管理那篇。退货运费与政策文案本身怎么写才既合规又能接住搜索流量，可以对着退换货政策页那篇改。

发票和这份确认，是两件容易被混起来的事

还有个常见的误解：我们发了发票，是不是就等于给了确认。

不等于。发票是税务凭证，确认是合同凭证，两者要求的字段只有一部分重叠。发票上通常没有撤回权说明，也没有争议解决途径；而合同确认里不必然包含税号和税率明细。开票、发货、退款在系统里各自是什么动作，订单处理与发票工作流那篇讲得比较细。

务实的做法是让确认邮件承担合同确认，发票单独出、单独发，两者引用同一个订单号。硬把它们合成一封，结果往往是两边都缺字段。

美国那边是另一套口径，别混着用

最后说一句边界。上面这一整套只在欧盟经济区适用，美国没有持久介质这个概念，联邦层面管的是发货时限那一块，各州的自动续费法另有要求。

所以不要指望做一份全球通用的确认邮件模板。可行的方案是分成两层：一层是所有市场共用的骨架，一层是按目的国追加的合规段落，用同一份订单数据渲染。做多市场店铺的话，这块的模板与作用域怎么切，多店架构那篇里的思路可以直接借。

顺带说一句我自己踩过的坑：把这段合规文案交给翻译流程之后，德语版里那句关于撤回期的表述被润色成了更顺口但更含糊的说法。合规段落应当锁死，不进翻译系统，只由法务确认过的版本直接落库。

六件事该落在页面上，还是落在那封邮件里？

源研究给了六个候选模块，却默认它们摆在同一块地皮上。先把地皮分清楚，再谈盖什么。

一次确认，其实有三份副本

下单完成这件事，在用户那边会留下不止一个痕迹。页面上有一份，收件箱里有一份，如果你还接了短信或者即时通讯，那边还有一份。

问题是绝大多数团队只把第一份当成设计对象。邮件模板往往是当年建站时随手改的默认模板，改完就再没人碰过；短信模板更惨，通常是物流服务商代发的，文案里还带着人家的品牌名。

可从用户的角度看，三份副本的分量恰好是倒过来的。页面那一份看一眼就消失，邮件那一份会在收件箱里躺到这笔交易彻底结束，中间被搜索、被翻出来、被转发给同事报销。

页面这一份最短命，也最会被高估

先给页面正名：它不是没用，它是有一件别人干不了的事，就是交互。

只有在这一页上，用户是带着刚完成一次付款的状态、且身份已经确定的。他点一下就能加购、点一下就能建号、点一下就能提交一个问卷答案，不需要再验证任何东西。邮件做不到这个，邮件里的每一次点击都要重新跳一次浏览器，中间会掉一大批人。

所以页面那一份的定位应该是：把需要一次点击就能完成的动作全都放在这里，把需要被保存和被回看的内容全都放到邮件里去。这条分界线一画，源研究里那六个模块该往哪儿摆，答案就自己出来了。

邮件那一份最持久，却最容易被当成模板杂活

确认邮件在多数公司的归属很尴尬。它不属于营销，因为它不带活动；也不属于产品，因为它没有界面。于是它常常挂在技术那边的通知模板目录下，跟找回密码邮件放在同一个文件夹里。

这个归属带来两个后果。一是它的内容长期没人审，法定字段该补的没补；二是它的投递质量没人盯，进不进垃圾箱全看运气。

而它偏偏是这三份副本里唯一一份法律认账的。前面那一节已经把这个道理讲透了。发件域、身份验证记录和发送信誉这套底座怎么搭，可以照着邮件投递率那篇做一遍体检，尤其别让确认邮件和促销邮件共用同一个子域。

三份副本，各自擅长什么

六个模块逐个定位：能点的留下，要存的寄走

把源研究给的那六项，按上面这条分界线重新排一遍。

这张表里唯一和源研究不同的一行是使用指南。源研究建议把它摆在确认页上，理由是这能让用户对刚买的东西更有信心。理由没错，落位错了，为什么错，最后那一节会用一个具体的翻车过程讲清楚。

邮件里的那几封，别挤在同一天发

顺着上面的分工，一笔订单从下单到签收，你真正需要发的邮件其实不多。

• 下单后立刻：合同确认，法定字段写全，附一份PDF
• 出库时：发货通知，带跟踪号和第一次可查的时间点
• 清关放行或进入目的国派送时：一次状态变更提醒
• 预计到达前一天：使用与保养指南，按品类映射
• 签收后若干天：一次评价邀请或复购触发

五封，全程不超过这个数。轨迹每更新一次就发一封的做法，会把真正重要的那两封淹掉。自动化流和一次性群发在系统里怎么分工，流与群发那篇里有更完整的拆法；具体到DTC场景该配哪几条流，高回报自动化流那篇可以直接对着抄。

那封邮件的可读性，比你的落地页还该讲究

最后说个很少有人管的细节：确认邮件的排版。

它会在一个你完全无法预测的环境里被打开，可能是手机上的深色模式，可能是网页客户端的窄栏，可能是某个企业邮箱把所有样式都剥掉。所以它的第一屏必须在纯文本状态下也说得清事。

具体三条：订单号放在主题行里，别只放在正文；金额和预计送达日期用文字写，不要做成图片；退订链接和客服联系方式分开放，别挤在同一行小字里。

还有一条容易忽略的：邮件里那个跳回订单详情的链接，对游客订单要能免登录打开，否则用户点进去看到的是登录框，而他根本没有账号。这一点和确认页的令牌是同一套机制，后面讲安全那一节会展开。

交叉销售摆在这一秒，为什么和摆在购物车不是一回事？

同样一个推荐位挪到这里之后，它省下来的东西比它多卖的东西更值钱，但也可能是负的。

不用再输一次卡号，这一条就值半个转化率

推荐位这个东西，站上到处都有。商品页有，购物车有，搜索无结果页也塞了几个。为什么单单确认页上的那一块值得单独拿出来说？

因为只有在这里，用户已经付过款了。

这句话听着像废话，但它在转化漏斗上的分量很重。购物车里的推荐，用户点了加购之后还要走完整个结账：填地址、选物流、输卡号、过一次三方验证。这一整段路上每一步都在掉人。而确认页上的推荐，理论上可以做成点一下就追加进原订单，支付凭证复用，地址复用，物流复用。

把这两条路径画出来对比一次，你会发现同样一个加购动作，在购物车里后面还挂着五六个步骤，在确认页上后面只挂着一个确认弹窗。这个差别不是文案能弥补的，它是结构性的。

顺带说一句，源研究里给的那个话术挺聪明：告诉用户在接下来的五分钟内，还可以给这一单加上某某配件，享受某个折扣。它把一个促销包装成了一个即将关闭的窗口，而这个窗口是真实存在的，不是编出来的紧迫感。

跨境还多省两笔：一次运费和一次清关

上面那一段是通用逻辑，本土站也成立。跨境这边还有两笔额外的账。

第一笔是运费。追加的商品如果能并进同一个包裹，省下的是一整段跨境头程加末端派送。对轻小件来说，这笔运费经常比商品本身的毛利还高。用户那边看到的是免运费追加，你这边实际付出的成本接近于零。

第二笔是清关。每一票跨境包裹都要做一次申报，多一票就多一次申报成本、多一次被查验的概率、多一次可能的滞留。合成一票，这些都省了。

所以在跨境语境下，确认页的交叉销售不只是多卖一件，它是把两次履约压成一次。这一点在算账的时候常常被漏掉，因为运费和清关费通常挂在物流成本里，而推荐位的效果被记在营销那边，两笔账根本不在同一张表上。

但也可能是负的：多加二十欧，收件人多交一笔税

反过来的情况更值得警惕，而我没在任何一份英文资料里见过有人提。

各国对进口小包都设了低值门槛，门槛以下免关税或者走简化申报，门槛以上要走正式清关、要交税、有时还要交一笔代理清关费。一笔本来在门槛以下的订单，因为在确认页上被追加了一件配件，总申报价值顶破了那条线，于是收件人在门口被要求付一笔他完全没预期的钱。

用户的感受是什么？他会觉得是那次追加坑了他。而他多花的那笔税费，很可能比那件配件本身还贵。

这个坑的解法不复杂，但必须在系统里做：交叉销售模块在渲染之前，先算一遍追加后的申报总值，如果会跨过目的国的门槛，就不推、或者只推能把总价压在门槛内的选项。各国的门槛线差异很大，动手前得按目的国逐个核一遍；这类跨境费用怎么在下单之前就跟用户讲明白，配送政策页那篇里有完整写法。

顺便说一句，这条判断在礼品订单上尤其要紧，因为付钱的人和被要求补税的人不是同一个，那笔钱等于是你替买家送给收件人的一份惊喜。

窗口该开多久，得去问仓库不是问运营

追加窗口的时长，很多站是拍脑袋定的，常见的是五分钟或者十五分钟。

正确的定法是倒着推：你的仓库在什么时刻把这笔订单打进拣货波次？在那一刻之前，订单还能改；在那之后，改一次的代价是把已经拣出来的货退回货位，或者干脆生成第二张面单。

不同履约方式给出的答案差得很远。自有仓库按批次拣货的，窗口可能有两三个小时；第三方海外仓接单即拣的，可能只有十几分钟；预售或者定制商品的，窗口甚至可以是一整天。

所以这个时长应该是从履约系统里读出来的一个值，而不是写死在前端模板里的一个数字。写死的后果是：要么窗口太短，白白浪费了本来可以追加的时间；要么太长，用户点了追加，系统却告诉他订单已进入拣货，无法修改。后者比不给窗口更伤。

合单这件事，在系统里比在页面上难得多

页面上加一个按钮很容易，难的是后面那一串。

追加的商品要不要生成一笔新订单？如果生成新订单，两笔订单怎么在履约端合并？合并之后运费怎么摊？其中一件退货了，退款该从哪一笔里扣？发票要开一张还是两张？

比较干净的做法是把追加做成对原订单的修改，而不是新建订单：追加一个订单行，重新计算总额，对差额做一次增量扣款。这样后续的发货、退款、发票全都还是一笔单。代价是你的支付流程要支持增量授权，而不是所有网关和所有本地支付方式都支持。这块的实现差异，可以对着支付网关配置那篇逐个确认。

如果做不到增量扣款，退而求其次是生成关联订单，在履约系统里打上合并标记。这条路能跑通，但退款和对账会变复杂，得提前跟财务打好招呼。

什么品类不该在这一秒推

交叉销售不是哪里都能放。有几类情况，在确认页上推反而是减分的。

• 需要尺码或者规格确认的商品，用户刚为主商品纠结完，没心力再选一次
• 单价接近或超过主商品的，会让用户开始怀疑自己刚才是不是买错了型号
• 会显著改变整单重量或体积的，容易触发上面说的申报门槛与运费档位跳变
• 需要冷链或者有独立时效要求的，合单反而拖慢主商品
• 刚被主商品替代掉的同类品，推出来像是在说你买的那个不太行

把这几条写成规则挂在推荐引擎的过滤器里，比在推荐算法上花力气划算。商品推荐位本身怎么配、相关产品与向上销售各摆在哪，商品推荐配置那篇里有系统的做法。

别把这块做成第二个结账页

最后一条提醒，也是我见过最多的做坏方式：把确认页的交叉销售区做得跟一个完整的商品列表一样，带筛选、带排序、带分页。

用户此刻的心理状态是收尾，不是开始新一轮购物，这时候多给一屏选择就是在往路径上加摩擦力。给他一屏放不下的选择，等于把一个收尾动作重新变成一个决策任务，多数人的反应是直接关掉页面。

三到四件，配一句为什么推荐它的理由，一个追加按钮，这就够了。理由那句话比商品图更重要，因为它要回答的是这件东西跟我刚买的那个有什么关系，而不是它好不好看。

让用户在这一秒建号，你到底替他省掉了什么？

六个模块里唯一被大规模量化过的一项，而那个百分比底下藏着一次归因错觉。

那个42%底下，藏着一次归因错觉

六个模块里，只有建号这一项被大规模量化过。Baymard在把建号留到确认步骤这条建议里给的数字是：他们基准库里42%的站，仍然在结账开始阶段或者下单之前就要求用户建号。

数字本身不稀奇，稀奇的是他们在可用性测试里观察到的那个副作用。原文的意思是，一旦在结账起点给出建号选项，不少用户会把整条结账流程里的大部分表单字段，都算在建号这件事的头上，而不认为那些是无论如何都得填的常规结账字段。

这是一次典型的归因错觉。姓名、地址、电话，本来就是发货必需的，跟有没有账号毫无关系。可因为建号那个选项出现在最前面，它就成了整段体验的解释框架，后面填的每一格都被记在它的账上。

换句话说，把建号放在结账开头，成本不是多了一个密码框，而是让用户觉得整个结账都是为了给你建档。这个成本远大于它本身。

结账开头问和结账结尾问，用户算的是两笔账

同样一句要不要建个账号，在这两个时刻触发的思考完全不同。

在结账开头，用户还没付钱，他会本能地把这个问题展开成一串：我该用哪个密码？这家店存我信息安全吗？他们会不会连卡也存了？我以后还会不会在这买？他们会不会天天给我发邮件？源研究把这一串问题列得很齐，我读到的时候还挺有共鸣，因为这正是我自己在陌生站点结账时脑子里跑的东西。

在确认页上，这一串全没了。钱已经付了，信息已经给了，邮件地址他们已经有了。此刻的问题只剩一个：存个密码方便下次查订单，要不要？

同一个动作，前面那个版本要用户做一次关系承诺，后面这个版本只要用户做一次便利选择。这就是为什么源研究说，把建号搬到确认步骤能显著简化结账流程——它简化的不是字段数，是思考量。

一个密码框就够了，但那个密码框有讲究

实现上，确认页的建号可以做到极简：邮箱已经有了，直接拿它当用户名，页面上只留一个设置密码的输入框加一个按钮。

但这个孤零零的密码框有个技术上的坑。浏览器和密码管理器判断一个输入框是登录还是注册，靠的是周围有没有用户名字段和autocomplete属性。一个只有密码框的表单，密码管理器多半会认成登录框，然后弹出一个你在本站已保存的密码，用户一点就填进去，结果注册了一个跟别处同密码的账号，或者干脆报错。

正确做法是两件事：给密码框标上autocomplete为新密码的取值，并且在表单里放一个只读的、已填好邮箱的用户名字段。这个字段可以视觉隐藏，但必须在无障碍树里存在，否则屏幕阅读器用户会不知道自己在给哪个账号设密码。

表单控件本身怎么选才不吃掉转化，可以顺带看看下拉框那篇里的判据，那套思路对确认页上这几个小表单同样适用。

密码规则写错，等于把人挡在自己的账户外面

接下来是密码规则。这块几乎每个站都在用十年前的模板：必须包含大写、小写、数字和符号，长度八到十六位，且不许粘贴。

这套东西在权威口径里早就被推翻了。NIST SP 800-63B关于记忆型口令的那一节给的是另一套：用户自选口令至少八个字符，应当允许至少六十四个字符；不应当施加其他组成规则，比如要求混用不同字符类型；不应当要求用户定期更换口令，除非有证据表明已经泄露；应当允许粘贴，因为这有助于使用密码管理器；不得对口令做截断；并且要拿新设的口令去比对已知的常用与已泄露口令清单。

逐条对照，多数站的规则至少踩中三条。而其中最伤的是不许粘贴那一条：它精准地惩罚了那批安全习惯最好的用户。想让用户在这一秒设一个像样的密码，可以顺手把密码生成与信息熵那篇里的口径抄进你的提示文案，比写一行至少一个特殊字符有用得多。

还有一个和源研究呼应的细节：如果用户在确认页设密码时被规则挡住，他大概率不会重试，而是直接关掉。这跟在结账中途被挡住不一样——那时候他还有订单要完成，只能硬着头皮换一个；此刻订单已经完成了，他没有任何理由继续。

建号这件事，在欧盟是一个新的处理目的

合规上还有一层，做跨境的容易忽略。

为了履行订单而收集地址和电话，法律依据是合同履行所必需；而为用户建立一个长期账户、保存他的历史订单、以后据此做推荐和营销，这是另一个目的，需要另一个依据。两者不能混为一谈，也不能靠一句已阅读并同意打包解决。

落到页面上就是：建号那个按钮旁边，得说清建了之后你会保存什么、保存多久、他以后怎么删。这段话不需要长，一句话加一个链接就够，但它必须存在。同意与偏好这一整套怎么在跨境站里落地，同意横幅与合规架构那篇和同意管理平台选型那篇可以配着读。

游客订单怎么和后来的账号接上

还有个工程细节，几乎决定了这个模块有没有意义：用户在确认页建了号之后，他刚下的这一单以及以前用同一个邮箱下的所有单，能不能自动挂到这个账号下面？

如果不能，那他建这个号就是白建，登进去看到的是一片空白的订单列表，下次也不会再登录了。

能做到的前提是订单表里存了邮箱，并且建号流程会按邮箱回溯关联。这一步要小心一点：同一个邮箱下的历史订单可能包含别人代下的单，也可能包含配送到不同地址的礼品单，回溯时应当只关联订单本身，不要把那些一次性地址一起并进地址簿。账户中心那一侧要准备哪些区块才接得住这批人，客户账户中心那篇里讲得比较全。

别把建号做成领奖的门槛

最后一句提醒。有些站会在确认页写：注册账号即可领取下次订单的折扣码。

这个做法短期数字很好看，但它把一个便利选择重新变成了一次交易。用户建号是为了拿券，拿完就走，账号的实际使用率极低，而你的客户库里多了一批永远不会二次登录的记录。

更稳的做法是把理由写成他自己的好处：存下密码，下次查订单不用再翻邮件，也不用重新填地址。这句话没有诱惑力，但它招来的每一个账号都是真的。至于折扣券，留给到货之后那一封邮件，那时候他手里已经有货，判断要不要再买一次才有依据。

订阅这个动作，在欧盟能不能默认帮他勾上？

答案是不能，但比答案更有用的是背后那条窄路：谁算已有客户、发什么算类似产品、退订按钮该长成什么样。

已有客户这条窄路，窄在哪里

先把结论摆出来：不能默认帮他勾上，但确实有一条路允许你在没有事先同意的情况下给他发东西，而且这条路的入口正好就在这一秒。

电子隐私指令2002/58/EC第13条第2款写的是：如果某个自然人或法人在销售产品或服务的过程中从客户处取得了电子邮件联系方式，那么同一主体可以用这些联系方式，对自己的类似产品或服务做直销；前提是在收集这些联系方式的时候、以及此后的每一封邮件里，都清晰明确地给了客户免费且简便的反对机会。

这条被业内叫作软性同意。它听着宽松，实际非常窄，四个限定词每一个都在缩小它的范围。

同一主体，意味着你不能拿A品牌收来的邮箱去推B品牌，哪怕是同一家公司旗下。销售过程中取得，意味着从抽奖、下载白皮书、领优惠券那些渠道来的邮箱不适用。自己的类似产品或服务，意味着卖咖啡豆的可以推咖啡器具，但推理财课程就越界了。至于最后那条，每一封都得给退订入口，没有例外。

默认勾选为什么在欧盟不成立

源研究在讲订阅这一节时提了一句：也可以把默认状态设成已订阅，让用户自己取消勾选，不过他们并不推荐这种做法。

这句话在欧盟不是推不推荐的问题，是根本不成立。同意必须是明确的肯定性行为，一个用户什么都没做就默认勾上的复选框，不构成有效同意——这个口径在欧盟法院关于预先勾选复选框的判例之后已经没有争议了。

那正确的做法是什么？两条路二选一。走软性同意那条路，就别设复选框，直接在页面上告知你会发什么、多久发一次、点这里可以拒绝，把选择权做成一个显眼的拒绝入口。走明确同意那条路，就设一个默认不勾的复选框，文案写清楚订阅之后会收到什么。

最糟的是两条路混着走：设了一个默认勾上的框，文案写着我同意接收营销邮件。这既不是软性同意，也不是有效的明确同意，两头不占。

要不要加一道双重确认

双重确认就是订阅之后再发一封信，让用户点一下链接才真正生效。它在确认页这个场景里要不要做，得分开看。

走软性同意那条路，不需要双重确认，因为你依据的不是同意，而是已有客户关系加上随时可拒绝。硬加一道确认反而画蛇添足。

走明确同意那条路，德国等市场的实践里双重确认几乎是标配，因为它顺带解决了举证问题：出事的时候你能拿出一条带时间戳的确认记录。代价是转化会掉一截，尤其在这个场景下——用户刚下完单，注意力马上就要转移，让他再回收件箱点一次链接，流失不小。

取舍怎么做、双重确认对列表质量的影响有多大，邮件列表合规获客那篇里有更完整的对比。这里只补一句在确认页特有的做法：可以把订阅的生效确认，搭在那封本来就要发的订单确认邮件里，用户点一下就完成，不用额外收一封信。

一键退订那个请求，为什么设计成不带身份

说到退订，有个技术细节值得单独讲，因为它和这一整篇的另一条线正好构成对照。

RFC 8058定义的一键退订要求邮件里同时带上两个头字段，其中一个的值固定是表示一键退订的那个键值对，并且这两个头必须被有效的DKIM签名覆盖。真正有意思的是它对那个退订请求本身的规定：邮件接收方发起的这个POST请求，不得携带任何Cookie、不得携带HTTP认证信息、不得携带任何其他凭据；发送方也不得对这个地址返回HTTPS重定向。

换句话说，退订这个动作在设计上就是无身份的。既然请求里没有任何身份信息，那个地址本身就必须自带足够的信息，让服务端知道该退掉谁的哪一个列表。

把这条和确认页的地址放在一起看，就有意思了：退订地址必须自带足够信息，因为它没有身份可依；而确认页地址恰恰相反，它自带的信息再复杂也不能当身份用。同一个技术形态，在两种场景下的要求正好相反，而不少团队用的是同一套令牌方案。

退订不能把确认邮件也一起退掉

这是我见过最贵、也最容易发生的一个配置错误。

用户嫌你的促销邮件太多，点了退订。结果他下一次下单之后，再也收不到订单确认邮件、发货通知和清关提醒了，因为这两类邮件在系统里挂在同一个订阅状态下面。

更糟的是这个错误几乎没有反馈回路：用户不会来投诉说我没收到确认邮件，他只会觉得这家店的系统不太靠谱，然后不再回来。你在后台看到的只是一个正常的退订数字。

正确的结构是把事务性邮件和营销性邮件彻底分开：不同的发送域或子域、不同的模板目录、不同的订阅状态字段、不同的抑制列表。退订只影响营销那一侧，事务那一侧只有在用户注销账号时才停。订阅者管理与群发队列在后台该怎么切，邮件订阅管理那篇里给了具体做法。

把全订或全不订这道二选一拆开

还有一个能明显降低退订率的改动，而且它不在源文的六条里。

Baymard另有一篇专门讲这件事：让用户自己选择邮件频率，他们的基准数据是80%的站没有提供这个选项。研究里的观察是，有一部分用户其实是愿意收你的邮件的，但如果摆在他面前的是全收或者全不收这道非此即彼的选择，为了避免被淹没，他会选全不收。

做法很简单：在确认页那个订阅入口旁边，给两三个频率档，比如每周一封、每月一封、只在有新品时。或者更省事的做法是在页面上先不问，把频率选项放进第一封欢迎邮件里。

这一步的价值不在于多收几个订阅，而在于把退订从一个二元开关变成一个可调旋钮。旋钮拧小了还能拧回来，开关关掉了基本就回不来了。

这一秒问订阅，比在结账表单里问强在哪

最后回到位置本身。把订阅入口从结账表单挪到确认页，省下来的不只是一行表单。

结账表单里的每一个额外元素都在跟主任务抢注意力，所以那里的订阅入口必须做得极小、极不起眼，通常只有一行小字加一个复选框，根本没有空间说清你到底会发什么。确认页上没有这个约束，你可以拿出整整一个区块，把订阅之后能收到什么写清楚。

写清楚这件事本身就是转化率。用户不订阅，很多时候不是不想收，而是不知道会收到什么。弹窗那边的经验在这里同样成立，具体的文案与字段取舍可以参考邮件弹窗那篇，只是场景换成了一个用户已经付过钱、对你有基本信任的时刻。

购后问卷是不是全站最后一处还能问出归因的地方？

平台不肯给的那半张归因表，只剩这一个地方还问得出来，可惜多数站在这里问错了问题。

你从哪知道我们的，这句老掉牙的问题为什么突然值钱了

源研究把问卷列为六个模块之一，理由很朴素：用户此刻刚做完购买决策，脑子里的东西最新鲜，不问白不问。这个理由在2023年成立，在今天成立得更强，因为中间发生了别的事。

移动端的应用追踪透明度机制上线之后，一大批点击级的归因数据消失了；浏览器对第三方标识的限制又砍掉一层；再往后，越来越多的购买决策发生在你完全看不见的地方——某个内容社区的一条回复里，某个视频的口播中，或者某次和AI助手的对话里。

这些来源有一个共同点：它们不会在你的地址栏里留下任何参数。用户是在那儿被说服的，然后打开新标签页搜了你的品牌名，进来直接下单。在你的报表里，这一单来自自然搜索的品牌词。

于是那句老掉牙的你从哪知道我们的，成了整个站上唯一还能问出这层信息的地方。

自报归因不是替代品，它是另一把尺子

这里要先破一个误解。有人把购后问卷当成平台数据失真之后的替代方案，指望用它算ROAS，这条路走不通。

平台数据量的是点击，问卷量的是印象。同一个用户可能在三个地方见过你，最后从其中一个点进来。点击数据只认最后那一下，问卷答案往往指向他印象最深的那一次，而那两次经常不是同一次。

把它们当成互相校验的两把尺子，才有用。当某个渠道在问卷里的提及率明显高于它在平台数据里的占比，说明这个渠道的影响力被点击模型低估了；反过来则说明它可能在收割本来就要来的人。多触点归因模型各自的偏向，归因模型选型那篇里拆得比较细；AI搜索这一层的可测部分，那篇讲两层测法的文章给了具体的动手方案，零点击归因那篇则补了代理信号这一侧。

单选题会把答案压进你预设的那几个格子

问法比问不问更重要，而多数站在这里犯的是同一个错：给一组预设选项，让用户单选。

预设选项的问题在于，它只能包含你已经知道的渠道。真正值钱的答案恰恰是你不知道的那一个——某个你从没投过的垂直社区、某个自发提到你的播客、某个AI助手在回答某类问题时顺口提了你一句。这些答案永远不会出现在你的选项里，于是用户只能勾一个最接近的，比如其他，或者干脆勾了朋友推荐。

更好的结构是一个开放文本框加一句引导，比如你是怎么知道我们的？随便写几个字就行。愿意答的人本来就是少数，愿意答的那批人也不介意打几个字。

如果一定要给选项，那就把开放文本框放在最上面，选项放下面当提示，而不是反过来。顺序会显著改变答案分布，这一点在任何一次问卷里都成立。

只问一个问题，而且不要放跳转

这一秒的用户注意力是极其昂贵的。他愿意给你的，大约是一次点击或者一行字，再多就没有了。

所以确认页上的问卷必须满足三条：只有一个问题；提交后原地反馈，不跳转到别的页面；不承诺任何奖励。

第三条容易被忽略。一旦挂上答完抽奖或者答完送券，答案质量立刻崩塌——为了拿券，用户会随便勾一个，而且会优先勾第一个选项。你收上来的不再是归因数据，是一堆按位置排序的噪声。

至于跳转，源研究里也提了一句类似的意思：让用户回答的时间成本越低，愿意答的人越多。跳转就是最贵的那种成本，因为它意味着离开这个已经完成的状态，进入一个未知的新页面。

样本偏差从第一秒就存在

拿到数据之后，得记住它是从哪儿来的。

确认页上的问卷，样本只包含完成了购买的人。所有中途放弃的人、所有看了不买的人，全都不在里面。这意味着你算出来的渠道占比，回答的是哪些渠道带来的人更容易成交，而不是哪些渠道带来的人更多。

还有一层更微妙的偏差：愿意花时间答题的人，本身就更偏向对品牌有好感的那一类。所以问卷里品牌相关渠道的占比天然偏高，投放类渠道天然偏低。

这两条不需要修正，只需要在解读的时候记住。真正危险的是拿这份数据去直接砍投放预算，那等于用一群已经买了的人的记忆，去否定一批还没买的人的来源。

答案怎么和后台数据对上

问卷答案要有用，得能和订单挂上。这一步在实现上有个坑：很多站把问卷做成第三方嵌入的表单，提交之后数据落在别人的后台，跟你的订单表毫无关系。

这样收上来的数据只能看一个总的分布，没法回答更有价值的问题，比如自报来源为某个渠道的用户，客单价和复购率是不是更高。

正确做法是把答案作为订单的一个属性存进自己的库，跟订单号绑定。存的时候只存答案文本，不要连着存任何能识别个人的额外字段，这样后续做分析也不用担心合规问题。如果站上已经有客户数据平台，这条数据应该往那边同步一份，客户数据平台那篇里讲了什么阶段该上、怎么选。

攒够量之后，最值得做的一件事是把自报来源和实际的复购表现放一起看。有些渠道带来的人当期转化一般，但九十天复购明显更好，这类渠道在纯点击模型里长期被低估。这套算法可以对着用户终身价值那篇里的分组模型搭。

别把问卷做成第二次营销

最后提醒一句常见的跑偏：问卷区做着做着，就变成了一个引导关注社交账号或者下载应用的入口。

这两件事都可以做，但别混在问卷里。问卷是你在向用户要东西，推广是你在向用户给东西，把它们塞进同一个区块，用户会觉得那句我们想听听你的意见是个幌子。

如果实在想在提交之后放点什么，最合适的是一句真诚的反馈，比如告诉他这条答案会被谁看到、大概会怎么用。这句话不值钱，但它是这一秒里唯一能建立一点人味儿的地方。至于A/B测试该怎么设计才不把问卷本身测成噪声，那篇讲三十个测试方案的文章里有可以直接照搬的框架。

地址里挂着订单号，不可收录到底挡得住谁？

这一节讲两件常被混为一谈的事：不让引擎收录，和不让别人打开，是两套完全不同的机制。

猜得到的订单号，就是猜得到的订单

确认页有一个别的页面都没有的处境：它经常要在没有登录态的情况下展示一整笔订单的全部细节。

原因很实在。跨境站的游客结账占比通常不低，这些人没有账号，你没法用会话去判断他是谁。于是最省事的实现就是把订单标识拼进地址里，比如某个路径下面跟着订单号，页面根据这个号去查数据然后渲染。

这就是OWASP那份不安全直接对象引用防护速查表讲的那类问题：攻击者通过改动地址或参数里的标识符，就能访问或修改本不属于他的对象，根源在于缺少访问控制检查。

而电商的订单号，恰恰是全站最容易猜的标识符之一。多数系统的订单号是顺序递增的，或者带着可预测的日期前缀。买一单，看一眼自己的号，前后加减几个数，就能翻出别人的姓名、地址、电话和买了什么。

换成猜不到的标识符，还不够

知道这个坑之后，常见的第一反应是把订单号换成随机串。方向对，但那份速查表专门提醒了一句：使用复杂标识符只能算纵深防御的一层，即便用了它，访问控制依然是关键；如果攻击者通过别的途径拿到了这些地址，应用仍然应当拦住他。

这句话点破的是一个常见的心理误区：把不可猜等同于不可访问。地址会泄漏的途径多得很——用户自己发到群里、被浏览器同步到别的设备、出现在第三方脚本的引用来源里、被截图发给客服。

速查表给的建议更彻底：尽量别把标识符暴露在地址和请求体里，而应当从会话信息中判断当前用户是谁；多步骤流程里，标识符应当在会话里传递，以防被篡改。

一次性令牌怎么发才不变成新的麻烦

对游客订单来说，会话这条路走不通，所以实操上的折中方案是一次性令牌。几条要点：

• 令牌与这一笔订单绑定，且足够长、足够随机，不从订单号推导
• 设一个明确的有效期，几十分钟到几小时，跟你的追加窗口对齐
• 过期之后不要报一个技术错误，而是引导到用邮箱加订单号自助查询的页面
• 令牌只授予查看权，任何修改操作都要再验证一次，比如向下单邮箱发一封确认信
• 不要把令牌塞进任何会外发的地方，包括第三方分析脚本的页面地址上报

最后一条特别容易漏。很多站的分析脚本会把完整地址上报给第三方，于是那串令牌就随着每一次页面浏览被送到了别人的服务器上，还会出现在报表的页面路径列表里。正确做法是在上报前把令牌部分替换掉。

这一页上不该出现的几样东西

访问控制之外，还有一层是内容本身。确认页因为是自己人写给自己人看的，常常会把不该露的东西一起渲染出来。

最后一行是最容易出事的一种：前端拿到的接口返回里带着一堆多余字段，虽然没渲染到页面上，但打开开发者工具就能看到。做字段过滤要在服务端做，不能指望前端不显示。

用户把链接转发给家人，这是正常需求不是攻击

有一类场景值得单独设计：用户下完单，顺手把确认页链接发给了配偶或者同事。

这不是滥用，是真实需求。家庭采购要报账，公司采购要留档，礼品订单更是常常需要给收件人看一眼预计到达时间。可你的令牌方案如果做得严，对方点开就是一个已失效的提示；如果做得松，那就是前面说的那个安全问题。

比较妥的做法是给一个明确的分享入口，生成一个内容删减过的版本：保留商品、数量、预计送达和跟踪入口，去掉价格、支付方式和账单地址。礼品订单更要按这个模板走，为什么礼品订单在整条链路上都需要区分两个人，我在礼品订单那篇里从九个环节拆过。

给了正规的分享入口之后，还有个附带好处：你能知道有多少订单被分享出去、分享给了谁看什么，这本身就是一份关于用户使用场景的数据。

不让引擎收录，和不让别人打开，是两回事

这里要澄清一个混淆。给页面加不收录标记，管的是搜索引擎的索引行为，它既不阻止爬虫抓取，也完全不阻止任何一个拿到地址的人打开这一页。

把它当访问控制用，等于在门上贴了一张请勿入内的纸条，然后不锁门。真正的锁必须在服务端，就是上面说的那一套。

标记本身还是要加的，而且要加对。确认页是整页不收录，没有例外，因为它没有一个匿名可复现的公共版本。这一点和跟踪页不同，跟踪页那个免登录查询入口是应该被收录的。别用一条目录级规则把两者一起处理掉。

这一页答不上来的问题，会跑到哪儿去

最后是这一节真正想说的那一跳。

确认页是不可被索引的，也就是说它上面写得再好，引擎和AI助手都读不到一个字。但它有一个别处没有的作用：它是一台探测器。

用户在这一页上读完之后仍然要去问客服的每一个问题，都对应着你的帮助中心里应该有、但现在没有的一个公开页面。这份缺口清单不需要花钱调研，把三个月的售后工单按提问时间过滤一遍，凡是在下单后二十四小时内提出的，基本都属于这一类，工单分流那一侧的口径可以参考出海客服从零搭起那篇。

接下来的动作就顺了：确认页上写个性化的那一份，比如你这一单预计几号到、你这一单的税费谁付；帮助中心里写公共的那一份，比如发往德国的订单通常几天到、我们的税费口径是什么。两份内容同源、同一个数据口径，只是一个带订单号一个不带。

前者降工单，后者能被搜索和被引用。这套从工单反推公开内容的做法，我在客服与内容协作那篇里写过完整的流程；如果站上还接了对话式客服，机器人能答什么、什么时候该转人工，可以对着那篇讲转人工边界的文章再校一遍口径。

说白了就一句话：确认页是内容需求的探测器，不是内容的载体。把探测到的东西留在探测器里，等于一份现成的选题清单被锁在了保险柜里。

这一页做的事，效果什么时候才算数？

最后把六个模块放到同一根时间轴上，你会发现它们唯一的共同点，就是共用了同一块屏幕。

六个模块的兑现周期，差了好几个数量级

前面九节讲的都是单个模块怎么做对。这一节讲它们放在一起的时候会出什么事，而这件事我自己栽过。

先看一张表。同样是摆在确认页上的模块，它们产生价值的时刻差得极远。

最上面那一行和最下面那一行，兑现时间差着好几个数量级：一个是五分钟，一个是一个多月。它们唯一的共同点，是共用了同一块屏幕。

我把那份指南折到了最底下

说个具体的。前两年我带过一个出海精品咖啡站，卖手冲壶、滤杯、磨豆机，也卖自家烘的豆子，主要市场在美国和德国。这个盘子的特点是器具是首购、豆子是耗材，复购能不能起来，几乎决定了它的生死。

那次改造，我把确认页从一个只有订单号的收据页，做成了六个模块齐活的完整版本：交叉销售、订阅、建号、冲煮指南、应用下载、一个单题问卷。做得挺认真，对着源研究那六条几乎条条满分。

第一个月的数据非常好看。追加订单贡献了不小一块增量，订阅率是弹窗那边的好几倍，建号率从游客结账时代的一成出头涨到六成以上。我在月报里写了一句确认页从死胡同变成了第二个入口，还挺满意。

接下来那件事，是所有麻烦的起点：我照着当期贡献给这六个模块重新排了序。交叉销售提到最上面，订阅和建号跟在后面，冲煮指南折叠到了页面最底部，默认收起。理由很充分——它是唯一一个当月没有产出任何可见数字的模块。

半年后，复购曲线不对了

问题是半年之后才浮出来的，而且不是以问题的形式出现的，是以一条走平的曲线出现的。

首购到复购的中位间隔在变长，六十天复购率在往下掉。我先查了豆子的价格、查了竞品、查了物流时效，都没找出所以然。真正定位到原因，是在翻一批客服工单的时候：有相当一批人买了手冲壶之后，第二次回来买的不是豆子，而是别的器具，或者干脆没回来。

再往下挖，问题出在一个特别具体的地方：研磨粗细。买了手冲壶的人，如果不知道该磨多粗，第一次冲出来的东西要么酸涩要么寡淡。而这件事，恰恰写在那份被我折到页面最底下、默认收起的冲煮指南里。

我用一个对当期数据最有利的排序，把这个盘子里最关键的一次用户教育机会藏了起来。

三条没能早点发现的原因

回头看，能早点发现的机会有好几次，都被同一类思路挡住了。

第一条最根本。这六个模块争的是同一块首屏，可它们的产出兑现周期差着好几个数量级。按当期贡献排序，本质上是在给一批期限完全不同的资产做贴现，而我用的贴现率是零——把一个月之后才兑现的东西，和五分钟后就兑现的东西，按同一个面值比大小。这么排，结论是注定的。

第二条是它的直接后果：唯一能当期看到数字的那个模块，必然会赢。这不是谁判断力差，是排序规则自己保证的。只要衡量周期短于兑现周期，长周期的东西就永远排在后面，然后因为排在后面而产出更少，然后因此更有理由排在后面。

第三条我想了很久才想明白，它跟数据无关，跟科目有关。教用户把东西用好这件事，在我们的预算表上挂在客服与售后支持下面，也就是成本科目。而在一个靠耗材复购活着的生意里，它其实是一笔营销投入——它买的不是这一单的满意度，是这个人还愿不愿意继续待在这个品类里。挂错了科目，它就永远排在被砍的那一队。

还有一条不算原因、但让整件事更难被发现的：第一次冲砸了的人不会来投诉。他不觉得是壶的问题，他觉得是自己没本事，然后安静地把壶收进柜子。这条路径上没有任何一个信号会进到你的工单系统里。

改了三处，代价是什么

找到原因之后的修改并不复杂。

第一处，把指南整个从确认页搬走，挪到一封新的邮件里，触发条件不是下单，而是轨迹进入目的国派送——也就是包裹预计到手的前一天。那时候用户即将拿到东西，读指南的动机是最强的。

第二处，指南按品类映射而不是按单品。全站几百个货号，一个个配内容不现实，但器具其实就那么几大类，先做了排在前面的八类，覆盖了绝大部分订单。这一点源研究里也提了：对于有成千上万个货号的站，可以先从几个主力品类或者畅销品做起。

第三处，给指南单独定了指标，不再和交叉销售放在同一张榜上比：看的是这个品类的九十天复购率，以及第二次下单里耗材的占比。

结果是六十天复购率在两个季度里回到了基线之上，而交叉销售的当期收入一点没掉。这一条我当时挺意外，后来想通了：它们本来就不在争同一批用户的同一个时刻——一个抓的是下单后那五分钟的顺手，一个抓的是拆包裹那一天的兴致。是我自己非要把它们摆在同一根柱子上比高矮。

这件事和开箱体验那篇讲的其实是相邻的两段：那篇处理的是包裹到手那一刻的观感，这次处理的是包裹到手之后第一次使用的成败。至于留存心理学里那些通用机制，增长心理学那篇讲得更系统，这里补的是它没覆盖的一个具体情形：当几个留存机制抢同一块位置时，该按什么排序。

该配着看的两个指标

如果只让我留两个指标来盯确认页，我会留这两个，而且它们必须配着看。

第一个是确认页的模块参与率，按模块分开算，分母是看到这一页的人。这个数告诉你哪个模块在被用。

第二个是同期的九十天复购率，按有没有参与过每个模块分组对比。这个数告诉你那个模块到底有没有用。

只看第一个，会得出我当年那个结论；只看第二个，样本积累太慢没法指导日常改动。两个一起看，才能识别出那种参与率不高但复购差异明显的模块——那类模块通常不该被砍，该被搬到更合适的位置去。这套分组算法可以直接用会员体系那篇里的口径，私域侧的承接则参考私域从零起步那篇。

上线前，这份自查过一遍

• 页面主标题的措辞，和底层支付状态是对得上的，异步支付有单独文案
• 库存、风控、清关资料这三类不确定，各有一句预先写好的说明
• 确认邮件正文写全了法定字段，并附一份可下载的凭证
• 邮件里没有把关键内容做成只有链接可点
• 事务邮件和营销邮件走不同子域、不同订阅状态，退订不影响前者
• 订阅入口没有默认勾选，且给了频率选项或拒绝入口
• 建号只需一个密码框，密码规则不加多余的组成要求，允许粘贴
• 建号后能把同邮箱的历史订单自动关联上
• 交叉销售有明确窗口，窗口时长来自履约系统而不是写死在模板里
• 追加商品前会校验申报总值是否顶破目的国门槛
• 问卷只有一题，不跳转、不给奖励，答案存进自己的订单库
• 页面地址里的标识符不可推导，且服务端有独立的访问控制
• 卡号做了掩码，内部字段在接口层就被过滤掉
• 整页不可收录，但免登录查询入口页没有被同一条规则误伤
• 有一个内容删减过的分享版本，礼品订单默认走这个模板
• 预计送达时间和跟踪页取自同一个服务，两处口径一致
• 使用指南不在这一页，而在到货前那封邮件里
• 每个模块都指定了它自己的兑现周期和对应指标

四周落地顺序

如果这一页你现在就想动，建议按这个顺序，一周一步。

第一周一行代码都别改。只做两件事：把三个月的售后工单按提问时间筛出下单后二十四小时内的那一批，数一数其中有多少条是这一页本来能答的；再把确认邮件原样打印出来，对着前面那份法定字段清单逐条打钩。这两个数出来，后面三周做什么、按什么顺序做，基本就定了。

第二周只改文案，不动结构。把主标题按支付状态分级，把三类不确定各补一句说明，把确认邮件缺的字段补齐。这一周的改动全是低风险的，但它能吃掉多数工单。

第三周做那两个见效最快的模块：交叉销售的追加窗口，以及一个只有密码框的建号入口。这两项都要动到后端，得留出联调时间。

第四周处理长周期的那几项：订阅入口与频率选项、单题问卷、以及把使用指南搬到到货前那封邮件里。同时把每个模块的兑现周期和指标写进文档，别让它们混进同一张周报。

三条反信号：出现这些就别再往上加了

最后给三条停手的判据。

第一条，确认页已经需要滚动两屏以上才能看到订单摘要。订单摘要是这一页的主业，主业被挤到第二屏，说明模块加多了。

第二条，客服工单里开始出现关于这一页某个模块的提问，比如那个折扣码在哪、我点了追加为什么没生效。一个用来降低咨询量的页面开始产生新的咨询量，方向就反了。

第三条，你已经说不清某个模块的产出该在什么时候、用什么指标来衡量。说不清就意味着它进不了任何一次复盘，进不了复盘的模块，迟早会因为一次排序调整被折叠到最底下——就像我那份冲煮指南一样。

常见问题解答

订单确认页需要设成不可收录吗？带订单号的那种要不要单独处理？

需要，而且是整页不留例外。带订单号或令牌的确认页没有任何一个匿名可复现的公共版本，被收录只有坏处没有好处。但要注意两点：一是不可收录标记管的是索引，不是访问控制，服务端仍然必须有独立的权限校验；二是别用一条目录级规则把整个订单相关目录一起挡了，因为免登录的订单查询入口页上不含任何具体订单，那一页应当保持可收录，品牌词加查询这类搜索需求是真实存在的。

订单确认邮件必须写全哪些内容才算合规？

面向欧盟消费者的话，参照消费者权利指令第8条第7款，它指向第6条第1款那张信息清单，落地大致是：商品主要特征与本单规格、商家身份与可联系到的地址电话邮箱、含税总价与全部附加费用、付款与配送安排、撤回权的条件期限与行使方式加那份标准表格、退货运费由谁承担、法定符合性保证与商业保证、争议解决途径。关键不只在写什么，还在于必须以持久介质提供——把这些内容只做成一个跳回网站的链接，法律上不成立。美国方向没有这套要求，别用同一份模板一刀切，做成骨架加按市场追加的两层结构更稳。

交叉销售的追加窗口设多久合适？

这个数不该由运营拍板，该从履约系统里读。倒着推一步：你的仓库在什么时刻把订单打进拣货波次，那一刻之前订单还能改，之后再改就要退货回位或者另开一张面单。自有仓按批次拣货的可能有两三个小时，第三方海外仓接单即拣的可能只剩十几分钟，预售和定制商品甚至可以放到一整天。窗口写死在前端模板里是最常见的错误，太短白白浪费可追加的时间，太长会让用户点了追加却被告知订单已进入拣货，后者比不给窗口更伤。

在确认页做邮件订阅，需要加双重确认吗？

看你走哪条路。如果依据的是电子隐私指令第13条第2款那条已有客户例外，也就是在销售过程中取得邮箱、只推自己的类似产品、每封都给免费简便的拒绝入口，那么不需要双重确认，硬加反而多此一举。如果走的是明确同意路线，在德国等市场双重确认几乎是标配，因为它顺带解决举证问题。折中的做法是把生效确认搭在那封本来就要发的订单确认邮件里，用户点一下即可，不用额外收信。无论走哪条路，默认勾选都不成立。

购后问卷该问几个问题、怎么问答案才有用？

一个问题，一个开放文本框，提交后原地反馈，不跳转，不给奖励。给奖励会让答案质量当场崩塌，用户为了拿券会随手勾第一个选项。如果一定要给预设选项，把文本框放在最上面、选项放下面当提示，顺序会显著改变答案分布。拿到数据要记住它的边界：样本只包含完成购买的人，所以它回答的是哪些渠道来的人更容易成交，不是哪些渠道带来的人更多；愿意答题的人也天然偏向对品牌有好感的那一类。答案要存进自己的订单库并与订单号绑定，否则没法回答自报来源与复购表现的关系。

确认页和订单跟踪页可以合并成一页吗？

不建议。两页在八个维度上几乎没有一处相同：确认页以分钟计、通常只看一次、数据全来自你自己的库、渲染后基本冻结；跟踪页以周计、会被反复打开、数据大半来自承运商、每天都在变。合并之后最常见的两种失败是，用户在下单那一刻点进跟踪页看到一片空白，或者确认页上摆着一排等待更新的灰色占位。正确的关系是接力：确认页把这一刻能说清的话说清，并告诉用户下一次消息什么时候来、从哪来。唯一必须共用的是预计送达口径，两页都该调同一个时效服务，谁都不许自己算。

权威参考资料