纯文字版教程展开阅读
Merchant Center 的红点消失，不代表问题真的关闭。本课把警告、审核拒登、价格不一致、缺 GTIN、图片问题和重复属性缺失拆成可执行的分流、追溯、复核和复查流程。
用一张价格冲突单，从平台提示走到源头关闭
案例仍是 NorthPaw 20oz/Sage/US。活动在周一 09:00 生效，Shopify price、页面主价格和 Product structured data 已经是 24.99 USD；Merchant Center item 仍保留 $29.99，并出现 mismatched price。先记下 item ID、US/USD、issue 发现时间、平台比较时间和最新 data-source sync。若只截一张红点图，你甚至不知道它是在活动前抓到旧页面，还是 Feed 根本没有更新。
把四个时间排在一起：08:30 主来源最后同步 $29.99；09:00 Shopify 活动价生效；09:05 PDP 和 structured data 变成 $24.99；10:12 issue detail 记录 Feed 与页面不一致。差额是 $29.99 − $24.99 = $5.00，约等于原价的 16.7%。这不是“打折太大”的问题，而是数据更新时间错位。根因若是旧同步，就修同步顺序；根因若是 supplemental source 仍写 $29.99，就修覆盖层。两者都不需要再改一次已经正确的 Shopify 源价格。
automatic item update 即使暂时把展示价改成 $24.99，也只是平台用页面信号做了纠偏，不代表主来源已经健康。下一次上传仍可能把 $29.99 写回来。关闭条件必须同时覆盖 source field、feed/item preview、PDP prominent value、structured data 和 issue state；复核按钮是修复后的动作，不是用来试探平台会不会放过。
| 证据面 | 本案例值 | 能证明什么 | 不能证明什么 | 通过条件 | 失败动作 |
|---|---|---|---|---|---|
| Shopify source | $24.99 / 09:00 / US | 源字段和活动窗当前正确 | 渠道已经读取 | price + sale window + owner | 源错先修源，不在平台打补丁 |
| Data source / item | $29.99 / 08:30 sync | 平台收到旧值或覆盖值 | Shopify 源头错误 | $24.99 + source name + new sync | 查 supplemental/rule/schedule |
| PDP + structured data | 24.99 USD / 09:05 | 买家和 crawler 当前可读页面事实 | 履约、货币和所有市场都正确 | 主价格、JSON-LD、币种一致 | 页面不一致则停止复核并修模板 |
| Issue detail | mismatch / 10:12 / affected item ID | 平台比较时发现的差异和范围 | 修复层和 root cause | 状态更新、范围不扩散、证据包完整 | 仍在就查新 crawl、源回写或扩大范围 |
PD-003 排错票：从 40 个受影响 item 到关闭
- 下载 40 个受影响 item，锁 target country、currency、issue 和发现时间。
- 先看最近 7 天有花费的 12 个 item；若价格/库存承诺错误，暂停这些商品池，同时保留完整 40 个修复范围。
- 逐 item 比对 source、override、feed row、PDP、structured data、sync/crawl timestamp。
- 只改根因层，重新提交/同步，记录 owner、change ID 和预计处理窗口。
- 样本 12 个和全量 40 个都回读；平台状态未更新前不恢复预算，也不重复点 review。
停止线：source/page/structured data 仍不同、同步未完成、issue 范围扩大、市场/币种对象不清，或 automatic update 只是掩盖主来源。临时停投不要伪造 out_of_stock；按当前官方规则使用适合的 pause 或 excluded destination 路径，并核对适用时限。
复核线：问题详情读清、根因层已修、源与页面一致、同步/抓取窗口已过、修复前后证据齐全，而且该 issue 当前提供 review 或 website check。提交后记录状态与下一复查日；红点消失后再抽查下一次同步。下面互动不能替代这组关闭条件。
本课产出：Merchant Center Feed 排错分流表
读完以后，你要能留下一个 Feed 问题分级表：问题级别、受影响 SKU、平台提示、字段来源、页面一致性、修复动作、负责人、复核证据和复核周期都写清楚。
这张表的目的不是让报错记录看起来专业，而是让下一位同事知道这个问题为什么优先处理、从哪里修、修完在哪里验证、什么时候可以提交复核。
先记住一个顺序：Needs attention、审核拒登、price mismatch 和 availability mismatch 不是同一种问题。先读商品级问题详情，再决定修源字段、暂停 SKU、等同步还是准备复核证据。
| 提示 | 先做什么 | 先不要做什么 |
|---|---|---|
| Needs attention | 记录受影响 SKU、目标国家、字段名、发现时间和严重程度。 | 不要只看红点，也不要没读详情就点复核。 |
| 审核拒登 / disapproved | 判断商品是否还能展示，必要时暂停受影响 SKU 或广告组。 | 不要把拒登当普通 warning，也不要让错误承诺继续花广告费。 |
| price mismatch | 同时查 Shopify price、sale_price、Feed 行、商品页主价格和 Product structured data。 | 不要只在 Merchant Center 里补一个价格，也不要页面没对齐就复核。 |
| availability mismatch | 查库存更新时间、Feed 同步时间、页面库存、结构化数据和履约承诺。 | 不要只把 availability 改成 out_of_stock 来止血，却不修同步节奏。 |
先把本课名词说清楚
Merchant Center 是 Google 管商品展示资格、商品数据和诊断问题的后台。你可以把它理解成 Google Shopping 商品能不能展示的体检表。
GTIN 是 UPC、EAN 这类商品条码编号的统称。它帮助 Google 识别商品身份。没有 GTIN 不一定不能投放，但品牌、型号、图片和页面事实要更稳定。
Product set / 产品集 是 Meta Catalog 或广告系统里按规则圈出来的一组商品，比如只包含热卖 SKU、清仓 SKU、某个集合页商品或高毛利商品。Merchant Center 排错本身不直接管理产品集，但 Feed 问题会影响后面产品集能不能稳定投放：如果价格、库存、GTIN、图片或分类在源头漂移，后面的产品集就会把错误商品继续分发给广告和再营销。
警告 通常表示商品覆盖、质量或优化空间受限；审核拒登 会直接影响商品展示资格。先处理不能展示的问题，再处理还能更好的问题。
复核证据 不是一句已修改，而是平台 issue detail 路径、源字段、商品页 URL 与可见字段值、修复后状态、抓取时间和下次复查日期。
下一步怎么接：GMC 排错要接 Meta Catalog 和促销放行
Merchant Center 的问题不是只给 Google Ads 看。字段、落地页和库存排错完成后，还要确认 Meta Catalog、促销价和季节性商品不会读到另一套事实。
- Catalog 路线：Meta Catalog 与产品集治理，比对 catalog item id、item_group_id、content_ids 和 Shopify collection。
- 促销路线：大促 Feed 准备度，确认 sale_price、effective date、库存、落地页和政策一致。
问题场景先分流
| 场景 | 先按什么级别 | 第一动作 | 不要这样做 |
|---|---|---|---|
| 价格与落地页不一致 | 通常按阻断型处理 | 核对 Shopify price、compare-at price、sale_price 规则、商品页价格和重新抓取时间 | 只在 Merchant Center 手工改价格并立刻提交复核 |
| 缺少 GTIN 或品牌标识 | 多半是受限型 | 确认是否真的有 UPC/EAN 厂家条码，再查供应商资料和 Feed 映射 | 为了消除提示随便编 GTIN |
| 图片质量或图片不符合 | 可能受限，也可能影响审核 | 核对 Shopify 主图、Feed 图片 URL、落地页图片、尺寸、水印和促销覆盖 | 只换广告素材，不修商品源图或 Feed 图片字段 |
| 同类变体反复缺颜色/尺寸 | 升级为源字段缺陷 | 检查 Shopify 变体选项、metafield、导入模板和 Feed 同步应用映射 | 逐个在 Merchant Center 补字段 |
四级分流表：先分级，再决定修哪里
| 级别 | 典型信号 | 第一检查 | 动作 | 复核节奏 |
|---|---|---|---|---|
| 阻断型 | 商品不展示、审核拒登、账号风险、价格库存不一致 | 必要字段、价格库存、落地页一致性 | 当天修复，必要时暂停受影响活动 | P0 当天复查 |
| 受限型 | 商品可展示但覆盖受限，GTIN、品牌、图片或类目较弱 | 标识符、图片质量、分类、属性完整度 | 排进本周字段治理 | 本周复查 |
| 观察型 | 建议项或机会项 | 标题清晰度、自定义标签、类目细化 | 纳入月度优化路线图 | 月度复盘 |
| 源字段缺陷 | 同类问题反复出现 | Shopify 源字段、Feed 同步应用规则、补充 Feed | 回到负责人、变更验收和变更日志 | 进入字段治理 |
Merchant Center 路径：先看 Diagnostics，再回到商品身份字段
新手最容易跳过的是路径：看到红点就 request review，或者看到 GTIN 提示就随便补一个值。更稳的顺序是 Merchant Center -> Products -> Needs attention / Diagnostics -> 打开 issue detail -> 记录 affected item id -> 回 Shopify Google & YouTube channel 状态、Feed 行、商品页和结构化数据核验。缺 GTIN 时，先判断商品是否真实存在 UPC/EAN 这类厂家条码；不确定就用 GTIN 工具做格式和校验位核查，但这个工具只能帮助判断格式和校验位，不能替代 GS1、包装、品牌或供应商给出的真实商品身份来源。广告侧怎么读 Feed 基础，可以接 Merchant Center 与商品 Feed 基础。
| 后台入口 | 要记录什么 | 下一步动作 |
|---|---|---|
| Products -> Needs attention | issue detail、affected item id、严重程度、目标国家、最后更新时间 | 先判断阻断型、受限型、观察型还是源字段缺陷 |
| Product detail / item preview | id、title、price、availability、GTIN、brand、image_link、link | 和 Shopify 源字段、Feed 行、商品页可见字段逐项对齐 |
| Feed source / app sync | 数据源名称、同步时间、覆盖规则、supplemental source 是否介入 | 避免只改 Merchant Center，下一次同步又覆盖回来 |
| Google Ads product groups | 受影响 SKU 是否仍在投放、花费、点击和转化是否继续发生 | 阻断型或库存承诺错误时，先暂停受影响商品池 |
Feed Evidence Four-Way Check：四处不一致，不能算修完
Merchant Center 报错不是只看一个后台截图。每个阻断型或重复型问题，都要把四处证据放在同一行：Shopify Google & YouTube channel 的商品状态、Merchant Center item issue、Feed 行或 channel 预览、商品页主显示与 Product structured data。四处都能对上，才说明修复已经从源头、渠道、页面和平台反馈闭环。
| 证据位置 | 要记录什么 | 卡住时说明什么 |
|---|---|---|
| Shopify Google & YouTube channel | 商品是否同步、缺哪些 required fields、最近同步时间、目标市场 | 源字段或 channel 设置还没准备好，Merchant Center 里手工改会被覆盖 |
| Merchant Center item issue | issue detail、affected item id、严重程度、目标国家、last crawl / update | 没有平台问题详情，就不知道该修字段、页面、政策还是账号状态 |
| Feed 行 / item preview | id、price、availability、gtin、brand、image_link、link、sale_price | Feed 仍旧错，页面修好也可能被下一次同步重新带歪 |
| 商品页与 Product structured data | 页面主价格、库存、图片、配送/退货承诺、结构化数据 offer | 页面承接和结构化数据不一致时，复核证据仍然不稳 |
Feed Issue Triage Router：把 issue detail 翻译成修复顺序
Merchant Center 的 issue detail 不是给你看一个后台标签，而是告诉你第一证据应该从哪里开始。你要把它翻译成四件事：这个问题影响展示资格还是质量覆盖；第一检查在哪里；修复顺序是什么；什么时候才可以提交复核或恢复预算。
| 后台提示 | Issue detail 要读什么 | 修复顺序 | 复核或放量条件 |
|---|---|---|---|
| 价格不一致 / price mismatch | price、sale_price、sale_price_effective_date、target country、currency、last crawl、affected item id | 源价格 -> 商品页主显示 -> Product structured data -> Feed 重新提交 -> Merchant Center 预览 -> 复核 | 预览、页面主价格和结构化数据三处一致后，才 request review |
| 图片问题 / image issue | image_link、additional_image_link、landing page image、促销覆盖、水印、crawl time、affected item id | Shopify 主图源头 -> Feed image_link -> 商品页可见图 -> Meta Catalog 对照 -> Merchant Center 预览 | 普通商品图在页面、Feed 和 Merchant Center 预览里一致后，才恢复主推商品组 |
| 库存状态不一致 / availability mismatch | availability、inventory source、variant id、target country、last update、last crawl、product group 状态 | 库存地点 / 变体 -> Shopify 可售状态 -> Feed availability -> 页面购买状态 -> 商品组恢复 | 可履约库存、商品页状态、Feed availability 和商品组状态都恢复后，再逐步恢复预算 |
| GTIN / brand 标识缺失 | gtin、brand、mpn、identifier_exists、item_group_id、variant option、affected item id | 商品身份来源 -> SKU / variant 表 -> Feed 标识字段 -> Merchant Center 预览 -> 下周覆盖复盘 | 没有真实来源时不要标记已修复；记录身份缺口和本周字段治理动作 |
| 落地页不可抓取或承诺不一致 | link、mobile landing page、HTTP 状态、robots/noindex、shipping、returns、price、availability、crawl time | 公开 URL -> 移动端主内容 -> 配送/退货承诺 -> 结构化数据 -> Feed link / price / availability -> 重新抓取 | 无登录公开页面和 Merchant Center 预览都看到同一承诺后，才提交复核 |
这一段要写进复制笔记总结：后台提示、issue detail 字段、第一检查、修复顺序、不能做的捷径、复核准备度和下一次复查日期。不要只写“已提交审核”。
来源追溯：不要修一个会被下次同步覆盖的值
如果某款宠物胸背带的 30 个变体都缺颜色，不要逐个在 Merchant Center 补。先查缺失发生在 Shopify 源字段、Feed 同步应用、补充 Feed、页面结构化数据还是规则层。
- Shopify 源字段：价格、库存、标题、图片、品牌、GTIN 是否完整。
- Shopify Google & YouTube channel：商品是否 approved / pending / not synced，哪些 required fields 缺失，目标市场和最近同步时间是否正确。
- Feed 同步应用映射：sale_price、availability、product_type 是否被规则覆盖。
- 补充 Feed / 规则：补充字段是否覆盖主 Feed，负责人是否清楚。
- 商品页承接：落地页价格、库存、图片和承诺是否与 Feed 一致。
目录规模不同，排错节奏也不同
本课里的 12 个主推 SKU、40 个 SKU 库存漂移都是教学样本，不是所有店铺的固定门槛。真正执行时要按目录规模决定抽样和节奏。
| 目录规模 | 排错方式 | 复查节奏 |
|---|---|---|
| 小目录：30 个主 SKU 以下 | 阻断型问题建议全量查：每个 SKU 都对齐 Shopify channel、Merchant Center issue、Feed 行和商品页。 | 当天关闭 P0；本周处理受限型字段。 |
| 中目录：30-300 个主 SKU | 先查有广告花费、订单、库存风险或高毛利的 SKU，再按同类 issue 扩展到同模板商品。 | P0 当天抽样复查；重复问题进入字段治理。 |
| 大目录：300 个主 SKU 以上 | 按市场、商品类型、custom label、广告花费、库存风险和毛利分层抽样，避免只看后台总数。 | 每天看阻断型队列；每周看受限型和重复源字段缺陷。 |
价格与库存不一致练习区：先判断处理动作
价格和库存不一致不是一个单纯的 Merchant Center 后台问题。Google 会对照商品数据、落地页、页面结构化数据和抓取时间。正确动作不是先点 request review，而是先判断：该修源数据、对齐同步时间、启用小范围 automatic item updates 兜底，还是先暂停受影响 SKU。
为什么这一步重要？ automatic item updates 可以降低少量价格或库存不一致造成的风险，但它不是商品数据治理方案。主 Feed、Shopify 源字段、商品页和结构化数据仍然必须准确、及时、一致。
| 场景 | 危险捷径 | 更稳动作 | 证据线 |
|---|---|---|---|
| 20oz 宠物出行水杯 Feed 24.99，页面 29.99 | 只在 Merchant Center 编辑价格并立刻复核 | 修源价格、sale_price、页面价格和 Product structured data，再重新提交商品数据 | 源价格字段 -> 页面价格 -> structured data -> 重新提交 -> 复核证据 |
| 网站已售罄，但 Feed 仍显示 in stock | 只改 availability，不改同步计划 | 对齐 Shopify 库存更新、Feed 同步、页面状态和抓取时间 | 库存源头 -> 页面状态 -> 同步计划 -> 抓取时间 |
| 少量清仓 SKU 高频改价 | 把 automatic item updates 当成主数据方案 | 主 Feed 继续做真相源，只用 automatic item updates 做小范围价格/库存兜底 | 主 Feed 准确 -> 页面 structured data 准确 -> 小范围兜底 |
| 40 个 SKU 库存漂移，广告还在放量 | 继续投放，等同步自己恢复 | 暂停受影响 SKU 或产品组，再修库存源字段和同步规则 | 暂停商品池 -> 修库存源头 -> 重跑同步 -> 复查 Feed 和页面 |
| 加拿大页面显示 CAD，Feed 仍传 USD | 只改页面货币符号 | 检查 target country、Feed currency、页面主价格、structured data 和 Shopify Markets 设置 | target country -> Feed currency -> 页面主价格 -> structured data |
怎么做？ 在 Merchant Center 的 Products / Needs attention 里先下载受影响商品或打开 issue detail；用商品 ID 回到 Shopify 源字段、Feed 行和商品页；确认结构化数据与页面主显示一致；最后记录重新提交或重新抓取时间。没有这些证据，不要把复核当成试探按钮。
复核请求准备门：四道门没过，不要 request review
| 门 | 要确认什么 | 不能提交的信号 | 必须证据 |
|---|---|---|---|
| 问题详情读清楚 | 确认是商品数据、网站/落地页、政策，还是账号级问题 | 只有红色提示状态，没有 issue detail 和影响范围 | issue detail 路径、受影响 SKU、级别判断 |
| 源字段已修 | 修复发生在源字段、同步规则、补充 Feed 或页面源头 | 只写已修改，不知道下次同步是否覆盖 | 源字段路径、规则名称、Feed 行、负责人和更新时间 |
| 页面承接一致 | 商品页价格、库存、图片、标题、配送或退换承诺与 Feed 一致 | Feed 改了，但页面仍显示旧价格、售罄状态或旧图片 | 商品页 URL、可见字段值、结构化数据检查、抓取/同步时间 |
| 适合提交复核 | 已经等到同步或重新抓取完成，并确认没有制造新问题 | 没等渠道读取就反复点击 request review | 复核提交时间、重新抓取状态、修复前后字段值、下次复查日期 |
Feed 问题压力判断练习：压力一来，先别跳过证据
Merchant Center 排错最容易错的地方，不是不会修字段，而是会议压力一来就跳过证据。红点、automatic item updates、广告消耗和 warning backlog 都会让团队走捷径。你要先判断这个问题处在什么压力里，再决定修源字段、等同步、暂停 SKU、还是提交复核。
| 压力场景 | 诱人的错误动作 | 更稳读法 | 第一证据 | 禁止动作 |
|---|---|---|---|---|
| 红点刚出现，团队想马上 request review | 不读问题详情，不查影响 SKU，不修源字段，直接提交复核 | 先把问题读成级别、范围、源头和证据要求；复核是修复完成后的提交动作 | issue detail、受影响 SKU、问题级别、源字段、页面 URL 与字段值、同步/重新抓取时间 | 四道复核准备门没过之前，不提交 request review |
| automatic item updates 开着，团队想不修主 Feed | 把 automatic item updates 当主数据治理方案 | automatic item updates 只适合小范围价格、库存或 condition 差异兜底；主 Feed、页面结构化数据和商品页仍要一致 | 主 Feed 行、页面结构化数据、商品页主价格/库存、automatic item updates 设置、最近自动改写样本 | 主 Feed 不准时，不把自动更新当长期解决方案 |
| 库存漂移但广告还在花钱 | 继续投放，等下一次同步自己恢复 | 先暂停受影响 SKU 或产品组，修库存源字段和同步规则，再复查页面、Feed 和广告产品组 | 受影响 SKU 样本、库存源字段、页面状态、Feed 行、广告产品组消耗、同步日志 | 库存承诺不一致时，不继续让错误承诺花广告预算 |
| 警告很多，团队想全部放进月度路线图 | 把所有 warning 当观察型优化，不分受限型和源字段缺陷 | 先看是否影响覆盖、展示资格、广告产品组和重复出现；受限型进本周治理，重复问题升级为源字段缺陷 | warning 类型、受影响 SKU 数、曝光/点击变化、重复频率、源字段样本、上次修复记录 | 没有分级前，不把所有提示都丢进月度优化 |
工具不是重点，重点是链路能不能跑通。Merchant Center 看到的是结果，真正要修的是源字段、同步、页面和复核证据。
比如一款宠物出行水杯的价格不一致演练
本周有 12 个主推 SKU 出现价格与落地页不一致。先按 P0 标记，恢复展示资格；再查 Shopify price、compare-at price、Google & YouTube channel 同步状态和 Feed 同步应用 sale_price 规则；保存问题详情、Feed 行、商品页 URL、页面可见价格、结构化数据和修复前后状态；等重新抓取后再决定是否提交复核。
如果同类问题下周又出现，就不要再当成单次报错处理。把它升级为源字段缺陷，进入字段负责人、变更日志和月度治理路线图。
停止/继续：没有证据，不算关闭
| 信号 | 动作 | 关闭条件 |
|---|---|---|
| P0 影响展示资格 | 当天修复并复查 | 问题详情、源字段、落地页、复核时间都保存 |
| 问题来源不清 | 暂停，先追溯唯一真相源 | 确认 Shopify、Feed 同步应用、补充 Feed、页面或规则来源 |
| 只在 Merchant Center 手工改字段 | 不算关闭，回源字段修 | 源字段和同步规则已经更新 |
| 缺复核记录和复核日期 | 不算关闭 | 保存修复前后字段值、重新抓取时间和下次复查日期 |
| 同类问题重复出现 | 升级为源字段缺陷 | 进入字段负责人、变更日志和月度治理路线图 |
真实搜索 FAQ：Merchant Center 报错先修哪里
用户搜索 Merchant Center 问题时，通常不是想看一堆后台名词，而是想知道红点出现后先改哪里、能不能点复核、automatic item updates 能不能兜底、GTIN 缺失要不要随便补。这里把真实问题翻译成排错动作。
| 真实问题 | 先判断什么 | 执行动作 |
|---|---|---|
| Needs attention 或 disapproved 先修哪里？ | 先看 issue detail、影响 SKU、目标国家和影响级别，不要只看红点。 | 阻断展示的先修源字段、页面一致性和同步；还能展示但受限的排进本周字段治理。 |
| 价格或库存不一致能不能直接 request review？ | 先确认 Feed、商品页主显示、Product structured data、Shopify 源字段和重新抓取时间是否一致。 | 修完源头并等同步 / 抓取后再提交复核；广告仍在花钱时先暂停受影响 SKU 或产品组。 |
| automatic item updates 开着是不是不用修 Feed？ | 不是。它只适合少量价格、促销价、库存或 condition 的临时兜底。 | 主 Feed、Shopify 源字段、商品页和结构化数据仍然要准确；反复出现就升级为源字段缺陷。 |
| GTIN 或品牌缺失能不能先随便填？ | 不能。GTIN 是 UPC / EAN 这类厂家条码，不确定时先查供应商、包装、品牌资料和 GTIN 工具格式校验。 | 没有真实 GTIN 就不要编；改为补强品牌、型号、图片、分类和页面事实，并记录谁负责确认商品身份。 |
复制笔记总结：Merchant Center Feed 排错分流表
复制出去的不是一句"Merchant Center 已处理"，而是一组能让下一位同事继续复查的笔记。它要记录本课结论、第一证据、禁止动作和下一课入口。
- 本课结论：Merchant Center 排错不是让红点消失，而是把问题级别、源字段、页面承接、同步和复核证据闭环。
- 第一证据：问题详情、受影响 SKU、源字段或规则、商品页 URL 与可见字段值、结构化数据、同步/重新抓取时间。
- 禁止动作：不要没读 issue detail 就 request review；不要把 automatic item updates 当主数据治理。
- 问题级别：阻断型、受限型、观察型或源字段缺陷。
- 字段来源：Shopify 字段、Feed 同步规则、补充 Feed、页面或广告规则。
- 页面一致性：价格、库存、图片、标题和承诺是否一致。
- 复核证据：问题详情、源 CSV 或 Feed 行、商品页 URL、可见字段值、重新抓取时间。
- 下一步动作：修字段、修规则、修页面、提交复核或进入字段治理。
- 下一课入口：Feed 排错闭环后，再进入 Meta Catalog、集合与产品集治理。
下一篇会进入 Meta Catalog、集合与产品集治理。带过去的是一张能被复查的排错分流表，而不是一个模糊的处理结论。
公开来源
这些来源不是让你背后台菜单，而是确认排错边界。Google Merchant Center issues and reviews 说明被拒登后可以修复或不同意问题再 request review；Request a review of your issues 说明商品级问题要从 Products / Needs attention 进入 Fix 查看；Google product data specification 定义商品字段准确性和落地页一致性；automatic item updates 只能用页面结构化数据和抓取信号做价格、促销价、库存、condition 等小范围兜底；Issue severity and Merchant Center Diagnostics 用来理解问题优先级；Shopify Google & YouTube product sync 用来确认 Shopify 侧同步状态和缺失商品数据。
| 官方边界 | 本课用法 |
|---|---|
| issues and reviews 定义修复后再复核，不是让团队反复试探。 | 四道复核准备门没过之前，不提交 request review。 |
| Needs attention / Fix 才能看到商品级 issue detail 和受影响商品。 | 先记录 affected SKUs、issue detail、源字段、商品页 URL、可见字段值和抓取时间。 |
| product data spec 要求价格、库存、图片、标识符、变体和类目与落地页一致。 | 分流表先判断字段要求、页面一致性、同步规则还是源字段缺陷。 |
| automatic item updates 会读取页面结构化数据和抓取信号。 | 只做小范围兜底，不能替代主 Feed、Shopify 源字段和页面一致性。 |
| Diagnostics severity 帮助判断哪些问题优先。 | 先分阻断型、受限型、观察型和源字段缺陷，不把所有 warning 都拖到月度清单。 |
| Shopify Google & YouTube channel 会提示商品同步状态和缺失数据。 | 把 Shopify channel 状态加入四方证据链，不只看 Merchant Center 红点。 |