商品页上那个推荐位，两套报表算出相反的结论，而且两套都没算错

摘要：商品页上那个推荐位，换一套统计口径就能得出方向完全相反的结论，而两套口径在任何一本分析教材里都站得住脚。分歧不在数字对不对，在于从来没有人正式写下来过：这个位起作用了，到底指的是什么。这篇文章讲的不是推荐算法怎么调参，是替代品和补充品这两类推荐为什么必须拆成两个位、为什么前者能自动算出来后者只能一条条录进去、以及怎么给一个把用户送走才算成功的模块记功。顺带把词汇表、商品数据源和欧盟法规在这件事上各自的说法对一遍账。

同一个推荐位，两套报表算出相反的结论，哪一套错了？

一套都没错。它们分歧的地方不在数字，在一句从来没人正式写下来的定义：这个位起作用了，到底指的是什么。

先把这个位干的活说清楚

用户打开一个商品页，接下来只会发生三件事之一：买它、去看别的、离开。

推荐位管的是中间那件。它不负责让用户买下当前这件商品——那是主图、价格、参数和评价的活。它负责的是当用户心里已经浮出“这个不太对”这四个字的时候，桌上还有没有下一张牌。

问题恰恰出在这儿。它干得越好，用户离开当前页面就越快。

而你的分析后台，是按页面记账的。

口径一：点了推荐位之后成交，功劳算它的

这是最常见的一种配置。给推荐位加上点击埋点，用户点了之后在一个归因窗口内下单，这笔订单就记在推荐位名下。报表上会长出一行漂亮的数字：推荐位带来的成交额，占全站的百分之多少。这类数字看着扎实，实际上最容易出问题，仪表盘全是绿灯生意却没动的那些老指标里列过好几个同样性质的例子。

这个口径没有任何技术问题，主流的分析工具默认就这么干。

但它藏着一个假设：用户是因为看到了这条推荐才买的。对配件类推荐来说，这个假设八成成立——他本来只打算买相机，是那条推荐让他想起来还缺一张存储卡。可对同类商品推荐来说，这个假设基本不成立：他本来就要买一台相机，推荐位只是让他从A型号换到了B型号。

换一件买，和多买一件，在这张报表里长得一模一样。

口径二：成交发生在下一个页面，功劳记在那里

另一批人用的是漏斗口径，或者末次接触口径。用户从商品页A点到了商品页B，在B页面加购、结账、付款，那么这次转化的归属是B。A页面在这条链路里的角色是上一步，而上一步这个身份在大多数看板里不折算成钱。

这套口径同样没有技术问题，它甚至更保守、更不容易高估。多触点归因模型的选型思路里讲过一件事：末次点击之所以被广泛使用，不是因为它准，是因为它不需要任何人对什么算贡献这个问题达成一致。

于是在这套口径下，同类商品推荐的贡献是零。不是低，是零——它压根没有出现在归因链条的任何一个环节里。这种在后台里查无此人的情形并不罕见，AI推荐带来的访问在后台隐了身那篇讲的是同一类困境的另一个版本。

两套口径吵不出结果，因为分歧不在测量层

把这两张报表并排放在一起，你会得到一个相当尴尬的局面。

请注意最后一行。两套口径都没算错，它们只是回答了两个不同的问题：第一套回答的是点过这个位的人后来花了多少钱，第二套回答的是钱是在哪个页面上被花掉的。这两个问题的答案本来就不该相等。

所以真正缺的东西不是数据，是一句从来没写下来的定义。你继续加埋点，加到明年，两个数字也不会收敛——它们分歧的地方在定义层，而埋点是测量层的工具。拿螺丝刀去拧一颗根本不存在的螺丝，拧多久都不会响。

根子在这儿：有的模块的产出是移交，不是完成

我把这类模块叫做移交型模块。它的工作成果不是这件事办成了，而是这件事被交到了下一个环节手上。

站内搜索框是一个，面包屑是一个，同级品类的横向入口是一个，商品页上的同类商品推荐也是一个。它们的共同点很明确：干得越漂亮，用户离开当前页面就越干脆，而成交总是发生在别处。

与之相对的是完成型模块——加购按钮、结账表单、支付组件。这些模块的成功形态就是转化本身，谁都不会怀疑它们的价值，因为功劳天然记在它们头上。

一个模块的报表数字难看，可能是因为它干得不好，也可能是因为它干的那份活按定义就记不到自己名下。分不清这两者的时候，最先被砍掉的永远是后者。

末次归因对移交型模块有系统性偏见

这不是某个工具的缺陷，是记账方式带来的必然结果。只要你用谁最后接触谁得分这一类规则结算，任何以移交为产出的环节都会被判成成本中心：它占着屏幕位置、消耗加载时间、需要有人维护，而收益那一栏是空的。

更麻烦的是这个偏见会自我强化。数字难看，就少给资源；少给资源，位置往下挪、条数变少；效果更差，数字更难看。三个季度之后它会顺理成章地被下掉，而下掉它造成的损失同样不会出现在任何一行里。

第四节我会给出破解的办法。核心不是换一套归因模型，是先找到那个能把两套口径换算过来的比例——那个比例大多数团队从来没量过，因为大家都默认它等于1或者等于0。

报表做得越细，这个偏见反而越重

有意思的是，这件事在十几年前不算问题。

那时候商品页上的推荐大多是人工挑的，一个位一挑就是一季度，报表也粗——整站转化率、品类转化率，顶多再拆到页面模板一层。粗报表有个副作用是它对所有模块一视同仁，因为它压根分不清哪一次成交里有谁的功劳。

现在不一样了。每个模块有独立的曝光数、点击数、点击后成交额，看板上一个位一行，谁高谁低一目了然。这套细分能力多数站是随着分析工具升级顺带拿到的，GA4核心指标最容易解析错的四个地方那篇里讲过它带来的几个常见误读。这本来是好事，可它同时带来一个后果：模块之间第一次可以直接比较，而比较的结果第一次被拿来分配资源。

报表精度的提高从来不是中性的。它先让那些能把功劳记在自己名下的模块受益，再让那些把功劳交出去的模块吃亏，而这两件事发生在同一次升级里，看上去只是数据变准了。

这跟砍掉虚荣指标、定准北极星指标要解决的问题不太一样。虚荣指标是那些好看但不驱动生意的数；这里说的是另一类麻烦——数是真的，驱动的生意也是真的，只是记错了户头。

不展开的三条边界

第一，不谈推荐算法本身怎么实现。召回怎么做、排序模型怎么训、用向量检索还是规则引擎，这些是算法工程的活，跟本文讨论的问题正交。你用最土的规则也能把两个位分清楚，用最贵的模型也可能一直分不清。

第二，不谈购物车和结账页里的交叉销售。那是另一个场景，用户已经做完决定，推荐的性质从帮你找变成了顺便加，翻车的形态也完全不同——购物车里推错配件造成的信任损耗那篇讲的就是这一层，包括兼容关系的数据治理该怎么落地。本文只站在商品页上。

第三，不谈后台里那些配置项怎么点。各家电商系统都有现成的关联商品、向上销售、交叉销售三组字段，Magento的商品推荐规则配置实战把操作路径写得很细。本文关心的是这三组字段该往里填什么、凭什么这么填，以及填完之后怎么判断它到底有没有用。

用户站在商品页上只有两种处境，你的推荐位分得清吗？

这个不对，和这个就是它了。同一秒钟里他只可能在其中一种处境里，而多数站把两种处境的答案塞进了同一个滑动条。

用户此刻只可能在两种处境里的一种

一个人站在商品页上，脑子里的判断只有两种走向。

第一种是：这个不太对。可能是尺寸不合适，可能是颜色不喜欢，可能是价格超了预算，也可能是某个参数差了一点点。这时候他要的是别的选项。

第二种是：这个就是它了。这时候他要的是别的东西——配套的、耗材、能一起用的那些。

这两种处境是互斥的。同一秒钟，他不可能既觉得这件不对又觉得这件对。而绝大多数商品页的做法是：把两类推荐塞进同一个横向滑动条，配上一个万金油标题，然后指望用户自己分辨。

替代型推荐解决的是找不到

用户进商品页的路径五花八门：从分类页点进来的、站内搜索来的、外部搜索来的、社媒链接来的、广告来的。这些入口各自把什么样的人送进来，首页首屏的导航与分类区设计那篇拆过一部分。这些路径唯一的共同点是——他是主动选择打开这一页的，所以这件商品离他想要的东西通常不远。

差一点点，不等于差很多。他现在需要的是从这一页跳到隔壁那一页，而不是退回列表页从头再筛一遍。退回去这个动作的代价比看起来大——集合页上的已应用筛选那篇讲过，用户连点五个筛选之后，往往连自己选过什么都记不清了。

这件事的价值不体现在客单价上，体现在他会不会买。替代型推荐让用户在商品页之间横着走，一页接一页，直到找到那件对的。没有这条路，他要么退回去重新筛，要么——更常见的——直接关掉。

行业侧有个数字能说明这条横向通路有多稀缺：Baymard对主流电商站做基准测试时发现，只有53%的站支持在同级品类之间横向切换，另外47%只提供了往上走的面包屑，用户想换个相邻的方向看看，得先退到上一层再往下钻。

补充型推荐解决的是配不齐

用户找到了那件对的相机，接下来他会想到存储卡、备用电池、包、三脚架。这些东西在你的站上通常挂在完全不同的品类下，从相机页面走过去要拐好几个弯。

补充型推荐提供的是一条直达的近路。

但这里有一个特别容易被误解的地方，我得说清楚：补充型推荐的主要价值，并不在于推对了那件具体的配件。

