商品都上传成功了，平台为什么还是看不懂你卖的是什么？

先给结论

因为“上传成功”通常只是一张接收收据。

它说明数据进入了 Feed、接口、抓取或连接器流程，却没有同时证明五件事：平台最后处理出来的商品记录是不是你以为的那一条；这条记录在指定国家和展示范围内是否具备资格；用户看到的页面、结构化数据和结账承诺是否一致；商品是否真的获得过曝光；这些曝光是否带来了合格的业务结果。

所以，面对这个问题，最危险的做法不是少加了几个关键词，而是把 submitted 当成 processed、把 approved 当成 served，再用一次手工搜索、一次标题波动或一个 AI 补值替代证据。

正确顺序不是先做一轮“Feed 优化”，而是先确认平台正在处理哪一件可购买商品、读到了什么事实、哪个来源改写了它、资格在哪个范围成立，以及有没有 item-level 的真实展示证据。

一、“上传成功”到底证明了什么？

一场常见复盘是这样的：后台显示同步完成，广告团队却说一些商品没有 Shopping impression；商品团队发现平台里的标题或类目和网站不同；网站团队又说页面明明有价格与库存。

这时，每个人都可能说对了一小段，但没人回答同一个问题。

把链路拆开，会更清楚：

• Submitted： 某个来源提交了一个 item 和一组字段。
• Processed： 平台合并数据源、应用规则并完成处理，形成最终商品记录。
• Eligible： 这条记录在某个国家、destination 或 reporting context 下具备参与资格，或至少没有被对应 issue 阻断。
• Served： 商品在某个查询、展示面或 Campaign 范围内真正获得 impression，随后可能有 click。
• Result： 点击后产生了有效购买或其他声明过的业务结果，并进一步进入利润与现金判断。

商品理解核验图 1

Google Merchant API 的当前说明把最终 processed Product、按 context 和国家拆分的状态、以及 item-level issues 分开。Google 的商品表现说明也把 approval、impression、click 和 purchase 分成不同指标。

这意味着：一个 approved 商品可以仍然是零 impression；一个被你手工搜到的商品也不能代表目录整体健康；一次购买更不自动证明广告增量、利润或现金。

老板现在要问的不是“平台有没有收货”，而是：我们最后能够直接证明到哪一层？

二、平台首先要知道：究竟是哪一件可购买商品？

商品数据最基础的问题先在 identity；文案要等确切商品身份明确以后再审查。

在一个简单目录里，商品、SKU、页面和价格可能一一对应。但现实目录常常有父商品、颜色和尺寸变体、套装、multipack、自有品牌、制造商品牌、汽车配件适配关系，以及一个页面展示多个可购买 offer。只要这些对象被混在一起，后面每个字段都可能“看起来有值，却描述错了东西”。

一件可审查的 offer，至少要把以下对象连起来：

• 真实可购买的商品或变体；
• 稳定的 item ID 与 item group 关系；
• 选中该变体后可验证的 URL 或页面状态；
• 制造商确实分配的 GTIN、MPN 与 brand；
• 该变体自己的尺寸、颜色、材质、价格和库存；
• 适用的国家、语言、Feed label 与 destination；
• 如果是 fitment 商品，物理商品与适配声明之间的真实关系。

商品理解核验图 2

这里有两个很容易犯的错。

第一个错，是因为批量收集标识符很麻烦，就把确实存在的制造商标识写成“不存在”，甚至生成一个 GTIN。Google 的制造商商品标识符说明明确要求使用制造商分配的值；拿不到时应保留缺口，不能猜测、借用相似商品值或用内部 SKU 冒充。与此同时，不是每件商品都有 GTIN，自有制造、定制商品、bundle 和 variant 也有各自条件。真实答案可能是“确实没有”，也可能是“尚未解决”，两者不能混用。

第二个错，是为了适配更多查询或测试标题，把一个没有实质差异的 offer 复制成多个 Feed ID。不同 ID 和 URL 不会自动创造多个真实商品，反而可能破坏身份与历史连续性。

