支柱指南 / product-knowledge-chain
Feed 不是表格：它是 Google 理解商品的知识链
从商品后台到 GMC，再到 Shopping 与 AI 场景，真正传递的是一组可核验、可区分、可交易的商品事实。
先把本篇问题写成一句话，再确认它影响的是流量、Feed、页面、结账、EDM 还是数据复盘。
围绕商品字段、网站事实、诊断状态、审核反馈和广告理解留下证据；稳定原则。
直接判断：Feed 的核心任务不是“把商品传上去”，而是让平台持续回答四个问题——这是什么、它和相邻商品有什么区别、现在是否可交易、用户点进去能否看到同一事实。只把 Feed 当成字段表，往往会得到“商品已通过，但匹配不准、点击不稳、放量困难”的结果。
先做判断
先不要问还缺哪个字段，先问三个更上游的问题：
- 商品源数据里是否已经存在稳定、真实的事实？
- 这些事实经过导出、规则、补充数据源后，有没有被改写或丢失？
- Feed、GMC 抓取结果和落地页是否在同一时间窗口内表达同一件事？
如果第一问是否定的，后面只能制造更整齐的空白；如果第二问有问题，应修同步与映射；如果第三问不成立，先修一致性，再谈广告结构。
知识链如何流动
一条健康链路可以写成：
商品后台的真实事实 → Feed 的结构化表达 → GMC 的校验与归一化 → Shopping／自动化投放的检索和排序 → 商品页的交易承接。
商品后台负责“真”，Feed 负责“说清楚”，GMC 负责“能否被接受与使用”，Campaign 负责“把哪些合格商品带入哪些拍卖”，页面负责“兑现承诺”。其中任意一层把责任推给下一层，系统就会出现看似投放问题、实为商品知识断裂的问题。
AI 商品发现让这条链更重要，而不是更不重要。自动系统会综合结构化商品数据与可访问的网站内容来理解复杂需求；如果标题说“防水”，页面只写“日常使用”，配送承诺又在不同位置互相冲突，模型得到的不是更丰富的知识，而是互相打架的证据。具体 AI Shopping 能力、字段名、适用市场与展示位置变化很快，执行时必须按当日 Google 官方资料复核。
诊断框架：五层证据
第一层是身份：稳定商品 ID、真实品牌与合法标识符能否指向同一商品。第二层是区分：型号、材质、颜色、尺码、容量等信息，能否把相邻变体分开。第三层是交易：价格、库存、促销有效期是否及时。第四层是服务：配送范围、送达预期、退货条件是否明确。第五层是页面：用户和抓取系统能否在落地页读到同样的信息。
排查时从第一层向下走。身份错了，历史学习会断；变体错了，查询与落地页会错位；交易事实错了，会形成拒登或坏体验；服务信号错了，会削弱信任；页面不一致，则前四层都难以被验证。
字段投入可结合 商品理解的字段优先级 继续拆解；当团队开始互相甩锅时，再用 Feed、GMC 与 Campaign 的责任边界 划清归属。
常见误判
- “商品已批准，所以 Feed 没问题。”批准只证明通过了当前最低门槛，不证明信息完整或匹配准确。
- “标题加更多词就能覆盖更多流量。”没有真实商品事实支撑的词，会让匹配和页面承接同时变差。
- “PMax 会自动理解网站，不用维护 Feed。”自动化扩大了输入面，也放大了脏数据和矛盾信息。
- “页面写对就行，Feed 晚一点更新没关系。”价格、库存等事实存在时间差时，短暂不一致也可能造成实质风险。
验证清单
- 随机抽取父商品与两个变体，逐层比对身份、区分属性和落地 URL。
- 对比商品后台、最终 Feed、GMC 已处理值与前台页面，而不是只看导出文件。
- 检查价格、库存、促销、配送和退货是否有明确更新时间与负责人。
- 用真实用户语言搜索商品，观察平台展示的标题、图片与落地商品是否一致。
- 记录平台自动改写或抓取覆盖的现象，但不要把自动修正当成主同步方案。
- 涉及字段要求、政策资格、界面入口和 AI 生成内容标注时，回到当前官方文档逐项复核。
适用边界
这套框架适合已经有商品目录、准备或正在使用 Shopping、PMax 及其他商品发现渠道的团队。它不是账户注册教程，也不能替代具体品类的政策审查。医疗、金融、成人、受管制商品等敏感品类，还需要独立的合规判断。本文讲的是长期有效的知识链原则；平台支持的字段、自动功能、国家范围和审核口径都属于使用前必须复核的动态层。