推对某一件配件的概率本来就不高——用户要的可能是64G的卡，你推的是128G的；他要的是硬包，你推的是软包。真正起作用的是另一件事：他因此知道了你这儿还卖存储卡、还卖包、还卖三脚架。这个认知，加上一条能走过去的路，比推对那件具体商品重要得多。

Baymard在首页研究里也验证过同一个机制的另一面：22%的站展示的商品范围不足以让用户推断出经营广度，而测试建议至少要展示四成的商品类型。首页和商品页是两个入口，要解决的却是同一个问题——用户不知道你还卖什么。电商类目页的集合机制里也提到过同一件事的第三个入口，那就是类目页本身承担的目录认知功能。

两类都做的站，当年只有四成

这不是新发现。2014年那次针对50个主流电商站的基准测试就给出过一个数：只有42%的站在商品页上同时提供了这两类推荐，剩下58%要么只做一类，要么把两类混在同一个模块里。

十几年过去了，这个数字有没有变好？可以拿另一组数据侧面看看。Baymard最新一轮商品页基准显示，桌面端只有48%的站商品页体验达到不错或良好，移动端38%，App端36%；换个说法就是，桌面52%、移动62%、App64%的站整体处在平庸或更差那一档。

一个存在了十几年、方案早就写清楚了的问题，行业整体还停在及格线附近。这跟列表页上那些没被点开的商品那篇里描述的情形很像：不是没人知道该怎么做，是这类损失在报表上不留痕迹。这种情况通常有两种解释：要么它不重要，要么它有某种结构性的原因让人做不成。第一种解释站不住脚——推荐位关系到成单和客单价，没人会说它不重要。所以只剩第二种，而第二种恰恰是这篇文章的主线。

同类推荐做得太像，等于没推

替代型推荐有个不太好拿捏的平衡：既要足够像，像到用户觉得跟这一件是一路货；又要足够不像，不像到能真正解决他刚才嫌弃的那一点。

做过头的典型症状是一排同款不同色。用户嫌这条裙子太短，你推给他五条一样长的裙子，只是颜色不同——这跟没推没有区别，甚至更糟，因为它消耗了一次注意力还给了个否定答复。

断货是另一个高频踩坑点，推过去的商品买不到，那次移交就白做了，商品缺货下架之后的收尾处理里讲的库存信号决策在这儿同样适用。拿捏这个平衡靠人工挑最准，但人工挑不了几千个SKU；自动生成能覆盖全站，代价是必须把好几个维度组合起来算，只用一个维度必然翻车。这个取舍会在第三节和第四节反复出现，它其实是整件事里成本最高的一块。

依赖关系是单向的，这一点很关键

两类推荐之间有个先后顺序，而且这个顺序不可逆。

用户如果连合适的主商品都没找到，他根本不会开始考虑配件。反过来则不成立：找到了主商品，就算你一件配件都不推，这单照样能成。

看最后两行。被依赖的那一类，恰恰是功劳记不到自己头上的那一类。这个组合会导致什么后果，第九节会专门讲。

混在一个位里，用户会读出第三种意思

把同类商品和配件塞进同一个滑动条，最直接的后果是用户看不懂这一排东西是按什么逻辑凑起来的。

更麻烦的是他会自己补一个逻辑出来，而且补的往往是错的。一排卡片里前三个是同款不同色的衬衫，第四个是一条裤子，用户很自然会理解成：这条裤子是这件衬衫的推荐搭配。如果这条裤子其实只是因为共同购买数据凑巧排上来的，那这个理解就是你亲手给的误导。

Baymard后来专门做过一次商品页交叉销售的基准，结论是68%的桌面站在推荐位的商品条目上信息不足，用户没法判断推荐过来的东西到底是什么，于是相关的商品也没被发现。

两个位不必挨着放

这是源自实测的一条建议，也是最容易被设计稿否掉的一条：两类推荐要分成两组，但这两组不需要放在一起，甚至不需要离得近。

拆开放反而有好处。替代型推荐适合放在参数区之后——用户刚看完规格，正是判断合不合适的时刻。补充型推荐适合放在加购按钮之后或者页面靠下的位置——那时候他已经做完决定，才有心思想配套的事。

放在一起有个隐蔽的坏处：两组用同一个视觉容器，用户会默认它们同源。位置分开之后，标签的差异会被读得更清楚，这比在同一排里挤两个小标题有效得多。

先花十分钟判断你的站在哪一档

不用做研究，打开自己站上销量最好的三个商品页，逐个回答：

• 页面上有几个推荐模块？分别叫什么名字？
• 每个模块里的商品，是同类的、配套的，还是混着的？
• 如果混着，混的比例大概是多少？
• 把模块标题遮住，你自己能说出这一排是按什么规则选出来的吗？
• 这两类推荐分别是谁在维护？多久更新一次？

最后一个问题往往最能暴露问题。多数站的答案是：同类那组没人维护，因为系统自动生成；配套那组也没人维护，因为当初没人接这个活。这两句话听着像同一句，其实差着一整套解决方案，下一节讲的就是这个。

为什么替代品能自动算出来，配套品必须有人一条条录进去？

一个能从已有数据里推出来，一个必须由人重新录一遍。所有别的差异，都是从这一条派生出来的。

替代型推荐要用的数据，你早就有了

想算出一件商品的同类替代品，需要什么？

同一个品类、相近的价格带、重合的属性值、看过这件也看过那件的行为记录。这四样东西，任何一个跑了半年以上的站都是现成的，甚至不需要专门建表——品类在分类树里，价格在商品表里，属性在规格字段里，共同浏览在日志里。属性这一块如果建得规整，算起来还会更快，商品属性与属性集的管理方式那篇讲的就是怎么把这层理顺。

把它们组合起来算一个相似度分数，是一件当天就能出结果的工程。质量好不好另说，但它至少能自动跑起来，而且能覆盖到全站每一个SKU。

补充型推荐要用的那条数据，你的系统里根本没有

再看另一边：这台相机需要哪一款存储卡？这张沙发配哪一张边几？这支灯用哪一号灯泡？

翻遍你的数据库，没有任何一张表天然记着这件事。连商品数据的批量导入导出这类批量维护商品数据的流程，导入导出的也全是商品自身的字段，没有一列是关系。品类树记不了——存储卡和相机分属两个完全不同的分支，树结构表达的是包含关系，不是配套关系。属性字段也记不了——那些字段描述的是商品自身的性质，不是它跟别的商品的关系。

这就是整件事的分水岭：替代关系可以从已有数据里推出来，配套关系必须由人重新录一遍。

一个能推、一个不能推，剩下的所有差异都是这一条派生出来的。

平台方早就把这个差别写进了产品设计

不用猜，看现成的系统怎么做的。Shopify把商品页的推荐拆成了两组，这两组的生成方式完全不同：

官方文档里对这两组的措辞差别很直白：相关商品是自动为店里的每件商品生成的，而互补商品要商家自己去选，一件最多选10个。

最后一行是重点。不管它，替代型推荐照样出结果，页面上看着有东西；不管它，补充型推荐就是一片空白。而一片空白在多数站的巡检清单里不会报警——没人给空推荐位配过告警。

词汇表层面藏着一个更别扭的事实

这里有个细节我第一次注意到的时候愣了一下。schema.org给商品定义了四个描述关系的属性，它们的方向并不一致：

• isSimilarTo：指向另一件功能相似的商品。方向是从本商品指出去。
• isRelatedTo：指向另一件某种意义上相关的商品。方向也是从本商品指出去。
• isAccessoryOrSparePartFor：指向另一件商品，本商品是它的配件或备件。方向是反的。
• isConsumableFor：指向另一件商品，本商品是它的耗材。方向也是反的。

读一遍就明白问题在哪：词汇表里描述配件关系的那两个属性，声明的位置在配件那一侧，不在主商品这一侧。你想在相机页面上标注这些是它的配件，词汇表里没有一个属性能直接这么写；你只能跑到每一张存储卡、每一个包的页面上，逐个写上我是那台相机的配件。

而你的推荐位是站在主商品这一边的。数据要写在一处，用在另一处。

录入的人和受益的人不是同一个人

把上面那个方向问题翻译成组织语言，就得到了这件事真正做不成的原因。

配件的关系数据，录入成本落在配件那一侧——通常是低客单价、低毛利、没人重点关注的那批SKU的运营手上。收益呢，落在主商品页面上，落在相机、沙发、笔记本那些大件的转化数字里。

录的人看不到自己的产出，看得到产出的人不掌握录入。这个结构在任何一家公司里都会得到同一个结果：先答应，然后一直排不上。

一份数据如果录入方和受益方不在同一条考核线上，它的真实优先级不由它的价值决定，由录入方那一侧的空闲程度决定。这就是为什么这件事十几年了行业整体还在及格线附近——它从来不是设计问题。

行为数据能不能顶上？部分能，但缺口正好在最需要的地方

最常见的替代方案是用共同购买数据自动生成配套推荐：谁买了这件也买了那件，就把那件推出来。

这条路能覆盖一部分，但它有两个结构性缺口。行为数据用在分人群上通常更靠谱，按动态规则给客户分组做个性化那篇讲的动态规则就是它更擅长的场景。第一个是它推的是常一起买，不是能一起用，这两件事在有兼容要求的品类里差得很远，而这类品类恰恰是配件推荐最值钱的地方。第二个更要命：新品和长尾商品没有共同购买数据。刚上架的相机，没人买过，也就没人一起买过存储卡，于是它的配件位是空的。

结果是这套自动方案在最不需要它的地方（老品、爆款）表现最好，在最需要它的地方（新品、长尾）完全失效。僵尸SKU怎么重新拿到曝光那篇讨论的零流量商品，有相当一部分就困在这个分布里。这个分布特点会在第十节的复盘里以一种很贵的方式再次出现。

一个反直觉的地方：手工录的那份反而更耐放