因此，任何标题、类目和属性动作之前，都应先冻结 exact offer：哪一个市场、哪一个变体、哪一个真实页面、哪一组制造商事实。身份没有解决，所谓“优化”只是在不稳定对象上继续加工。

三、完整不等于正确，unknown 也不是空白

目录治理常把完整率当作目标：字段越多越好，空值越少越好。这个方向只有在一个前提下成立——填进去的值适用于这件商品，而且有可追溯证据。

平台字段通常不是“所有商品都必须填写”的一张固定清单。要求会随商品类型、变体、国家、destination 和使用方式变化。某个属性可能在一个品类中是 required，在另一个品类中只在特定条件下需要，或根本不适用。

为了避免“填满即正确”，可以给每个关键字段保留五种事实状态：

• 状态: verified · 含义: 有权威来源并与 exact offer 对齐 · 安全处理: 可以提交，并保留来源与时间
• 状态: undisclosed · 含义: 真实值可能存在，但当前来源没有披露 · 安全处理: 保留空白并寻找 owner，不能猜
• 状态: unresolved · 含义: 多个来源或记录无法确认哪个正确 · 安全处理: 阻止批量覆盖，交给人工核验
• 状态: not-applicable · 含义: 有证据证明该属性不适用于该商品 · 安全处理: 记录判断依据，不填伪值
• 状态: conflicted · 含义: 来源之间给出不同值 · 安全处理: 保留冲突及时间，找到权威事实源

商品理解核验图 3

独立研究也显示商品属性可能分散、缺失并随时间变化；WDC-PAVE 还把抽取与 normalization 分开。但这些 benchmark 只能说明目录异构是真问题，不能证明 Google 的内部逻辑，更不能把“文本里没找到”写成“商品不适用”。

对自动化来说，最有价值的能力不是把每个空格补满，而是让缺口保持可见：指出缺少哪个事实、来源冲突在哪里、需要谁确认。AI 可以帮助抽取、标准化、比较和提出候选，但没有权力发明品牌、标识符、fitment、价格、库存或客户承诺。

四、同一个字段，可能经过四个主人

很多团队对着 Merchant Center 里的一个值争论，却没有追问它从哪里来。

以标题为例，网站上可能同时存在商品主标题、SEO 标题、变体文本和结构化数据；连接器可能选择其中一个字段，也可能套一层模板；Merchant Center 的 attribute rule 还可能拼接品牌或覆盖值；最终展示面又可能因为截断或产品数据定制而呈现不同文字。

所以“平台里的标题为什么不是 Shopify 主标题”没有通用答案。要检查的是：

• commerce source 中的原始值和更新时间；
• 当前使用的连接器、Feed、API 或自动发现来源；
• mapping、模板、primary/supplemental join 与 active rules；
• final processed value；
• 观察对象是商品详情、preview、free listing，还是实际展示。

类目也一样。Google product category 是 Google taxonomy 中的分类；product_type 是商家自己的 taxonomy，可用于组织和报告。Feed label、custom labels 与 listing groups 又分别服务数据源范围、经营分组和投放范围。把这些字段都叫作“类目”或“标签”，会让团队在错误的控制面上修问题。

商品理解核验图 4

补充数据源也不是万能修复。它通常要与 primary source 中已有商品准确匹配，并通过适用的规则补充或覆盖字段。若 ID、Feed label、语言、币种或更新时间不一致，团队看到的就可能是“部分 SKU 生效、部分不生效”。安全做法不是默认删除 supplemental source，也不是默认把字段放回 primary source，而是检查 exact join、原始值、规则和 processed value。

这里最重要的操作原则是：比较相邻两层，在第一次出现差异的地方停止。 如果 commerce source 已经错误，先回到商品 owner；如果连接器 mapping 错，修 mapping；如果规则覆盖错，修规则并保留 rollback；如果 processed record 正确而页面错，交给网站 owner。不要同时改四个地方，然后用流量波动猜哪个动作有效。

