购物车里推错一次配件，用户就不再相信你这个站的任何一个推荐位

摘要：购物车里的商品推荐，是整个电商页面上少见的三不管地带。欧盟写给平台的三条推荐系统规则全部绕开了自营独立站；schema.org定义好的配件与耗材关系，没有任何一个主流引擎在读；而你自己的实验报表按位子拆分，天生测不到一个坏推荐对其他位子的伤害。这篇文章把这三层空白摊开，讲兼容性数据该从哪儿来、标签文案怎么写才救得回相关性、什么时候该少推甚至干脆不推，以及一次让推荐位净贡献从负数变成正数的复盘。

购物车里的商品推荐，为什么会成为整站唯一没人管的地方？

先把这块空白的形状描出来：外面没有规则管它，机器读不到它的依据，你自己的报表里也没有一个数字会因为它变差。

52%这个数字背后的两种失败长得不一样

Baymard Institute的Sally Collins在购物车交叉销售相关性的大规模可用性研究里给出一个数：他们基准测试的桌面站中，52%在购物车或加入购物车的确认层里展示的推荐，要么完全不相关，要么只基于其他顾客买了什么。

这句话其实装了两种毛病。第一种是没逻辑，用户买了个水龙头，页面推给他一个马桶。第二种更隐蔽：推荐本身有依据，依据是别人的购买行为，只不过这个依据在购物车这一刻不够用。

研究里那位在Home Depot买浴室龙头的受试者说得很直白——家里东西坏了才来买，不会顺手再换个马桶；他真正需要的是接头、密封胶和配件，而这些一个都没出现在推荐里。

用户不会只惩罚那一个位子

如果损失止步于这一次点击，这就只是个小问题。麻烦的是研究里另一条观察：哪怕只出现一个可疑的推荐，用户也会开始忽略这个站上的全部推荐。

在Tesco找相机包的那位受试者的反应很典型。她看到旁边列出的东西跟相机毫无关系，得出的结论不是这一条不准，而是这些包大概也没一个真配得上我的相机。信任是整体崩的，不是逐条崩的。

换个说法：推荐位的信任度是一个公共资源池，每个位子都从里面取水，但没有哪个位子的报表里记着它往里面倒了多少泥沙。

为什么购物车这一刻的容错率格外低

同样一条推荐，摆在商品详情页和摆在购物车里，性质完全不同。在详情页上用户还处在探索状态，看到不相关的东西顶多划过去；到了购物车，他已经做完选择，脑子里跑的是这单一共多少钱、什么时候到。

这时候插进来的每一个东西，都要跟他的结算动作抢注意力。Baymard的测试记录里有位在Overstock的用户，被购物车里的联名信用卡、会员计划、看了又看的商品列表、两个捐赠选项、一个免运费提示外加第二遍会员计划一起轰了一遍，然后说这个站太吵了。

移动端更狠。屏幕就那么大，用户想确认一下自己买了什么、一共多少钱，结果得先滑过三屏推荐。结账页放弃率超过70%的九个真实成因里讲过，用户在结账路上流失，往往不是因为某个致命错误，而是被一连串小摩擦磨没了耐心。

第一层空白：写给平台的规则不写给你

欧盟《数字服务法》给推荐系统写了一整条透明度义务，要求把主要参数写进条款、解释为什么向你推荐这条信息、还得给用户一个能随时切换的开关。听上去正是购物车推荐位该守的规矩。

问题是这条义务的适用对象是在线平台，而在线平台在该法第3条里有一个相当具体的定义。绝大多数自营独立站根本不符合那个定义。规则不是对你宽松，是压根没把你写进去。

后面第二节会把这几条规则连同它们各自的适用边界摊开对着看。结论会有点反直觉：真正管得到自营站的只有一条，而那一条讲的根本不是相关性。

第二层空白：机器读不懂什么是配件

推荐相关性里最硬的一类事实是兼容关系——这块电池是给这把门锁用的，这张存储卡是这台相机能认的。schema.org早就给这类关系准备好了属性，isAccessoryOrSparePartFor和isConsumableFor说的就是这两件事。

但按schema.org页面公布的全网使用量，前者只有1000到10000个域名在用，后者不到1000个。而Google那两份商品结构化数据文档里，被明确支持的商品间关系只有isVariantOf，也就是同一款商品的不同规格。

翻译一下：机器能读懂这件衣服有S码和M码，读不懂这块电池是给那把锁配的。而后者恰恰是购物车推荐最需要的那种事实。

第三层空白：你的报表里没有负向科目

第三层最要命，因为它是自己造的。推荐位的常规衡量方式是给这个位子做实验，看加购率和带来的订单额。这个做法有一个隐含假设：这个位子的好坏只影响这个位子。

可上面那位相机包用户已经证明这个假设不成立。一个坏推荐的伤害会跨位子传播，而对照组的用户也在被同一批其他位子污染。实验能测出的只是位子之间的差，测不出整体水位在往下掉。

更实际的一点：多数站的订单行里根本没有记这件商品是怎么进购物车的。于是退货、客诉、二次退款这些负向结果没有一条能挂回推荐位头上，推荐位的报表在结构上就只可能是正的。

三层叠起来，剩下的只有你自己定的规矩

把三层放一块看：外面没人管，机器读不到，自己的仪表盘只显示好消息。这不是三个独立的小毛病，是同一个空洞的三个侧面。

这种局面有一个共同后果——任何一次把推荐位做得更激进的提议，在会上都找不到反对它的证据。不是没人反对，是反对的人手里没有能报数的东西。

所以这篇文章的实际立场是：既然没有外部标尺，那这把尺子得你自己刻，并且刻在别人能看懂的地方，指标分层与单一真相那套办法在这里同样管用。

这篇文章接下来怎么走

前三节讲规则边界，第四到第六节讲数据，第七到第九节回到页面，最后一节是保哥自己的一次失手复盘——那一节里有本文最重要的一个原语，我把它留在最后。

这篇不讲推荐引擎选哪家，也不讲协同过滤怎么调参。想看后台开关怎么拧的，Magento 2商品推荐的相关产品、向上与交叉销售规则那篇更合适；这篇讲的是拧之前该想清楚哪几件事，中间会牵扯到配送政策页的口径。

先把结论摆在前面

推荐位真正的产出物不是加购量，是用户对你这个站的一个判断：这家店知道我买的是什么。这个判断一旦形成是全站通用的，一旦破坏也是全站通用的，跟社会证明体系要解决的是同一类问题。

所以衡量推荐位的正确姿势不是问它这个月贡献了多少收入，而是问两件事：它推错的时候，多久会被发现？发现之后，谁的报表上会掉数字？

如果这两个问题都答不上来，那这个位子在事实上处于无人监管状态，无论它当期的数字有多好看。

欧盟给推荐系统写了三条规则，为什么一条都落不到你的独立站上？

五条规则并排放着看，每一条不适用的理由都站得住，而它们加在一起围出了一块谁都没打算管的地方。

先看这条规则要求了什么

欧盟《数字服务法》第27条叫推荐系统透明度，一共三款。第1款要求用简明易懂的语言把推荐系统的主要参数写进条款，并说明用户有哪些选项可以修改或影响这些参数。

第2款把主要参数拆得更细：这些参数必须解释为什么某条信息会被推荐给该用户，至少要包含决定推荐结果的最重要的那几条标准，以及这些参数之间相对重要性的理由。

第3款最实在——如果推荐系统提供了多个排序选项，平台必须给用户一个能随时选择和修改的功能，而且这个功能必须能从展示该信息的那个界面区域直接方便地进入。不是藏在设置里的第七层。

在线平台这四个字把绝大多数独立站挡在门外

这三款听起来正是购物车推荐位该守的规矩。但整条的义务主体写得很清楚：使用推荐系统的在线平台的提供者。

而在线平台在该法第3条第i项里有定义：一种托管服务，应服务接收方的请求存储信息并向公众传播该信息。关键在于两点——信息是别人放上来的，以及它被传播给不特定的第三方。

自营独立站的商品推荐位既不存储用户上传的内容，也不向公众传播第三方信息，它展示的是你自己的商品目录，跟产品feed这份资产同源。定义对不上，义务自然落不下来。

广告透明度那一条也是同一个主体

第26条讲广告透明度，要求用户能清楚识别出这是广告、代表谁投放、谁付的钱，以及第1款第d项那句相当锋利的话：从广告本身直接方便获取的、关于决定向谁展示该广告的主要参数的有意义信息。

