购物车交叉销售推荐相关性，卡在兼容数据和净贡献核算上

摘要：购物车里的商品推荐，是电商页面上少有的无人监管区域。欧盟写给平台的三条推荐系统规则全部绕开了自营独立站；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条的具体要求

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

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

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

在线平台的法律定义把多数独立站排除在外

这三款看起来正适用于购物车推荐位。但整条的义务主体写得很明确：使用推荐系统的在线平台的提供者。

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

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

广告透明度条款的义务主体同样是在线平台

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

如果这一款适用于购物车推荐位，就等于要求每个推荐旁边注明为什么推给你。但它的义务主体仍然是在线平台的提供者，适用范围与第27条相同。

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

暗黑模式禁令还设有让位条款

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

它的第2款规定：本条第1款的禁令不适用于已被2005/29/EC指令或2016/679号条例涵盖的做法。因此，即使你符合主体定义，这条也会把已由其他法规管辖的做法排除在外。

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

不公平商业行为指令的黑名单条款只针对搜索结果

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

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

同一次修订还修改了价格披露部分，那属于另一个议题，与这里的排名披露没有交集。

排名参数披露义务同样有前置条件

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

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

该款还专门说明，无论交易最终在哪里完成都适用。这句话针对的是把成交环节挪到站外的交易市场，并没有把单商家站纳入进来。

五条欧盟规则与自营站推荐位的适用对照

逐行读这张表会发现，每一行的不适用理由都成立，没有一条是靠钻法律漏洞得出的。各条规则都有正当的立法理由，只是合在一起，留下了一块没有任何规则打算覆盖的区域。

英国DMCC法案附表20的界线在诱饵调包

英国脱欧后另行立法。《数字市场、竞争与消费者法案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的bundle属性

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

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

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

套装商品必须有明确的主商品

该文档还有一句容易被忽略、实际上是硬性约束的话：套装的主商品是那件被主打的商品，而附加的商品应当是补充主商品的配件或附加件。

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

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

加购弹层里的默认选中也属于预设勾选

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

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

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

高价附加品为什么不应放进购物车推荐位

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

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

这条规则的依据是决策成本，与法律无关。买一台四千块的相机时顺手加一张八十块的存储卡，用户三秒就能想清楚；同一个位置塞一份六百块的两年延保（这已经属于定价决策而不是推荐），他要么随手划过，要么被迫在结算路上做一道应用题。后一种情况下无论他怎么选，结算流程都已经被拖慢了几秒钟。

附加付款规则与推荐相关性的关系

这条规则背后的原则与相关性间接相关：法律不允许你用默认值替用户做决定，是因为默认值会让人的选择显得像是他自己做的。

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

本节的实操结论是：推荐位可以做得很积极，但它必须始终停在用户主动点击那一步之前。越过这一步收上来的钱，退款时还会连带损失用户的信任。

购物车推荐相关性依赖哪些数据，欧盟同意规则如何影响它？

Baymard给的数据配方是个体行为加通用行为，但这两部分数据在欧盟的获取成本完全不同，差别并不在技术层面。

Baymard的推荐数据配方只说了一半

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

这个配方本身没错，绝大多数第三方推荐引擎也确实是这么做的。它没有提到的是：这两部分在欧盟的获取成本完全不同，差别来自法律，与技术无关。

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

个体行为数据需要用户先同意

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

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

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

同意弹窗决定了用户能得到哪种推荐

这里有个容易被忽略的结构性问题。你的用户被分成了两拨，一拨的推荐系统可以使用全部数据，另一拨只剩下通用行为数据。决定用户归属的因素与他的品类偏好、客单价都无关，只取决于他几秒钟前在同意弹窗上点了哪个按钮。

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

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

拒绝同意的用户看到的恰好是质量最差的推荐

把两个事实放在一起，会得到一个很不利的结论。

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

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

五种推荐依据的数据来源、同意要求与相关性对比

这张表的关键在于排列：不需要同意的那三行里，有两行的相关性质量排在最前面。换成结论就是，你在合规上最没有障碍的输入，恰好是效果最好的那两种。

购物车当前内容是被严重低估的推荐输入

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

这很反常，因为那三件商品是用户此刻给出的最强意图信号：他已经决定要买这三样，比可能对某个品类感兴趣明确得多。

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

会话内轨迹与跨会话轨迹应分开处理

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

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

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

推荐降级应切换依据，而非直接关闭

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

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

这套降级顺序对没有登录、没有历史、第一次来的新用户同样适用。而新用户正是最需要确认这个站够专业的那批人。

同意管理平台的分组配置也会影响推荐覆盖率

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

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

把推荐系统按依据拆开、分别归组，跟双重确认订阅的分层设计是同一件事，成本很低但收益直接体现在覆盖率上。拆分之后你会发现，常说的推荐系统在欧盟效果差，有一半是自己的配置造成的。

商品兼容关系是最可靠的推荐依据，为什么搜索引擎读不到？

schema.org词表已经有定义，网页上几乎没人使用，搜索引擎也不读取。三层都没有被堵死，合起来却是一条断开的链路。

兼容性推荐是用户最难反驳的一类推荐

Baymard的六条建议里，第五条的分量明显高于其他几条：兼容性依赖的商品应当优先于其他类型的推荐。理由很简单：买了没电池的玩具就得配电池，买了相机就得配它认得的存储卡，这些由商品本身的规格决定，不需要猜。

他们的比方是：这种推荐的作用相当于一个称职的店员，客人买电视时提醒他还得配根线。用户对这类推荐的反应通常是幸好你提醒了我，很少会觉得被推销。

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