人工维护听起来就意味着永远维护不完，但配套关系有个性质救了它：它比替代关系稳定得多。

这台相机吃哪种卡口的镜头、用哪个规格的存储卡，三年五年都不会变，除非产品线整体换代。而同类替代品是另一回事——每上一批新货、每调一轮价、每换一次季，相似度排序就得重算一遍，不重算它给出的答案很快就过时了。

把这张表拍在会上，那句这活干不完通常就没那么理直气壮了。你要付的是一笔一次性投入，换来的是一份多年不用重做的资产；而看起来免费的那一份，其实每个月都在悄悄扣费。

把它挂在谁名下，比怎么录更重要

前面说过录入方和受益方不是同一个人，那么解法也就清楚了：把录入这个动作挪到受益的那一侧去。

具体做法是三条硬规则。第一，配套关系的字段挂在主商品上，由主商品的运营负责，不是让配件那边的人去写自己是谁的配件。第二，把它写进新品上架清单——新品要上架，必须填至少两个配套品类，缺了就上不了架，跟主图和价格一个待遇。第三，给这个字段设一个负责人字段，谁填的记下来，因为半年后一定会有人来问这条为什么是这么配的。

第二条会遭到最强的抵抗，理由永远是这会拖慢上新节奏。可以让一步：只在有兼容要求的品类上强制，服饰这类品类本来就没有兼容问题，不必陪绑。数据口径的对账清单里那句话在这儿同样成立——没有校验的规范都是建议，而建议在排期表上排最后。

三条低成本的补数据路径

不用一上来就建全量的关系表，那基本等于宣布这件事永远做不完。可以先这么走：

第一条，先做品类对品类，不做商品对商品。相机这个品类配存储卡、包、三脚架这三个品类，这条规则一次配好覆盖全品类几百个SKU。粒度粗，但它让推荐位有东西可展示，而且能带用户走到对的品类里去——前面说过，走到对的品类比推对那一件更重要。

第二条，从售前咨询和退货原因里挖。客服每天被问的那些能不能配、配哪个型号，就是最真实的关系清单，而且它自带优先级——问得最多的就是最该先录的。这批数据当天就能导出来，不用等任何排期。

第三条，问供应商要。有兼容要求的品类，供应商手上多半已经有一张兼容对照表，只是从来没人跟他们要过。要过来之后需要做值域清洗和抽样核对，但比从零开始建便宜一个数量级。清洗的时候顺手把口径也统一了，海外仓的SKU周转与滞销预警那篇里的滞销预警同样依赖这批基础数据的干净程度。

一个把用户送走才算成功的模块，功劳该怎么记？

别急着换归因模型。先去找那个能把两套口径换算过来的比例——它通常就是大家默认为0或者1、却从没人量过的那个数。

别急着换归因模型，先找那个换算的比例

遇到两套口径打架，多数团队的第一反应是选一套，或者引入第三套更复杂的模型来仲裁。这两条路都不太行——选一套是拿立场当结论，引入更复杂的模型只是把同一个定义问题挪到了更难解释的地方。

更省事的做法是承认两套都对，然后去找那个能把它们换算过来的数。

口径一说这个位值一整笔订单额，口径二说值零。真相在中间某处，而决定它落在哪里的，是一个很朴素的比例：用户点了同类推荐之后买的那件东西，是替代了原来那件，还是在原来那件之外多买的？

这个数大多数团队从来没量过。不是因为难，是因为大家都默认它已经知道了——要么默认全是替代，要么默认全是新增。

指标一：替换率，把两套口径接起来的那座桥

定义很简单：在所有点击过同类推荐并最终成交的订单里，被点击的那件原商品没有出现在订单里的比例。

算它需要的东西你都有——订单明细里的商品行，加上会话内的页面浏览序列。不需要新埋点，不需要改前端，写个脚本跑一遍历史数据就出来了，通常半天。要注意的是样本量得够，A/B测试样本量的估算那三个公式可以直接拿来估这个数需要多少订单才稳。

拿到这个数之后，那笔糊涂账立刻能算清：

• 真实新增部分 ≈ 表观成交额 ×（1 − 替换率）
• 剩下的那部分不是零，它是防止用户离站的价值，得用另一个指标去测

我见过的实际值多半落在七成到九成五之间，也就是说这个位绝大部分时候在做替换而不是加购。手头没有同行数字可比的话，行业基准数据该对标多少才正常里有一份能拿来对标的区间参考。这不是坏消息——替换本来就是它的本职工作。坏消息是如果没人算过这个数，你的报表一直在把这七到九成当成新增收入往上报。

两套口径吵不出结果的时候，不要去选一个口径，要去找那个能把两者换算过来的比例。它通常就是那个所有人都默认为0或者1、却从来没人量过的数。

指标二：死路页面率，告诉你该先铺哪些页

把每个商品页作为会话最后一页的次数，除以它的总访问量，就是这一页的死路率。

这个数不用新埋点，任何分析工具里的退出率都是它的近似值，只是很少有人按商品页拆开看。拆开之后你会发现分布极不均匀：有些页面的死路率两成出头，有些能到六七成。

死路率高的那批页面，就是替代型推荐最该优先覆盖的地方。它们通常有共同的特征——从外部搜索直接落地的、参数比较特殊的、价格明显高于同类的、已经断货的。这批页面上，用户找不到下一张牌就只能关掉。

最后一行值得多说一句。死路率低不必然是好事，它也可能意味着用户在你的站里来回打转就是买不到东西，这时候该查的是站内搜索这个高转化入口的设计和列表页的筛选逻辑，跟推荐位关系不大。

指标三：移交成功率，替代型推荐的本职分数

定义是：在点击过同类推荐的会话里，本次会话内最终发生加购的比例。对照组是同一批商品页上没有点过任何推荐就离站的那些会话。

这两个数放在一起看，才是替代型推荐真正的成绩单。想把它做成一次正式的对照，实验设计与统计功效里关于单因素隔离和最小可检测效应的部分值得先读一遍。它衡量的不是它赚了多少钱，而是它把多少个本来要走的人接住了。

为什么要用加购而不是成交？因为加购之后的流失属于购物车和结账的问题，那是另一段旅程的事，混进来只会把信号搅浑。结账放弃的那些真实成因跟推荐位干的活隔着好几个环节，两者不该记在同一本账上。

指标四：配套那一侧看订单行数，但要加一道限定

补充型推荐的成绩单简单得多，因为它的功劳本来就记在自己名下：看平均订单行数有没有涨。

但有一道限定必须加上，否则这个数会虚高：只统计那些在本次会话中首次被看见就是在推荐位里的商品。用户本来就打算买存储卡，自己搜过、看过，最后顺手从推荐位点进去买了，这一件不该算推荐位的功劳。

加上这道限定之后，数字通常会掉三到五成。掉下来的才是真的。这个思路跟AI搜索归因里的两层里区分影响与增量的做法是一样的：先问这件事没发生的话会怎样。

两个数交叉着看，才知道毛病出在哪

单看任何一个指标都容易误判，把替换率和移交成功率放在一起交叉读，指向会清楚很多：

第三行是最容易被忽略的一种情况。有些站的所谓相关商品位里混着大量配套品，替换率自然低，而移交成功率因为加购发生了显得挺高，看板上一片祥和，实际上两类推荐从来没被分开过。这时候任何调参都是白费力气，得先回到第二节把位拆干净。

四个数按什么顺序上

不用一次全上，按这个顺序推进最省事：

第一周先算死路页面率。它不需要任何新计算，现成的退出率按商品页拆一下就有，而且它直接产出一份工作清单——死路率最高的那两百个页面就是第一批要改的。当周就能开工，不用等任何人拍板。

第二周算替换率。这一个数的政治价值比技术价值高：它会把报表上那个被高估的数字拉回真实水位，也顺带说明为什么这个位过去看着回报率高得不像话。提前跟看这张报表的人打个招呼，别让人以为是效果掉了。

第三周开始算移交成功率和订单行数。这两个要跑一段时间才有意义，因为它们要跟改版前的基线比。把它们跟成本放在一起看会更有说服力，内容ROI的评估方法那套单项盈亏表的算法可以直接借用。基线没有就先攒两周，别用记忆里的印象当基线——那个东西一向偏乐观。

这套东西跑起来不需要新埋点，但需要有人负责口径不变。指标层的单一事实来源怎么建那篇讲过一个很实在的教训：口径改了没人记，三个月后的对比就全废了。

为什么不该拿点击率给这两个位排名

看板上最方便的做法是把所有推荐位并排列出来，比点击率，谁高谁多给资源。这个做法有个不明显的毛病。

同类推荐的点击率天然更高。用户正在看这个品类，同品类的商品跟他此刻的注意力最贴，点进去的门槛也最低。配件跨品类、单价低、需要多想一步，点击率天生就矮一截。

更麻烦的是点击率还会被标签的含糊程度推高——一排看不出是什么逻辑的商品，用户为了搞清楚会去点，这种点击在数据里跟真兴趣长得一模一样。把两个目标不同的模块放进同一张表比点击率，等于让它们去比一个只有其中一个在乎的数。

正确的做法是各看各的：替代型看死路率和移交成功率，补充型看订单行数和配套渗透率，谁也别去比对方的主场指标。真出现异常波动时怎么定位，从指标体系到异常诊断那套诊断顺序可以照着走。这四个数放在一张周报上，比一列点击率有用得多。

标签上换一个词，用户凭什么就默认它们配套？

因为署名变了。推荐位的标签不是装饰性文案，它是一份责任的署名，写谁的名字，就由谁来担保。

用户默认推过来的东西是配套的

这是实测里反复出现的一条：只要推荐是以站方口吻给出的，用户就默认这些东西跟他正在看的这件是能配的。