这一款如果适用于购物车推荐位，等于要求每个推荐旁边挂一句为什么推给你。可它的义务主体还是在线平台的提供者。同一扇门，同一把锁。

第3款禁止用敏感类别个人数据做画像投放，第28条第2款禁止对已知为未成年人的用户做画像广告。这两条的适用主体一样。

界面设计禁令上还挂着一条自我让位

第25条是那条被广泛引用的暗黑模式禁令：不得以欺骗或操纵服务接收方的方式，或以实质性扭曲、损害其自由与知情决策能力的方式，设计、组织或运营界面。

有意思的是它的第2款：本条第1款的禁令不适用于已被2005/29/EC指令或2016/679号条例涵盖的做法。也就是说，即使你符合主体定义，这条也会主动把已经归别的法管的事情让出去。

第3款给了三个例子供委员会出指引，包括把某些选项做得更醒目、反复要求用户对已经做过的选择再选一次、以及把退订流程做得比订阅难。这三条里第二条和购物车推荐位关系最近——同一个促销在页面上写三遍，就是在反复要求用户做同一个决定，这一点在首屏区块的排布上也常犯。

不公平商业行为指令的那条黑名单只管搜索结果

2005/29/EC附件一是黑名单，里面的做法在任何情况下都被认定为不公平。第11a项是2019/2161号指令插进去的新条目：在回应消费者的在线搜索查询而提供搜索结果时，未清楚披露任何付费广告，或未披露专门为在结果中获得更高排名而支付的款项。

这一项对购物车推荐位的适用性很勉强。它锁定的场景是回应消费者的搜索查询，而用户在购物车里没有输入任何查询——他甚至没有要求你推荐任何东西。

顺带说一句，同一次修订还改了价格披露那一块，那是另一个题目，跟这里的排名披露没有交集。

排名参数信息义务同样有一个前置条件

该指令第7条第4a款要求：当你向消费者提供以关键词、短语或其他输入形式搜索由不同商家或消费者提供的商品的能力时，关于决定排名的主要参数及其相对重要性的一般信息应被视为重大信息，且必须放在从结果页直接方便可达的专门区域里。

这里有两个限定词卡得很死。一是搜索，二是由不同商家或消费者提供的商品。自营站卖的是自己的东西，只有一个商家，第二个条件天然不成立。

该款还专门说明，无论交易最终在哪里完成都适用——这句话是用来堵住那些把成交环节挪到站外的市场的，不是用来把单商家站拉进来的。

五条规则并排放，空洞的形状就出来了

把这张表读一遍会有一种奇怪的感觉：每一行的不适用理由都站得住，没有一条是钻空子钻出来的。它们各自都有正当的立法理由，只是加在一起，围出了一块谁都没打算管的地方。

英国那边的线画在别处

英国脱欧后走了自己的路。《数字市场、竞争与消费者法案2024》附表20是那份在任何情况下都构成不公平的做法清单，2025年4月6日经S.I. 2025/272生效。

这份清单里第12段管的是付费的编辑内容促销未披露，第6段管的是以某个价格发出购买邀请之后拒绝展示该商品、拒绝在合理时间内接单或交付、或者展示有缺陷的样品，意图借此推销另一款产品——这就是诱饵调包。

绝大多数推荐位离第6段那条线远得很。但它标出了一个方向性的上限：在用户已经选定商品之后，如果你的推荐位系统性地把他往另一款推，同时对他选的那款制造不可得或不划算的印象，性质就开始变了。

不适用清单该怎么读

做合规的人习惯读适用清单，把管得到自己的条文摘出来做成检查项。这题反过来读收获更大：把明确不管你的规则并排列出来，中间那块空白的形状，就是你的风险地图。

这块空白的边界很清楚——它不包括价格标示，因为那有专门的条例管；不包括个人数据处理，因为那有同意模式与跨境合规架构那一整套；也不包括虚假声明，因为那落在一般条款里，跟退换货政策页的表述是两套东西。

它剩下的正好是：推什么、推几个、怎么标、什么时候不推。这四件事在欧盟法上没有一条专门的规则，而它们恰好是决定购物车推荐位好坏的全部内容。下一节讲那条唯一真正抓得住你的规则，你会发现它管的是一个完全不同的角度。

真正抓得住你的那一条，为什么管的是别替用户勾选？

它不问推荐相不相关，只问那个勾是用户自己打的还是你替他打的。德国那边还给这条规则补了一句相当具体的后果。

它管的不是推什么，是谁按下了那个勾

2011/83/EU号消费者权益指令第22条只有两句话，标题叫附加付款。第一句：在消费者受合同或要约约束之前，商家必须就超出主合同义务约定对价的任何额外付款，寻求消费者的明示同意。

第二句才是真正带牙齿的部分：如果商家没有取得消费者的明示同意，而是通过消费者必须主动拒绝才能避免该付款的默认选项来推定同意，消费者有权要求返还这笔款项。

注意这条规则的角度和前一节那五条完全不一样。它不问你推的东西相不相关，不问你标签写得清不清楚，只问一件事：那个勾是用户自己打的，还是你替他打好的。

德国把这句话落成了一个更硬的形态

德国《民法典》第312a条第3款把它写成了两句。第一句：商家与消费者之间，指向超出主给付约定对价的额外付款的约定，只能明示达成。

第二句专门针对线上：商家与消费者在电子商务中订立合同的，此类约定只有在商家不是通过预先设定促成该约定的情况下，才成为合同的组成部分。

预先设定这个词在德语原文里是Voreinstellung，指的就是页面上那个已经勾好的复选框、那个默认选中的加价选项、那个你不动它就会被算进总价的东西。

那笔钱收不到，但订单照发

同条第6款是这套规则里最容易被忽略、也最能说服工程团队的一句：依第3款至第5款未成为合同组成部分或者无效的约定，不影响合同其余部分的效力。

把这句话翻译成运营语言：用户在购物车里被默认勾上了一条39欧元的延保，他付了整单的钱，然后主张这条约定没成立。结果是延保那39欧元你得退，主商品那部分合同完好无损，货照发、成本照出。

换句话说，这个玩法的期望收益是负的。做对了你多赚一笔，做错了你不但退钱，还白搭一次客服工单和一次退款手续费。它甚至不能算灰色地带的套利，因为套利至少得有个赢面，而退款与退货流程那边还要为它多跑一趟。

三种把配件塞进购物车的做法，性质差得很远

中间那一行是绝大多数站在做的事，也是这篇文章真正关心的场景。第一行和第三行放在这里，是为了把边界标出来：往上一格越界，往下一格换赛道。

真想卖套装，Google那边有一个专门的字段

如果你的结论是这个配件确实该跟主商品一起卖，那正解不是在购物车里替用户打勾，是把它做成一个真正的套装商品。这时候商品数据那边有一件事必须做。

Google商品数据规范里有一个bundle属性用来标记自建套装，官方定义是：用来表明你把一个主商品与其他不同商品组合在一起，按单一价格作为一个包装出售。

这个属性的作用是把你的自建套装和厂商原厂捆绑、多件装以及不含配件的普通商品区分开，这也影响免费商品信息的收录。免费商品信息里如果你的套装含有主商品，这个属性是必填；购物广告在包括德国、法国、意大利、西班牙、荷兰、英国、美国、日本等十二个国家投放时同样必填。

套装这个概念自带一个产品设计约束

该文档还写了一句容易被当成废话、其实是硬约束的话：套装的主商品是那件被主打的商品，而附加的商品应当是补充主商品的配件或附加件。

它给的例子很直白。玩偶配一套不在同一包装里的衣服，玩偶是主商品；游戏机配三款游戏，游戏机是主商品。反过来说，如果你凑的这个套装里没有一件东西够格当主商品，那它就不是套装，只是一堆商品被绑在了一起。

这个约束刚好倒推出一条选品纪律：能做成套装的组合，必须存在明确的主次关系。分不出主次的组合，用户在购物车里也分不清你为什么把它们放在一起，用捆绑做差异化那条路也走不通。Magento 2里虚拟、可下载与捆绑三种商品类型的建法差别，本质上就是在建模这层主次关系。

加购弹层里的默认选中是同一个问题的变形

有一种做法处在灰色边缘：用户点加入购物车之后弹出一个层，里面列了三个配件，其中一个是预先选中的，下面一个按钮写着继续。

