用户扫完一整屏商品一个都没点开,这件事在你的报表里等于没发生
本文目录
- 用户扫过去没点开那一下,为什么在你的后台里不留痕迹?
- 被记录下来的,全是用户做过的事
- 这类失败不是没埋点,是原理上不产生记录
- 沉默拒绝的三种形态,报表里长得一模一样
- 永久原语:数据驱动的组织对沉默的失败有结构性盲区
- 行业基准里那个50%说明什么
- 还有一层:机器看不到的那部分连跳过都不会发生
- 不展开的三条边界
- 哪五样东西一旦缺席,用户宁可跳过也不愿点进去确认?
- 先把标准立对:不是重要,是缺了会被主动回避
- 一张比清单更有用的表:缺失时用户拿什么代替推断
- 价格:不是要不要显示,是不能有条件地显示
- 名称:型号名不是名称,品类词才是
- 名称的第二个问题:它是全站被复用最狠的一个字段
- 缩略图:唯一一个缺了就等于不存在的属性
- 评分与评价数:DTC站的例外,以及这个例外的代价
- 变体:默认款不合适,用户否掉的是整个款式
- 品类专属的那一两条参数,凭什么判定它该不该进列表项?
- 四类品类属性,覆盖了绝大多数场景
- 技术规格:关键不在参数多,在于配不配得上
- 尺寸与容量:凡是要装进某个空间的,都得写
- 适用人群:买的人不是用的人,属性就得当导购用
- 场景适用性:用户不敢赌的那一格
- 怎么找到自己类目的那两三条?四个来源,都不用做用户调研
- 三个类目的推演结果,看一眼就懂差在哪
- 促销角标也在抢同一块地,且它通常抢赢
- 上限是一到三条,不是越多越好
- 列表项那点地方是个固定预算,被挤掉的到底是什么?
- 三个数字互相咬死,动一个必然动另外两个
- 被挤掉的那个,通常没人记账
- 视觉分层:同一块地方,其实能放下更多
- 截断点治理:决定性信息必须在截断之前
- 桌面端可以延后,移动端只能取舍
- 图片这一格其实也是可以扩容的
- 属性别做成纯图标,尤其是多市场的站
- 一张预算表,评审的时候摊在桌上
- 同样是没写,用户为什么会把它读成没有?
- 空着的那一格,用户读到的不是空
- 参差比缺失更糟,因为它诱发归纳
- 覆盖率闸门:低于阈值就整个类目别上
- 覆盖率必须按能被读懂的值统计,不是按非空
- 值域没统一,等于写了也白写
- 缺值还有第二个受害者,而且它连曝光都没有
- 补数据这件事,得从入库那一端卡
- 空值到底怎么渲染?三种做法,各有代价
- 哪几条属性其实轮不到你决定要不要显示?
- 四部互不相干的法规,说了几乎同一句话
- 产品安全条例:连图片都是法定必需项
- 玩具指令:法条用的判据,和本文第三节一模一样
- 纺织品条例:法条里直接点名了目录
- 能效标签:不是提一句,是要把那张标签挂出来
- 四条并排看,形状就出来了
- 这块地的边界在这几年里刚被挪过一次
- 落地:必显项要做成上架阻断,不是运营提醒
- 同一个属性在页面上、在feed里、在结构化数据里,为什么不是同一个东西?
- 同一份数据,三个出口,三拨人维护
- feed这一侧:一百多个属性,真正必填的只有七个
- 一个很能说明问题的字段:能效等级
- 结构化数据这一侧:评分只是推荐项
- 列表本身这一层,规范里几乎是空的
- 被机器读走的那份清单,就是它给出的那个答案
- 三张表叠起来,缺口就藏不住了
- 那些看不见的损失,能不能换算成表里真有的数字?
- 思路:抓不到那个事件,就去抓它的影子
- 指标一:折返率
- 指标二:属性补偿点击占比
- 这就引出了那条最容易搞反的结论
- 指标三:零点击扫视深度
- 三个指标怎么配着用
- 第四个可选项:按商品维度看零点击
- 把这些数字折算成钱,立项才立得住
- 还有一个更笨但很有效的办法
- 为什么把一个属性藏起来,比把它加上去便宜一个数量级?
- 加法实验贵在哪:它的成本大头不在实验
- 减法实验:把已经有的那个藏起来
- 两种实验并排比一比
- 具体怎么跑,六条就够
- 三条禁忌,碰了就别做
- 结论怎么用:排出一张边际价值表
- 四周路径:第一周一行代码都不用改
- 三档投入,最小那档能吃掉大半收益
- 减法实验测不到的那部分,用另外两条路补
- 保哥踩过的坑:一个字段被搬到决策位之后
- 背景:一个折返率高得离谱的工具站
- 头几个月:全绿,而且我把点击率下降解释对了
- 第七个月:出问题的地方不在转化,在退货
- 第一层:名义覆盖率96%,真实覆盖率63%
- 第二层:不只是缺,还有一批是错的
- 第三层,也是最贵的那一层
- 改了三处,两处是闸门,一处是渲染
- 结果,以及那笔算不清的账
- 常见问题解答
- 列表项上到底放几个属性才算够?
- 改版之后列表页点击率掉了,是不是做砸了?
- 属性数据只有六七成覆盖率,是先上线还是先补数据?
- 卖到欧盟的话,列表页上有哪些信息是法律强制的?
- 商品feed里的必填字段和页面显示的字段要保持一致吗?
- 减法实验会让部分用户体验变差,有没有更稳妥的替代?
- DTC品牌站没多少评价,评分那一格该怎么办?
- 权威参考资料
摘要:用户在列表页扫过一排商品、一个都没点开,这件事在你的后台里没有任何一条记录与之对应。它不是点击,不是工单,不是退货,也不是差评——它在所有报表里的取值都是零。可它偏偏是列表项信息不足最主要的代价形式。这篇文章讲的不是“列表项该放几个字段”这种排版题,而是:为什么这类损失在原理上不产生数据,它会怎样系统性地把这件事排到需求池的最后一名,以及有哪三个不用新埋点就能算出来的影子指标、还有一种比常规实验便宜一个数量级的验证办法,能把这块看不见的东西拽回到表里来。
用户扫过去没点开那一下,为什么在你的后台里不留痕迹?
能被记下来的全是他做过的事。他因为看不到一行参数而放弃的那件商品,没有点击、没有工单、没有退货,在所有报表里的取值都是零。
被记录下来的,全是用户做过的事
先说一个不太舒服的事实。
你的分析工具、你的埋点、你的数据仓库,本质上都是一台事件记录器。它记的是发生了什么:一次曝光、一次点击、一次加购、一次下单、一次退款。每一条记录背后都有一个动作,动作发生了,记录才存在。
可用户在列表页上做的最关键的那个判断,恰恰不是一个动作。
他扫过一排卡片,其中有一件其实完全符合他要的东西,只是卡片上没写尺寸,也没写这一款有没有别的颜色。他犹豫了半秒,跳过了。接下来他点开了旁边那件写得更全的,看了看,觉得一般,退回来,又扫了两屏,关掉页面。
在这一整段过程里,那件被跳过的商品,产生的数据是:一次曝光。
就这样。它和“用户看见了、不喜欢、跳过了”产生的数据一模一样,和“用户压根没扫到那个位置”也几乎分不出来。你手上没有任何一列能把这三种情况区分开。
这类失败不是没埋点,是原理上不产生记录
很多人第一反应是:那就补埋点。
补不了。这里的问题不在采集精度,而在事件本身的性质。用户因为信息不足而放弃一件商品,这个行为在浏览器里没有对应的交互——没有点击、没有悬停、没有滚动到某个阈值、没有任何一个能被监听的信号。他甚至可能连眼睛都没在那张卡片上多停。
我把这类失败叫作沉默拒绝:结果确实发生了,代价确实付出了,但过程不留痕迹。
与之对照的是那些吵闹的失败。支付失败会留下一条被拒的授权记录;报错文案写得不清楚,用户会填错三次然后发工单;商品页描述有误导,会变成退货。这些失败都自带一个可以被计数的载体,所以它们进得了报表,也就进得了周会。退货甚至有专门的台账与流程,退款与退货的完整处理链路在系统里被拆得很细,每一步都留痕。
沉默拒绝没有载体。它唯一的表现形式是某个数字比它本来应该有的样子小了一点,而“本来应该有的样子”这个基准,你手上没有。
沉默拒绝的三种形态,报表里长得一模一样
把它拆细一点会更好办。用户在列表页上“没点开”这个结果,至少对应三件完全不同的事。
| 形态 | 用户当时在想什么 | 你的报表里长什么样 | 补埋点能不能解决 |
|---|---|---|---|
| 信息缺口型跳过 | 看不出这一款是不是我要的,懒得点进去试 | 一次曝光,零点击 | 不能,浏览器里没有对应交互 |
| 误判型跳过 | 卡片上写的那点信息让我判断它不合适,其实它合适 | 一次曝光,零点击 | 不能,且比上一种更冤 |
| 真实不感兴趣 | 看清楚了,确实不要 | 一次曝光,零点击 | 不需要解决,这是正确结果 |
三行数据完全一致,业务含义天差地别。第三行是列表页在正常工作,前两行是它在漏钱。
更麻烦的是第二种。它连“用户没获得信息”都不算——用户获得了信息,只是那点信息不够,于是他基于一个残缺的画面做出了完整的判断。这种误判在测试里能看得很清楚,因为有人坐在旁边看着;在生产环境里,它和“不喜欢”永远长着同一张脸。
永久原语:数据驱动的组织对沉默的失败有结构性盲区
这条推论比上面那些具体现象值钱。
所有排优先级的方法——RICE、影响面估算、按工单量排、按流失金额排——都建立在同一个前提上:问题的严重程度可以被量化。而量化依赖可观测量。
于是就出现了一个很尴尬的循环:一个问题被长期忽视,往往不是因为它不重要,而是因为它在你的观测系统里没有阳性样本。这几年最典型的例子是零点击时代的归因——生意明明来了,后台却一片空白,处理办法只能是找代理信号。越是数据驱动的团队,这个循环闭合得越紧——因为大家都很自律,谁也不肯凭感觉排需求。
这也是我要在开头就把话说透的原因。列表项该显示什么,这个话题在绝大多数公司里躺在需求池的下半区,不是因为有人论证过它不重要,而是因为从来没有人能把它的收益算出来。砍掉虚荣指标、定准北极星指标这类工作解决的是“盯错了数字”,而这里的麻烦更靠前一步:该盯的那个数字压根不存在。
行业基准里那个50%说明什么
Baymard Institute在关于列表项信息的大规模测试里给出过一个数字:受测的电商站里有50%没有把列表项的信息配到位,导致用户漏掉本来相关的商品,甚至因此离站。
这个比例本身不算惊人,惊人的是它的分布方式。它不是集中在几个小作坊站上,而是横着铺开的——一半,意味着这里面有大量投入不菲、有专职数据团队、有完整实验平台的站。
换个角度想就通了:如果这类损失能被看见,一半的站不可能同时在同一件事上栽跟头。能被看见的问题会被修掉,修不掉的是那些看不见的。这个50%与其说是在描述设计水平,不如说是在描述观测能力的边界。
同一家机构在2025年更新的产品列表基准里,把这个边界描得更清楚:桌面端有58%的站在产品列表体验上处于“较差到平庸”的区间,移动端这个数字是78%。移动端更糟不奇怪,屏幕小,每张卡片能放的东西更少,取舍更狠。
还有一层:机器看不到的那部分连跳过都不会发生
上面说的都是人。列表页还有第二类读者,它比人更不宽容。
购物类的自动比价、垂直导购、以及现在越来越多用户直接张嘴问的那些助手,读的不是你的卡片布局,是结构化的字段。人看不到一个属性,至少还会犹豫一下、有一定概率点进去确认;机器读不到一个属性,等于这件商品在那次筛选里不具备这个维度,它连被比较的资格都没有。
换句话说,在人那里沉默拒绝好歹还有一个“跳过”的动作,在机器那里连这个动作都不存在——它是在候选集生成阶段就被漏掉的。这是同一个问题的第二次不可观测,而且更彻底。这条线我在集合页在AI购物时代的角色那篇里展开过,本文第七节会回到字段层面接着谈。
不展开的三条边界
为了不把话题摊成一张大饼,这里先划三条线。
第一条,本文不谈筛选与排序。筛选解决的是“把不相关的挑出去”,列表项信息解决的是“挑剩下的这些我该点哪个”,两者作用在不同环节。筛选器的URL治理与抓取预算问题我在电商导航SEO的系统方案里单独写过,那是另一条线上的事。
第二条,本文不谈变体的URL与索引策略。同一款商品的几十个变体该合并成一个URL还是拆开,这是收录侧的问题,我在WooCommerce变体的三层治理与Magento可配置商品的库存矩阵里分别拆过。本文只关心一件事:变体这个事实要不要出现在卡片上、以什么形式出现。
第三条,本文不谈类目页本身的SEO价值。集合页凭什么被单独收录、冷启动怎么做,这些在电商类目页SEO的机制拆解里有完整答案。本文站在页面已经有流量之后,只问进来的人在这一屏上能不能做出判断。至于分类页的分页方案与无限滚动的机制取舍,同样不在本文范围内。
哪五样东西一旦缺席,用户宁可跳过也不愿点进去确认?
大规模测试挑出来的五项不是按重要性排的,是按缺了它会不会被主动回避排的。回避这个动作,比不喜欢难挽回得多。
先把标准立对:不是重要,是缺了会被主动回避
关于列表项该放什么,市面上的清单一抓一大把,问题出在排序依据。
大部分清单是按“用户觉得重要”排的,而这个口径靠问卷得来,问卷里人人都说什么都重要。真正能指导取舍的是另一个口径:缺了它,用户会不会主动回避这件商品。
回避比不喜欢严重得多。不喜欢是看完之后的结论,回避是看之前就把它排除了;前者你还有机会靠详情页翻盘,后者连翻盘的入口都没打开。Baymard的测试里挑出来的五项,用的正是回避这个口径——受测者会主动绕开缺少这几项的商品。
五项分别是:价格、商品名称或品类词、缩略图、用户评分均值与评价条数、变体。测试同时给出一个不太好看的比例:约有35%的站没能把这五样配齐。
一张比清单更有用的表:缺失时用户拿什么代替推断
我在给客户过这一节的时候,从来不直接给五项清单,而是给下面这张表。原因很简单:清单只能让人点头,这张表能让人吵起来——而吵起来才会改。
| 属性 | 它替用户回答的问题 | 缺失时用户拿什么代替推断 | 推断的错误方向 |
|---|---|---|---|
| 价格 | 这东西在不在我的预算里 | 用品牌与图片猜档次 | 猜贵了直接跳过,猜便宜了点进去后失望 |
| 名称或品类词 | 这到底是个什么东西 | 只看图,靠形状认 | 把配件认成主机,把套装认成单件 |
| 缩略图 | 它长什么样、是不是我要的那一类 | 没得推断,直接当成信息不全 | 整条列表项被视为不完整而忽略 |
| 评分与评价条数 | 别人买过之后是什么反应 | 去站外搜,或者只挑有分的那几个看 | 离站,且不保证回来 |
| 变体 | 还有没有别的颜色、尺寸、材质 | 看默认那一个,或者从价格区间倒着猜 | 因为默认款不合适而否掉整个款式 |
这张表的第四列才是重点。缺一个属性造成的不是“信息少了一点”,而是“用户用一个错误的替代物把它补上了”,而替代物的偏差方向是可以预判的,几乎每一条都指向少卖一件。
价格:不是要不要显示,是不能有条件地显示
价格这一项,绝大多数站是过关的。少数不过关的往往不是忘了放,而是主动藏了——最常见的写法是加入购物车之后再看价。
受测者对这种设计的反应相当直白:不理解为什么一个钱包的价格需要保密,然后转头去点旁边那个明码标价的。做这种设计通常有它的商业理由,比如渠道价格约束,但这些理由是你的,不是用户的,他不会替你分担。价格规则本身怎么配才不打架,目录与购物车两层价格规则那篇里有完整的取舍。
还有一种半藏:只在促销位显示价格,普通列表位不显示;或者会员价要登录才可见,未登录状态下那一格是空的。这类实现的效果和完全不显示接近,因为用户在扫视时并不会为你的价格策略停下来做阅读理解。
名称:型号名不是名称,品类词才是
名称这一项容易被误判成已经做到了。你的数据库里当然有商品名,问题在于那个名字对陌生人说不说得通。
家居家装类是重灾区。系列名往往是一串没有语义的专名,用户扫过去只会得到一个印象:这是个词。真正让人看懂的是后面那个品类词——三人位沙发、双门冰箱、直角书桌。国际化家居品牌把系列名与品类词并排放,正是这个道理。
名称里那些反复出现的特征词还有额外的价值,属性共现对品牌实体的作用那篇讲的就是这层机制。反过来,护肤、3C这类,名称本身带功效或规格的,可读性就高得多。用户看到视黄醇这三个字,立刻知道它对应哪个诉求,不需要再点进去确认。
所以判据不是“有没有名称”,而是这条名称在没有上下文的情况下能不能被识别。目录规模大、品类杂的站,逐条人工判断不现实,稳妥做法是名称与品类词都放,让品类词兜底。
名称的第二个问题:它是全站被复用最狠的一个字段
这一点很少有人当回事。
商品名称这一个字段,同时出现在列表项、搜索结果页、购物车行、订单邮件、导出的对账表、投放的商品广告、以及各类比价与导购的抓取结果里。改它一次,牵动的下游比任何其他字段都多,而每个下游的截断长度都不一样。
这就带来一个常被忽略的约束:名称必须做到前若干个字符自足。把决定性的信息塞在名称末尾,在商品页上看着没事,到了移动端列表项、到了广告标题、到了搜索结果的截断位置上,那部分就集体消失了。像素级的截断预览工具能帮你看清这件事,我在SERP模拟器的用法那篇里讲过怎么按像素而不是按字数判断截断点。
测试里还有一条经验值得记:移动端的商品名称不宜超过三到四行,超过之后用户不再把它当成名称,而是当成一段描述,扫视时会整体跳过。名称写得越全越好这条直觉,在这里是失效的。
缩略图:唯一一个缺了就等于不存在的属性
缩略图的特殊之处在于,它不是“少一个信息”,而是“整条列表项作废”。
测试里反复出现同一个反应:没有图的那一条被判定为不完整,然后被整条跳过,用户甚至不会去读它旁边的文字。旅行住宿类的测试里有个很典型的画面,受测者一边笑一边略过一间没有配图的房型,那间房其实价格更合适。
这条对运营的含义是:缺图的SKU不该出现在列表里。与其让它带着一个灰色占位框站在那儿拉低整屏的观感,不如临时把它排到最后,或者干脆在补图之前不上架。图片这一侧的基础功课也别落下,从命名到压缩的图片清单与alt文字的写法边界都属于一次配好就长期受益的那类。至于缩略图本身该怎么选、机器又是按什么规则决定抓哪一张,我在Google缩略图的三大元数据里单独拆过。
评分与评价数:DTC站的例外,以及这个例外的代价
评分这一项,在综合电商与大型零售那边是刚需——大规模测试里高达九成五的用户依赖站内评价来评估商品。缺了它,用户会去站外找,而这一去就有相当一部分不回来了。
DTC品牌站是个例外。同一家机构针对DTC场景的研究给出过更细的结论:这类站的站内评价没那么关键,因为用户对一个陌生品牌本来就不太采信它自己页面上的分数。
但这个例外不是免死金牌,它的代价被写在同一份研究里:测试中有62%的DTC用户表示,在一个不熟悉的品牌上下单之前,他们会自己去做一轮调研、去找第三方或站外的评价;而在测试过程中真的中途离站去找信息的,占到29%。
所以准确的表述不是“DTC站不需要评分”,而是DTC站的评分环节被外包出去了。外包的意思是这一步你管不着,也看不见——又是一次沉默拒绝。真正该做的是把那些用户离站去找的东西,尽量以可信的形式提前放在自己这边,而不是把这一格空着当成省事。做外贸B2B的同行对这件事体会更深,图片越假信任越低讲的是同一个道理的视觉版本。
变体:默认款不合适,用户否掉的是整个款式
变体是五项里最容易被漏的,因为它在数据结构上不属于单个商品,而属于商品组。
测试里的典型场景是这样的:一款炒锅有三个尺寸,列表项只展示了默认那一个,也没有任何提示说还有别的规格。用户量了一下自己的灶台,判定这口锅太大,跳过。他要的那个尺寸就在里面,他不知道。
价格区间那种写法(比如从多少钱起)确实能暗示存在多个规格,但它有两个毛病:一是用户得替你做推理,二是它说不清变的是哪一维——变的是尺寸、颜色,还是材质?一屏几十上百条都让人这么猜,成本太高。
反过来也有该省的。服装的尺码就不必在列表项里罗列,因为用户默认衣服本来就有码;而书桌的尺寸必须写,因为家具不一定有多个尺寸可选。判据是:这一维的变体是不是用户能凭常识默认它存在。能默认的就别占地方,不能默认的必须明示。
品类专属的那一两条参数,凭什么判定它该不该进列表项?
不是把规格表搬上来。判据只有一条:它能不能改变点开还是跳过这个决定。找它的地方也不在竞品页面上,在你自己的后台。
四类品类属性,覆盖了绝大多数场景
五项通用属性配齐之后,接下来的一到三条才是拉开差距的地方。它们是品类专属的,换个类目就完全不一样。
把大量测试样本归拢之后,这一到三条基本落在四个筐里。
| 类型 | 它回答的问题 | 典型品类 | 没有它会怎样 |
|---|---|---|---|
| 技术规格 | 参数够不够、跟我手上的东西配不配 | 笔记本、影音、配件、工具 | 被迫逐个点开比参数,效率崩塌 |
| 尺寸与容量 | 装不装得下、放不放得进去 | 家具、家电、箱包、厨具 | 用户量完自家空间之后无从判断 |
| 适用人群 | 合不合适我要送的那个人 | 玩具、母婴、礼品、珠宝 | 买错对象,且往往到收货才发现 |
| 场景适用性 | 在我要用的环境里能不能顶住 | 户外、运动、劳保、涉水设备 | 宁可不买,也不敢赌 |
基准数据上,这一块的达标率比通用五项高一些:大约15%的站完全没有配品类专属属性。听着不多,但这15%通常集中在规格驱动型的类目里,也就是最需要它的那批。这类类目往往也是红海里靠差异化突围最吃力的地方,参数说不清楚,差异化就无从谈起。
技术规格:关键不在参数多,在于配不配得上
规格驱动的品类里,用户在列表页真正比的往往只有两三个数。买笔记本时是屏幕尺寸与硬盘容量,买充电器时是功率与接口。
这里有一个容易被忽略的子类:兼容性。找笔记本电源、找相机电池、找滤芯这类需求,用户要判断的不是好不好,而是配不配得上。兼容信息不在列表项里,他就只能一个个点开翻规格表,翻到第四个的时候基本上就换个站了。
英国那家大型综合零售的测试里有个很小的细节:受测者在列表项上看到电池续航时长,当场就说了句这个续航不错,然后把这一款放进了候选。她没有点开商品页——这就是品类专属属性最理想的工作状态:它替商品页省掉了一次访问,而不是引诱一次访问。
尺寸与容量:凡是要装进某个空间的,都得写
尺寸这一类的判据比较好记,分两种情况。
第一种,商品本身要装东西。箱包、收纳、锅具、机箱这类,用户关心的常常是内部尺寸而不是外部尺寸,而绝大多数站只写外部尺寸。这个差别在书桌抽屉那种场景下不算大,在装乐器、装笔记本那种场景下就是买不买的分界线。
第二种,商品要被装进某个空间。冰箱、沙发、床、洗碗机,用户在动手之前已经拿卷尺量过自家的位置,他在列表页上要做的就是拿那三个数去对。对不上就跳过,对得上才点开。测试里有人在圣诞树的列表项上一眼读到六英尺预装灯这几个字,直接完成了比较,这就是尺寸写在卡片上的价值。
容量同理。八夸脱的汤锅这种信息,写在列表项里能让人当场判断够不够一家人用;写在商品页第三屏的规格表里,等于没写。
适用人群:买的人不是用的人,属性就得当导购用
这一类的共同特征是,付钱的人和使用的人不是同一个。
玩具最典型。列表项上标着适合六岁及以上,等于替一个不知道该给侄子买什么的舅舅做完了第一轮筛选。珠宝按赠送对象分、礼品按场合分,也是同一个逻辑。这类属性几乎可以当成一份嵌在列表里的导购手册用,它的作用不只是描述商品,是在替用户缩小范围。
顺带说一句,适用人群这一类在部分市场不是可选项,是法定必须在购买前可见的东西。这一层我放在第六节讲,因为它会改变整件事的性质。
场景适用性:用户不敢赌的那一格
第四类针对的是在特定条件下工作的商品:户外、涉水、高温、承重、防护。
音响品类里那个防水等级标注是很好的例子。便携蓝牙音箱的列表项上写着防水等级,用户就能在列表页判断这台能不能带去泳池边;不写,他要么点进去查,要么直接换一款敢写的。
这类属性有个特点:缺失时用户的默认假设是保守的。他不会假设这台音箱大概也防水,他会假设它不防水。所以在这类品类里,不写等于写了一个否定值,而且是你自己写下去的。
怎么找到自己类目的那两三条?四个来源,都不用做用户调研
这一节是我给客户过方案时被问得最多的地方:道理都懂,我怎么知道我这个类目该选哪两三条。
答案不在竞品页面上,在你自己后台的四个地方。
| 来源 | 怎么取数 | 能得出什么 | 局限 |
|---|---|---|---|
| 站内搜索词 | 导出高频查询,按是否含属性词分桶 | 用户主动打出来的维度,可信度最高 | 只覆盖会用搜索框的那部分人 |
| 筛选器使用率 | 统计每个筛选维度被点开与被选中的次数 | 用户愿意花力气去筛的维度 | 只能看到你已经提供的维度 |
| 售前咨询问题 | 抓最近三个月的会话,按问题类型打标 | 页面没说清的东西,一条一条摆着 | 肯问的人是少数,量偏小,可参考选品三角验证的做法交叉印证 |
| 退货原因 | 取与预期不符那一类,按品类拆 | 判断失误的实际后果,金额可直接算 | 滞后,且只反映买了之后才发现的 |
四个来源里,前两个反映决策过程,后两个反映决策失误。四份名单交出来之后,重叠部分基本就是答案——出现在两个以上来源里的属性,几乎不会选错。
这套做法的好处是当天就能出结果,不用排用户研究的档期。站内搜索词那一路还有个附带收获:它顺手能喂给搜索需求建模,让选词和选属性用上同一份原始材料。至于取数环节怎么落到具体报表上,可以对照SEO数据分析的指标体系与异常诊断那一套,把口径先定死再取,免得三个人跑出三个数。
三个类目的推演结果,看一眼就懂差在哪
抽象讲总是显得轻巧,举三个真做过的类目对照一下。
| 类目 | 四个来源里重叠出来的维度 | 最终进卡片的属性 | 被否掉的候选与理由 |
|---|---|---|---|
| 户外照明 | 亮度、供电方式、防水 | 流明数、太阳能或接电、防护等级 | 色温:咨询里问得多,但退货原因里几乎不出现 |
| 宠物主粮 | 适用体型、主要蛋白源、规格重量 | 适用体型、蛋白源 | 规格重量:已经能从单位价格那一行读到 |
| 办公椅 | 承重、可调节项、材质 | 承重上限、扶手是否可调 | 材质:图片已经说清楚了,文字重复 |
三行里被否掉的三个理由值得单独看:第一个是“问得多不等于影响决策”,第二个是“这条信息在卡片上已经有别的载体”,第三个是“图片已经承担了这个属性”。后两条构成一个通用判据:能被卡片上已有元素表达清楚的属性,不该再占一行文字。
促销角标也在抢同一块地,且它通常抢赢
还有一个几乎必然发生的争夺战,值得提前说。
列表项上除了商品属性,通常还挤着一堆运营元素:新品角标、折扣百分比、限时标、包邮标、库存紧张提示、收藏按钮。这些东西的共同点是有明确的负责人、有可以直接归因的短期指标,因此在争位置的时候它们从来不缺弹药。
而品类属性没有这样的代言人。它的收益是沉默拒绝减少,而沉默拒绝——按前面说过的——在报表里不存在。于是每一轮改版,属性位都在被慢慢蚕食,且每一次蚕食都有充分的数据支持。
我的做法是把这件事摆到台面上:在设计稿评审时明确写出这张卡片有几个信息位、哪几个位置归属性、哪几个归运营,改动需要动到属性位时必须显式申请。听着有点官僚,但它是我见过唯一能防住这种慢性侵占的办法。设计与SEO之间的协作节奏,网页设计师的七个协作动作点那篇里给过一份可以直接抄的清单。
上限是一到三条,不是越多越好
最后强调一个容易走反的方向。品类专属属性的建议数量是一到三条,这个上限不是随口定的。
列表页的价值在于快速比较,而比较的效率取决于信噪比。每多加一条属性,单条卡片的信息密度上升,但整屏能扫的条数下降、每条被分配到的注意力也下降。加到某个点之后,用户读一屏的成本超过了点进去看一眼的成本,这时候你的列表页就退化成了一份排版更差的规格表。
把规格表整个搬上来,是我见过最常见的一种过度补偿——通常发生在被老板批评过一次列表信息太少之后。方向是对的,力度反了:该做的是选出那两三条,不是把选择权继续推给用户。
列表项那点地方是个固定预算,被挤掉的到底是什么?
卡片高度、每行卡片数、文字区行数三个数互相咬死。加法从来不是白加的,只是被挤下去的那个从来没人记账。
三个数字互相咬死,动一个必然动另外两个
前面两节讲的都是该放什么。这一节讲一件更物理的事:放不放得下。
一张列表卡片的容量由三个数决定,而这三个数是互相咬死的。
- 卡片高度:决定一屏能看到几行卡片。
- 每行卡片数:桌面端三到五张,移动端一到二张,这个数一变,单卡宽度跟着变。
- 文字区行数:图片占掉的高度是刚性的,剩下给文字的就那么几行。
移动端两列布局下,一屏能完整看到的卡片通常在四到六张之间。给文字区加一行,一屏就要少掉将近一整张卡。这不是审美问题,是一次真实的交换:多写一条属性,换掉的是用户这一屏少看到一件商品。
所以列表项设计从来不是加法题。它是一道预算分配题,而且预算是封闭的。
顺便说一句,这个预算比大多数人以为的更紧。真机上量一下就知道:把手机横过来、把字号调大、把系统显示比例往上推一档,很多站的卡片当场就只剩下图片和价格了。而这三种情况在真实用户里的占比,加起来并不小。顺带一提,长列表的渲染开销也是移动端的老问题,六项体验信号的优化与排序那篇里把这类拖慢首屏的因素归了个类。
被挤掉的那个,通常没人记账
预算封闭这件事本身不可怕,可怕的是账目单向。
加一个元素上去,有人提需求、有人写PRD、有人跟进上线、有人看数据;被挤下去的那个,没有提出者,没有记录,甚至没有一次明确的决定——它只是在某一版设计稿里悄悄没了。
我见过最典型的一次是这样:为了给限时折扣角标腾地方,某站把列表项的第二行属性砍掉了,砍掉的正是承重上限。改版之后折扣角标的点击贡献被清楚地统计了出来,涨了;承重信息消失带来的损失没有任何一栏对应,因为——还是那句话——它是沉默的。
永久原语:在一块封闭预算里,加法总是有人署名的,减法从来没有。这不是谁的错,是记账方式决定的。要对冲它,只能在流程上硬性要求:每一次往卡片上加东西,必须同时写清楚挤掉了什么,两件事写在同一张单子上。
视觉分层:同一块地方,其实能放下更多
预算封闭不代表只能做减法。在动手砍之前,先看看现有的地方是不是用足了。
最常见的浪费是所有文字一个字号、一个颜色、一个字重。这种排版下,用户读一张卡片需要逐行扫,信息再多也进不去脑子。
正确的做法是把卡片上的文字分成两到三层:主信息(价格、核心品类词)用大字重字号,次信息(规格、变体提示)用小一号的灰字,第三层(促销、库存)用色块或角标。做过分层之后,同样的行数能承载的信息量能提高不少,因为用户是跳着读的,不是逐行读的。
做规格丰富的品类时,还有一种取巧写法:把名称本身做成分层的,前半段是主标题、后半段是特征串并用弱化样式呈现。这样一行文字实际上承担了名称加两条规格的职能。音响电子类的垂直站很爱用这一手,效果不错。
截断点治理:决定性信息必须在截断之前
分层之后紧接着的问题是截断。
移动端列表项的名称一般显示两行,按常见字号折算,大约在二十四到三十二个汉字之间被切断。这个数字每个站不一样,但量级就在这里。
于是有了一条很硬的运营纪律:能决定点开还是跳过的那部分信息,必须落在截断点之前。把品牌名、系列名、一长串修饰语堆在开头,把真正区分度最高的规格甩到最后,是我在客户站上见得最多的写法,而它在移动端等于把那条规格删了。
具体操作也不复杂:导出全量商品名,按显示字符数截断,人工抽检两百条,看截断之后的那一段还能不能认出这是什么东西。这个活半天能干完,收益却相当直接。字符与像素之间的换算关系不是线性的,中英文混排时尤其容易估错,用像素级的预览工具核一遍更稳。
桌面端可以延后,移动端只能取舍
桌面端有一个移动端没有的出口:悬停。
鼠标停在卡片上时展开更多图片或更多规格,这是个成熟做法,能在不占用静态空间的前提下多给一层信息。类似的还有快速查看浮层——点开之后不离开列表就能看到主要信息,看完直接关掉继续扫。视觉驱动的品类里,这个功能的普及率大约只有一半,还有不少空间。
但这两条路在移动端都不成立。手指没有悬停这个状态,快速查看在小屏上又和直接进商品页差别不大。所以桌面端的方案是延后,移动端的方案只能是取舍——而移动端往往才是大头。
这也解释了为什么产品列表体验的基准数据上移动端明显比桌面端差:不是移动端团队水平低,是移动端没有那个可以把问题往后推的出口,所有矛盾都必须当场解决。
图片这一格其实也是可以扩容的
讨论预算时大家习惯只盯文字区,忘了图片那一格同样有容量。
同一张缩略图的位置上,多给两三张可切换的图,等于在不增加一个像素高度的前提下,多回答了两三个问题:这件外套的背面什么样、这只锅的手柄是什么材质、这台设备的接口在哪一侧。同一份基准里,能在列表与搜索结果中提供三张以上缩略图的站是少数,八成的站做不到。
这条对服饰、家居、箱包这类靠外观决策的品类尤其划算。机器怎么在多张图里挑一张当代表,读图机制那一套也值得顺手看看。它是整个预算表里少见的一种改动:不占额外空间,却实实在在增加了信息量。代价在数据侧——你得保证每个SKU都有三张以上可用的图,这又回到了覆盖率问题,下一节会专门讲。
属性别做成纯图标,尤其是多市场的站
省地方还有一条捷径很诱人:把属性做成小图标,一行能塞五六个。
这条路在少数几个高度约定俗成的符号上是通的,比如插头形状、洗涤符号。除此之外基本都会翻车,因为图标要求用户先学会一套图例,而列表页恰恰是他最不愿意学东西的地方。
多市场的站还有第二重风险:图标的语义在不同地区并不一致,同一个符号在两个市场可能指向不同的东西,而这类误读不会有人来告诉你。真要用,配一行小字兜底;实在放不下,说明这条属性本来就没资格进这一屏。
一张预算表,评审的时候摊在桌上
把上面这些落成一张表,评审时会省掉很多口舌。
| 信息位 | 桌面端 | 移动端 | 能否延后到悬停或浮层 |
|---|---|---|---|
| 缩略图 | 必留 | 必留 | 不能,它是入口本身 |
| 名称首段 | 必留 | 必留,且需按截断点重排 | 不能 |
| 价格 | 必留 | 必留 | 不能 |
| 评分与评价数 | 必留 | 必留,可压成一行 | 不能,它影响是否点开 |
| 变体提示 | 必留 | 压成色块或一句还有几种 | 色块留,具体清单可延后 |
| 品类属性一到三条 | 必留 | 优先保留判定性最强的那条 | 次要的可延后 |
| 促销角标 | 看策略 | 最多一个 | 可延后 |
| 次要规格 | 放悬停层 | 不放 | 可延后 |
这张表最大的用处不是告诉设计师该怎么排,而是让每一次争位置的讨论都发生在同一张表上。谁要加东西,先在这张表里指出它挤掉了哪一行。指不出来的,说明这次改动还没想清楚。页面骨架层面还有一份可以自动跑的体检,页面结构与语义标签的抽查能在改版前后各跑一次做对照。
顺带一提,首屏的信息分配逻辑和这里是一脉相承的,只是尺度不同。首页首屏的导航与分类区设计那篇讲的是同一件事在更大画布上的版本:位置有限,谁上谁下必须有个说法。
同样是没写,用户为什么会把它读成没有?
空白不会被读成空白,它会被读成一个否定的断言。而参差不齐的覆盖率比整体缺失更糟,因为它诱发的是一次错误归纳。
空着的那一格,用户读到的不是空
前面几节的潜台词都是:把该写的写上。这一节要说的是,写一半比不写更危险。
先看一个最简单的场景。同一屏里十二件商品,其中八件标了承重上限,四件没标。用户会怎么读那四件?
他不会读成数据缺失。他会读成这四件承重比较差,或者厂家不敢写。空白从来不会被读成空白,它会被读成一个否定的断言,而这个断言是用户替你下的。
这条在场景适用性那一类属性上尤其致命。前面说过,用户对防水、承重、耐温这类东西的默认假设本来就是保守的。你在八件商品上写了防护等级,剩下四件留空,等于亲手把那四件标成了不防水。
参差比缺失更糟,因为它诱发归纳
再往前推一步。全站都不写某个属性,用户至少知道这个站就是不写这个,他会调整策略,比如改用筛选器,或者接受多点开几个页面。
可一旦写得参差不齐,用户就会启动归纳:有的写有的不写,那不写的一定是有原因的。这个归纳在逻辑上完全合理,在事实上通常是错的——真实原因往往只是那批商品是三年前另一个供应商导入的,字段没补齐。
永久原语:属性的覆盖率不够时,缺失的那部分不是变成中性,是变成负面。所以上一个新属性之前,先看覆盖率,比先看设计稿重要得多。库存状态这一类字段同样吃这一套,缺货与预售的状态治理那篇里的判据可以直接搬过来用。
覆盖率闸门:低于阈值就整个类目别上
由此得出一条相当硬的运营规则,我一般叫它覆盖率闸门。
规则很简单:某个属性在某个类目下的有效覆盖率低于阈值,这个属性在该类目的列表项里就整个不显示。不是显示一部分,是整个不显示。等补到阈值以上再统一放开。
阈值定多少要看品类。我的经验值是这样的:
| 属性性质 | 建议阈值 | 理由 |
|---|---|---|
| 安全或适用性相关(防护等级、承重、年龄) | 95%以上 | 缺失会被读成否定,代价最大 |
| 规格比较型(尺寸、容量、功率) | 90%以上 | 参差会直接破坏可比性 |
| 描述型(材质、风格、产地) | 80%以上 | 用户容忍度较高,且图片能部分兜底 |
| 法定必显项 | 100% | 没有商量余地,缺一个都不能上架 |
这套阈值不需要谁审批,写进上架校验里就行:达不到覆盖率的属性,模板层直接不渲染。这样运营就算临时想加,也加不上去。
覆盖率必须按能被读懂的值统计,不是按非空
接下来是这一节里最值钱的一句,也是我自己吃过亏的地方。
大多数团队报出来的覆盖率,口径是字段非空。这个口径会系统性地把数字报高,因为下面这些值在数据库里全都是非空的:
- 空字符串与只有空格的字符串
- 占位文本:待定、待补充、TBD
- 无值标记:无、-、/、N/A、null这个字符串本身
- 单位丢失的裸数字:一个孤零零的45,不知道是厘米还是公斤
- 从旧系统带过来的编码:一串谁也不认识的内部码
永久原语:覆盖率要按能被用户读懂的值统计,不是按字段非空统计。两者的差距在老目录上经常大到离谱,我见过名义九成多、实际六成出头的情况——中间那三成全是上面这五类。
核算方法也不复杂:对每个属性写一条值域校验(数值型看范围与单位、枚举型看是否落在受控词表里、文本型看长度与黑名单词),跑一遍全量,输出的通过率才是真覆盖率。这一步跑完,往往比接下来所有设计工作都更能提升列表页的实际信息量。多店多市场的站还要多一层,同一个属性在不同站点视图下的取值可能不同,站组三层与商品共享那篇里讲过这套结构怎么搭。
值域没统一,等于写了也白写
覆盖率过关之后还有一关:同一个属性的值必须可比。
典型翻车现场是这样的:防水这一列里同时存在生活防水、防泼溅、IPX4、四级防水、可水洗五种写法,全都非空,全都通过了覆盖率统计,可用户在列表页上没法拿它们互相比较。他要么放弃比较,要么随手挑一个看着最唬人的。
尺寸单位的混排更常见。同一屏里有的写厘米有的写英寸,有的把长宽高写成一串没有标注的数字。跨境站还要叠一层:源数据来自不同市场的供应商,单位系统天然不一致。
解法是老生常谈但必须做:属性值一律走受控词表或标准单位,入库时归一化,展示时再按市场转换。单位换算这类小事最容易出岔子,温标换算与规格填写那篇里就记着几个跨境场景下的真实翻车。把归一化放在展示层做是个常见的错误选择,因为feed、结构化数据、导出报表这些出口不走展示层,它们拿到的还是原始的一团乱麻。属性建模这一层,Magento那套属性集与作用域机制其实提供了不错的骨架,我在Magento属性与属性集的管理那篇里拆过它的取舍。
缺值还有第二个受害者,而且它连曝光都没有
属性缺失的杀伤面比列表项本身更大,这一层很多人没想到。
同一个属性字段,通常同时喂着两个东西:卡片上那行文字,和左边那排筛选器。用户勾选防水这个筛选条件时,系统的做法是保留该字段有值且匹配的商品——没有值的那批,被整批筛掉了。
注意这里的性质变化。在没筛选的列表里,缺值商品至少还露了个脸,用户有可能凭图片点进去;一旦用户用了筛选器,缺值商品连出现的机会都没有。它不是被跳过,是根本没被端上来。
这就是沉默拒绝的第三种形态,而且是最彻底的一种:前两种至少还有一次曝光,这一种连曝光都是零。你在漏斗上任何一层都看不到它,因为它从来没进过漏斗。
更要命的是这条链路的反馈是反的:某个筛选值下的结果太少,运营的第一反应通常是这个需求不大,于是把这个筛选维度撤掉;而真实情况是那批货就在仓库里,只是字段是空的。库存与仓配那一侧的口径也常有类似问题,多源库存与预留治理里讲过同一批货在不同视角下为什么会对不上。
补数据这件事,得从入库那一端卡
知道要补是一回事,让它别再退回去是另一回事。
目录数据的来源大致三类:供应商发来的表格、平台或代运营导入的历史数据、自己团队手工录的。三类里最容易失控的是第一类,因为表格的列顺序、单位、值域随时会变,而对面并不认为这是件需要通知你的事。
可执行的做法是把校验前移到入库那一刻:新SKU入库时,本类目的必填属性缺一项就不予通过,走待补队列;已有SKU的属性被改动时,值必须落在受控词表内,否则拒绝写入并留一条记录。校验规则本身的写法可以很朴素,数据验证与异常值自动标红那一套思路搬到入库环节同样成立,核心就一句:映射关系必须显式声明并版本化,不能靠导入时肉眼对齐。
这条规则带牙齿,也因此最容易被绕过——总有人会说这批货急着上、先放进去后面再补。放进去就不会有后面了,这个我可以打包票。同类的批量维护还可以参考Magento的产品导入导出,两套系统的坑几乎一模一样。
空值到底怎么渲染?三种做法,各有代价
最后一个具体问题:万一确实有一小部分商品没有值,那一格该怎么处理。
| 做法 | 用户读到的 | 适用场景 | 代价 |
|---|---|---|---|
| 整行隐藏 | 这件商品在这一维上比较差 | 覆盖率极高、缺失是极少数 | 被误读成否定,且你看不见 |
| 保留占位空行 | 这个站数据不全 | 几乎没有适用场景 | 既显得残缺又浪费空间 |
| 显式写未提供 | 厂家没给这个数据 | 覆盖率中等且属性重要 | 诚实,但会拉低整体观感 |
三种里我通常选第三种,前提是这个属性确实重要。理由不在体验,在可观测性:显式写出未提供,等于把一个沉默的缺口变成了页面上一个能被数出来的东西。你可以统计它在多少个位置出现过,可以按类目排序,可以拿它去催供应商——它终于变成数据了。
覆盖率实在太差的属性,回到上一条:那就整个别上。写满一屏未提供,还不如那一行不存在。
哪几条属性其实轮不到你决定要不要显示?
四部互不相干的法规用几乎同一句话规定了同一件事:购买之前必须清晰可见,网上买也算。它们唯一的共同点是都落在同一张卡片上。
四部互不相干的法规,说了几乎同一句话
到这里为止,我们讨论的都是设计取舍:该放什么、放不下怎么办、覆盖率不够怎么办。这一节的性质完全不同。
如果你的商品卖到欧盟,那么列表项上有一部分内容压根不归你决定。四部彼此毫无关系的法规——一部管产品安全、一部管玩具、一部管纺织品、一部管能效——各自规定了一批必须在购买之前对消费者清晰可见的信息,并且都明确写了:网上买也算。
它们唯一的共同点是:这些要求最后全都落在同一张卡片、同一个页面上。而在大多数公司里,没有任何一个岗位的职责范围同时覆盖这四部法规。
产品安全条例:连图片都是法定必需项
先说范围最广的那一部。欧盟通用产品安全条例第十九条针对的是线上与其他远程销售场景,要求商品的要约中至少清晰可见地标出四项内容:
- 制造商的名称、注册商号或注册商标,以及可联系到它的邮寄地址与电子地址;
- 制造商不在欧盟境内时,欧盟境内责任人的名称、邮寄地址与电子地址;
- 能够识别该产品的信息,包括一张产品图片、产品类型以及其他产品标识;
- 依照相关法规须随附的任何警示或安全信息,且要用该成员国消费者容易理解的语言。
第三项值得单独拎出来看。前面第二节讲缩略图时,依据是测试里受测者会把没有图的商品当成不完整而整条跳过——那是一个体验结论。而在这里,图片是法条正文里写着的必需项。同一件事,一边由用户行为支持,一边由法律要求,这种情况在电商设计里其实不多见。
另外注意最后一项的措辞:警示与安全信息要“随产品或包装或随附文件”提供的那些,在线上要约里也得给到。这意味着一部分原本印在包装盒侧面的小字,现在必须爬到你的页面上来。这类把线下信息义务搬到页面上的做法,和退换货政策页该怎么写是同一个方向:能不能被查到,比写没写更要紧。
玩具指令:法条用的判据,和本文第三节一模一样
接下来这一条是我认为整篇文章里最值得咀嚼的一段法条。
玩具安全指令第十一条第二款规定:会决定玩具购买决策的那些警示,例如规定使用者最低与最高年龄的那些,必须出现在消费包装上,或者以其他方式在购买之前对消费者清晰可见,包括在线上购买的情形。
请注意它挑选信息的判据:会不会决定购买决策。
这不正是第三节那条判据吗——一个属性该不该进列表项,看它能不能改变点开还是跳过。用户体验研究是靠大量测试观察归纳出这条判据的,而这部指令2009年就把同一条判据写进了正文,还顺手补了一句包括线上购买。
两条独立的路径走到了同一个结论,这件事本身就有说服力。它说明“哪些信息必须在决定之前给到”不是审美偏好,是一个可以被独立验证的客观问题。下次有人说列表项放什么全看设计师喜好,可以把这一条甩过去。顺带说一句,界面上那些看着无关紧要却真能提转化的细节,被低估的反直觉杠杆那篇里也收了几个同类样本。
纺织品条例:法条里直接点名了目录
第三部管的是纤维成分。纺织品名称与标签条例第十六条第一款要求,纤维成分描述必须在目录与商业文件、包装、标签与标记上以易读、可见、清晰的方式标示,字号、字体与样式统一;并且这条信息必须在购买之前对消费者清晰可见,包括通过电子方式购买的情形。
这一条里有两个细节容易被漏掉。
第一,法条点名的是目录,而线上的目录就是你的列表页与集合页。第二,它对呈现方式提了要求——统一的字号字体样式。也就是说,把纤维成分塞进商品名称末尾、用比别的字小一号的灰字挤在角落,在字面上就已经不满足了。
能效标签:不是提一句,是要把那张标签挂出来
第四部的要求最重,因为它要的不是一行字。
能效标签框架条例第五条第一款规定,经销商应当以可见的方式展示供应商提供的标签,包括线上远程销售的情形。第六条第(a)项接着要求,在针对具体型号的视觉广告或技术推广材料中,必须提及该产品的能效等级以及标签上可用等级的范围。条例的说明部分也讲清了立法者的意图:在某些远程销售、视觉广告与技术材料里确实没法完整展示标签,那么至少要给出等级和等级范围。
换成人话:家电类目的列表项上,那个带箭头的等级标识与“A到G”这样的范围,是法定动作,不是营销物料。
四条并排看,形状就出来了
| 法规 | 必须在购买前可见的内容 | 对应本文哪一类属性 | 线上明确适用 |
|---|---|---|---|
| 通用产品安全条例第十九条 | 制造商与责任人信息、产品标识与图片、警示与安全信息 | 缩略图、名称与标识 | 是,条文直接针对远程销售 |
| 玩具指令第十一条第二款 | 会决定购买决策的警示,例如适用年龄区间 | 适用人群 | 是,明写包括线上购买 |
| 纺织品条例第十六条第一款 | 纤维成分描述,且呈现样式须统一 | 材质类品类属性 | 是,明写包括电子方式购买 |
| 能效标签条例第五条与第六条 | 标签本体,或至少能效等级与等级范围 | 技术规格 | 是,明写包括线上远程销售 |
把四行放在一起,一件有意思的事浮出来了:这四条要求分别落在了第三节那四类品类属性上——适用人群、材质、技术规格,再加上通用五项里的图片与名称。
也就是说,立法者从风险与知情权出发圈定的范围,与用户体验研究从决策效率出发圈定的范围,重合度高得惊人。两拨人用完全不同的方法论,划出了几乎同一块地。
永久原语:当合规要求与体验研究独立地指向同一批字段时,这批字段的优先级就不需要再论证了。这也是我在给客户做优先级排序时最爱用的一招——把合规清单与体验清单叠在一起,重合的部分直接进第一批,谁都没法反对。
这块地的边界在这几年里刚被挪过一次
还有一层时间维度值得说清楚,因为它直接影响你手上那份检查清单还准不准。
玩具那条写于2009年,纺织品那条写于2011年,能效那部框架条例是2017年的。这三部老规矩这些年基本没动。真正变的是产品安全那一部:它是2023年通过的新条例,自2024年12月13日起适用,取代了此前那部老的通用产品安全指令。
变化的关键不在于要求变严了多少,而在于它第一次把线上要约里该显示什么写进了一条独立条款。在此之前,产品安全的信息义务主要指向实物与包装,线上怎么办要靠推导;现在它有了明确的落点,而那个落点就是你的商品卡片。
这条对内容团队的含义很实在:你在2024年之前做的那份列表页字段清单,很可能没有这一栏。不是当时的人不专业,是当时确实没有这条要求。清单该重新过一遍了,尤其是制造商与责任人信息那两项——它们以前几乎从来不出现在商品卡片的讨论里。
落地:必显项要做成上架阻断,不是运营提醒
合规这一块的落地方式,和前面那些属性完全不同。
前面讲的覆盖率闸门是九成到九成五,法定必显项没有这个说法,它是百分之百。差一个SKU就是一个风险点,而这类风险不会均匀发生,它会在某一次抽查里集中爆出来。
所以实现方式必须是硬的:该市场该类目的必显字段缺任意一项,商品不允许上架;已上架的商品被改成缺失状态,自动下架并告警。这类硬闸门与缺货下架的收尾规则是同一种思路:状态一变,系统自动动作,不依赖人记得。做成运营提醒、做成周报里的一行数字,都会在某个大促前一晚失效——因为那天所有人都在赶时间,而提醒是可以点掉的。
还有一个跨市场的坑:必显清单挂的是销售目的地,不是站点语言。同一套德语页面可能同时服务德国、奥地利与瑞士,而瑞士不在欧盟。把规则挂在语言上,这三个市场的必显项就会串。这个错误我在DTC海外主体架构的三地区对照里提过一次,换个场景又出现了,可见它有多容易犯。
同一个属性在页面上、在feed里、在结构化数据里,为什么不是同一个东西?
三套规则由三拨人维护,必填的定义各不相同。有三项在哪儿都必填,有两项在哪儿都不必填——而后两项恰好最常缺。
同一份数据,三个出口,三拨人维护
你的商品数据至少要从三个口子出去。
第一个是页面本身,前面六节讲的都是它。第二个是商品数据源,也就是喂给购物广告与免费商品列表的那份feed。第三个是页面上的结构化数据,被搜索引擎和各类自动读取的程序拿去用。
三个出口的必填定义由三套完全不同的规则决定,而这三套规则在大多数公司里由三拨人负责:页面归产品与设计,feed归投放,结构化数据归SEO或者前端。于是同一个属性,在一个出口是必填,在另一个出口可以为空,没人觉得这有什么问题,因为没人同时看这三张表。
这一节就把三张表叠起来看一遍。
feed这一侧:一百多个属性,真正必填的只有七个
Google的商品数据规范里定义的属性数量相当可观,一路数下来超过一百二十个。但标注为必填的核心属性其实只有七个:唯一标识、标题、描述、落地页链接、主图链接、库存状态、价格。
把这七个和本文第二节那五项通用属性对一下,有意思的地方就出来了:
- 价格、标题、主图——三处都必填,没有争议;
- 库存状态与落地页链接——feed必填,页面上通常也有;
- 用户评分与评价条数——在这份规范里根本不是一个属性,商品评分走的是另一套单独的机制,不在这份列表里;
- 变体——不是一个属性,是一组约定:靠商品组标识把同款的不同版本串起来,再由颜色、尺码等子属性区分。
结论有点反直觉:用户体验研究认定的五项必要属性里,有两项在feed规范里不具备必填身份,而这两项恰恰是实际项目中最常缺的。这不是巧合——没有哪一侧的规则在逼你补,那它自然就一直缺着。
feed这份资产该归谁管、为什么它不该被当成投放部门的内部文件,我在产品feed的归属问题那篇里专门写过一次,本节可以看成那篇的字段级续集。至于这份数据最终会怎样影响你在购物结果里的位置,从关键词转向AI选品那篇给过一个更靠前的判断。
一个很能说明问题的字段:能效等级
同一份规范里有个字段的演化过程特别值得看。
早先能效等级是一个普通的可选属性,你自己填一个字母上去。现在的规则变了:面向欧盟市场、且依法必须展示图形能效标签的商品,要改用认证属性,而这个属性的值不是等级本身,是一个指向欧盟官方产品数据库的编号,形如某个前缀加上一串数字。原来那个直接填等级的属性,如今只保留给瑞士、挪威与英国这几个不在欧盟的市场。
这个变化背后的逻辑很硬:当一个属性被法律定成必显项之后,它在你的系统里就不再是一个内容字段了,而是一个外部主键的引用——你没有权利去填它,只有义务去指向它。
这条原语的适用面比能效大得多。凡是有官方注册库的属性,最终都会往这个方向走:你负责建立对应关系,不负责编写内容。运营那边最不习惯的也是这一点——以前是填一个值,现在是维护一条对应关系,填错了不是文案错误,是指向了别人的产品。这类外部标识的维护纪律,和结构化数据里的语言与地区标识要求的严谨程度是一个级别的。
结构化数据这一侧:评分只是推荐项
第三个出口是页面上的结构化标记。商家商品信息的结构化数据文档把要求写得很清楚。
商品这一层的必填属性是三个:名称、图片、报价。报价那一层里价格是必填的,而且对商家商品信息这类展示形式而言,价格必须大于零——这条规定顺手堵死了用零元占位的做法。
接下来是推荐属性,这一栏里躺着几个熟面孔:聚合评分、受众(也就是适用性别与年龄段)、品牌、类目。
看出规律了吗?评分与适用人群,在页面体验研究里是决定用户点不点开的关键,在结构化数据里却是推荐级别的;而推荐级别在真实项目中的落地率,大家心里都有数。又一次,最容易缺的那几项,恰好在每一套规则里都没有强制力。
列表本身这一层,规范里几乎是空的
还有一个更根本的问题:列表这个概念,在结构化数据里其实非常单薄。
schema.org的列表类型自身只定义了四个属性:列表元素、列表顺序、元素数量,以及一个用来挂聚合信息的原型元素。四个里没有任何一个描述这些商品有什么特征——它只回答有多少个、按什么排、每一项是什么。
换句话说,结构化数据层面根本不存在“列表项信息”这个概念。要让机器知道第三张卡片上写着防护等级四级,唯一的办法是在那一项里嵌一个完整的商品对象,把属性挂在商品上。你不这么做,机器读到的就只有一个名字和一个链接。
这就接回了第一节末尾那个说法。人少看到一个属性会犹豫、会跳过,好歹留下一次曝光;机器少一个属性,这件商品在那次比较里根本不具备这个维度,它在候选集生成阶段就被漏掉了,连“跳过”这个动作都不会发生。
被机器读走的那份清单,就是它给出的那个答案
这里有一个对做内容的人特别重要的推论。
当用户不再自己翻列表,而是直接问一句“帮我找一款能带去泳池边的便携音箱,预算八百以内”时,回答他的那台机器手上只有两样东西:它抓到的结构化字段,以及它读到的公开文字。你的卡片长什么样、图标排得多好看,与它无关。
于是属性覆盖率这件事,直接决定了你的商品在这一类问答里出不出现。缺防护等级的那批音箱,不是排得靠后,是压根没进这次筛选。而这一次,你连一次曝光都拿不到——回到第一节那句话,机器那边的沉默拒绝更彻底。
反过来讲,这也是眼下少有的、还没被卷烂的机会。同品类里能把属性填全、值域规整、结构化数据渲染正确的站还不算多,谁先做完谁就先被读进去。想先摸清自己现在被引用成什么样,电商场景的引用规律实测与发布前的引用模拟这两条路都能跑。购物结果的排序因素那篇讲的是排序,本节讲的是入场资格——排序再好,进不了候选集也是白搭。
还有一条容易被忽视的:机器读的是你写在公开位置上的东西。放在需要登录、需要展开、需要悬停才出现的属性,人还有机会看到,抓取程序通常没有。把关键属性藏进交互里,等于对人半开、对机器全关。
三张表叠起来,缺口就藏不住了
| 属性 | 页面(体验研究) | 商品feed | 结构化数据 | 欧盟法定 |
|---|---|---|---|---|
| 价格 | 必要 | 必填 | 必填且大于零 | 部分品类另有价格规则 |
| 名称或品类词 | 必要 | 必填 | 必填 | 产品标识属必显 |
| 主图 | 必要 | 必填 | 必填 | 产品安全条例点名要图 |
| 评分与评价数 | 必要(DTC站有例外) | 不属于该规范 | 推荐 | 无要求 |
| 变体 | 必要 | 靠商品组标识约定 | 需另建商品组结构 | 无要求 |
| 适用人群 | 品类专属 | 可选属性 | 推荐 | 玩具类必显 |
| 材质 | 品类专属 | 可选属性 | 可选 | 纺织品类必显 |
| 能效等级 | 品类专属 | 特定市场条件必填 | 可选 | 能效品类必显 |
这张表我建议直接抄进你自己的文档里,把第一列换成你实际用的属性名,然后逐行填。填的过程本身就是收获——你会发现有几行在三个出口里的状态互相矛盾,而那几行就是接下来要修的东西。变体那一行尤其容易出问题,WooCommerce的分步配置路线里把产品页与分类页该配的几项列得比较全。
最后提醒一句取数纪律:这张表要按实际产出的数据填,不是按字段定义填。feed里那个属性是不是真的每条都有值、结构化数据是不是真的渲染出来了,得拿实际抓取的结果去核。做法可以参考产品列表的信号体检工具那一套,先跑一遍现状再谈改进。
那些看不见的损失,能不能换算成表里真有的数字?
事件本身抓不到,它的影子能。三个不用新埋点就能算出来的指标,其中一个还会告诉你点击率上涨可能是坏消息。
思路:抓不到那个事件,就去抓它的影子
第一节的结论是这类损失在原理上不产生记录。这一节要说的是,虽然它本身不产生记录,但它会逼着用户做出别的动作,而那些动作是有记录的。
关键在于换一个提问方式。不要问“有多少人因为信息不足而放弃了”——这个问题没有答案。要问的是:“当卡片上的信息不够时,用户会被迫做什么?”然后去数那件事。
用户被迫做的事一共就那么几件:点进去看一眼再退出来、来回翻同一屏、干脆什么都不点接着往下滚。这三件事分别对应下面三个指标。
指标一:折返率
定义:在同一个列表页会话里,从列表点进商品页、又退回同一个列表页且未发生加购的次数,占该列表页全部点击的比例。
这个动作的含义很直白:用户用一次点击去换一个本该写在卡片上的信息。他不是想去商品页,他是被派去的。
取数不需要新埋点。列表页与商品页的浏览记录本来就有,会话内的页面序列也有,需要做的只是把序列拼起来,识别出“列表页→商品页→同一列表页”这个模式。加购与否用现成的电商事件判断。这类会话内路径的拼装,GA4的渠道与会话口径那篇里把容易踩的定义问题讲得比较清楚。
判读大致是这样:
| 折返率区间 | 说明什么 | 该动哪里 |
|---|---|---|
| 高于六成 | 卡片信息严重不足,用户几乎必须进详情页才能判断 | 先补通用五项,再谈品类属性 |
| 四成到六成 | 通用项基本齐了,品类关键属性没上 | 用第三节那四个来源找出那两三条 |
| 两成到四成 | 比较健康,属于正常的深入了解 | 按类目拆,找出偏高的那几个类目 |
| 低于两成但加购率也低 | 不是信息够了,是用户压根没兴趣点 | 问题在选品或流量质量,不在卡片 |
最后一行是防止误用的护栏。折返率单独看会骗人,必须和点击量、加购率一起看。一个没人点的列表页,折返率天然好看。
指标二:属性补偿点击占比
折返率还是粗了一点,它把两种点击混在了一起:真的想深入了解的,和被逼着去查一个数的。第二个指标把后者单独择出来。
定义:从列表页进入商品页后,停留时间低于阈值且滚动深度未超过某个位置就返回的点击,占全部列表页点击的比例。阈值需要按自己的站校准,起步可以取停留低于八秒、滚动未过四成。
这类点击的画像非常一致:进去、扫一眼规格区或者图片区、拿到那个数、退出。用户的目的从头到尾只是补一个信息,而不是评估这件商品。
滚动深度这一项通常需要额外配置,但成本很低,属于一次性工作。做GA4指标口径时顺手就能带出来,别单独立项。顺带把机器流量的过滤也配上,否则滚动深度这类指标会被爬虫拉得很难看。
这就引出了那条最容易搞反的结论
把上面两个指标想通之后,会得到一个让人不太舒服的推论。
属性补偿点击,在点击率这个指标里长得和兴趣点击一模一样。两者都是一次从列表到商品页的跳转,两者都会把列表页点击率往上推。
于是就有了这个局面:卡片上的信息越少,列表页点击率可能越高。因为用户没法在列表页做决定,只能挨个点进去看。反过来,把关键属性补齐之后,点击率大概率会往下掉——用户在列表页就把不合适的排除掉了,剩下的点击都是奔着买去的。
这条如果没提前跟老板说清楚,改版之后的复盘会开得非常难看:点击率掉了,跳出率可能还涨了(用户扫完一屏没找到合适的就走,这是正常结果),只有加购率和最终转化在涨。要是评估这次改版用的是点击率,结论就会是失败,然后被回滚。
永久原语:当一个指标同时被健康行为和补偿行为推高时,它就不再能作为这次改动的评价标准。这类情况下必须换一组指标:列表页到加购的转化率、每次会话浏览的商品页数(应当下降)、以及下面第三个指标。该换掉哪些骗你的老指标那篇讲的是同一类毛病在另一个场景里的表现,而社媒指标的四层漏斗则示范了怎么把一堆好看但无用的数拆成能驱动生意的那几个。
指标三:零点击扫视深度
前两个指标都建立在用户点了的基础上。第三个专门看那些一次都没点的会话。
定义:在列表页滚动超过若干屏、却一次商品点击都没有的会话,占该列表页全部会话的比例。屏数按自己的布局定,通常取三屏起。
这个指标之所以有价值,在于它筛掉了两类干扰:滚动很浅就走的人多半是流量不精准或者落错页;而滚了三屏以上,说明这个人是真的在找东西,找了半天一个都没点,那大概率不是他不想买。
它是三个指标里最接近沉默拒绝本体的一个。虽然仍然测不到“他跳过的是哪一件”,但至少测到了“他扫了很久、什么都没选”这件事的规模。
按类目拆开看最有用。全站零点击扫视率在一个水平,某个类目明显高出一截,那个类目的属性配置多半有问题——而这正是那种在总量报表里永远看不出来的信号。
三个指标怎么配着用
| 指标 | 回答的问题 | 是否需要新埋点 | 看它的频率 |
|---|---|---|---|
| 折返率 | 用户是不是被迫用点击换信息 | 不需要,拼页面序列即可 | 周度,按类目拆 |
| 属性补偿点击占比 | 那些点击里有多少是纯补信息 | 需要滚动深度,一次性配置 | 月度,改版前后对比 |
| 零点击扫视深度 | 认真找过又一无所获的人有多少 | 需要滚动深度 | 月度,重点看类目差异 |
三个指标的共同点是:都不需要问用户任何问题,都能在当月的数据里跑出来,也都不依赖新的采集方案。这一点很重要——需要新埋点的方案,从提出到拿到第一个数字通常要一个季度,而一个季度足够让这件事重新沉回需求池底部。
另外提醒一句口径纪律:这三个指标都涉及会话内的页面序列,跨设备、跨域名的会话切断会影响结果。定口径的时候先把这些边界写死,别等到第三次复盘时才发现两个人算的不是一回事。这类问题的排查思路,指标分层与单一事实源那篇里有比较完整的一套。
第四个可选项:按商品维度看零点击
前三个指标都是页面维度的。想再往前一步,可以做一个商品维度的版本。
取每件商品在一段时间内的曝光次数与点击次数,按它出现的平均位次做一次归一化,然后找出那些位次不差、曝光足够、点击却明显低于同位次均值的商品。
位次归一化这一步不能省。列表页第一屏和第五屏的点击率差着好几倍,不做归一化的话,你找出来的只是排在后面的那批货,跟属性没关系。
归一化之后剩下的那份名单很值得看:同样的位置、同样的曝光,别人被点、它没被点。原因无非几种——图片差、价格不合理、名称看不懂、关键属性缺失。逐个核一下卡片,通常十分钟内就能认出是哪一种。
这个做法的门槛在于要有商品级的曝光数据,不是每个站都有。海外仓那一侧其实早就在按SKU算账了,SKU周转率与滞销预警那套分层方法可以直接借来给商品分组。有的话强烈建议做,因为它是唯一一个能把问题定位到具体SKU的指标,前面三个都只能定位到页面或类目。
把这些数字折算成钱,立项才立得住
指标算出来只是第一步。要让这件事排进日程,还得翻译成财务语言。
折算路径其实不复杂,四步:
- 取零点击扫视会话数,乘以这批会话的历史平均下单率,得到一个理论上可能的订单数上限;
- 按一个保守的挽回比例打折——我一般取一成到两成,别贪心;
- 乘以客单价与毛利率,得到年化金额;
- 把属性补齐的工时成本、数据清洗成本、供应商沟通成本列在旁边。
这个算法当然不精确,它的假设一大堆。但这里有个很现实的道理:需求池里排在你前面的那些项目,收益测算的精确程度也就这样。它们能排上去,不是因为算得准,是因为算了。把自然流量折成金额这件事,关键词漏斗的收入测算那篇给过一套可以照抄的算法。
而列表项属性这件事之所以长期排不上,往往就是因为从来没有人给它算过任何一个数字。一个粗糙的估算,胜过一句“这个很重要”。
还有一个更笨但很有效的办法
如果连上面这些都嫌重,还有一个土办法:让客服每周报三个最常被问到的商品问题,只报三个,坚持八周。
这份名单的信息密度高得惊人。用户肯打字来问的问题,一定是他在页面上找不到、又必须知道的东西;而肯问的人是极少数,所以每一条背后都站着一大批没问、直接走掉的人。
这个办法的局限在第三节那张表里写过——量小、有偏。但它有一个无可替代的优点:它是唯一一个用自然语言描述缺口的来源,其他指标只会告诉你有问题,它会直接告诉你缺的是哪个字段。
为什么把一个属性藏起来,比把它加上去便宜一个数量级?
加法实验的成本大头在实验开始之前就花完了,减法实验今天想做明天就能跑。两者测的是同一个量,方向也一致。
加法实验贵在哪:它的成本大头不在实验
假设你想验证“给这个类目加上承重上限,能不能提升转化”。常规做法是做一版新设计,分流跑实验,看结果。
听着简单,实际的时间线是这样的:
- 确认这个属性在系统里有没有字段,多半没有,先建;
- 找数据,可能要向几十个供应商要,或者从PDF说明书里抠;
- 清洗与归一化,把各种写法收敛到统一单位;
- 补覆盖率,补到能上的水平——按第五节的闸门,起码九成;
- 改模板、改feed、改结构化数据;
- 然后才开始跑实验。
前五步通常要几周到几个月,且大部分成本在实验开始之前就已经花掉了。更要命的是这笔投入不可逆:万一实验结论是这个属性没用,前面那些数据工作也退不回来。
于是就出现了一个很常见的死循环:因为不确定值不值,所以不愿意投;因为不投,所以永远不确定值不值。
减法实验:把已经有的那个藏起来
破这个循环的办法,是把方向反过来。
不要测“加上它能涨多少”,去测“把它拿掉会掉多少”。拿掉一个已经存在的属性,不需要数据准备,不需要供应商配合,不需要清洗,只需要在模板里加一个条件判断。今天想做,明天就能跑。
逻辑上,这两个实验测的是同一个量:这个属性在这块屏幕上的边际价值。方向相反,绝对值相同。可它们的成本差着好几个零。
我第一次用这个办法是在一个僵住的项目上:客户坚持要给全站加三条属性,我认为其中一条没用,双方谁也说服不了谁。后来的做法是把另外两条已经有的属性各藏掉一次,用两周时间拿到了这个类目属性边际价值的量级——那之后的讨论就变成了算术题,不再是立场之争。想找更多可以直接拿去跑的题目,三十个从CTA到结账的实验方案那份清单足够用上一年。
两种实验并排比一比
| 维度 | 加法实验 | 减法实验 |
|---|---|---|
| 准备周期 | 几周到几个月,卡在数据侧 | 一到两天,只改模板 |
| 主要成本 | 数据采集、清洗、覆盖率补齐 | 实验期内小比例流量的体验损失 |
| 可逆性 | 数据投入不可逆 | 随时可停,改回来就行 |
| 能回答 | 这个新属性值不值得投 | 已有的哪些属性最值钱、哪个类目最敏感 |
| 不能回答 | —— | 一个你从来没有过的属性值多少 |
| 主要风险 | 投完发现没用 | 实验期内确实少卖了一点 |
最后一行要正视:减法实验是一个会让部分用户体验变差的实验。这一点跟大多数实验不一样,大多数实验两个版本至少都是善意的。所以流量比例要小、周期要短、结论一到就停,别拖成一个常设的对照组。
具体怎么跑,六条就够
做法本身没什么玄机,但有几个地方特别容易做坏。
- 单因素。一次只藏一个属性。同时藏两个,你拿到的是两者的合力,拆不开。
- 随机分流,不要按类目或时段分。按类目分等于把品类差异算进了结论里。
- 周期至少覆盖一个完整的自然周。工作日与周末的浏览行为差别很大,尤其是家居家电这种全家一起看的品类。
- 样本量先算再跑。这一步跳不得,跑到一半才发现功效不够,等于白跑。样本量的三个公式那篇够用了,选其中一个,把最小可检测效应定得现实一点。统计功效与单因素隔离这两件事的细节,实验设计与统计功效那篇讲得更透。
- 主指标用加购率与列表页到加购的转化率,不要用点击率。理由上一节讲透了:藏掉属性之后点击率大概率会涨,你会得到一个完全反过来的结论。
- 同时看零点击扫视深度。它是这个实验里最直接的信号——属性没了,认真找又什么都没点的人应该会变多。
还有一条属于常识但常被忘记的:分流实现方式别影响抓取。给不同版本发不同URL、或者用跳转做分流,都可能带来收录侧的副作用,A/B测试页面怎么做才不影响SEO那篇里把该注意的几条列全了,动手之前扫一眼。
三条禁忌,碰了就别做
第一,法定必显项一律不能拿来做减法。第六节那四类,藏掉哪怕百分之一的流量都不行——那不是实验,那是违规。这条没有商量余地。
第二,价格与主图不用测。结论早就明确,而且藏掉它们会让整个列表页失去基本可用性,测出来的是崩溃程度,不是边际价值。
第三,不要在大促期间跑。大促期间的流量结构和平时完全不同,冲动型购买占比高,属性敏感度被稀释,结论没法外推。而且真出了问题,损失也放大了。另外要提醒一句:别把自然增长算成实验功劳,增量测试的思路在这里同样适用。
另外有个心理层面的提醒:减法实验的结论有时候会很难看——某个大家争了半年的属性,藏掉之后指标纹丝不动。这时候要忍住不去解释,也别急着改口径。那个属性可能真的不重要,这恰恰是你花这两周想知道的事。
结论怎么用:排出一张边际价值表
把几轮减法实验的结果拼起来,就得到了一张属性边际价值表:每个属性在每个类目下,藏掉之后指标掉多少。
这张表有三个用法。
第一,指导取舍。回到第四节那个封闭预算——现在你有依据了。位置不够时,砍掉边际价值最低的那个,不用再靠嗓门大小决定。
第二,指导投入。如果某个已有属性的边际价值很高,那么同一类性质的新属性大概率也值得投。这是一种类比推理,不严谨,但比拍脑袋强得多。
第三,暴露类目差异。同一个属性在不同类目下的敏感度经常差好几倍。全站一刀切地配置列表项,本身就是一个没有依据的默认设定,而这张表能给你把它拆开的理由。
四周路径:第一周一行代码都不用改
把前面九节的东西压成一个可以直接开工的排期,大概是这样。
第一周,不动代码,出三张清单。第一张是现状清单:每个主力类目的列表项现在显示了哪些字段,逐个截图标注。第二张是覆盖率清单:这些字段按第五节那个“能被读懂的值”的口径重新统计一遍真实覆盖率。第三张是合规清单:按销售目的地与品类,把第六节那几类必显项列出来,标出哪些还没有。这一步的产出形式可以参考变更日志的治理方式,让每一次改动都能被追溯。
第二周,动最便宜的那一层。把折返率与零点击扫视深度算出来,按类目排序;同时把名称字段按截断点抽检两百条。这一周的产出是一份按类目排的问题严重度清单,以及一份名称重排的候选名单。
第三周,跑第一个减法实验。挑一个折返率最高的类目,藏掉一个非法定的品类属性,两周周期,这周先把分流与口径搭好。同时开始补合规清单上的缺口,这一项不用等实验结论,它没得选。
第四周,做名称重排与空值渲染的改造。这两件事都不依赖新数据,属于纯改造,且收益立竿见影。等实验结论出来的这段时间,正好用来做它们。
四周之后,你手上会有:一份真实覆盖率、一份合规缺口、一份类目严重度排序、一个属性边际价值的量级、以及两项已经上线的改造。这些东西加起来,足够支撑一次正经的立项。
三档投入,最小那档能吃掉大半收益
| 档位 | 做什么 | 大致投入 | 预期能拿到 |
|---|---|---|---|
| 最小档 | 补齐通用五项、按截断点重排名称、修空值渲染、补合规必显项 | 两到四人周,不含数据采集 | 大半收益,且几乎没有争议 |
| 中档 | 加上覆盖率闸门与值域校验、上一到两条品类属性、跑两轮减法实验 | 一到两人月,含一轮数据清洗 | 类目级的精细化,以及一张边际价值表 |
| 完整档 | 三个出口的字段对账、入库校验前置、商品级零点击监控 | 一个季度,需要跨部门配合 | 不再复发,新SKU天生合格 |
我的建议是:最小档立刻做,中档排进下个季度,完整档等中档拿到结果之后再谈。把这件事当成一条产品线来推进,比当成一次改版更容易活下来,把SEO当产品做那篇讲的就是这种节奏。这类项目最常见的死法不是做不动,是一开始就按完整档立项,然后在跨部门协调阶段耗光了所有人的耐心。
减法实验测不到的那部分,用另外两条路补
必须说清楚这个方法的边界:它只能测你已经有的属性。那个你从来没有过、正在犹豫要不要投的属性,它测不了——这是它最大的局限。
补救有两条路,都不完美,但合起来够用。
第一条是横向对照:找出同品类里那些做得比较认真的站,把它们列表项上有、你没有的属性列出来。这份名单不能直接照抄,但可以作为候选池,再拿第三节那四个数据来源去交叉验证。做时尚这类季节性强的品类,还可以叠一层搜索需求的趋势预测来判断哪些属性正在变重要。
第二条是低成本试点:不要全站上,挑一个类目、几百个SKU,手工把数据补齐,只在这一个类目上线,跑两周。手工补几百条数据的成本,比建一整套字段管线低两个量级,而它能给出的信号是一样的。试点成功了再谈系统化,失败了也就损失几个人天。
我见过太多团队在这一步卡住:非要先把数据管线建好、把所有类目都覆盖了才敢上线,结果这个项目在立项阶段就死了。先用最脏的方式验证一次,是这类不确定性高的事情上最省钱的做法。
保哥踩过的坑:一个字段被搬到决策位之后
方向对、数据也一路支持,问题出在那个字段的数据质量撑不住它的新位置。等发现的时候,账已经记在退货那一栏了。
背景:一个折返率高得离谱的工具站
这个客户做出海电动工具与五金,主力是无绳电钻、角磨机与工具套装,卖德国、法国、英国三个市场,客单价大致在80到400欧之间。
接手时最扎眼的一个数:列表页点进商品页之后,很大一部分会话在很短时间内退回了同一个列表页。当时还没有折返率这个说法,我们叫它来回跑。按类目拆开一看,无绳类工具那一块尤其严重。
原因不难找。这个品类的用户在列表页要判断三件事:电池平台是哪一个、包不包含电池、是无绳还是有绳。三条全都没在卡片上,全都只写在商品页最底下那张规格表里。于是每个人都得点进去看一眼,看完发现平台不对,退出来,再点下一个。这种来回跑对结账环节的伤害是累加的,结账放弃率的九个真实成因里那几条在这个站上几乎全中。
方案因此很直接:把这三条提到列表项上。同时把电池平台做成一个筛选维度——这个决定后来变得非常关键,虽然当时看起来只是顺手。
头几个月:全绿,而且我把点击率下降解释对了
上线之后的数据很漂亮。
列表页点击率下降了一截,加购率上升,商品页到加购的转化率明显改善,会话内平均浏览的商品页数下降。用今天这篇文章里的话说,就是补偿型点击被消掉了,剩下的点击质量更高。
当时客户那边的投放负责人对点击率下降很紧张,保哥花了一次会的时间讲清楚这件事:点击率掉是因为用户终于能在列表页做判断了,这是目标,不是副作用。后来的数据支持了这个解释,那次沟通我至今认为做得对。
于是团队加码:又往卡片上加了转速与重量,把筛选器也做得更细。整整两个季度,所有能看的数字都在往好的方向走。当时的投放侧数据也在涨,而多触点归因模型的选择这件事那会儿还没理顺,现在回头看,那份涨幅里有多少是真的,其实说不清。
第七个月:出问题的地方不在转化,在退货
问题第一次露头,不是以转化率下降的形式,而是月度退货复盘里的一行。
退货原因里“与描述不符”那一类的占比翻了一倍多,而且几乎全部集中在无绳工具这一个类目。其他类目纹丝不动。
拉出具体工单看,用户的说法高度一致:买回来发现电池接口跟自己手上那套对不上,或者以为包含电池、拆开发现是裸机。
这就很奇怪了——这两件事正是半年前刚在列表页上写清楚的。写清楚之后,因为它买错的人反而变多了?
第一层:名义覆盖率96%,真实覆盖率63%
查下去的第一个发现,是覆盖率的口径问题。
报表里电池平台这个字段的覆盖率一直显示96%,所有人都觉得够格上线。可这个96%的口径是字段非空。把值拉出来逐个看,情况是这样的:
- 真正落在已知电池平台清单里的:约63%;
- 写着“通用”或“兼容多种”的:约两成,其中相当一部分并不真的通用;
- 写着短横线、待确认、暂无的:约一成;
- 写着一串供应商内部编码的:剩下那点。
而前端的处理逻辑是:值为空就整行不渲染,值不为空就原样输出。于是那些写着“通用”和短横线的商品,在卡片上要么显示了一个毫无意义的词,要么什么都不显示——而用户把不显示读成了这一款不挑电池。
这就是第五节那条原语的实例:覆盖率必须按能被用户读懂的值统计,不是按字段非空统计。两个口径之间那三十几个百分点,全是坑。
第二层:不只是缺,还有一批是错的
再往下查,发现了更难受的东西。
这个字段的真值来源是供应商发来的表格,按季度更新。其中一家供应商在某一次更新里调整了表格的列顺序,把电池平台那一列和另一列的位置换了。导入脚本按列序号取值,没有校验列头,于是那一批商品的电池平台被整体标成了另一个品牌的平台。
关键在于,这个错误在半年前是无害的。那时候这个字段只出现在商品页最下面那张规格表里,几乎没有人翻到那儿;就算翻到了,一个和图片对不上的参数也很容易被当成笔误忽略掉。
可现在它出现在列表项上,还成了筛选维度。用户勾选自己的电池平台,系统就把这批标错的货端了上去,还端得理直气壮。
永久原语:把一个字段搬到决策位之前,先看它的数据质量能不能承受这个位置;展示位置每往前移一格,同样的数据错误,代价就翻一倍。
这条我后来反复讲给客户听,因为它不只适用于列表页。同一个字段,在规格表里错了没人管,在卡片上错了会误导,在筛选器里错了会把商品推给完全不该看到它的人,进了feed错了还会花钱把这个错误推出去。一个字段的数据质量要求,取决于它在决策链上的位置,跟它是什么字段没关系。
第三层,也是最贵的那一层
把账彻底算了一遍之后,最难受的发现在这里。
因为那批货被分到了错误的筛选桶,它产生了两个方向的后果:
第一个方向能看见——被推给了错误人群的那批用户,一部分真的下单了,然后退货。这就是退货报表里那一行,损失可以精确到欧元。
第二个方向看不见——真正该看到这批货的用户,勾选正确的平台之后,结果里根本没有它们。他们不知道你有货,你也不知道他们来过。这批人没有退货,没有工单,没有差评,什么都没留下。
整篇文章讲的沉默拒绝,就是这个东西。区别只在于:前九节讲的是数据缺失造成的沉默拒绝,而这一次,是我们自己在一次本意良好的改进里,亲手多制造了一批出来。
更具体一点说:那三个月里,一个搜索特定电池平台的德国用户,在这个站上看到的结果集是错的。他不会写工单说“你们的筛选结果不对”,因为他不知道结果应该是什么样。他只会觉得这家店货不全,然后去别处买。筛选结果里的这类静默偏差,和筛选页该不该放出去那种收录侧的判断完全是两回事,别混为一谈。
改了三处,两处是闸门,一处是渲染
第一处,值域校验加受控词表。电池平台这一列的值必须落在一份维护好的平台清单里,落不进去的一律不予写入并进待办队列。新增平台需要人工确认之后才能进清单——这一步不能自动化,否则等于没有校验。
第二处,覆盖率闸门。按第五节那张表,这类属性归到规格比较型,阈值定在九成。有效覆盖率低于阈值的类目,这个属性在列表项与筛选器里都不出现。刚上线时无绳类目直接被这条规则关掉了两周,等数据补到位才重新放开。
第三处,空值显式渲染。不再隐藏,改成明确写出未提供。这一改还有个意外收获:客服很快就报上来说,用户开始主动问“这款为什么没写电池平台”——一个原本沉默的缺口,变成了一条可以计数的咨询记录。
此外还加了一条兜底:导入脚本改成按列头取值,列头对不上直接整批拒收并告警。这条属于事后诸葛亮,但值得写进任何一份数据导入的检查清单里,具体做法可以参考批量导入导出的字段映射实战。
结果,以及那笔算不清的账
三个月之后,与描述不符那一类退货回到了改版之前的水平,还略低一点。折返率没有反弹,加购率也守住了——这说明当初把三条属性提到列表项这个方向本身是对的,出问题的是数据质量,不是设计决策。
但有一笔账始终算不清楚。
那三个月里,勾选了正确电池平台却没看到该看到的货的用户,究竟有多少,损失多少,无从知晓。他们在任何一张报表里都不存在。我能给客户的最好交代,也只是一个用当月筛选使用量倒推出来的量级,误差大得不好意思写进结案报告。
这件事之后我给自己加了一条规矩:凡是要把一个字段提到列表项或筛选器上,先花半天核一次它的真实覆盖率与值域,再谈设计。这半天的成本,和后面那三个月比起来,实在便宜得不像话。数据质量这条线上的监控该怎么搭,在掉量之前抓住事故那篇的框架可以直接套用。
还有一句总结,我觉得比上面所有细节都更该记住:属性缺失会让用户跳过你,属性错误会让用户跳过你之后还觉得是你的问题。前者你看不见,后者你看得见,但看得见的时候通常已经晚了三个月。
常见问题解答
列表项上到底放几个属性才算够?
先把五项通用的配齐——价格、名称或品类词、缩略图、评分与评价条数、变体,然后再加一到三条品类专属的,总数就到头了。
判断够不够,不要数字段个数,去看用户的行为。折返率如果长期高于四成,说明还差;如果已经降到两成上下,而加购率同步在涨,那就够了,再加只会稀释注意力。
还有一个很土但很准的自查:把自己的列表页截一屏给一个不懂这个品类的人看,问他能不能说出这几件商品的区别在哪。说不出来,就是不够。想再客观一点,可以拿查询变体覆盖度的测法换个角度检查同一批商品。
改版之后列表页点击率掉了,是不是做砸了?
多半没有,但要用另外几个数来确认。
补齐属性之后点击率下降是预期之内的:以前用户必须点进去才能判断,现在在列表页就能排除掉不合适的,那批“只为查一个数”的点击自然消失了。真正该看的是加购率、列表页到加购的转化率,以及每次会话浏览的商品页数——前两个应该涨,第三个应该降。
如果点击率掉了、加购率也掉了,那才是真的出问题,优先查两件事:属性值本身是不是错的,以及新加的元素有没有把价格或图片挤到了不显眼的位置。排序规则最近有没有被人动过也值得查一眼,分类页的排序改造那类改动常常没人通知。
属性数据只有六七成覆盖率,是先上线还是先补数据?
先补,别上。
覆盖率不够时,缺失的那部分不会被读成中性,会被读成否定——用户看到八件写了防护等级、四件没写,他判定那四件不防水。这个损失通常大于另外八件带来的收益。
操作上按属性性质分档:安全与适用性相关的要九成五以上,规格比较型九成以上,描述型八成以上,法定必显项必须百分之百。达不到就整个类目不显示这一项,等补齐再统一放开。
还有一个前提别忘了:这里说的覆盖率是“能被用户读懂的值”的比例,不是字段非空的比例。把待确认、短横线、内部编码这些剔掉之后,很多站的真实数字会比报表上低三成。
卖到欧盟的话,列表页上有哪些信息是法律强制的?
至少四类,分别来自四部不同的法规,而且都明确写了线上购买同样适用。
第一类是通用产品安全条例要求的:制造商名称与联系方式、欧盟境内责任人信息、能识别产品的信息(含一张图片)、以及适用的警示与安全信息。第二类是玩具类的年龄区间等会影响购买决策的警示。第三类是纺织品的纤维成分,法条里直接点了目录这个场景。第四类是能效品类的标签,或至少是能效等级与等级范围。
落地方式要硬:该市场该类目的必显字段缺任意一项就不允许上架,已上架的变成缺失状态要自动下架并告警。做成提醒是没用的,大促前一晚一定会被点掉。
商品feed里的必填字段和页面显示的字段要保持一致吗?
不需要完全一致,但必须知道差在哪儿、为什么差。
三套规则的必填定义本来就不同:feed的核心必填是七项,结构化数据这边商品层必填三项、报价里价格必填,而页面上的取舍还要受屏幕空间限制。真正的风险不在不一致,在没人对过账。
建议做一张对照表,横轴是页面、feed、结构化数据、法定四栏,纵轴是你实际用的属性,逐格填当前状态。填的过程中一定会冒出几行互相矛盾的——那几行就是要修的。填的时候按实际抓取到的数据填,别按字段定义填。
减法实验会让部分用户体验变差,有没有更稳妥的替代?
没有等效的替代,只有把风险控住的做法。
控住的办法有三条:流量比例压到最低可用水平、周期只跑到样本量达标就停、以及绝不拿法定必显项和价格主图来做。做到这三条,损失通常远小于因为迟迟无法决策而拖着不改的成本。
如果实在不能接受,退一步的做法是低成本试点:挑一个类目、几百个SKU手工把数据补齐,只在这个类目上线两周,跟同期的其他类目做对照。它没有随机实验那么干净,但方向性的信号足够用,而且不会让任何人的体验变差。
DTC品牌站没多少评价,评分那一格该怎么办?
先接受一个事实:这一格空着的代价,比综合电商小,但不等于零。
相关研究里给过两个数:约62%的用户在一个不熟悉的品牌上下单前会自己去做一轮外部调研,测试过程中真的中途离站去找信息的占29%。也就是说这一步没有消失,只是搬到了你看不见的地方,而离站的人不保证回来。
可行的做法有三条:第一,别把评价位空着,哪怕只有个位数的真实评价也比什么都没有强;第二,把用户离站去找的那类信息尽量提前放在自己站上,比如第三方检测、材质来源、真实使用场景的图;第三,在列表项上用别的确定性属性去补位——参数、认证、尺寸这些客观信息,在缺少社会认同时会被赋予更高的权重。
权威参考资料
本文标题:《用户扫完一整屏商品一个都没点开,这件事在你的报表里等于没发生》
本文链接:https://zhangwenbao.com/product-list-item-attributes-silent-rejection.html
版权声明:本文原创,转载与引用请注明作者与原文链接。许可协议: CC BY 4.0