这个默认不是用户不谨慎，是生活经验的直接迁移。你去实体店买了台相机，店员转身拿来一个包说这个配它正好，你不会追问这包到底装不装得下——他既然拿了，就是这个意思。线上那一排卡片承担的是同一个角色。

所以问题从来不是用户为什么这么想，而是你有没有资格让他这么想。

唯一能解除这个默认的，是把署名换掉

测试里有一个很干净的分界：只有当推荐被明确标成其他顾客也买了、其他顾客也看了这一类说法时，多数用户才会意识到这些东西需要自己核对一下。

因为署名变了。

推荐位的标签不是一句装饰性的文案，它是一份责任的署名。写你的名字，用户读到的是你在担保；写其他顾客的名字，用户读到的是这些人这么干过，你自己看着办。两种写法的字数差不多，承担的东西差着一整个售后成本。

一张能直接拿去改文案的对照表

把常见的几种说法按承诺强度排一下，选起来会容易很多：

最后一行是个高频陷阱。这类万金油说法读上去很安全，正因为它什么都没说，用户会按最有利于自己的方式去理解，通常就是理解成配套。含糊不会降低承诺，只会把定义承诺的权力交给对方。

推错配件的代价在购物车场景里更容易被看见，因为那时候用户往往已经下了单，退货、工单和差评会把账算得明明白白。商品页比购物车更早，同一个错误在这里发生时，用户还没有付钱，损失表现为他直接走了，一个字都不会留下。

还有一种同形歧义：这件配件到底含不含在里面

兼容不兼容之外，用户在推荐位上还要判断另一件事——这东西是不是已经在包装里了。

这个问题比想象的严重。Baymard的测试里，一台随机附赠三件钢制配件的搅拌机，63%的受试者没能看出这些配件是随机附送的；同一轮基准里，31%的站在主力商品上根本没提供随附配件的实拍图。

把这两件事叠在一起，用户站在推荐位前面其实要同时回答三个问题：这件东西跟主商品配不配、它是不是已经含在主商品里了、买它是不是要另外花钱。三个问题，一排卡片，通常一个都没答。

答这三个问题不用加设计，只要加字

解法比想象的便宜。逐条来：

配不配的问题，靠标签措辞加适配说明解决。能保证兼容就把型号写出来，写在卡片上而不是藏在详情里；不能保证就换成行为署名的说法，一个词的事。适配说明这类文字最好有统一模板，别让每个运营各写一版，产品详情页的模块化结构里的模块化思路可以照搬。

含不含的问题，靠一张随附件实拍图解决。主图区里放一张把所有随附件摆开的照片，比任何一段文字都管用。这类自己拍、自己写的内容还有个附带好处，摆脱供应商文案做出唯一内容那篇讲过它对页面唯一性的价值。做这张图的成本是一次拍摄，收益是这个品类的售前咨询会明显少一截。

要不要另花钱的问题，靠价格前缀解决。推荐位里的价格前面加一个加号或者另购两个字，用户扫一眼就明白这是要加钱的。这个改动小到不值得单独开需求，但它消灭的是一整类结账时才发现总价对不上的惊吓。

出海站的坑：这些标签不能直译

上面那张表是按中文语感排的，搬到别的语言市场会走样，而且走样的方向不一样。

英文里最常见的那个词本身就极其含糊，它既能指同类也能指配套，用户读到它基本等于没读到任何限定。德语区的情况相反——那边的商品页习惯把配件和同类商品用两个界限分明的词分开，用户对这两个词的预期比英文市场清晰得多，你要是混着用，读起来会很别扭。法语市场介于两者之间。

所以标签这件事不能交给翻译流程处理。翻译解决的是这句话怎么说，而这里要定的是这句话承诺了什么，后者是业务决策。可行的做法是：先把每个位要承诺的强度定下来写进规范，再让每个市场各自去找承载这个强度的说法，允许各市场用词不一致，只要强度一致。

这跟出海品牌声音体系的搭法是同一个思路：统一的不是字面，是那句话在当地读者耳朵里的分量。

一个五分钟的自查

不用做用研，找一个没参与过这个项目的同事，做三步：

1. 打开一个商品页，把所有推荐模块的标题遮住，只留商品卡片。
2. 请他说出每一排是按什么规则选出来的，以及这些东西跟主商品是什么关系。
3. 把标题揭开，问他刚才的理解跟标题说的是不是一回事。

三步走完，问题会自己浮出来。最常见的结果是他说不出第一排的规则，第二排则被理解成配套——而第二排其实是按浏览行为拼的。这两条结论加起来，基本就是这一节要修的全部东西。

做这个自查不需要预算、不需要排期，午饭前就能干完。它的价值不在于发现了什么新东西，在于它把一件所有人都以为不必确认的事，变成了一条写在纸上的确认结论。

标签写对了，还有个执行细节容易漏

标签和内容必须是同一套逻辑生成的。

我见过不止一次这种情况：文案改成了常一起购买，可后台的数据源没动，出来的还是按属性相似度算的同类商品。这跟拿用户评论去生成商品描述时容易犯的错是同一类：话说得比数据能支撑的更满。于是标题说的是行为数据，内容其实是属性数据，用户看到的是一排跟主商品几乎一样的东西被说成常一起购买——这比标签含糊还糟，因为它是一句能被当场证伪的话。

所以改标签这件事必须和改数据源绑在同一次上线里，谁都不许单独发。这条听着像废话，但它是这一节里最常被违反的一条，因为改文案实在太容易了，容易到不需要经过任何人。

同一批关系，为什么在三个系统里是三种不同的东西？

页面上两个位，词汇表里四个属性，商品数据源里六种关系类型。三种粒度、两种方向、零条互通的通道。

页面上只有两个位，这是最粗的那一层

前面几节讲的都是页面：一个替代位，一个配套位，最多再加一个行为署名的位。用户能看见的就这些。

但同一批商品关系还活在另外两个系统里——页面的结构化标记，和你推给购物渠道的商品数据源。这两处的切分方式跟页面完全不同，而且彼此也不同。

这件事的麻烦不在于三处不一致，在于三处都不会因为不一致而报错。每个系统都认为自己手上那份是完整的。

词汇表分了四种，其中两种是反着写的

schema.org给商品定义的那四个关系属性，前面提过一次，这里把它们跟页面的两个位对上看：

顺带一提，属性之间的共现关系本身也是一种可被机器读取的信号，用属性共现构建实体识别那篇讲的就是怎么用它把模糊的品牌喂清楚。第二行的isRelatedTo是个万金油，跟页面上那个你可能也喜欢是一路货色，含糊得没法用来做区分。挑属性这件事本来就该按用途来，常用的十三种Schema类型那篇给过一个按实际使用率排的优先级参考。真正有用的是第一行和后两行，而后两行的方向是反的——这意味着如果你想让机器知道相机页上那几件是它的配件，光改相机页没用，得去改每一张存储卡的页面。

商品数据源里是一个属性配六种关系

再看第三层。Google的商品数据规范里有一个叫做关联商品的属性，它把关系拆得比谁都细，一共六种类型：

规范里对这个属性的定义还给了几条硬约束：它是可选的，一件商品最多挂30个关联商品，三个子属性全部必填（关系类型、标识符类型、标识符），同一种关系有多个对象时要拆成多条而不是用逗号并列。子属性缺一个整条就不生效，这类静默失效跟JSON-LD里一个尾逗号让整页标记失效里那个尾逗号是一个性质。

最值得看的是第五种：不同品牌的同款

六种里有五种在页面上都能找到对应的位置，唯独第五种没有——把一件更便宜的自有品牌商品，显式声明成当前这件的同款替代。

没有哪个站会在商品页上开一个位专门写这个。可在商品数据源里，规范不但允许你这么写，还专门举了自有品牌这个例子。

这个差别很说明问题。页面是给用户看的，所以你只会写对当前这笔交易有利的关系；数据源是给机器看的，机器要的是完整的关系图，包括那些你不想在页面上主动说的。两者要表达的东西本来就不是同一批。

六种里优先级最高的，是必需部件那一条

规范给必需部件举的例子很朴素：电池灯里的那节电池。翻译成人话就是——不买它，主商品用不了。

这条关系在所有配套关系里性质最特殊，因为它不是锦上添花，是缺一不可。而它恰恰是最容易在页面上被漏掉的一条：商品页写着这台设备的全部参数，就是没写它不含电池；用户买回来通电，发现还得再跑一趟。

这类事故的表现形式很有欺骗性。它不表现为转化率下降——用户已经买了；它表现为差评、退货和一句这店坑人。而在你的报表里，这单是成功的。

所以必需部件不该只活在推荐位里。它至少要出现在三个地方：商品页正文的显著位置（一句不含电池就够）、配套推荐位的第一条、以及商品数据源里那个关系类型。三处都写，成本是一次性的；漏一处，代价按订单量线性增长。

先填三种就够，剩下三种可以往后放

六种全填是个不小的工程，实际上不必。按投入产出排，前三种能覆盖绝大多数场景：

还要留意变体的情况：同一款商品的几十个规格如果各自都是独立SKU，关系数据的条数会成倍膨胀，同一商品的几十个URL该合还是该拆那篇讨论过该合还是该拆。第三行有个容易被忽略的用途：断货。主商品断货的时候，替代品关系是唯一能把这个用户接住的东西，而这时候页面上那个自动算的相似度推荐往往还在推别的断货商品——因为相似度算法通常不看库存。这条关系如果提前填好，断货页的处理逻辑会简单很多。库存本身的口径也得跟上，库存预警与防超卖的配置那套预警和防超卖的配置是这条规则能不能生效的前提。

一句最容易被漏掉的话：这个属性没有页面标记的对应物

规范在这条属性下面明确标着：它在schema.org里没有对应的属性。