用户点继续，那个配件就进了购物车。从交互上讲他确实点了一下，但他点的是继续，不是我要这个配件。这个动作到底算不算明示同意，取决于那个界面把什么设成了默认路径。

稳妥的做法很简单：弹层里所有选项一律不预选，按钮文案写去结算而不是继续。用户想加就点那个配件旁边的加号。少了几个默认勾，你会发现真实需求的规模比你以为的小，但那个数字是干净的。

附加品贵到什么程度就不该待在推荐位里

还有一类东西天生站在这条线附近：延保、安装服务、意外损坏险、会员计划。它们的共同点是没有实物、价格不低、而且用户很难在几秒钟内判断值不值。

保哥给客户定过一条很土但很好用的规矩：附加品的价格超过主商品的两成，就不许出现在购物车推荐位里，只能出现在商品详情页那个用户还愿意读说明的地方。

理由不是法律，是决策成本。买一台四千块的相机时顺手加一张八十块的存储卡，用户三秒就能想清楚；同一个位置塞一份六百块的两年延保——这已经属于定价决策而不是推荐——他要么随手划过，要么被迫在结算路上开始做一道应用题。后一种情况无论他选什么，你都已经输了几秒钟的结算动能。

把这条规则的逻辑抽出来看

这条规则背后的原则其实和相关性有关，只是绕了个弯：法律不允许你用默认值替用户做决定，是因为默认值会让人的选择显得像是他自己做的。

而推荐位的全部价值恰恰建立在相反的东西上——用户必须清楚地知道，是他自己决定加这个配件的，因为这个站帮他想到了他没想到的事。这两件事一旦混起来，推荐位就从服务变成了埋伏。

所以这一节的实操结论只有一句：推荐位可以做得很积极，但它必须始终停在用户主动点击那一步之前。越过那一步收上来的钱，退回去的时候是要带着信任一起走的。

推荐相关性建立在什么数据上，那份数据谁在维护？

源头那篇给的配方是个体行为加通用行为，可这两半在欧盟的取得成本完全不同，差别不在技术上。

源头那篇文章给的配方，只说了一半

Baymard的建议是把用户个体的行为数据和通用的行为数据结合起来用。前者指这个人的浏览历史、会话轨迹、购买记录、账户资料以及购物车里现在装着什么；后者指整体购物行为、品类之间的关联。

这个配方本身没错，绝大多数第三方推荐引擎也确实是这么做的。它没说的是：这两半在欧盟的取得成本完全不同，差别不在技术上，在法律上。

而这个差别的后果不是某个功能不能上——那属于客户数据平台的选型——是同一套推荐逻辑会对两拨用户跑出两种质量，并且你在报表里看到的是它们混在一起的平均值。

那半个配方需要用户先点一下同意

2002/58/EC号指令第5条第3款的规定是：在订户或用户的终端设备中存储信息，或获取已存储于其中的信息，只有在该订户或用户在获得清楚完整的信息之后表示同意的前提下才被允许。

同款后面留了两个例外：仅为在电子通信网络上传输通信所必需的技术性存储或访问，以及为提供订户或用户明确请求的信息社会服务所严格必要的存储或访问。

把跨会话的浏览历史存进用户浏览器、下次再读出来做推荐，这件事既不是为了传输通信，也很难说是提供用户明确请求的服务所严格必要——用户请求的是买东西，不是被记住。所以它落在需要同意那一侧。

分界线不在用户身上，在几秒钟前那个弹窗上

这里有个容易被忽略的结构性问题。你的用户被切成了两拨，一拨的推荐系统满血运行，另一拨只剩下通用行为数据。而决定谁在哪一拨的，不是他的品类偏好、不是他的客单价，是他几秒钟前在同意弹窗上点了哪个按钮。

这条分界线有三个讨厌的性质，跟多触点归因模型的困境有点像：它不在你的产品逻辑里、它对每个市场的比例都不一样、而且它每次改弹窗文案都会移动一点。

更麻烦的是它在报表里几乎不可见。除非你专门按同意状态给推荐位的点击率分组，否则你看到的永远是一个被两拨人拉扯出来的平均数。出海独立站怎么选同意管理平台里聊过选型，这里补一句选完之后该做的事：把同意状态透传给推荐服务，让它知道自己现在是满血还是残血。

被拒绝同意的那一半，看到的恰好是最差的那种推荐

把两件事接起来看，会得到一个相当刺眼的结论。

Baymard那篇研究说，只基于其他顾客买了什么的推荐，是用户最容易判定为不相关的那一类。而拒绝了同意的用户，你的系统能给他的恰恰只剩这一类——因为个体数据那一半被合法地拿走了。

于是这拨用户成了推荐质量最差的实验组，而他们同时也是隐私意识最强、对被推销最敏感的那拨人。这个组合有点像把最挑剔的客人安排在离厨房最远的那张桌子，而高客单价品类的信任建设最怕的就是这个。

五种推荐依据摊开对着看

这张表最值得盯的是它的排列方式：不需要同意的那三行里，有两行的相关性质量排在最前面。也就是说，你在合规上最没有障碍的输入，恰好是效果最好的那两种。

购物车里装着什么，是被低估最狠的一个输入

很多推荐位从来没认真用过购物车内容本身。它们读的是用户画像、是这个人的品类偏好、是本季度的热销榜，唯独没读那三件已经躺在车里的东西。

这有点讽刺，因为那三件东西是用户在这一刻给出的最强意图信号——他不是可能对某个品类感兴趣，他是已经决定要买这三样了。

而且这个输入在法律上最干净：它就是用户明确请求的服务的一部分，不需要跨会话追踪，不需要账户，不需要同意弹窗。对拒绝了同意的那一半用户来说，这是唯一还能撑起相关性的东西。

会话内和跨会话是两个不同的开关

实现层面有一条界线值得跟工程团队掰扯清楚：只在本次会话内、由服务端持有的浏览轨迹，和写进浏览器留到下次的轨迹，是两种不同的东西。

前者接近购物车状态，后者是典型的跨会话追踪。很多站的推荐服务把这两种一锅端进同一个用户画像对象里，于是一旦同意被拒，整个对象连带作废，连本次会话看过什么都读不到了。

正确的做法是分成两个字段、走两条路径。同意被拒时只关掉跨会话那一半，会话内那一半照常工作。这一改动的收益，通常比给推荐算法换个模型大得多。

降级不是关掉，是换一套依据

大多数系统的降级逻辑写得很敷衍：拿不到画像就退回热销榜。热销榜恰恰是相关性最低的那种依据，等于在最需要精准的时候切到了最粗的档位。

更合理的降级顺序是：兼容性关系优先，其次是购物车内商品的同主题商品，再次是同一系列或同一套装里的其他件，最后才轮到全站热销。这四档里前三档全都不需要同意。

顺便说，这套降级顺序对没有登录、没有历史、第一次来的新用户同样适用。而新用户恰恰是最需要被这个站证明它懂行的那批人。

还有一处连带影响藏在同意管理的配置里

同意管理平台通常按用途分组：必要、偏好、统计、营销。推荐系统这件事该归到哪一组，很多团队没有认真想过，默认就扔进了营销。

一旦扔进营销，它的同意率会跟着广告像素一起掉，而实际上其中相当一部分能力（购物车内容、兼容关系、主题标签）根本不需要落在那一组里。

把推荐系统按依据拆开、分别归组，跟双重确认订阅的分层设计是同一件事，成本很低但收益直接体现在覆盖率上。做完之后你会发现，所谓推荐系统在欧盟不好使，有一半是自己配出来的。

兼容关系是最可靠的推荐输入，为什么机器一个字都读不到？

词表层定义好了，语料层几乎是空的，消费层没有读者。三层都没被堵死，加起来却是一条断掉的链路。

只有一类推荐是用户没法反驳的

Baymard的六条建议里，第五条的分量明显高于其他几条：兼容性依赖的商品应当优先于其他类型的推荐。理由不复杂——买了没电池的玩具就得配电池，买了相机就得配它认得的存储卡，这不是猜的，是这件商品自己规定的。

他们打的比方也很到位：这种推荐的作用相当于一个称职的店员，客人买电视时提醒他还得配根线。用户对这类推荐的评价通常不是你在推销我，而是幸好你提醒了我。

