商品页写着 USD44.90、有货，结构化数据却写 USD49.90；feed 与结构化数据一致，结账又拒绝该商品。应该改哪一层？
不一定是与多数不同的那一层，更不能自动选择最高价或最低价。先确认所有观察对应同一商品、规格、市场、币种、数量和适用报价条件，再与商家批准的定价和履约状态比较。
Google 的 10 月 15 日 Universal Cart 公告提供了重新检查这些问题的契机。美国上线范围涉及跨商家商品保存、降价及补货提醒，以及由 UCP 支持的结账体验。公告中的 Shopping Graph 规模为 60+ billion，也就是 600 多亿条商品记录。规模大，不等于独立站某个商品的冲突数据就正确。数据一致性通过，也不保证接入 Universal Cart 或获得某种购物展示。
本文解决“差异在哪里、如何确认修好”。协议角色见代理商务协议比较，字段覆盖见 Product schema 清单；这里的产出是一份可重复的证据记录和同条件复测。
1. 先固定比较键
记录 SKU 或 offer ID、颜色／尺码／容量、目标市场、币种、数量、登录或会员状态、促销条件和观察时间。保留包含规格选择的准确落地 URL。黑色水壶与白色水壶，不能因为商品名称属于同一系列就混在一起。
Google 的商品规格文档说明了规格关系与不同报价 URL。比较价格或库存之前，先跟到实际选中的规格。系列级“起价”不一定是所选 SKU 的价格；如果导航或 URL 规范化丢掉必要选择，可结合 canonical 与语言检查清单排查。
下文的本地练习固定为 NS-KETTLE-BLK、黑色、美国市场、USD、数量 1、无登录和促销。这些是虚构输入，不是真实商家目录。
2. 独立获取四层数据
| 数据层 | 获取什么 | 暂时不能直接比较的常见原因 |
|---|---|---|
| 可见商品页 | 所选 SKU／规格、当前金额与币种、库存文字及购买控件 | 展示的是默认规格或全系列起价 |
| Product/Offer | 匹配的 Product 标识及其实际 Offer、价格、币种、库存、URL | 模板输出了其他规格、旧 Offer 或多个含糊节点 |
| 商品 feed | 准确商品 ID、规格、链接、适用价格与库存、导出／提交时间 | 取到父商品或旧导出，忽略了实际生效的促销价 |
| 结账 | 同一商品和数量、商品单价、库存判断、适用条件 | 地址、账号等级、数量或促销条件不同 |
保留原始值，也保留规范化后的值。若 JavaScript 会改写商品信息，应同时检查服务端 HTML 和渲染页面。存在多个 JSON-LD 节点或 Offer 时，不要简单提取遇到的第一个价格，而应匹配商品与报价标识。schema 检查流程能帮助找到标记，但 JSON 合法不代表它符合实际销售数据。
真实 feed 还要区分：查的是源导出、已提交版本，还是平台处理后的商品。它们可能对应不同时间；刚生成文件，不证明 Google 已处理。审计记录不要公开凭据、账号标识或顾客资料。
3. 复现价格、库存和身份三种故障
下载并检查独立本地示例服务器，然后运行：
node server.mjs
打开 http://127.0.0.1:4335/inspect?case=price。服务器仅监听本机回环地址，使用虚构 Northstar 数据，没有 Merchant Center 连接、UCP 结账端点、订单创建或付款。feed JSON 是规范化教学快照，不是 Google Merchant API 的上传报文；最小 JSON-LD 只演示被检查字段，不是完整富结果模板。测试完用 Ctrl+C 停止。
我们于 2026 年 10 月 18 日复现四种情景，分别读取可见 HTML、Product/Offer、feed 快照和只读结账预览，总计十六条数据层观察：
| 情景 | 实际观察到的差异 | 诊断结果 |
|---|---|---|
price | 同一黑色 SKU，页面44.90，Offer／feed／结账49.90 USD；都显示有货 | 身份一致，价格不一致，库存没有冲突 |
stock | 同一 SKU，各处均44.90 USD；页面／Offer／feed有货，结账预览缺货 | 身份一致，库存不一致，价格没有冲突 |
variant | 页面／Offer／结账是44.90的黑色 SKU，feed是39.90的白色 SKU | 身份不一致，暂不进行价格和库存一致性判断 |
fixed | 四层都是黑色 SKU、44.90 USD、缺货 | 身份一致，两种冲突均消失；结账预览的库存判断不允许下单 |
这是受控示例截图，不是 Google 或客户账户。情景中的差异是有意设置的；截图本身不能证明真实商店的根因。
要查看原始响应，可将 case 值依次替换为 stock、variant 或 fixed：
curl -sS 'http://127.0.0.1:4335/product?case=price'
curl -sS 'http://127.0.0.1:4335/feed.json?case=price'
curl -sS 'http://127.0.0.1:4335/checkout-preview.json?case=price'
页面响应包含可见数据属性和 Product/Offer JSON-LD；另外两个响应提供 feed 与结账观察。/snapshot.json?case=price 是便于查看的汇总，但只读这个汇总不算独立核验四层数据。
4. 统一含义，不只统一数字
Google 的价格要求要求适用的价格与币种和落地页、结账保持一致，但并不是页面上的每个数字都必须相同。先区分：
- 单价与总额：按相同数量比较商品单价，税费、运费和其他费用分列；订单总额更高可能正常。应按目标国家的当前规则处理，不要将一个国家的税费口径复制到另一个国家。
- 原价与促销价：比较正在生效的报价及其有效时间。原价49.90加上有效促销价44.90，不等于上面刻意构造的普通价格故障。参阅 Google 的促销价说明。
- 公开价与附条件价格：会员、优惠券、阶梯数量折扣都要记录适用条件，不要用无条件报价去比需要另一种顾客状态的价格。
- 币种与精度：保留币种，不只保留符号。USD 示例可用整数分4490与4990比较，但不能假设每种货币都有两位小数。
- 库存：将
https://schema.org/InStock对应到相应 feed 状态，同时保留 preorder、backorder 及日期的区别。Google 的库存说明区分接受未来订单和不接受订单。
示例不计算税费、运费，也没有促销。“未计算”不等于零，结账预览也不代表完整应付总额。这些限制是为了单独看清三种故障，不是可直接照搬到生产结账的模型。
5. 先定位旧值或错误层，再改数据
价格情景能证明不一致，却不能直接证明哪一个49.90是错的。要将四层观察与商家批准的目录或定价规则比较，再检查标识、版本／更新时间、导出计划、模板生成、客户端改写和缓存状态。它们是待验证假设，不是仅凭截图就能断言的原因。
| 差异模式 | 下一步应取得的证据 |
|---|---|
| 只有标记不同 | 模板数据源、重复 Offer 节点、服务端与渲染后状态 |
| 只有 feed 不同 | 商品映射、导出版本、接收／处理时间、所选规格 URL |
| 只有结账不同 | 数量、市场／账号规则、当前库存与预留状态、定价服务响应 |
| 标识不同 | 先修正商品／规格的关联，再比较金额 |
本地修复情景指定一个共享的黑色 SKU 记录：4490分、out_of_stock，四层都使用它。真实商店不能随意选最低价，也不能把所有价格改成与旧页面一致。库存修复还应反映是否真的能接受订单；只改标签、不改履约行为并不够。
技术 SEO与页面审计可处理发现和响应问题，但库存、定价判断仍需保留商务系统证据。页面扫描器不是库存或支付的权威来源。
6. 用原始条件验收修复
重复同一落地 URL、SKU、市场、币种、数量和顾客状态。本地 fixed 情景要逐行核对四层，不能只看一致性汇总，并查看结账预览中的 stock_permits_order: false。测试不会下单。真实结账应在获得许可的测试环境核对购买控件和拒绝行为，不要为了证明问题去完成购买。
留下简明的前后对照记录：
检查时间 | 商品/规格 | 市场/币种 | 数量/顾客状态
可见页面 | 匹配Offer | 准确feed版本 | 结账观察
原始值 | 规范化规则 | 差异 | 修复版本
同条件复测 | 仍未验证的边界
还应在相关导出和缓存更新周期之后复测。一次即时本地通过，不证明旧值不会再出现。Google 侧处理、商家资格和购物界面展示是独立观察，不能因为自己的端点一致就一并标记通过。
真正实用的完成标准是：顾客作决定和尝试购买时，同一报价在各处说的是同一个事实。无论商家是否接入 Universal Cart，这都能提升数据可靠性。