这类跨系统的映射关系怎么组织，用图结构把实体关系串起来那篇给过一套用图结构串起来的思路，可以拿来理清各实体之间的指向。换句话说，你在页面上用JSON-LD写多少关系标记，都不会变成商品数据源里的关联商品；反过来，你在数据源里填得再全，页面上的结构化数据也不会因此多出一个字段。商品结构化数据后来补上category属性那一次，是页面标记和数据源第一次在分类这件事上对齐；关系这一块，到现在还是两条互不相交的线。

这就把整件事说清楚了：同一批事实，在三个系统里有三种粒度、两种方向、零条互通的通道，而且每个系统都不会为缺失报错。它们不会打架，只会各自安静地不完整。

那就只能靠一张人工对的账

既然系统之间不互通，就得有人把它对起来。这张表不复杂，横轴四列，纵轴是你实际在用的关系类型：

• 页面上有没有：哪个位、什么标签、覆盖了多少SKU
• 页面标记里有没有：用的哪个属性、写在哪一侧的页面上
• 商品数据源里有没有：用的哪种关系类型、填了多少条
• 数据从哪来：人工录的、算出来的，还是供应商给的

这张表建议直接用表格工具维护，导出成结构化格式再做校验，把JSON-LD调试这件事讲透那篇里的调试办法能省掉不少肉眼比对。填的时候有一条纪律：按实际抓到的数据填，不按字段定义填。定义写着这个字段有值，跟线上真的有值，是两件经常对不上的事。做全站范围的核对时，百万级SKU的站点地图分片那篇讲的分片和进出场策略可以顺带解决抽样怎么抽的问题。

填完之后，那几行互相矛盾的就是要修的。顺便说一句，一件商品同时挂在多个品类下时这张表会更难填，商品的交叉分类怎么处理那篇讲过怎么处理这种交叉归属。经验上矛盾最集中的地方在第二列和第三列之间——页面标记那侧多半是主题模板自动生成的，没人专门配过关系，而数据源那侧是运营手工维护的，两拨人从来没对过话。这种矛盾在用工具把页面上五种格式的字段缺漏一次扒清之后会看得很直观，不必逐页人肉核对。

法律给推荐位下了定义，义务为什么挂在了别人身上？

定义宽到能把你完全罩住，义务却被限定在搜索结果和线上平台上。定义的宽度和义务的宽度，是两件独立的事。

先说结论，免得白紧张

如果你做的是自营的品牌独立站，卖的全是自己的货，那么下面要讲的两部法规里，最硬的那几条义务大概率不落在你头上。

但值得读完，原因有两个。第一，它们对推荐位下的定义宽到能把你完全罩住，而定义本身已经替你写好了用户会怎么理解这个模块——用户不会因为你不是平台就降低期待。第二，只要你的推荐位里掺进了任何一点付费成分，情况立刻不同。

欧盟对排名的定义，宽到出乎意料

不公平商业行为指令在修订时加进了一条定义：排名指的是交易者给予商品的相对显著性，不论采用何种技术手段来呈现、组织或传达。

把这句话拆开看：不论何种技术手段，意味着它不关心你用的是算法还是人工挑；相对显著性，意味着它不只指列表页那个从上到下的顺序，任何让某些商品比另一些更显眼的安排都算。

商品页上那个推荐位，一排六件商品，从几万个SKU里选出来放在用户眼前——按这个定义，它当然是排名。同一部指令在价格展示上也有类似的宽定义，商品页上被划掉的那个原价那篇里那个被划掉的原价就是一例。

可是两条硬义务都限定在搜索结果里

定义如此之宽，接下来的义务却窄得多。同一部指令里跟排名有关的两条硬规定，适用范围都被明确限定了：

前两条掉出去了，第三条兜住了。这个差别不只是技术性的：附件一里的行为属于在任何情况下都不公平，不需要证明它实际影响了谁；而误导性遗漏那条要看具体情境，要判断它是否可能让普通消费者做出本来不会做的决定。

一个概念被法律定义了，不等于围绕它的每条义务都跟着适用。定义的宽度和义务的宽度，是两件各自独立的事。

数字服务法把这件事说得更细，但主语不是你

另一部法规讲得更直接。数字服务法第27条要求：使用推荐系统的线上平台，必须在条款里用清晰易懂的语言说明推荐系统所用的主要参数，以及用户有哪些选项可以修改或影响这些参数。

第2款还进一步规定，这份说明至少要包括两样东西：决定推荐内容最重要的那些标准，以及这些参数为何具有这样的相对重要性。

注意主语——线上平台。而这部法规给线上平台下的定义是：应服务接收方的请求，存储信息并向公众传播的托管服务。你的品牌独立站卖的是自己的货，不存储也不传播第三方提交的信息，所以不落在这个定义里。

但它给推荐系统下的定义，一个字都没漏掉你

同一部法规里，推荐系统的定义是这么写的：全自动或半自动的系统，用于在线上界面向服务接收方建议特定信息或对该信息排优先级，包括作为搜索的结果，或者以其他方式决定所展示信息的相对顺序或显著性。

逐句对照你商品页上那个位：自动的，是；在线上界面建议特定信息，是；决定相对顺序和显著性，是。

唯一不匹配的是句子开头那半句——由线上平台使用。法律给你的功能起了名字、下了定义，然后把义务挂在了另一个主语上。你不需要遵守它，但那份定义已经把这个模块该是什么样子写在纸上了。

这跟前面讲的归因问题是同一个结构的两面：一个是义务的归属，一个是功劳的归属。都是同一件事在不同的账本上被记到了不同的名下。

这些条文是什么时候长出来的

值得把时间线摆一下，因为它本身就是这一节最有意思的部分。

本文开头提到的那份推荐位研究发表于2014年。那一年，排名这个词在欧盟消费者法里还没有定义，推荐系统这个词在欧盟法规里也还不存在。当时把两类推荐分开、把标签写清楚，纯粹是一条体验建议——做不做，取决于你在不在乎用户体验。

之后的事情是这样发生的：排名的定义和那两条披露要求，是通过2019年那轮消费者保护现代化修订加进来的，2022年5月底开始适用；推荐系统的定义和第27条的透明度义务，来自2022年通过的数字服务法。

也就是说，一条2014年的体验建议，在八年之内被两部法规分别接管了一部分，而在这个过程中，没有任何人通知过当年做这个模块的那些人。这类变化不会以需求单的形式出现在你的看板上，它只会在某一天以另一种形式出现——通常是一封询问函，或者一个客户投诉。

把推荐位过一遍这五个问题

不用请律师，先自己答这五题，答不上来的就是要查的：

1. 这个位里的商品，排序依据是什么？说得出一句话吗？
2. 这个依据里有没有任何付费因素、任何商务合作、任何人工置顶？
3. 如果有，用户能不能从页面上看出来？
4. 你的站上有没有第三方卖家的商品混在这个位里？
5. 这个位的内容是不是由站内搜索接口返回的？

第二题的答案经常是不知道，因为置顶规则往往散落在几个人手上，有的写在配置里，有的写在一段谁也不敢删的旧代码里。把它们集中到一处并记下每条的来由，是这一节唯一算得上工程量的动作，但也就一两天。

第三题如果答否，别急着解释这是行业惯例。行业惯例在监管口径里从来不是抗辩理由，而且这一条改起来实在便宜——加个角标的事。

什么时候你会突然被拉进义务范围

有三种情况会让上面的结论翻转，值得逐条核对。判断自己适用哪一套规则时，经营主体注册在哪、主要面向哪些市场也得一并考虑，出海主体的三地区架构对照那篇整理过这一层：

第一，推荐位里有付费成分。供应商付钱买推荐位、品牌方付费换更靠前的位置，只要用户看不出来这是付费的，误导性遗漏那条就有话可说了。它不需要落进附件一的黑名单也能构成违规，只是举证要求不同。

第二，你的站上有第三方卖家。一旦引入市场模式，你的身份就从卖家变成了中介，前面那些被排除掉的条款会一条条回来，还会额外叠加线上市场自身的信息披露义务。

第三，推荐位由站内搜索驱动。如果推荐结果实际上是搜索接口返回的，且用户能感知到这是对他某次查询的响应，那么它是不是搜索结果就变成了一个需要认真判断的问题，而不是想当然。

不管落不落在义务里，这三件事都该做

合规是底线，不是目标。抛开法条，下面三条按体验标准也该做：

付费位必须标出来，一个词就行；推荐依据可以自愿说明一句，比如根据你看过的商品、根据同类顾客的购买；别用一句为你推荐去包装一个纯粹按利润率排的位——这句话在用户那里是承诺，在监管那里是断言，两边都不好交代。

另外提醒一句，欧盟这几年在商品页上加的显示要求不止这一处，列表页上那个每千克单位价格也是同一批规则里的一条，做欧洲市场的话最好一次性梳理完。这三条跟商品页上的环保表述要拿证据是同一套思路：先假设有人会认真追问你这句话凭什么，然后确保你答得上来。

机器从你的推荐位里读走的，和用户看到的是同一件事吗？

商品页上那个位，是你的站上关于商品之间怎么搭配的唯一一份可读材料。而它多半是异步加载的。

用户问的问题里，有一整类是关于关系的

购物这件事正在从关键词检索往别的形态挪，电商从关键词转向AI选品那篇讲过这个转向对商品数据提出的新要求。把用户在AI助手里问的购物问题分个类，会发现有相当一部分不是在问某件商品好不好，而是在问关系：这台相机配什么包、这个型号能用哪种滤芯、买了这张桌子还得配什么椅子。

要回答这类问题，机器需要的不是商品描述，是一张关系图。被检索和被引用是两套打法那篇拆过这两层的区别：被检索到和被拿去当答案用，需要的材料并不一样。而你的站上，这张图存在于哪里？