所以兼容关系是相关性的天花板。它不依赖任何个人数据、不需要同意、对新老用户一视同仁，而且推错了会立刻被发现——用户拿回家插不上。这最后一点很关键，它意味着这类数据自带纠错回路，而其他几类没有。

这类关系在词表层早就有位置了

schema.org的Product类型上挂着几个专门用来表达商品之间关系的属性，它们来自GoodRelations词汇，是Martin Hepp为电商数据交换设计的那一套。

其中isAccessoryOrSparePartFor属性表示本商品是另一件商品的配件或备件，isConsumableFor属性表示本商品是另一件商品的耗材。另外两个是isRelatedTo，指某种相关的商品；isSimilarTo，指功能上相似的商品。

四个属性刚好对应推荐位里最常见的四种关系：配件、耗材、相关、替代，比GTIN这类标识字段表达力强得多。词表这一层不但没缺东西，分得比大多数站自己的推荐引擎还细。

语料层的数字比想象中冷清得多

schema.org的属性页上会显示一个使用量区间，数据来自Google网页索引的月度聚合。isAccessoryOrSparePartFor那一栏写的是1K到10K个域名；isConsumableFor那一栏写的是少于1K个域名。

作为对照，Product这个类型本身的使用量是以百万计的域名。也就是说，几乎每一个电商站都在告诉机器这是一件商品，而愿意再多说一句它跟哪件商品配套的站，全球范围内是四位数级别。

这个反差挺说明问题的。Schema官方第一次公开全网使用数据之后，很多人的第一反应是照着用量榜去补高频类型；这里给出的是相反的读法——用量低不一定代表没用，也可能代表还没人占。

消费层这边，关系里只有一种被读

再往下一层看谁在消费这些标记。Google的商品结构化数据文档分两份，一份讲商家商品信息，一份讲商品摘要。我把两份文档里出现的属性都过了一遍。

结果是：isVariantOf在商家商品信息那份里有位置，也就是同一款商品的不同规格之间的关系被明确支持；而isAccessoryOrSparePartFor、isConsumableFor、isRelatedTo、isSimilarTo四个属性，在两份文档里一次都没有出现。

这不是说写了会有害，写了没坏处，只是没有读者——结构化数据对AI搜索到底有没有用那篇讨论过这种情况。用一句话概括这层落差：机器能读懂这件衣服有S码和M码，读不懂这块电池是给那把锁配的。

三层摆在一起才看得清这是一条断链

三层没有哪一层是被堵死的，每一层都有各自合理的原因：词表方定义了、站点方觉得没收益所以不写、引擎方看没人写所以不读。可是三层加起来，就是一条从头断到尾的链路。

断链的另一面是一个还没人占的位置

把这件事翻过来想就有意思了。当有人问某个型号的智能门锁支持哪些网关、某台咖啡机能用哪种滤纸的时候，答案引擎得从某个地方把这份清单找出来。

而目前能被它找到的，基本上是论坛帖子、评论区里的只言片语和厂商PDF里的表格。谁把这份关系做成结构清晰、机器可读、且明确署名的公开事实，谁就是这个细分领域里唯一一份能被引用的权威。

这跟让商品页对齐AI的理解逻辑是同一个思路的延伸：真正稀缺的从来不是把已有字段填满，是把只有你知道的那类事实写出来。兼容关系正好是这种事实——它在你的售后工单里、在你的退货记录里，而且别人抄不走，因为他们没卖过这些东西，这正是实体关联最难被复制的部分。

兼容数据有三个来源，错法各不相同

第三行值得单独说，用结构化数据审计是查不出它的毛病的。它是三种里最省事的，跑一个脚本就能覆盖全目录，产出的表格行数漂亮、格式规整、看不出任何毛病。

共同购买挖出来的不是兼容，是没退货

关联分析回答的问题是这两件商品经常被一起买。它没有回答、也没能力回答的问题是这两件商品能配着用。

这两者之间的差在大多数品类里很小，小到你可以忽略；但在有硬性兼容约束的品类里，差会集中在一小撮特定组合上。比如某个组合其实不适配，但买它的多半是发烧友，他们自己刷个固件就解决了，从来不退货。

于是数据认为它兼容，然后你把它推给了一个完全不打算刷固件的普通用户。这个错误的隐蔽之处在于：它的证据来自真实订单，而真实订单是团队里最不容易被质疑的一类数据。

兼容表该长什么样

最小可用的兼容表只需要四个字段：主商品的最小可售单元、配件的最小可售单元、关系类型（配件、备件、耗材、替代）、以及最重要的那个——依据来源。

依据来源这一列不许留空，取值就三种：厂商规格、工单确认、行为挖掘。渲染管线只吃前两种，第三种只能生成待人工确认的候选清单。这一条规矩看着刻板，它挡掉的正是上一节那类错误。

另外两条：关系必须记到最小可售单元而不是款号，因为同一款不同容量的机型往往适配不同配件；以及关系要写成有方向的，A是B的配件不等于B是A的配件，把方向丢了的表在推荐时会把主机推给来买电池的人，属性与属性集的作用域没理清的站尤其容易这样。

推荐几个才对，固定数量为什么是相关性最大的敌人？

写死返回五条，实际上是在下一道指令：不管有没有，都给我凑够五个。系统会很听话地一路往下降标准。

源头那篇的第一条建议，是六条里最反直觉的一条

Baymard把别用固定数量放在了六条建议的第一位。这个排序有点意外，因为它听起来最像技术细节，而不像用户体验原则。

他们的论证是这样的：大多数推荐区块永远推同样数量的商品，因此更容易混进不相关或只有部分相关的东西。如果真正合适的只有一件，那它单独出现时反而更受关注，因为信噪比更好；而把它和四个可疑的商品摆在一起，只是因为推五个是推荐逻辑里写死的默认值。

研究里给的正面例子是Crutchfield的加购弹层，用户加了一根HDMI线，弹层里出现的是数量不固定的、按兼容关系筛出来的推荐，而不是一个固定长度的列表。

信噪比在这里不是比喻

推荐位的信噪比可以算得很实在：分子是这一屏里用户认可的推荐条数，分母是总条数。推五个中一个，信噪比是五分之一；推一个中一个，信噪比是一。

用户不会去算这个数，但他会形成一个感觉，而这个感觉的形成速度快得惊人——扫一眼就完了。问题在于，那四个凑数的商品不只是被忽略，它们还会把那一个好推荐的可信度一起拉下来。

这就是本文开头那条观察的机制层解释：一个可疑推荐的伤害不是加法，是乘法。它不是让这一屏的价值减去五分之一，是让整屏打个折。

固定名额是一种把垃圾生产出来的机制

换个角度看这件事：当你的推荐逻辑写着永远返回五条，它实际上是在下一道指令——不管有没有，都给我凑够五个。

系统很听话，于是它会一档一档往下降相关性要求，直到凑满为止。你以为你在配置一个展示位，其实你在配置一条最低相关性标准，而这条标准是由库存和目录规模决定的，不是由你决定的。

目录小的时候这个机制不明显，因为可选项本来就少，批量导入把目录撑大之后才开始显形；目录一大反而更糟，因为总能找到五个勉强沾边的东西，凑满这件事变得毫不费力。

改成动态数量，本质是把名额换成阈值

实现上的改动其实不大：把返回条数固定改成返回所有相关性分数高于阈值的商品，上限设一个（比如四条或六条，防止某些主商品配件太多把整屏占满），下限设零。

难的不是这一行代码，难的是那个阈值定在哪儿。多数团队卡在这里，然后选择了那个最省事的方案——还是固定数量。

阈值这件事没法从推荐引擎的分数分布里直接读出来，因为那个分数只是个内部量纲，它不知道用户觉得多少算相关。得从外面找一把尺子，这一步跟增量测试的标定思路是一样的。

用退货率给相关性分数标定刻度

这把尺子保哥用得最顺手的一根是退货率，跨境退货率怎么降那篇讲过它的构成，理由很简单：配件推错了，用户会退货，而退货是有记录、有金额、有责任人的。

做法是这样：给推荐位带来的每一笔加购打上标记，记录它当时的相关性分数落在哪一档；三十天后回过头，按分数档位算这批商品的退货率。你会看到一条曲线——高分档的退货率贴着站均走，到某个分数以下开始明显翘起来。

那个开始翘的位置，就是这个品类的相关性阈值。它是从真实后果里长出来的，而不是产品经理拍的。不同品类的这条线位置差得很远，有硬兼容约束的品类通常比服饰高出一大截。

