商品 Feed QA 不是把一张表格填完整。它是在确认 Shopify 后台、商品页、结构化数据、Merchant Center、广告系统和库存系统是否讲同一套商品事实。Google Merchant Center 的产品数据规范明确指出，准确且格式正确的商品数据会影响广告和免费 listing，错误、缺失或冲突的数据可能造成 disapproval、eligibility 限制或展示问题。
小团队最常见的问题不是不知道要填字段，而是不知道谁是 source of truth。title 从哪里来？GTIN 是条码还是 SKU？价格以 Shopify 后台、落地页还是 feed 为准？availability 和 checkout 是否一致？本文用 title、GTIN、price、availability 四个高风险字段，建立一套上线前 Feed QA。
Feed QA 从商品事实开始
先建立商品事实表，而不是直接改 Merchant Center。每个 SKU 或 variant 至少要有稳定 ID、title、brand、GTIN 或 identifier status、price、sale price、availability、link、image、shipping 和 returns 信息。这个事实表要指定 owner：商品负责人管标题和属性，运营负责人管价格和库存，数据负责人管 feed 和 structured data，客服负责人管政策承诺。
如果没有 source of truth，feed 修复会变成平台报错驱动。今天 Merchant Center 报 title 问题你改 feed，明天 Shopify 商品页没改，后天结构化数据仍是旧标题。真正的 QA 应该从源头修，而不是在每个下游系统做临时补丁。
Title、价格、库存、GTIN 分别查什么
Title 要准确描述产品，并和落地页标题一致。Google 产品数据规范要求 title 清楚识别你销售的商品，不要堆促销词、全大写或噱头字符。价格和 availability 更敏感，Google 要求 availability 与落地页、checkout 和 structured data 匹配；如果缺货，落地页仍要清楚显示价格。
GTIN 是 UPC、EAN、JAN、ISBN 等全球贸易项目编号，不是你自己在 Shopify 里编的 SKU。Google 的 unique product identifiers 指南强调，当真实 identifier 存在时，GTIN、MPN 和 brand 帮助系统区分商品。不要为了消除警告就编造 GTIN，也不要把内部 SKU 当 GTIN。
什么时候不要发明 identifier
如果商品确实没有 GTIN，比如定制品、自有手工品、部分配件或某些 private label 商品，你应该按平台要求正确表达 identifier 状态，而不是随便填一个看起来像条码的数字。错误 GTIN 比缺失 GTIN 更危险，因为它可能把你的商品和另一个真实商品混淆。
内部 SKU 的工作是帮助你管理库存和履约；GTIN 的工作是帮助外部系统识别全球商品身份。两个字段都重要，但不能互相替代。Feed QA 表里应该同时有 SKU、variant ID、brand、GTIN/MPN、identifier source 和谁确认的记录。
商品页、结构化数据和 Feed 必须一致
Google Search Central 的 Product structured data 和 Merchant listing 文档都指向一个原则：结构化数据应该反映页面可见内容，商品信息要让系统和用户都能理解。不要让商品页显示 49 美元，feed 提交 39 美元，structured data 里还是旧库存。系统可能抓到其中任何一个版本，冲突会降低可信度。
一致不代表每个文案完全相同。商品页 title 可以更适合用户阅读，feed title 可以更结构化，但核心事实不能冲突：是什么商品、哪个变体、什么价格、是否有货、能不能购买、配送和退货承诺是什么。QA 的目标是事实一致，而不是每个字段机械复制。
Shopping 或 PMax 前的 QA 工作流
先抽核心 SKU，不要一开始全量重写。选出广告预算最高、利润最高、库存最紧、报错最多的 20 个商品。逐个检查 Shopify、商品页、structured data、feed、Merchant Center diagnostics 和 checkout。每个 mismatch 都写 owner 和修复位置：源头、feed、页面、结构化数据、库存同步还是价格规则。
修复后不要马上放量。等待 feed 处理和 Merchant Center 状态更新，再用小预算验证展示、点击、商品组和转化。商品数据变化也要进入 change log：改了哪个字段、影响哪些系统、什么时候复查。Feed QA 是持续治理，不是一次性清单。
商品 Feed 字段 QA 矩阵
| 字段 | source of truth | 不一致症状 | 修复负责人 |
|---|---|---|---|
| title | Shopify 商品事实和落地页 | Feed title 与页面不一致或含促销词 | 商品负责人 |
| GTIN | 品牌/供应商条码资料 | 用 SKU 冒充 GTIN 或编造编号 | 商品数据负责人 |
| price | Shopify 价格和结账价 | Feed、页面、结账价格不一致 | 运营负责人 |
| availability | 库存系统和结账可购买状态 | Feed 显示有货但页面缺货 | 库存负责人 |
| structured data | 页面可见商品事实 | Product/Offer 与页面或 feed 冲突 | SEO/数据负责人 |
把这篇文章变成可复用的运营闭环
不要把这篇文章当成一次性阅读材料。围绕 Feed QA 从商品事实开始 / Title、价格、库存、GTIN 分别查什么 / 什么时候不要发明 identifier 这些判断点，给团队留下一个能重复执行的小闭环：什么时候检查、谁负责、证据放在哪里、什么情况暂停发布、什么情况继续推进。最后产出的不应该只是“看过了”，而应该是一条带日期、带负责人、带结论的运营记录。
商品 Feed 字段 QA 矩阵 里的 title / GTIN / price 可以当成最低证据集合。只要其中一项无法验证，就先把页面、广告、Feed、事件或政策标成未放行，并写清楚缺的是什么证据。这样做不是为了让流程变慢，而是为了避免电商团队最常见的误判：指标动了，大家开始反应，但没人知道当时的店铺、追踪、内容和 offer 是否真的处在可判断状态。
执行完这张清单以后，再进入文中链接到的 Ecomwith 工具、教程或答案页。本文先帮你做第一层判断；后续页面负责计算、审计、记录或修复具体问题。这样，读者能顺着一个清楚的操作路径继续行动，搜索系统也更容易理解页面之间的关系。