大概率哪里都不在。它以人能理解的形式存在于推荐位的视觉排布里，以机器能理解的形式——多半不存在。

推荐位是少数几处把两个品类放进同一页的地方

换个角度看这件事。你的分类树里，相机在影像器材下面，摄影包在配件下面，这两个分支之间没有任何连接。搜索页是按查询词组织的，也不体现关系。

唯一一处把这台具体的相机和这个配件品类放在同一个页面上、还带着一条链接的地方，就是商品页上那个配套推荐位。

对站外的机器来说，那不是一个推荐模块，那是你这个站上关于商品之间怎么搭配的唯一一份可读材料。它读到什么，就以为是什么；读不到，就当你这儿没有这件事。这跟列表页凭什么被单独收录那篇讨论的是同一个道理：一个页面凭什么被单独理解，取决于它自己交代了多少。

2014年那条建议，今天多了一个理由

关于推荐位，早年的研究里有一条建议是：推荐出来的商品，最好同时给出它所属品类的链接，别只给商品链接。

当时的理由完全是体验层面的——推对那件具体商品的概率不高，用户真正想去的是那个品类，你直接给条路，省得他点进商品页再找面包屑再往上爬。这个推理今天依然成立。

但现在有了第二个理由，而且这个理由跟用户没关系：那条指向品类的链接，是机器判断你经营范围的直接证据。一条从相机页指向存储卡品类页的链接，说明的是这家店卖存储卡，而且这两件事是相关的——这句话没有别的地方能说出来。AI购物时代的集合页优化那篇里讲的集合页优化，本质上也是在给机器补这类目录信号。

同一个改动，十年前的收益是省用户几次点击，今天多了一份收益是让机器知道你卖什么。围绕这个目标还有一批更系统的做法，让商品页对齐AI的理解逻辑那篇整理了十条。而这个改动的成本，还是那么低。

最大的坑：这个位常常是异步加载的

说到这儿必须泼一盆冷水。商品页上的推荐位，在多数实现里是页面加载完之后再去请求接口拿数据、拿回来再渲染的。理由很正当——推荐要个性化，要实时，要不影响首屏速度。

代价是它在初始的HTML里不存在。顺带说一句，为了首屏速度做的渲染优化也可能带来类似的副作用，长列表的渲染跳过与CSS隔离那篇讲的就是这类跳过渲染的机制该怎么用才不出事。

抓取方能不能拿到它，取决于对方执不执行脚本、等不等得起、以及那次抓取有没有踩上超时。这三个条件里任何一个不满足，你精心设计的两个推荐位在机器眼里就是一片空白。从抓取日志里解码不同AI爬虫的行为能看到相当一部分请求根本不具备完整渲染的能力，它拿走的就是第一份HTML。

不用推翻实现，留一条静态的就够

解法不需要把整个推荐位改成服务端渲染，那个代价太大也没必要。折中的做法是：

在初始HTML里放一组静态的品类链接。这台相机对应的配件品类有三到五个，这个映射是稳定的（第三节讲过配套关系比替代关系耐放），完全可以写死在模板里，跟异步加载的个性化推荐并存。用户看到的还是那个动态的位，机器至少能读到品类关系。

把关系写进页面标记。词汇表里那几个属性虽然方向别扭，但至少存在。配件页上写清楚它是谁的配件，成本是一次模板改动。顺带把推荐位里那些图片的替代文本也补上，图片alt的批量体检能一次性查出哪些是空的。

面包屑一定要完整。这条听起来不相干，其实是同一件事——机器要通过面包屑才能知道推荐过去的那个商品属于哪个品类。整站的层级搭得深不深也会影响这件事，网站架构的抓取深度那篇讲过抓取深度的账该怎么算。Baymard的移动端研究里提到36%的电商站不提供完整的品类路径，路径断了，关系也就跟着断了。面包屑该怎么配、要不要上标记，面包屑导航的四种类型与结构化数据那篇讲得比较全。

同一个位，两类读者拿到的东西差得很远

把用户和机器各自能从这个位上获取的信息列出来，差距会很直观：

最后一行是根子。前面四行不管做得多细，只要机器连这个位存不存在都不知道，全都白搭。所以顺序很明确：先保证有一份静态的能被读到，再谈里面写得细不细。

怎么确认机器到底读到了什么

不用猜，三步就能验完，加起来不到半小时：

第一步，把浏览器的脚本执行关掉，刷新商品页。推荐位还在不在？标签文字还在不在？品类链接还在不在？这一步能筛掉八成的问题，而且任何人都会做。

第二步，看抓取工具渲染之后拿到的HTML。跟第一步的区别在于它模拟的是会执行脚本的抓取方。两步结果如果不一样，说明你的推荐位对不同抓取方是不同的样子，这本身就是个要记录下来的事实。

第三步，翻服务器日志。看那些提供推荐数据的接口有没有被爬虫请求过。多数情况下答案是没有——爬虫拿走了商品页的HTML，但从没碰过那个接口。这条日志比任何推断都硬。

三步做完，你会得到一句相当具体的结论：我的推荐位对某几类抓取方可见，对另外几类不可见。有了这句话，要不要投入去改就是个简单的算术题了。

顺带说一个容易搞反的优先级

常有人问，是不是该给推荐位单独做一套结构化数据，把每一条推荐都标出来。

我的看法是先不必。推荐位是高度动态的，今天推这六件明天推那六件，标记跟着变的维护成本不低，而收益不明确。从全网结构化数据的使用统计来看该优先做哪些类型，这类高频变动的模块从来不在优先级前列。

真正值得先做的是稳定的那部分：品类归属、品类之间的配套关系、必需部件。至于标记本身对AI搜索到底有多大作用，结构化数据对AI搜索有没有用里有官方说法和实测的对照，可以校准一下预期。这些一年动不了几次，标一次能吃很久。标记的价值跟它的稳定性成正比，跟它的实时性没什么关系。

还有一层：你的关系数据会被别人拿去用

最后提一句可能被忽略的事。你填进商品数据源里的那些关系类型，用途不止是给自己的推荐位供数。

购物渠道那边会用它来组织商品展示，AI助手在回答配套问题时也可能引用到。想知道自己的商品信息在这类场景里够不够用，产品描述的七项AI购物信号可以拿来做一次快速体检。这意味着那份数据的质量不只影响你自己的页面——它一旦出错，错误会被搬到你控制不了的地方去，而且你连它被搬到哪儿了都不知道。

这批流量的转化能不能接住是另一回事，AI来的流量与落地页的落差那篇提醒过一个常见落差：人来了，落地页却没准备好回答他的问题。这也是为什么第三节强调要有负责人字段。关系数据填错了，页面上还能靠人工巡检发现，出了站就只能等别人来告诉你。AI推荐里冒出根本不存在的商品这类问题，有一部分源头其实就在商家自己给出去的数据上。

预算是怎么一步步流到那个最不该拿走它的位置上的？

被依赖的那一方数字更难看，依赖别人的那一方数字更好看，而资源按数字分配。这是个不需要任何人犯错的自毁配置。

两个位争的不只是版面

版面的争夺是看得见的：商品页往下滚，谁排在前面，谁占几屏，移动端谁进折叠区。这部分大家都有感知，吵起来也吵得明明白白。

真正决定胜负的是另一场看不见的争夺——维护资源。谁的数据有人定期清洗，谁的规则有人调，谁出了问题有人第一时间去修，谁的效果有人每周盯着。这些东西没有会议纪要，但它决定了半年后这两个位各自是什么状态。把优化当产品来做的节奏那篇里说过一句很实在的话：没有归属的模块，衰减是默认状态。

而资源的分配依据，是报表。

把前面几节的结论叠起来，会得到一个很别扭的形状

逐条摆出来：

• 用户先要找到对的商品，才会开始考虑配套。依赖是单向的。
• 替代型推荐的功劳记在下一个页面，或者被替换率吃掉大半。
• 配套型推荐的功劳完整地记在自己头上，因为它带来的是订单里多出来的那一行。
• 资源按报表分配。

四条连起来：被依赖的那一方，是报表上数字更难看的那一方；依赖别人的那一方，是数字更好看的那一方。而资源会持续从前者流向后者。

这是个自毁的配置。它不需要任何人犯错就能自己运转下去，因为每一步单独看都是对的：数字好的多给资源，这条规则本身没有任何问题。

最难对付的地方是每一步都有数据支持

如果这个过程是靠拍脑袋推进的，那还好办——摆事实就能拦住。麻烦在于它的每一次推进都有一份漂亮的数据。

这类改动通常还会走一遍实验流程，常见的A/B测试方案里那三十个方案大多是这么跑的，流程越规范，单看每一步就越挑不出毛病。配套位上移一屏，客单价涨了，数据支持；配套位从四条扩到八条，订单行数涨了，数据支持；把替代位挪进折叠区腾出空间，页面上方的转化没掉，数据支持。三次改动，三份正向数据，没有一次是错的。

掉下去的那部分，落在替代位身上——而替代位的贡献本来就记不到自己名下，所以它掉了多少，报表上不会有任何一行显示。

在一块封闭的预算里，能证明自己收益的那一方会持续侵蚀不能证明的那一方，而且这个过程的每一步都符合理性决策的标准。这不是有人做错了，是记账方式决定的走向。

止损的办法不是讲道理，是设配额

试图靠讲清楚依赖关系来保住替代位，通常撑不过两个季度——道理会被记住，但下一次排优先级的时候，摆在桌上的还是那两个数字。

有效的做法是把它移出竞争：给替代位设一个硬性配额，这个配额不参与和其他模块的效果比较。

具体是三条：

