一句话：购物类问题是用商品事实回答的——属性、约束条件、比较——所以电商的工作单位是商品页和它的属性，不是品牌页和它的定位。
品牌看板为什么看不到这件事
用品牌问题搭起来的衡量集合，告诉你的是这家公司有没有被点名。而购物者问的是「1500 元以内、宽脚型、防水的登山靴」。引擎是用商品属性回答这个问题的，于是一个品牌完全可能在品类层面可见度很好，同时它的商品没有一件能满足哪怕一道带约束的问题。
从商品目录出发，不从问题清单出发。一件从不出现在任何答案里的商品，在品牌看板上不会显示为问题——它只是在数据里根本不存在。
属性就是全部
带约束的问题是靠匹配属性回答的。如果属性没有以机器可读的形式写出来，这件商品就没法被匹配上：
| 属性类别 | 它为什么决定能否入选 |
|---|---|
| 价格与币种 | 几乎每个购物问题都带预算约束 |
| 尺码、版型、尺寸 | 最常见的淘汰项，也是最常被留在图片里的 |
| 材质与兼容性 | 「能不能配合 X 用」这类问题靠它解决 |
| 可购状态与配送区域 | 买不到的商品，再合适也会被排除 |
| 明写的局限 | 让引擎把你匹配到对的问题上，而不是错的 |
困在图片里、规格 PDF 里、或者只有交互之后才渲染的规格选择器里的属性，对引擎来说都不算属性。
电商特有的自伤
- 变体由客户端渲染。价格和尺码藏在选择器后面，服务端渲染的页面两样都没有。
- 描述写成了文案，不是事实。「为冒险而生」匹配不上任何东西；「防水 10000mm、480 克、欧码 36–48 含宽脚型」能匹配很多东西。
- 商品结构化数据与页面不一致。
Offer里写着页面早已不显示的价格，比不加标记更糟。 - 优化了分类页，冷落了商品页。答案引用的是含有那条匹配事实的页面，而那几乎总是商品页。
怎么衡量
从商品目录出发建问题集：对每件主力商品，列出买家可能会问、而它本该满足的那些带约束的问题。于是结论是一个覆盖率——你的主力商品里有多少件压根出现在任何答案中——这个数字比品牌提及率可操作得多，因为每一次缺席都指向一张具体的页面，而且通常指向一条具体缺失的属性。