顺手能拿到一个指标：凑数率

标定完阈值之后有一个副产品，保哥把它叫凑数率：某个推荐位实际展示出去的商品里，相关性分数低于阈值、纯粹因为要填满名额而出现的那部分占比。

这个指标有三个好处。第一，它上线当天就能出数，不需要等实验；第二，它可以按位子拆、按品类拆、按市场拆，责任落得下去；第三，它是负向的，而推荐位的报表体系里原本一个负向指标都没有。

经验上，凑数率长期高于四成的推荐位，基本可以判定它在消耗信任而不是创造价值。而凑数率接近零、展示条数却常年稳定在五条的位子，说明阈值定得太松，等于没定。

零条推荐是一个合法且经常正确的输出

这一点在会上最难通过，因为它听上去像放弃了一块流量。但它其实只是承认了一件事：有些商品就是没有配件，有些购物车就是没有该补的东西。

一支口红需要配什么？一本书需要配什么？在这些场景里硬推，得到的不是零收益，是负收益——你花掉了用户的一屏注意力，还顺手告诉他这个站的推荐不太懂行。

所以推荐逻辑要允许返回空，页面要允许这个区块整块不渲染。注意是不渲染，不是渲染一个空框加一句暂无推荐——后者比什么都不显示更糟，它等于在公告栏上贴一张写着没有通知的纸。

版位设计得先接受这件事，代码才敢这么写

动态数量做不成的原因，一半在设计稿上。设计师交付的稿子是五个卡片整齐排一行，视觉平衡是按五个算的；工程按稿实现，于是数量就被钉死了。

所以这件事要往前推一步，在设计阶段就要求给出零条、一条、两条到上限的全部形态。一条推荐时它该是什么样子？答案通常是一张更大的卡片，带更多说明文字，而不是一张孤零零的小卡加四块空白，这跟集合页的卡片密度是同一类取舍。

这个改动还有一个附带的好处：一条推荐的形态天然能容纳一句为什么推给你，而五条并排的卡片里塞不下任何解释。下一节讲的标签文案，其实是在这一步就被版位决定了的。

为什么固定数量在组织上特别难去掉

技术上一天的活，往往拖上几个季度，原因不在技术。

固定数量的推荐位有一个组织上的优点：它的曝光量是可预测的。做促销排期的人知道这个位子每天会展示多少次，做联盟素材的人知道能塞几个坑位，做预算的人有一个稳定的分母。改成动态之后，这些数字全都开始波动，而波动会让好几张报表变得难解释。

推动这件事的正确姿势不是讲用户体验，是先把凑数率算出来给他们看。当一个位子的凑数率是55%，讨论就从要不要改变成了那55%的曝光原来一直是虚的，而虚的曝光在虚荣指标与北极星指标那套框架里该怎么处理，团队里通常已经有共识了。

在结账路上推替代品，什么时候会变成把用户从自己手里推走？

同一条推荐，摆在商品页是帮忙，摆在购物车是在问他确定吗。而这个问题一旦被问出来，风险是不对称的。

同一条推荐，换个位置就从帮忙变成拆台

Baymard的第二条建议写得很克制：对列出替代商品这件事保持谨慎。他们的理由是一句大白话——用户不该在结账的过程中开始怀疑自己。

在商品详情页上，替代品是帮忙。用户还没定下来，多看两款是他本来就想做的事。到了购物车，他已经做完了那个决定，这时候你把另一款摆到他眼前，等于在问他确定吗。

而且这个问题一旦被问出来，风险是不对称的：他有可能点过去看看，然后再也没回到结账流程；他基本不可能因为看了一眼替代品而更坚定地买原来那件。

那两个数字说的是同一件事的两面

Baymard另有一篇讲商品页推荐的研究，Jamie Holst在同时推荐替代品与补充品的基准测试里给了两个数：他们测的大型电商站中只有42%同时提供这两类推荐，而58%要么只做其中一种，要么把两种塞进同一个推荐区块里。

这里最值得注意的不是42%这个覆盖率，是后半句那个混在同一个区块里。因为一旦混在一起，用户就无法判断你到底想干什么——这些东西是让我替换，还是让我加购？

而这两件事需要的心理状态完全相反。前者要求他重新打开决策，后者要求他在已经关闭的决策上再加一笔。同一个区块同时提出这两个要求，多数用户的处理方式是两个都不理。

混装区块的真实成本比看上去大

混装还有一个更实际的代价：它让标签写不下去。区块里既有替代又有补充，你只能起一个足够模糊的名字，比如你可能还喜欢、相关商品、看了这件的人还看了。

这些名字有一个共同点：说了等于没说。用户看不出这些商品和他车里那件的关系，于是只能靠自己扫一眼判断，而扫一眼的判断标准很朴素——长得像不像我买的那个。长得像的会被当成替代品，长得不像的会被当成噪音。

于是那些真正有价值的配件，因为长得跟主商品完全不像，被系统性地误判成了噪音。这大概是混装区块造成的最大一笔隐性损失。

替代品在购物车里也有站得住的时候

源文留了个口子：某些站点特定的场景是可以推替代品的，比如产品的升级款或者同一产品的新版本。这个口子开得对，但需要说清楚边界。

能站住的情况有一个共同结构：新推的这一款在用户已经认可的那件的基础上更进一步，而不是另起炉灶。同型号的大容量版、同系列的新一代、同款商品的多件装。

站不住的情况也有共同结构：它是一个平行选项。同价位的另一个品牌、另一种设计风格、另一个颜色系列。这类东西属于选购阶段的工作，属于商品描述层面的信号，放到购物车里只有拖慢的作用。

缺货是唯一必须推替代品的场景

有一种情况不推替代品才是失职：用户车里那件东西已经买不到了。这时候页面上必须给出下一步，而不是只显示一句该商品已售罄。

这个场景的处理有个优先级：先给同一款的其他可售变体（别的尺码、别的颜色），再给功能等价的其他款，最后才是到货通知。前两步没做就直接推到货通知，等于把一个还在店里的客人请回家等，缺货预售与低库存预警要一起配。

顺带一提，缺货商品在站外的后续处理是另一套活儿。商品下架之后301、410与软404怎么选讲的是页面层面的收尾，跟这里的车内替换不冲突，两边配合起来才不会出现页面还在、车里却买不了的情况。

从推荐滑到诱饵调包，中间只隔着两个动作

前面提过英国那份禁止清单第6段：以某个价格发出购买邀请，然后拒绝展示该商品、拒绝在合理时间内接受订单或交付、或者展示一个有缺陷的样品，意图借此推销另一件产品。

绝大多数推荐位跟这条线离得很远。但把它拆开看，构成要件其实只有两个：用户想要的那件变得不可得或显得不好，同时另一件被推到他面前。

值得警惕的是这两个动作可以在毫无恶意的情况下同时发生。库存系统把一件商品标成暂时缺货，推荐引擎按规则填上一个替代款，运营那边还给替代款配了个优惠——三个团队各做各的，合起来的效果就开始靠近那条线。这类事故的特点是没有任何一个人做错，所以也没有任何一个人会发现，订单处理工作流里的类似事故也是这么来的。

替代品推荐的三条硬规矩

第三条最容易被违反，而且往往是营销侧无意中造成的：他们给某款商品配了促销，促销组件是全站通用的，于是这个角标就跟着这款商品出现在了所有位置，包括别人的购物车推荐位里。

变体不是替代品，这两件事经常被混为一谈

还有一类混淆值得单独拎出来：同一款商品的不同规格，在数据模型里是变体，在推荐位里经常被当成替代品推出去。

用户买了500毫升装，购物车里给他推1升装，这个动作在系统看来是推荐了一个相关商品，在用户看来是这个站在暗示我买错了规格。可配置商品的变体与属性矩阵建得越完整，这类误推越容易发生，因为变体之间的关联度天生就很高。

正确的处理是把变体从推荐候选池里整个排除掉。用户想换规格，他会回到商品页去换，那里有完整的规格选择器，比推荐位里孤零零一张卡片好用得多，变体的三层治理做扎实了这一步几乎不费力。

一条能立刻执行的检查

如果你现在就想知道自己的购物车推荐位属于哪一类，做一件事就够了：随便挑十个有明确配件的主商品，把它们分别加进购物车，然后把推荐位里出现的东西按四类记下来——配件、耗材、同款变体、平行替代。