第一，位置配额。替代位在参数区之后必须存在，位置固定，不因为效果数据而下移。要动它，得走一个专门的评审，而不是当成一次常规的版面优化。

第二，条数配额。不少于四条，其中至少一条来自最近九十天内上架的商品，且只按属性相似度选，不看行为数据。这一条是给新品留的入口，理由下一节的复盘会讲得很清楚。

第三，考核配额。替代位的周报只看死路页面率和移交成功率，不列点击后成交额。这一条比前两条更重要——只要那个数字还在报表上，它就迟早会被拿去跟别人比。

顺便解决另一个常见的争论

配套推荐到底该放商品页还是购物车，这个问题经常没有结论。有一个不太被提到的角度可以拿来判断：放在购物车里，它会跟结账这个动作直接竞争。

用户已经决定要结账了，这时候在他面前铺开一排别的商品，最好的结果是他多买一件，比较常见的结果是他退回去继续逛，最差的结果是他关掉页面明天再说。而商品页上不存在这个竞争，因为用户本来就在浏览状态。

所以两边都放并不冲突，但重心应该在商品页。购物车里的那一版要克制得多：条数少、干扰小、绝不遮挡结账按钮，最好也别在那里引入用户没见过的新品类。

不是所有品类都得照这个来

上面这套东西不是普适的，有几类站可以大幅简化，硬套反而是浪费。

服饰配饰类。这个品类基本没有兼容问题，一条裤子不会跟一件衬衫不兼容，所以标签里那些兼容承诺的顾虑不成立，配套推荐的性质从能不能配变成了好不好看。这时候配套关系可以放心用行为数据生成，人工维护的必要性大幅下降。反过来说，替代型推荐在这个品类里格外重要——尺码、颜色、版型任何一项不合适，用户立刻就要看别的。

纯耗材或单一品类站。如果你卖的东西彼此之间既是同类又互为补充（比如各种规格的滤芯），两个位强行拆开反而让用户困惑。这种情况下一个位就够，但标签要写清楚排序依据。

高客单价的单品站。只卖一两款主力产品的品牌站，替代位无处可放，全部精力应该投在配套上。这时候真正的替代位其实在站外——用户会去别的站比较，这一层高客单价独立站靠内容和信任接住用户那篇讲得更透。

判断自己属于哪一类，问一个问题就够：我的品类里，两件商品有没有可能不兼容？答是，就按完整方案做；答否，砍掉一半工作量。

三条该停手的反信号

方案推进过程中，出现下面任何一条都该停下来重新看，而不是继续加码：

第一条，两个位拆开之后，两边的数据一起掉。正常情况下拆开会让替代位的点击率下降、配套位上升，总量持平或略增。如果两边一起掉，多半是拆的时候把总曝光量也砍了，或者新的位置太靠下没人看见。先查曝光，别急着怪拆位这个决定。

第二条，配套关系录了半年，覆盖率还在两成上下。这说明录入这件事在组织里没有真正落地，继续投人只会重复前半年的结果。这时候该退回去改流程——把它绑进上架清单，或者干脆降级到品类粒度，而不是继续催。

第三条，替代位开始被投诉推的都是断货商品。这是相似度算法不看库存的典型症状，也说明这个位已经很久没人维护了。修它只要在候选集上加一个库存过滤，半天的活；但它出现本身是个信号，说明前面说的资源流失已经在发生了。

四周能走完的路径

不用做大改版，按周排：

第一周不改代码，只出三张清单。一张是现状清单（有几个位、叫什么、内容从哪来、谁维护）；一张是死路页面率排名（前两百个页面）；一张是配套关系的覆盖清单（哪些品类有、哪些没有、缺口多大）。这三张表是后面所有决策的依据，也是唯一不能省的一步。把它们串成一条从曝光到成交的完整链路来看，从被看见到成交的全链路路径那套路径图的拆法可以借鉴。第一张表最好连页面底部那些容易被忽略的区域一起盘进去，页脚这个被当成杂物抽屉的区域里提到的那些位置经常也挂着推荐模块。

第二周把两个位拆开。先拆结构，再改标签，数据源跟着一起改，一次上线。这一周的产出是可见的，适合拿去让人相信这件事在推进。整体版面怎么排才不打架，高转化电商站的模块排布那套模块顺序可以拿来对照。

第三周补数据。先做品类对品类的粗关系，覆盖住主要品类；同时把客服那边的问答记录导出来，按频次排，前五十条先录进去。

第四周把指标搭起来。死路页面率和替换率两个先跑，其余的攒基线。到这周结束，你手上会有一套能持续用下去的判断依据，而不是又一次改完就没下文的改版。

三档投入，先看能不能只做第一档

多数站做完最小档就能拿到大部分收益，这跟那些被低估的界面杠杆的分布规律一致——改动最小的那批往往回报最高，因为它们修的是明确的错误，而不是在做优化。

完整档的价值不在于多赚多少，在于它让前两档的成果不会在下一次版面调整里被悄悄抹掉。这个价值不好量化，但凡是经历过一次成果被回滚的人都知道它值多少。

保哥踩过的坑：砍掉一个位之后，报表里没有出现任何负数

方向对、执行对、每一次调整都有数据支持。等发现的时候，账已经记在了三个月后的采购单上。

背景：一个把这套方法完整做了一遍的站

客户是做专业摄影器材的出海站，卖镜头、三脚架、灯光设备和各类相机配件，主要打德法英三个市场，客单价从两百欧到两千欧不等。

改造之前，他们的商品页上只有一个位，标题是相关商品，里面同类镜头和配件混着排，排序依据是一套跑了三年没人动过的相似度规则。

我们做的事跟这篇文章前面讲的完全一致：拆成两个位，替代位放在参数区之后，配套位放在加购按钮下方；标签分别改成同类型号和常搭配的附件；配套关系先做品类级，再从客服问答里补了三百多条商品级的。

头两个季度，所有数字都在往对的方向走

结果比预期还好一些：

• 死路页面率从四成二降到两成八
• 平均订单行数涨了将近两成，主要来自滤镜、快装板、电池手柄这些低单价配件
• 会话内浏览的商品页数下降，说明用户更快找到了想要的
• 整体加购率上升

复盘会上我讲得很笃定：这套方法是对的，数据在四个维度上同时支持。这句话本身没错，问题出在后面那句——既然对，那就继续加码。

第三个季度，一系列都有数据支持的调整

加码是从配套位开始的，因为它的数字实在太漂亮：客单价的提升几乎全记在它头上，投入产出比在所有模块里排第一。

于是三个动作依次发生：配套位从加购按钮下方上移到了参数区之前；条数从四条扩到八条；替代位被挤到了页面更下方，移动端进了折叠区。

每一个动作都做了对照，每一个动作的数据都是正向的。我当时也看过这几份数据，没有提出异议——因为按当时看板上那套指标，反对的理由确实不成立。

第七个月，问题从一个完全没想到的方向冒出来

不是转化率下降，不是投诉增加，也不是退货变多。

是选品那边发来的一句话：最近上的新镜头卖不动，是不是选品方向出了问题。

拉数据一看，确实。近半年上架的新品，动销周期比过去长了一大截，其中镜头和灯光这两个类目最明显。选品那边用的是DTC选品的三角验证那套验证方法，方向本身没问题，问题出在他们拿到的销量信号已经被前端配置扭曲过了。而同期整体销售是正常的——老品和爆款把总数撑住了，所以这件事在大盘上完全看不出来。

第一层：新品被关在了一个闭环里

把新品的流量来源拆开，问题一下就清楚了。

新品上架，没有历史销量，没有共同购买数据，也没有多少浏览记录。配套位是按行为数据生成的，所以它进不去；页面上其他几个位也都或多或少依赖行为数据，同样进不去。它唯一能被看见的地方，是列表页里靠后的位置和站内搜索。

没有曝光，就没有行为数据；没有行为数据，就更进不去推荐位。这是一个自己锁死自己的循环，而新品是被锁在里面的那一方。

那么改造之前它是怎么被看见的？答案很讽刺：靠那个后来被挤进折叠区的替代位。因为替代位是按属性相似度算的——同一个卡口、同一个焦段区间、同一个价格带——它压根不看行为数据。对一件没有任何历史的新品来说，只按属性算的那个位，是它唯一的入口。

我们把它挪走的时候，没人意识到自己顺手关掉了新品的门。

第二层：为什么半年都没人发现

这一层比第一层更值得记。

推荐位的周报是按位分行的，每一行有曝光、点击、点击后成交额。改版后的报表上，配套位那一行的数字一路走高，替代位那一行的数字缓慢下滑——而下滑被解释成了它本来贡献就不高，符合预期。

关键在于：报表上没有任何一行代表被削弱的那部分损失。新品曝光量的下降不在推荐位报表里，它在另一张选品的表上，两张表从来没人放在一起看过。

而更根本的是记账方式本身：报表只会给存在的东西留一行。你削弱或者砍掉的那个模块，不会在报表里留下一个负数，它留下的是一片空白，而空白在任何一张报表上读起来，都跟一切正常一模一样。

第三层：最贵的代价落在了三个月之后

如果故事停在这儿，损失是一批新品卖得慢，补救起来不算难。真正贵的部分在后面。

选品团队看到的是一串真实的数字：这两个新品线的动销明显低于预期。他们据此做了一个完全合理的决定——砍掉其中两条线的补货计划，把预算调去老品。

这个决定是不可逆的。供应商那边的排产改了，季度的采购计划改了，等三个月后我们搞清楚原因，那批货已经不在计划里了。这类需求预测本来就难，用搜索需求做趋势预测那篇讲的趋势预测方法能提前一点，但它同样依赖干净的销量信号。

前端的曝光配置会通过销量数据反向写进采购决策。你调整一个推荐位的时候，实际上是在给三个月之后的采购单投票，只是当时没有人告诉你这一票投了出去。