schema.org早已定义商品兼容关系属性

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

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

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

配件与耗材属性的实际使用量很低

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

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

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

Google商品结构化数据只支持变体关系

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

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

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

兼容关系在词表、语料、消费三层的断链

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

兼容关系数据的空白也是被引用的机会

反过来看，当有人问某个型号的智能门锁支持哪些网关、某台咖啡机能用哪种滤纸的时候，答案引擎需要从某个地方把这份清单找出来。

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

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

兼容数据的三个来源及各自的出错方式

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

共同购买数据只能说明没退货，不能证明兼容

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

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

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

最小可用兼容关系表的字段设计

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

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

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

购物车推荐数量为什么应由相关性阈值决定？

把返回条数写死为五条，等于要求系统不管有没有合适商品都凑够五个，系统就会照做，一路降低相关性标准。

不用固定数量为什么排在Baymard六条建议之首

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

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

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

推荐位信噪比的计算方式

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

用户不会去算这个数，但会形成直观印象，而且扫一眼就形成了。问题在于，那四个凑数的商品不只是被忽略，它们还会把那一个好推荐的可信度一起拉下来。

这解释了本文开头那条观察背后的机制：一个可疑推荐造成的伤害按乘法计算，而非加法。它不是让这一屏的价值减去五分之一，而是让整屏的价值一起打折。

固定推荐名额会持续产出低相关推荐

当你的推荐逻辑写着永远返回五条时，它实际下达的指令是：不管有没有合适的，都要凑够五个。

系统会照做，一档一档降低相关性要求，直到凑满为止。你以为在配置一个展示位，实际上是在配置一条最低相关性标准，而这条标准由库存和目录规模决定，并不由你决定。

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

动态推荐数量就是用相关性阈值替代固定名额

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

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

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

用退货率标定推荐相关性阈值

实践中比较好用的一把外部标尺是退货率，跨境退货率怎么降那篇讲过它的构成。理由很简单：配件推错了，用户会退货，而退货是有记录、有金额、有责任人的。

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

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

标定阈值后得到的新指标：凑数率

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

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

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

零条推荐是合理且经常正确的输出

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

一支口红需要配什么？一本书需要配什么？在这些场景里硬推，收益会是负的：你占用了用户一屏的注意力，还让他觉得这个站的推荐不够专业。

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

推荐版位设计需要先支持动态数量

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

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

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

固定推荐数量为什么在组织上难以取消

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

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

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

购物车推荐替代品在什么情况下会干扰结账？

同一条替代品推荐，放在商品页是帮用户选购，放在购物车里等于问他确定吗。这个问题一旦提出，风险并不对称。

替代品推荐的作用取决于所在页面

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

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

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

替代品与补充品混装是更大的问题

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

这里的关键在后半句的混在同一个区块里，42%这个覆盖率倒在其次。因为一旦混在一起，用户就无法判断你到底想干什么：这些东西是让我替换，还是让我加购？

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

混装推荐区块的隐性成本

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

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

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

购物车里推荐替代品的合理场景

Baymard也留了余地：某些站点特定的场景是可以推替代品的，比如产品的升级款或者同一产品的新版本。这个例外是合理的，但边界需要说清楚。

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

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

缺货是购物车里唯一必须推替代品的场景

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

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

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

替代品推荐距离诱饵调包只差两个动作

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

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

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

购物车替代品推荐的三条硬性规则

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

商品变体与替代品经常被混为一谈

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

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

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

一条马上能做的购物车推荐位检查

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

四类的比例能直接反映这个位子的作用。前两类占多数说明它在帮用户完成这次购买；后两类占多数说明它在让用户重新考虑这次购买。

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

推荐标签文案为什么比推荐算法更影响用户信任？

标签无法提高推荐本身的准确度，但能让用户更准确地判断推荐。标签一旦写错，整套标签体系都会一起失去可信度。

推荐标签提高的是用户理解推荐的准确度

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

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

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

常见推荐标签各自对应哪种数据？

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

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

反面案例是IKEA的你可能还喜欢：那个区块里的商品其实都挑得不错，但标签本身没有向用户传达任何信息。

推荐标签与数据源、同意要求、降级方式对照

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

推荐标签必须与数据源一致

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

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

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

主动采用不适用于你的推荐透明度规则

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

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

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

推荐标签的长度与位置规范

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

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

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

多语言市场的推荐标签容易出现翻译问题

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

有些标签直译过去还会改变含义。搭出整套在服饰语境下没问题，直译成德语容易读成一整套家具；必备配件里的必备在某些语言里带有强制购买的暗示，而这正是这条规则最想避免的暗示。

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

一个标签写错会拖累全站标签的可信度

本文开头那条观察同样适用于标签，而且影响更大。用户在一个位子上发现必备配件其实并不必备之后，得出的结论会是这个站的标签不可信，而不只是这个位子不准。

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

因此标签的准确度要求比推荐本身更高。推荐推错了是一次判断失误，标签标错了是一次陈述失实，用户对这两种错误的容忍度相差很大。

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

起步不需要一套十几个标签的分类体系，四个就够用：必备配件、这件商品的耗材、同系列其他商品、买了这件的人也常买。

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

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

免运费凑单推荐为什么在跨境场景下经常是负贡献？

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

Baymard的两个反问背后是一笔简单的账

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。把这份关系做成结构清晰、机器可读的公开事实，成本很低，而这个位置目前几乎没人占。此外，做这件事的过程会迫使你把兼容表建干净，那个收益比结构化数据本身大得多。

权威参考资料