四类的比例会直接告诉你这个位子的性格。前两类占多数说明它在帮用户完成这次购买；后两类占多数说明它在让用户重新考虑这次购买。

这个测试花不到一小时，不需要任何埋点，也不需要跟任何人申请权限。保哥每次接手一个新站，第一天做的就是这件事，因为它的结论往往比接下来两周的数据分析更早指出问题在哪。

推荐位的标签写什么，为什么比推荐算法本身更能救场？

标签不会让推荐变准，它让用户对准确度的判断变准。而标签一旦写错，整套标签体系会一起贬值。

标签不会让推荐变准，它让用户对准确度的判断变准

Baymard第三条建议的措辞很精确，值得原样看一遍：清楚地给购物车里的推荐商品打标签，虽然不会提高推荐的准确度，但会提高用户对这些推荐的理解的准确度。

这句话拆开就是本节的全部内容。用户看到一件他觉得无关的商品时，脑子里其实在解一道题：这个站为什么给我看这个？题没解出来，他的默认答案就是它想多卖我点东西。

而只要标签把依据讲清楚，同一件商品的性质就变了。基于你看过的商品推荐意味着这是我自己的行为造成的；买了这件的人也常买那件意味着这是别人的经验。用户仍然可能不感兴趣，但他不会觉得被骗，这跟评论区的可信度是一个道理。

源文给的那几个标签，各自对应一种数据

研究里点名了几个可用的写法：基于此前浏览过的商品用受你的浏览记录启发；基于其他用户购买模式的补充推荐用经常一起购买；搭配服饰用搭出整套；同一系列或合集的其他件用本系列的其他商品。

他们记录的正面案例也各有各的准：Zalando在购物车里用受你的挑选启发，B&H Photo在加购弹层里给蓝牙音箱打的标签是必备配件，Macy's用买了这件的人还看过并且只推同品牌同系列的其他饰品。

反面案例是IKEA那种你可能还喜欢——虽然那个区块里的商品其实都挑得不错，标签本身却没告诉用户任何东西。

标签、数据、同意、降级，得放在同一张表里看

这张表有一个很实用的读法：第五行是唯一一个会因为同意状态而消失的。所以做降级设计的时候，只有这一行需要准备一个替身，而替身的标签必须跟着一起换。

标签是承诺，不是装饰

这是最容易犯、也最伤人的一个错：区块标签写着必备配件，里面推的却是引擎按共同购买挖出来的东西，其中一部分根本装不上。

这种情况下标签起的是反作用。没标签时用户会自己判断，标了必备配件他就不判断了，直接下单，然后收到货发现接口对不上。这一单的退货成本比不推荐高得多，连带海外仓的周转也跟着受影响，而信任损失比退货成本还高。

所以有一条规矩得写死在代码里：标签由数据源决定，不由运营在后台自由填写。兼容表出来的东西才能挂必备配件，行为挖掘出来的东西只能挂买了这件的人也常买。文案可以调整措辞，但不能跨源使用。

把那条不适用的规则反过来用

第二节说过，《数字服务法》第27条要求平台解释为什么某条信息会被推荐给该用户，而这条义务不适用于自营独立站。

不适用不代表没价值。这条规则之所以被写出来，是因为立法者认定用户有权知道推荐的依据，而这个判断跟平台还是自营站没关系——用户的心理需求在两种场景里是一样的。

所以这里有一个免费的差异化机会：把那条法律没要求你做的事情主动做了。成本是一行标签文案，收益是用户对整个推荐体系的信任度。在一个52%的同行连相关性都没做对的赛道里，这个投入产出比相当难得，在AI代理替用户下单的场景里还会再加一层价值。

标签写多长、放哪儿，也有讲究

长度上，区块标题控制在十个汉字以内，超过这个长度用户不会读完。真正需要解释的东西放在单条推荐下面的一行小字里，而不是塞进标题。

位置上，标签必须在推荐商品的上方而不是下方。用户是先看到东西再看到解释，还是先知道这是什么再看东西，这两种阅读顺序的效果差很多——解释放在后面时，多数人已经在看到商品的那一刻做完判断了。

还有一个细节：单条推荐的解释文字要具体到这一条，而不是重复区块标题。区块标题写必备配件，某一条下面写的是适配你车里那台XR200，这才是解释；写的是必备配件，那是复读。

多语言市场里，标签是翻译陷阱的重灾区

这些标签短、出现频率高、而且往往硬编码在前端组件里，于是它们经常成为最后一批被本地化的字符串，有时候干脆漏掉。

更麻烦的是有些标签直译过去会变味。搭出整套在服饰语境下没问题，直译成德语容易读成一整套家具；必备配件里的必备在某些语言里带有强制购买的暗示，而这个暗示恰恰是这条规则最不想给的。

所以标签文案得跟正文一样走本地化流程，最好由懂那个市场的人重写而不是翻译。多语言内容本地化的生产流水线那套方法在这里同样适用，只是对象从长文变成了几十个短字符串。

一个标签写错，全站的标签一起贬值

本文开头那条观察在标签这件事上也成立，而且更狠。用户在一个位子上发现必备配件其实并不必备之后，他学到的不是这个位子不准，是这个站的标签不能信。

之后他再看到搭出整套、本系列其他商品，反应会是这些名字大概也是随便起的。你花在标签体系上的所有工作，被一条错标的推荐一起打包作废。

这就是为什么标签的准确度要求比推荐的准确度要求还高。推荐推错了是一次判断失误，标签标错了是一次陈述失实，用户对这两种事情的宽容度完全不在一个量级上。

最小可用的标签体系只需要四个

不用一上来就搞一套十几个标签的分类学。四个就够开工：必备配件、这件商品的耗材、同系列其他商品、买了这件的人也常买。

这四个覆盖了绝大多数场景，每一个都对应一个明确的数据源，而且都不需要同意。等这四个跑顺了、凑数率降下来了，再考虑要不要加主题类和个性化类，就像分组商品要先把关联关系建对再谈定价。

顺序很重要：先把不需要同意、错了能立刻发现的那几类做扎实，再去碰依赖行为数据的那几类。反过来做的团队，通常会在第一轮就把标签体系的信誉透支掉。

凑单和免运费门槛，为什么在跨境场景下经常是负的？

运费的阶梯、包裹的三边和、两张不在同一个会上出现的报表——这道账多数团队从来没有完整算过。

那两个反问句里藏着一道很简单的算术

Baymard第六条建议讲的是促销要看用户所处的情境，论证方式是两个反问：用户有多大可能为了凑够免运费门槛，在一件4.99美元、运费只要3美元的商品上再多花60美元？又有谁会为了在一笔5美元的订单上省10%，去申请一张信用卡？

研究里的实例是Lowe's在一笔6美元的订单上推18个月免息分期，以及Wayfair那个做对了的对照——车里是落地灯这种高价商品时推联名信用卡，车里是灯泡时不推。

这道算术的荒谬程度是可以直接量化的：为了省3美元运费再花60美元，等于用二十倍的钱买一个折扣。用户不需要懂运营也能一眼看穿，而看穿之后他对这个站的判断不是这个促销不合适，是这个站根本没在看我买了什么。

免运费门槛这件事会自己拆穿自己

免运费门槛的推荐组件通常长这样：还差43元即可免运费，下面跟着几个商品。这个组件的效果好坏，全押在那几个商品上。

如果它推的是跟车里那件毫不相干、单价刚好卡在差额上的东西，用户读到的信息不是这里有个优惠，而是这个站想让我多花43块钱。凑单商品的相关性要求比普通推荐更高，因为它的动机已经写在标题上了。

比较体面的做法是只从耗材、配件和低价补充品里挑凑单件，并且允许凑不够就不显示。凑不够的时候显示离免运费还差43元、暂无合适的补充商品，比硬塞几个抱枕强得多。

跨境场景下，凑单可能整体是负的

这一点在国内电商里几乎不成立，在跨境场景里却相当常见，值得单独拆开算。

跨境物流的报价基本都是阶梯式的：0到500克一个价，500克到1公斤一个价，往上按公斤跳。凑单件如果把整单从一个档位顶进下一个档位，你省下的那笔运费补贴和多付的那段运费，很可能是同一个数量级，甚至反过来。