这一层的损失至今算不清楚。被砍掉的那两条线后来在别的渠道卖得不错，但那是别人家的数据，只能当个参考。

回头查，最早的信号其实出现过一次

整改的时候我们做了一件事：把过去半年的客服记录翻了一遍，看有没有更早的迹象。

有。第四个月的时候，客服提过一次，说有用户来问某款新出的镜头在站上怎么找不到，明明看到过上新的推送。当时这条被记成了一次搜索问题，回复用户一个直达链接就结了，没人往上报。

现在回头看，那就是第一声。但它当时不可能被听见，原因很实在：它是一句话，而桌上摆着的是四份指标都在涨的报表。一条孤立的定性信号，在一张量化报表面前是没有立足之地的——而这类问题在早期，恰恰只能以定性信号的形式出现。

这件事没有完美的解法，但有一个成本很低的做法：给客服记录加一个标签，专门标记那些找不到、看不到、以为没有的咨询，每月看一次数量趋势。不需要人工分析每一条，只看这一类的条数有没有异常抬头。

这个做法的价值不在于它准，在于它把一类本来会被逐条消化掉的信号攒成了一个数。用代理信号去补那些后台里看不见的部分是同一个思路：真信号拿不到的时候，退而求其次去数它的影子，比什么都不数强得多。

改了三处，其中一处是给报表加行

第一处，替代位的考核指标换掉。周报里删掉它的点击后成交额，换成死路页面率和新品曝光覆盖率两个数。删掉那一行的时候有人反对，理由是这样就没法评估它的价值了——这句话恰恰是问题本身，那个数字从来就没有在评估它的价值。

第二处，加硬性配额。替代位固定不少于四条，其中至少一条必须来自最近九十天内上架的商品，选取规则只看属性相似度，不看任何行为数据。这一条不参与效果比较，改动需要单独评审。

第三处，报表里加一行：当前在售但未被任何推荐位覆盖过的SKU数。这一行的作用不是驱动决策，是把那片空白变成一个能被数出来的数字。上线第一天这个数是一千两百多，占在售SKU的三成出头，看到的人都愣了一下。

结果，以及一句没那么好听的总结

整改期间还顺手把退货原因的分类细化了一轮，退款退货流程里的原因归集那套流程里的原因字段正好能用来沉淀这类关系数据。两个季度之后，新品动销周期回到了改造之前的水平并略好一些；长尾SKU的曝光覆盖率从六成七回到八成八；客单价的提升守住了大部分，掉的那一点来自配套位条数从八条压回六条。

还有一个意外收获：那行未被覆盖SKU数变成了选品和运营之间的共同语言。以前选品说这批货没曝光，运营说数据不支持推它，两边各执一词；现在这句话有了一个具体的数字，吵架变成了排期。预算与归因的跨部门对账里也强调过同一件事：跨团队的争论多半不是立场问题，是缺一个双方都认的数。

但有件事我得说清楚：整改之后，替代位在报表上的数字依然很难看，而且它永远会很难看。它的活就是把用户交出去，交出去这个动作在任何一套按成交结算的账本里都不产生收入。

我们花了七个月才明白这件事。在那之前，我们一直拿一把量收入的尺子去量一个不产生收入的模块，量了很久，然后按量出来的结果把它挪到了折叠区——而每一步，都有数据支持。

常见问题解答

就做一个推荐位不行吗，非得拆成两个？

能不能只做一个，取决于你的品类里两件商品有没有可能不兼容。答否的话，比如服饰、家居软装这一类，一个位配一个说得清的标签是够用的。答是的话，一个位迟早要出事，因为用户会把里面所有东西都默认成跟主商品配套，包括那些其实只是同类替代品的。

另外一个判断角度是看你的死路页面率。如果超过四成，说明大量用户在商品页上走进了死胡同，这时候替代型推荐是刚需，必须有自己的位置，不能跟配件挤在一起被挤到看不见。反过来如果死路率只有两成出头而客单价上不去，那说明你缺的是配套那一侧，重心该放在补关系数据上。

还有一种中间做法可以过渡：先不拆位置，只把同一个位里的商品按类型分组排列，中间加一条分隔和两个小标题，成本极低，能先把用户的误解挡掉一大半，等验证有效再动结构。独立站优化的十二步清单里也提过这类低成本改动的共同特点：改的是明确的错误，所以基本不会亏。

替换率算出来九成，是不是说明这个位没什么价值？

恰恰相反，九成说明它在正常工作。替代型推荐的本职就是让用户换一件买，不是让他多买一件，替换率高只是把这个事实量化了。

真正要看的是另一个数：这些用户如果没有点这条推荐，会去哪里。拿同一批商品页上没点过推荐就离站的会话做对照，两组的加购率差多少，那个差值才是它创造的东西。九成替换率加上明显高于对照组的加购率，是这个位最健康的样子。如果替换率九成而加购率跟对照组没差别，那才是真的白占地方，该查的是推过去的商品是不是跟原来那件差不多，用户换了个页面还是没解决问题。顺便说一句，这个数第一次跑出来之后最好提前跟看报表的人打个招呼，因为它会把过去那个漂亮数字拉回真实水位，不解释一下容易被当成效果变差。

几万个SKU的配套关系，怎么可能录得完？

不用录完，这是个常见的误解。先做品类对品类，相机配存储卡、包、三脚架这三个品类，一条规则覆盖几百个SKU，一天能配完主要品类。粒度粗，但它解决的是最要紧的那件事——让用户知道你还卖这些、并且有条路能走过去，而这本来就比推对某一件具体配件更重要。

商品级的关系只做两类：一是必需部件，缺了主商品就用不了的那些，这类漏了会直接产生退货和差评；二是客服问得最多的那几十条，导出咨询记录按频次排，前五十条录进去就能覆盖大部分咨询量。剩下的长尾可以永远不做，或者等有人来问了再补。把目标从做完改成覆盖住高频，这件事就从做不完变成了两周能干完。还有一条省力的路子经常被忘掉：有兼容要求的品类，供应商手里多半已经有一张对照表，要过来做一次值域清洗和抽样核对，比从零开始建便宜一个数量级。

推荐位是第三方服务提供的，我改不了怎么办？

三件事你还是能做，而且都不需要动那个服务。

第一件是改标签。标签几乎总是在你自己的模板里，换个说法的成本是一次发版，而这恰恰是承诺强度最要紧的那一环。第二件是加一组静态的品类链接放在初始HTML里，跟第三方那个位并存，机器至少能读到品类关系，用户也多一条路。第三件是把替换率和死路页面率自己算出来——这两个数只需要订单数据和页面浏览序列，跟推荐位由谁提供毫无关系。

三件事做完，你手上就有了跟服务商谈判的材料，而不是只能接受对方给的那份报表。谈的时候把诉求说具体：能不能按类型输出两组结果、能不能给一个只按属性算的候选集，这类要求多数服务商是支持的，只是默认不开。

商品页上的推荐条数，多少算合适？

比条数更重要的是可见性。桌面端一排四到六条、移动端一屏能看到两条到两条半是比较稳的起点，关键是别让用户需要横向滑很久才看得完——滑到第三屏的那些商品，曝光量通常只有第一屏的零头，而它们仍然占着你的维护成本。

如果非要在两个位之间分配，我的经验是替代位不少于四条、配套位四到六条。替代位少于四条时用户几乎感觉不到有得可选，等于没做；配套位超过八条会开始稀释注意力，而且往往是因为关系数据不够精准才用数量去凑。另外提醒一句，条数是最容易在版面调整里被悄悄改动的参数，最好把下限写进规范，否则半年后你会发现它变成了两条，而且没有任何一次改动的记录能说清是谁在什么时候改的。

卖到欧盟的话，推荐位上有没有必须披露的东西？

如果你是自营站、卖自己的货、推荐位里没有任何付费成分，那么欧盟消费者法里那两条关于排名披露的硬要求大概率不落在你头上——它们的适用范围被限定在响应消费者搜索查询而给出的结果，商品页上的推荐位不属于这一类。数字服务法里的推荐系统透明度义务也不适用，因为它的主语是线上平台，而自营品牌站不落在那个定义里。

但有三种情况会让结论翻转，值得逐条核对：推荐位里有付费成分或商务置顶、站上引入了第三方卖家、以及推荐内容实际由站内搜索接口驱动。任何一条成立，都建议找法务过一遍。另外即便都不成立，误导性遗漏那条通用条款始终适用，所以有付费成分就标出来、别用一句为你推荐去包装一个按利润率排的位，这两条按体验标准也该做。值得留意的是排名这个词在欧盟的定义相当宽，指的是交易者给予商品的相对显著性、不论技术手段，所以别用我们这不是排序来自我安慰。

新品什么数据都没有，怎么让它出现在推荐位里？

靠属性，不靠行为。这条路的前提是属性本身建得规整，可配置商品的属性与库存矩阵那篇讲的变体与属性矩阵是它的地基。这是新品唯一能走的路——相似的规格、相近的价格带、同一个品类分支，这些属性在上架那一刻就齐了，不需要等任何人来点击。

具体做法是给替代位设一条硬性配额：每次展示的商品里，至少有一条来自最近九十天内上架的商品，选取只按属性相似度，完全不参与行为数据的排序竞争。这一条看起来像是牺牲了一点点效率，实际上它打破的是一个死循环——没曝光就没数据、没数据就更没曝光。缺了这条通路，你的新品要么靠站外投放硬推，要么就在列表页深处躺到下架，而后者在报表上什么痕迹都不会留下。想验证自己站上有没有这个问题，可以算一个数：当前在售但从来没有在任何推荐位里出现过的SKU有多少个，第一次算出来的结果通常会让人坐直身子。

权威参考资料