五、Feed、页面、结构化数据和结账必须说同一件事

平台看到的商品记录，最终要对应客户能够购买到的商品。价格与库存直接承载客户承诺；把它们当作后台装饰会制造事实冲突。

对于一个有变体的商品，父页面可能显示价格区间，但广告或 listing 对应的是一个具体 offer。选中该变体后，页面价格、结构化数据、Feed price、sale price、币种和结账金额应描述同一件事。库存也要在 exact variant 上对齐：Feed 说 in stock，页面却只允许 preorder；结构化数据继承父级库存，结账又无法下单，都会造成冲突。

安全检查要同时保存 submitted 与 processed price、sale date、currency、exact variant 的页面与 structured data、是否可下单、结账金额与履约承诺，以及各层更新时间。

自动 item update 可以缓解某些被平台观察到的价格或库存不一致，但它不是商品事实 owner。平台修正一次值，也不能为陈旧库存、错误页面或虚构到货日期背书。真正的 source of truth 仍需要业务 owner，且客户看见的承诺必须能兑现。

做到一致，只能说明这一层更可靠。它没有证明市场存在需求，也没有证明这个商品会进入某个查询、获得 click 或产生利润。

六、修完字段后，先看资格，不要直接看 ROAS

字段修好以后，团队常常直接去广告后台看 ROAS 有没有变化。这跳过了至少两层证据。

第一层是 final processed Product。要确认新值已经处理完成，而不是只确认源文件已经上传。第二层是 eligibility 与 item issue。状态可能随 country、destination 和 reporting context 不同；同一个商品可以在一个范围 active，在另一个范围被 issue 阻断。

一个实用顺序是：

• 对照 exact offer 检查 raw submitted 与 final processed value；
• 记录 processing 状态与最后更新时间；
• 查看 affected attribute、issue severity、resolution guidance 和对应 context；
• 修复 owning layer，而不是只让提示消失；
• 等待处理后复核 issue 和资格；
• 资格恢复后，再独立观察 item-level impression 与 Campaign inclusion。

Analytics、Search Console 等界面的 Merchant 提示只是路由线索，不是 issue authority 或流量证明。Issue 消失也不证明商品已重新进入目标 Campaign 或恢复展示。

七、Approved 仍然可能没有 impression

这是最容易把商品问题和广告问题混在一起的地方。

当 processed record 正确、页面一致、指定 context 下也 approved，仍然可能没有 item-level impression。此时至少要保留以下竞争解释：

• 目标市场的真实需求不足，或当前查询不需要这件商品；
• 商品价格、运费、图片或 Offer 在竞争中没有获得展示机会；
• Campaign、asset group、listing group 或商品过滤没有包含它；
• Feed label、country、language 或 destination 与投放范围不一致；
• 预算、出价、目标、学习信号或 auction 条件限制 delivery；
• 新记录或修复仍在处理、重新评估或报告延迟中；
• 报告分母、时间和展示面与手工观察并不相同。

因此，手工搜索没找到商品只能成为一个观察，不能替代 impression report。账户层面大部分商品 approved，也不能解释为什么只有一小部分 offer 获得流量。

如果商品已有 impression，却没有 click 或合格购买，也不应继续往 Feed 塞字段。W6-B 的职责，是把商品事实与资格交接给查询、Campaign、页面、测量和经营 owner，而不是替它们作结论。

八、一张 Product Understanding Record，找到最早断点

下面是一张完全合成的示例。它不对应任何客户、账户、Campaign、SKU、预算或真实指标。

假设一件虚构商品有两个尺寸变体。团队发现其中一个变体已上传，但 Merchant Center 显示的库存和网站不一致，并且没有观察到 item-level impression。