更麻烦的是这笔账记在两个部门。免运费门槛的收益记在营销的报表上，档位跳变的成本记在物流成本里，而这两张表通常不在同一个会上出现。这就是为什么这个坑能存在很久——不是没人算，是没人有机会同时看到两个数。

还有一个更隐蔽的：包裹装不下

重量之外还有体积。很多跨境线路对单个包裹的三边和有硬性上限，超了就得分箱，而分箱意味着从一票变成两票，头程、清关、末端派送全部翻倍。

凑单件恰恰经常是那种轻、但占地方的东西——收纳盒、抱枕、大包装的耗材。它对重量档位的影响可能很小，对体积的影响却是决定性的。

所以凑单推荐的候选池需要一个额外的过滤条件：把加上这件之后的包裹体积算出来，超过分箱阈值的一律不推。这个规则实现起来不难，前提是商品的包装尺寸字段是全的，而这个字段的覆盖率在多数站上比重量还差，税率与含税显示那边也吃这套主数据。

门槛该定在哪儿，不该看客单价中位数

免运费门槛常见的定法是取客单价中位数往上加个百分比。这个方法的问题是它没有考虑凑单这个动作本身的可行性。

更实用的定法是从商品结构倒推：看看你的目录里，主商品加一件典型配件的总价落在什么区间，把门槛定在那个区间的下沿。这样凑单这个动作在物理上是可完成的，用户加一件真正有用的东西就够了。

如果按中位数定出来的门槛，需要用户加两件以上才够得着，那这个门槛在实际中只会产生两个结果：要么他放弃，要么他随便凑一件他不需要的，然后在收到货之后退掉。第二种结果的成本比第一种高，本地支付方式的选择在这一步也会放大差异。

横幅这个地方，四分之一的人根本看不见

促销和推荐还有一个共同的失效模式，Baymard在另一篇研究里量化过。Edward Scott在免运费信息不该只放在站头横幅里的基准测试里给了几个数：64%的用户从商品页阶段就开始考虑运费，55%的用户在过去一个季度里因为额外费用太高放弃过订单。

而32%的电商站只把免运费信息放在横幅或站头里，测试中有多达27%的受试者完全没看见它。也就是说，一条你以为已经告诉所有人的信息，实际上有四分之一的人不知道。

这个数字对推荐位的启示是：位置比文案重要得多。写得再好的凑单提示，放在一个用户已经训练自己忽略的区域里，等于没写。它得贴着价格合计出现，因为那是用户在这一页唯一一定会看的地方，跟CTA与结账的实测方案里说的位置问题同源。

移动端的优先级需要重新排一遍

这张表的实操结论只有一句：移动端的购物车推荐位，应该整块放在结算按钮之后。用户想看会往下滑，不想看不影响他结账。研究里Crate & Barrel那个被点名的例子，问题正是把推荐和信用卡广告放进了移动端购物车的主区域。

同一个促销长出三种说法，根源在三处各写一遍

还有一类问题在购物车里格外刺眼：横幅上写满200减30，推荐位角标写立省15%，结算页写优惠券已应用。三句话说的是同一件事，用户却会以为有三个优惠，然后在总价里找那两个不存在的。

根源通常是这三处文案由三个系统渲染：横幅在内容管理后台，角标在促销引擎，结算摘要在订单模板。三个地方各写各的，谁也不知道另外两个写了什么。

正确的做法是让促销在系统里只有一个身份，页面上出现几次是渲染问题，说法不一致就是数据问题。这一条和目录与购物车价格规则的配置方式直接相关——规则建得越散，同一个优惠长出不同说法的概率越高。

什么时候干脆别推促销

最后给一个可以直接抄的排除清单。以下几种情况，购物车里不要出现任何促销或金融类推广：

订单总额低于该市场客单价中位数的一半时，不推信用卡、分期、会员计划；订单只含一件低价耗材时，不推免运费凑单；用户已经使用了优惠券时，不再推第二个优惠；配送目的地是运费本来就免的区域时，不显示免运费门槛；以及最容易被忽略的一条——用户已经点过一次关闭之后，本次会话内不再出现同一个促销。

这五条没有一条需要复杂的判断逻辑，全都是几个if就能写完的东西。它们省下的不是钱，是用户在结算路上的耐心，而那个东西的库存比你以为的少得多。

为什么所有实验都在告诉你推荐位在赚钱？

一次失手复盘。代码没错、数据没错、实验也没造假，可证据在自己的数据库里躺了半年，没有一条查询会碰到它。

一个所有数字都在报喜的项目

这个客户做出海智能家居，门锁、网关、门窗传感器和几款智能灯，主力市场德法英。这类品类的兼容性约束是硬的：这把锁配不配得上那个网关，锁体厚度够不够，某个传感器能不能接进现有的网关，全都是有明确答案的事实，跟属性共现要喂给机器的那类事实同源。

他们找过来的诉求很朴素：客单价上不去，想在购物车里做一个配件推荐位。这个诉求在这类品类里几乎是天生成立的——买锁的人多半还需要一个网关，装了网关的人接下来会一个个加传感器。

排期第一周就卡住了。兼容关系表当时不存在，要建的话得从厂商规格文档里一条条抄，产品团队估了两个多月。而技术那边给了另一个方案：从历史订单里跑关联分析，把经常被一起购买的组合挖出来当兼容关系，两周能上线，覆盖率九成以上。

那个决定当时看起来毫无问题

保哥同意了这个方案。理由在会上说得挺顺：先用行为数据跑起来，看到效果之后再补厂商规格表，是标准的先跑通再优化。

现在回头看，那个决定的实质是用两周换两个多月，代价是把一个还没有治理的字段，变成了一个看起来已经有治理的字段。表建好了，行数漂亮，格式规整，接进推荐引擎一点问题都没有。

上线后三个月的数据非常好：推荐位的加购率远高于原来那个热销榜位子，客单价涨了两成多。于是这个位子被加码——首屏固定位、加购弹层里也上一份、邮件里的加购未支付提醒也带上推荐商品。

第七个月，问题不是以问题的形式出现的

先出现的是一条财务口径的异常：德国仓的逆向物流成本超了预算。查下来是退货件数涨了不少。

但退货率这个指标没有报警。整站退货率从14.8%涨到16.1%，而智能家居品类的正常区间本来就在十几个点上，一个多点的波动完全在噪音里。件数涨得多，是因为单量本身涨了。

这就是这个错误最擅长的伪装：它的影响被一个足够大的分母稀释掉了，只看好看数字的老毛病换了个形态。整站退货率是全部商品除以全部发货，而出问题的只是一小撮通过推荐位卖出去的配件。它在总数里连一个凸起都算不上。

定位它花了很大力气，因为该有的字段不存在

真正把它揪出来的是一位刚入职的分析师，他问了一个之前没人问过的问题：能不能按这件商品是怎么进的购物车，把退货率切一刀？

答案是不能，因为订单行里没有这个字段。商品从搜索进的、从分类页进的、从商品页进的、从推荐位进的，落到订单里长得一模一样。

他只好绕了个远路：拿推荐位的曝光日志和加购事件的时间戳做时间窗关联，粗略匹配出一批很可能来自推荐位的订单行。这个方法不精确，但足够说明问题——这批行的三十天退货率是38%，是站均的两倍多。

证据在自己的数据库里躺了半年

接下来那一步才是真正让人难受的。他去看这批退货的原因，发现下拉框里绝大多数选的是不符合预期或者其他。

而这两个选项后面的自由文本框里写着什么呢？网关不支持这个型号、这个锁体厚度装不上、说明书上说要另外买转接件。用户把问题说得清清楚楚，一条不落地写在了那个框里。

但退货分析的周报只统计下拉框的枚举值。其他这一项长期占到两成三，报表上就是一行数字，从来没有人展开去看过里面写了什么。

这一条我认为是本文最值得记住的东西：任何把用户的话装进自由文本的字段，如果没有一条定期运行的查询会读它，它在事实上就等于没有被记录。其他这个选项不是一个兜底项，它是你亲手挖的一座证据坟场。

那为什么当初的实验没测出来

上线前是做过实验的，两周，一个位子，加购率和订单额都显著为正。这个实验没有造假，也没有算错，它测的东西本身就不包含后来出问题的那部分。

三个原因叠在一起。第一，实验的处理只覆盖了购物车这一个位子，而一条坏推荐造成的信任损失会跨位子传播——对照组的用户同样在被商品页、加购弹层里的其他推荐位污染。实验测出来的是两组之间的差，而水位是一起在往下掉的，样本量算得再准也救不了这一点。

第二，也是更硬的一条：实验的观测窗是两周，退货的兑现窗是三十天。实验在后果发生之前就已经宣布胜利了。任何一个观测周期短于后果周期的实验，测的必然是一个还没结算的中间量，实验设计与统计功效那篇讲的是另一半问题。

第三，加购来源没进订单行，意味着即使实验跑三个月，也没有任何一条查询能把退货挂回这个位子上。测量的能力天花板，在建表那一刻就已经定死了。

改了三处

第一处是补字段：订单行增加加购来源，取值是推荐位标识、搜索、分类页、商品页、直接链接、营销落地页。这个字段一进来，退货率就能按来源切，而按来源切出来的第一张表，就是这个位子上线以来最重要的一张表。

第二处是让自由文本进流程：退货原因里其他与不符合预期的自由文本每周跑一次归类，占比超过一成五自动转人工，结果直接进产品周会。这一条的成本是一个人每周半小时。

第三处是给兼容关系降级：从行为挖掘出来的关系不再直接进渲染管线，只生成待确认候选清单，必须经厂商规格表或者售后工单确认之后才能上线。推荐位的标签也跟着数据源走——只有确认过的才能挂必备配件，没确认的一律降级成买了这件的人也常买。

结果里最有意思的是那个减法

改完之后，推荐位的加购量掉了差不多三分之一。这个数字在当时挺难看的，几个人在会上都不太痛快。

然后我们把净贡献算了一遍：推荐位带来的商品交易额，减去这批商品的退货交易额，再减去逆向物流成本和退款手续费。结果是正的，而按改动之前的数据倒推回去，那半年里这个数一直是负的。

负了半年，没有任何一张报表显示过它。因为从来没有人做过这个减法——被减数在营销的表里，减数在物流和财务的表里，两边的口径甚至连商品维度都对不齐。

三个季度之后加购量回到了原来的八成左右，而净贡献一直在涨。附带的收获是客服那边：兼容表清理干净之后顺手做成了一个公开的适配查询页，这个网关支持哪些锁这类工单量明显下去了，而那个页面后来成了这个站上被外部引用最多的一页，AI购物排名的六项因子那套算法在它身上也顺带兑现了。

十八项上线自查

前六项管数据：兼容关系表存在且有依据来源列；依据来源不许留空且渲染管线只吃厂商规格与工单确认两类；关系记到最小可售单元而不是款号；关系是有方向的；商品包装重量与体积字段覆盖率达标；订单行有加购来源字段。

中间七项管页面：推荐区块允许返回零条且零条时整块不渲染；替代品与补充品分属不同区块；购物车里默认只出补充品；变体被排除在推荐候选池外；标签由数据源决定不可后台自由填写；移动端推荐位整块位于结算按钮之后；促销提示紧贴价格合计。

后五项管流程：凑数率按位子按品类出数并进周报；退货率按加购来源切分并进周报；退货原因自由文本每周归类；同意状态透传给推荐服务且降级顺序不退回热销榜；促销在系统内只有一个身份，页面上的每一次出现都指向它。

四周该怎么走

第一周一行代码都别改，只出三张清单：兼容关系的现状与依据来源分布、推荐位的凑数率、订单行里加购来源字段是否存在。这三张清单出完，接下来该做什么基本就定了。

第二周补字段。加购来源这个字段是所有后续工作的地基，它不落地，后面所有的度量都是估的。同时把退货原因的自由文本拉一次历史数据，看看里面到底躺着什么。

第三周动逻辑：固定数量改成阈值加上限，标签绑定数据源，变体移出候选池。第四周动版位：移动端把推荐块挪到结算按钮之后，替代与补充拆成两个区块。

这个顺序有意为之——先让自己看得见，再改看得见的东西。反过来做的项目，通常在第六周会陷入一场关于到底有没有变好的争论，而那场争论没有数据可以终结。

三条该让你停下来的反信号

第一条：推荐位的各项指标全线飘红、连续几个月没有任何负向数字。这不是做得好，这是负向指标不存在。任何一个真实运行的系统都会有代价，看不到代价说明没在测。

第二条：某个推荐位的凑数率很低，但展示条数常年稳定在同一个数。这两件事很难同时为真，通常意味着阈值形同虚设，或者凑数率这个指标本身算错了。

第三条：退货原因里其他这一项的占比在涨，而没有人能说出里面写的是什么。这一条是这次复盘里最贵的一课，它值得被写进每一份数据治理清单——一个没有人读的字段，和一个不存在的字段，在决策上是同一个东西。

常见问题解答

购物车里的推荐位到底该放几个商品？

没有固定答案，正确的做法是别定这个数。把逻辑改成返回所有相关性分数高于阈值的商品，设一个上限（四到六条）防止某些主商品的配件太多把整屏占满，下限设零。

阈值可以用退货率标定：给推荐位带来的加购打上相关性分数标记，三十天后按分数档位算这批商品的退货率，退货率开始明显翘起来的那个分数就是阈值。不同品类的这条线差得很远，有硬兼容约束的品类通常比服饰高出一大截。

兼容关系数据从零开始建，第一步该做什么？

第一步不是建表，是给表加一个依据来源列并规定它不能为空。取值只有三种：厂商规格、工单确认、行为挖掘。渲染管线只吃前两种，第三种只生成待人工确认的候选清单。

然后按销量排序，先做前二十个主商品的配件关系。这二十个通常能覆盖推荐位一多半的曝光。关系要记到最小可售单元而不是款号，并且要有方向——A是B的配件不等于B是A的配件。

欧盟《数字服务法》的推荐系统透明度要求，自营独立站到底要不要守？

从法律义务上讲不需要。该法第27条的义务主体是在线平台的提供者，而在线平台在第3条第i项的定义是应服务接收方请求存储信息并向公众传播的托管服务。自营站展示的是自己的商品目录，对不上这个定义。

但这条规则里有一件事值得主动做：在推荐位上写清楚为什么推给你。成本是一行标签文案，收益是用户对整个推荐体系的信任度。法律没要求你做的事情，不代表用户不在意。

把配件默认勾选进购物车，在欧盟会有什么后果？

消费者权益指令第22条规定，商家必须就超出主合同对价的任何额外付款取得消费者的明示同意；如果是通过消费者必须主动拒绝才能避免的默认选项推定的同意，消费者有权要求返还这笔钱。

德国《民法典》第312a条第3款把它写得更死：在电子商务中，这类约定只有在商家不是通过预先设定促成的情况下才成为合同组成部分。同条第6款还补了一刀——该约定不成立不影响合同其余部分的效力，也就是配件的钱你得退，主商品照发照出成本。

用户拒绝了Cookie同意，购物车推荐还能做吗？

能，而且能做得不差。需要同意的只有跨会话读写终端存储那一类，也就是基于历史浏览记录的推荐。兼容关系、购物车当前内容、主题或用途标签、同系列商品这四类都不需要同意。

要注意两件事。一是把会话内轨迹和跨会话轨迹拆成两个字段走两条路径，很多站把它们塞进同一个画像对象里，一拒绝就整个作废。二是降级顺序别退回热销榜——那恰恰是相关性最低的依据，等于在最需要精准的时候切到了最粗的档位。

怎么判断一个推荐位是在赚钱还是在赔钱？

做一次减法：这个位子带来的商品交易额，减去这批商品的退货交易额，再减去逆向物流成本和退款手续费。多数站从来没算过这个数，因为被减数在营销的报表里，减数在物流和财务的报表里。

要能算这个数，前提是订单行里有加购来源字段。这个字段不存在的话，退货、客诉、二次退款没有一条能挂回推荐位头上，那个位子的报表在结构上就只可能是正的。

schema.org的配件属性既然Google不读，还值得写吗？

值得，但理由不是富媒体结果。isAccessoryOrSparePartFor与isConsumableFor在Google的两份商品结构化数据文档里都没有出现，写了不会让你多一个搜索结果样式。

值得写的理由在另一边：当有人问某个型号支持哪些配件时，答案引擎得从某处找到这份清单，而目前能找到的多半是论坛帖子和厂商PDF。把这份关系做成结构清晰、机器可读的公开事实，成本很低，而这个位置目前几乎没人占。顺便，做这件事的过程会强迫你把兼容表建干净，那个收益比结构化数据本身大得多。

权威参考资料