• 记录层: Exact offer · 合成证据: 指定市场、指定尺寸、稳定 ID、对应页面选择状态 · 当前判断: verified · Owner / 下一步: 商品运营冻结检查范围
• 记录层: Identifier · 合成证据: 制造商记录存在 brand 与 MPN；GTIN 状态待确认 · 当前判断: unresolved · Owner / 下一步: 向制造商事实 owner 核验，不生成值
• 记录层: Commerce fact · 合成证据: 该尺寸当前可下单，但为延后发货 · 当前判断: verified · Owner / 下一步: 库存 owner 确认真实承诺与日期依据
• 记录层: Submitted value · 合成证据: connector 提交为 in_stock · 当前判断: conflicted · Owner / 下一步: 保留原始 payload 与时间
• 记录层: Rule / processed · 合成证据: active rule 没有改 availability；processed 仍为 in_stock · 当前判断: processed-divergence · Owner / 下一步: 连接器 owner 修映射并准备 rollback
• 记录层: Page / markup / checkout · 合成证据: 页面写延后发货，markup 继承父级现货，checkout 接受订单 · 当前判断: conflicted · Owner / 下一步: 网站与结构化数据 owner 对齐 exact variant
• 记录层: Eligibility / issue · 合成证据: 指定 destination 报 availability mismatch · 当前判断: blocked · Owner / 下一步: 完整修复后复核，不提前申诉
• 记录层: Served evidence · 合成证据: 当前没有可用 impression 证据 · 当前判断: insufficient-evidence · Owner / 下一步: 资格恢复后再观察 item-level delivery
• 记录层: Business result · 合成证据: 无 · 当前判断: not-assessed · Owner / 下一步: 不用 ROAS 或利润解释尚未发生的展示

商品理解核验图 5

这张表的价值，不是一次修好所有问题，而是阻止团队在一个证据缺口上同时改 Feed、页面、Campaign 和预算。

一次复盘最后只批准一个主要动作。例如：修正该变体的 availability mapping，并同时让页面 markup 与客户可见承诺对齐。记录 owner、exact scope、保持不变项、重新处理后的观察窗口、停止条件和恢复路径。资格复核以前不加预算；资格恢复以后，若仍无 impression，再把记录交给 Campaign 与 demand owner，而不是继续重写商品事实。

自己的版本至少要保留 exact offer scope、事实 owner 与状态、raw/submitted/processed values、mapping 与 rules、selected page/markup/checkout、status 与 item issue、served 和业务证据，以及 competing explanations、owner、one action、window、stop 与 rollback。

最后，把问题改写成可以工作的提问

“平台为什么看不懂我的商品？”太大，也容易把所有低流量都推给 Feed。

更有用的问法是：

对这个 exact offer，在这个市场和 destination 中，权威商品事实经过哪个来源和规则成为 final processed record？页面与结账是否一致？当前证据只到 submitted、processed、eligible、served，还是已经到 business result？最早的差异由谁负责？

如果团队能回答这组问题，就不需要靠标题公式、插件推荐、固定等待期或 AI 猜测来安慰自己。它会得到一个更诚实的结果：可能是商品事实错了，可能是资格还没恢复，可能是 Campaign 没有包含，也可能只是当前证据不足。

DataFlowForever 可以在声明过的只读范围内，协助团队把一个小而明确的商品样本整理成这张 Product Understanding Record，区分商品、页面、资格、投放、测量与经营 owner，并给出一个有观察窗口和停止线的下一步。实际 Feed、Merchant Center、页面或广告变更仍需要单独授权与执行责任；我们不承诺曝光、ROAS、收入、利润或 Lift。

主要来源与边界

• Google Merchant API：读取最终商品数据与 item issues
• Google Merchant Center：制造商商品标识符
• Google Merchant Center：商品数据规范
• Google Merchant Center：商品数据优化建议
• Google Merchant Center：商品表现
• MAVE：多来源商品属性值抽取数据集
• WDC-PAVE：商品属性值抽取 benchmark

官方资料定义平台机制，不证明任何账户的当前实现、流量或结果。独立研究说明目录异构与缺失问题，不代表 Google 内部处理，也不提供可迁移的效果数值。社区来源只用于匿名问题语言、冲突和反例；本文未使用用户名、原文、账户数据、固定门槛或自报结果。