Merchant Center 排错工作台
红点消失，不代表 Merchant Center 问题已经关闭。
Merchant Center 出现警告或审核拒登后，不要先改 Feed。 先判断是阻断型、受限型、观察型还是源字段缺陷。 再追溯 Shopify channel 状态、Merchant Center item issue、Feed 行、页面承接、复核证据和负责人。
本课产出
Merchant Center Feed 排错分流表
完成标准：每个问题都有级别、受影响 SKU、平台提示、字段来源、页面一致性、修复动作、负责人、证据和复核周期。
阻断型
当天修复，必要时暂停受影响活动
受限型
排进本周字段治理
观察型
纳入月度优化路线图
用一张价格冲突单走完排错
Merchant Center 显示的是平台读到的结果；真正的工作是找出哪一个源、哪一次同步、哪一个页面事实制造了它
案例仍是 NorthPaw 20oz/Sage/US。活动在周一 09:00 生效，Shopify price 和页面主价格已经是 $24.99，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；复核按钮是修复后的动作，不是用来试探平台会不会放过。
决定条件不是折扣幅度，而是根因能否定位到过期同步或覆盖层。 automatic item updates 临时修正展示值，不能替代主来源修复。
| 证据面 | 本案例值 | 它能证明什么 | 它不能证明什么 | 通过条件 | 失败动作 |
|---|---|---|---|---|---|
| Shopify source | $24.99 / 09:00 / US | 源字段和活动窗当前正确 | 渠道已经读取 | 价格 + 活动窗口 + 负责角色 | 源错就先修源，不在平台打补丁 |
| 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。
- 只改根因层，重新提交/同步，记录负责角色、change ID 和预计处理窗口。
- 样本 12 个和全量 40 个都回读；平台状态未更新前不恢复预算，也不重复点 review。
什么时候停止，什么时候提交复核
停止复核：source/page/structured data 仍不同、同步未完成、issue 范围扩大、市场/币种对象不清、或团队只是用 automatic update 掩盖主来源。临时停投不要伪造 out_of_stock；按当前官方规则使用适合的 pause 或 excluded destination 路径，并核对适用时限。
可以提交：问题详情读清、根因层已修、源与页面一致、同步/抓取窗口已过、修复前后证据齐全，而且该 issue 当前提供 review 或 website check。提交后记录状态与下一复查日；红点消失后再抽查下一次同步，确认问题没有被回写。
下面互动会切换 issue 类型、price/availability 场景、压力条件、复核判断、测试题和证据包。动态反馈不能替代静态关闭条件：平台提示、源字段、同步、页面、结构化数据、受影响 item、预算保护和复查日期都要能被下一位同事回读。
先别点复核
先把提示翻译成该查哪里。
Merchant Center 的 Needs attention、拒登、价格不一致和库存不一致，不是同一种问题。先把提示、字段、页面、同步时间和流量风险写清楚，再决定修源字段、暂停 SKU、等待同步还是提交复核。
Needs attention
先做：先打开商品级 issue detail，写下受影响 SKU、目标国家、字段名、发现时间和严重程度。
先不要：不要只看红点，也不要没读详情就点 request review。
审核拒登 / disapproved
先做：先判断商品是否还能展示，必要时暂停受影响 SKU 或广告组，再修源字段和页面承接。
先不要：不要把拒登当普通 warning，也不要让错误承诺继续花广告费。
price mismatch
先做：先同时查 Shopify price、sale_price、Feed 行、商品页主价格和 Product structured data。
先不要：不要只在 Merchant Center 里补一个价格，也不要页面没对齐就复核。
availability mismatch
先做：先查库存更新时间、Feed 同步时间、页面库存、结构化数据和履约承诺。
先不要：不要只把 availability 改成 out_of_stock 来止血，却不修同步节奏。
00 问题分流
看到提示后，先判断它是哪类问题。
Merchant Center 的提示不等于修复路径。价格不一致、缺 GTIN、图片问题、变体属性重复缺失，先查的位置完全不同。这里先把该查哪里定下来。
当前看到的提示是什么？
排错判断
通常先按阻断型处理。
问题详情路由
Feed Issue Triage Router：从详情读到修复顺序。
选择一个问题类型，先读对应字段，再按顺序修复；最后用复核或放量条件判断是否能继续。
选择问题类型
当前路由反馈
价格不一致 / price mismatch
- Issue detail 要读什么
- price、sale_price、sale_price_effective_date、target country、currency、last crawl、affected item id
- 修复顺序
- 源价格 -> 商品页主价格 -> Product structured data -> Feed 重新提交 -> Merchant Center 预览 -> 复核
- 复核 / 放量条件
- 只有预览、商品页主价格和结构化数据一致后，才提交复核。
名词先说清楚
先把本课会用到的词讲清楚。
Merchant Center
Merchant Center 是 Google 管商品展示资格、商品数据和诊断问题的后台。新手可以把它理解成 Google Shopping 商品能不能展示的体检表。
价格不一致时，不要只看报错文案，要同时查源字段、同步规则、商品页和重新抓取时间。
GTIN
GTIN 是 UPC、EAN 这类商品条码编号的统称。它让 Google 更容易确认商品身份；没有 GTIN 不一定不能投放，但品牌、型号、图片和页面事实要更稳定。GTIN 工具只能做格式和校验位检查，不能替代 GS1、包装、品牌或供应商记录。
Merchant Center 提示缺少 GTIN 时，先确认商品是否真的有厂家条码，不要随便编一个。
Product set / 产品集
产品集是 Meta Catalog 或广告系统里按规则圈出来的一组商品，比如热卖 SKU、清仓 SKU、某个集合页商品或高毛利商品。Merchant Center 排错不直接管理产品集，但 Feed 源字段漂移会影响后续产品集能不能稳定投放。
如果库存在 Feed 里是 in stock、页面却售罄，后续产品集会继续把错误商品送进广告。
警告与审核拒登
警告通常表示覆盖、质量或优化空间受限；审核拒登会直接影响商品展示资格。新手要先处理不能展示的问题，再排还能更好的问题。
审核拒登先恢复资格；警告要写复查窗口，不能无限期挂着。
复核证据
复核证据是平台问题详情、源数据、商品页截图和修复后状态的组合，不是一句已修改。它的作用是让下一个人也能判断问题是否真的关闭。
关闭问题前，至少留下受影响 SKU、修复动作、负责人和下次复查时间。
01 分流表
先分级，再决定修哪里。
同样是 Merchant Center 提示，阻断型、受限型、观察型和源字段缺陷的处理节奏不同。所有问题都按同一张表记录，避免靠感觉决定优先级。
阻断型
商品不展示、审核拒登、账号风险、价格库存不一致
必要字段、价格库存、落地页一致性
当天修复，必要时暂停受影响活动
P0 当天复查
受限型
商品可展示但覆盖受限、GTIN/品牌/图片/类目弱
标识符、图片质量、分类、属性完整度
排进本周字段治理
本周复查
观察型
建议项或机会项，标题、自定义标签、分类仍可优化
标题清晰度、自定义标签、类目细化
纳入月度优化路线图
月度复盘
源字段缺陷
同类问题反复出现
Shopify 源字段、Feed 同步应用规则、补充 Feed
回到负责人、变更验收和变更日志
进入字段治理
02 来源追溯
不要在 Merchant Center 手工补一个会被下次同步覆盖的值。
如果某款宠物胸背带的 30 个变体都缺颜色，先查缺失发生在 Shopify、Feed 同步应用、补充 Feed、页面结构化数据还是规则层。
Shopify 源字段
价格、库存、标题、图片、品牌、GTIN 是否在源头完整？
商品后台截图、导出 CSV 行、最近更新时间
Shopify Google & YouTube channel
商品是 approved、pending 还是 not synced？缺哪些 required fields，目标市场和最近同步时间是否正确？
Channel 商品状态、缺失字段、目标市场、最近同步时间
Feed 同步应用映射
sale_price、availability、product_type 是否被规则覆盖？
映射规则截图、同步日志、样本 SKU
补充 Feed / 规则
补充字段是否覆盖主 Feed，且负责人清楚？
补充 Feed 行、规则说明、负责人
商品页承接
落地页价格、库存、图片和承诺是否与 feed 一致？
商品页截图、结构化数据检查、重新抓取时间
任何会被下一次同步覆盖的更改，都不算源头修复。
一篇关于 Product Information Extraction using ChatGPT 的离线研究，在 MAVE（源自 Amazon 商品报价）的受限商品标题属性抽取子集上，把提示式抽取与已训练基线作精确匹配比较。这里的用法很窄：把标题里读出的属性当作线索，回到源字段、Feed/item、商品页和 issue detail 逐项核对，并记录哪一层负责修复。研究只覆盖论文选择的类别、属性和模型版本；它不证明当前 Merchant Center 已修好，也不证明商品真相已经建立，更不代表完整目录、线上质量、转化或销售结果。
03 页面一致性
Merchant Center 不只看 feed，也看落地页承接。
价格、库存、促销价、图片、标题和履约承诺如果在 Feed 与页面之间不一致，复核就没有稳定证据。
价格 / 促销价
促销价规则冲突会造成预防性拒登或展示资格问题。
库存 / availability
后台有货但页面售罄，会触发页面与 Feed 不一致。
图片
占位图、促销覆盖、水印或尺寸不足会影响质量或审核。
标题 / 承诺
标题、履约承诺、页面模块不一致，会让复核证据变弱。
页面主显示与 structured data 一致，只证明当前页面事实；库存地点、履约范围和 checkout 承诺仍要按同一市场范围单独读回。
04 价格与库存不一致练习区
先判断该修源数据、等同步、用 automatic item updates，还是暂停 SKU。
价格和库存不一致是 Merchant Center 最常见的高压问题之一。这里训练你把同一个 mismatch 拆成源字段、页面、结构化数据、同步时间和预算风险，而不是立刻点击 request review。
第一步：选择 mismatch 场景
第二步：选择处理动作
20oz 宠物出行水杯价格和页面不一致
课堂选择必须先固定 target country、币种、受影响样本和当前同步/抓取时间；同一个按钮不能替所有市场给出通用答案。
05 证据清单
提交复核前，先跑四方证据链。
Feed Evidence Four-Way Check 要同时说明 Shopify channel 状态、Merchant Center item issue、Feed 行和商品页 structured data。只写已检查不算关闭。
Shopify channel 状态
证明 Google & YouTube channel 已同步，或明确缺哪些 required fields。
Merchant Center item issue
说明平台具体提示、影响范围、目标国家和发现时间。
Feed 行 / item preview
证明不是只在 Merchant Center 手工改，也确认下一次同步不会覆盖。
商品页与 structured data
证明页面主显示、结构化数据、价格、库存、图片和承诺已经承接。
四方证据要在同一商品、同一市场和相近时间窗口上对齐；一张孤立截图不是关闭证明。
05B 目录规模
12 个 SKU 和 40 个 SKU 是教学样本，不是固定门槛。
小目录可以全量查；中目录先查有花费、订单、库存风险或高毛利的 SKU；大目录要按市场、商品类型、custom label 和风险分层抽样。
小目录：30 个主 SKU 以下
阻断型问题建议全量查，每个 SKU 都对齐 Shopify channel、Merchant Center issue、Feed 行和商品页。
P0 当天关闭；受限型字段本周处理。
中目录：30-300 个主 SKU
先查有广告花费、订单、库存风险或高毛利的 SKU，再扩展到同模板商品。
P0 当天抽样复查；重复问题进入字段治理。
大目录：300 个主 SKU 以上
按市场、商品类型、custom label、广告花费、库存风险和毛利分层抽样，避免只看后台总数。
每天看阻断型队列；每周看受限型和重复源字段缺陷。
06 复核准备门
不是修完就立刻点复核。先确认四道门都过了。
Google 的问题处理逻辑是：读清楚问题，修正商品数据或网站，再提交或等待复核。小团队最常见的失败是没修源头、没等同步、没截图，就反复 request review。
问题详情读清楚了吗
是否已经确认这是商品数据问题、网站/落地页问题、政策问题，还是账号级问题？
可以提交：问题名称、影响范围、受影响 SKU、发现时间和复核入口都写入分流表。
不要提交：只截图了红色提示，没有记录 issue detail 或影响范围。
必须证据：Merchant Center 问题详情截图、受影响 SKU 列表、级别判断。
源字段真的修了吗
修复是否发生在 Shopify 源字段、Feed 同步规则、补充 Feed 或页面承接源头，而不是只在 Merchant Center 手工补？
可以提交：源字段、同步规则和受影响样本都能复查。
不要提交：只写已修改，但不知道下次同步会不会覆盖。
必须证据：源字段截图、规则截图、Feed 行或导出 CSV、负责人与更新时间。
页面承接一致吗
商品页价格、库存、图片、标题、配送或退换承诺是否与 Feed 和结构化数据一致？
可以提交：修复后页面截图、结构化数据检查和重新抓取时间齐全。
不要提交：Feed 改了，但落地页仍显示旧价格、售罄状态或旧图片。
必须证据：商品页截图、结构化数据检查、抓取/同步时间、受影响 SKU 抽样。
现在适合提交复核吗
是否已经等到同步或重新抓取完成，并确认没有新的同类问题被制造出来？
可以提交：有修复前后证据、复核时间、下次复查日期和反证信号。
不要提交：为了快点恢复展示，没等渠道读取就反复点击 request review。
必须证据：复核提交时间、重新抓取状态、修复前后截图、下一次复查日期。
06A 当前复核状态
把“能不能点复核”读成当前状态，不要写成固定等待承诺。
同样是拒登，商品级与账号级的入口、所需步骤和可用按钮都可能不同。先确认当前屏幕实际显示什么，再决定下一次读回。
商品级问题
从 Products 的 Needs attention 找到商品，再用 Fix 打开问题详情。 只有当前问题提供对应入口时，才可能出现 Request website check 或 Request review。
账号级问题
在 Needs attention 里进入 setup 和 policy issues。 身份验证、数据源非空或其他当前页面要求没有完成时，不把“想复核”写成“已经可以复核”。
等待与重试
审核、处理、已批准、受限和未批准是状态，不是每种问题都适用的统一 SLA。 若第二次复核后问题仍未解决，可能出现一周冷却期且之后可能延长；记录已尝试次数和当前页面状态，回到证据而不是反复点击。
06B 可保存分流记录
把一次判断留成可恢复、可导出的课堂分流记录。
这份记录只组织判断和证据，不连接 Merchant Center、Shopify、Google Ads 或真实商品数据。
先把问题范围、根因层和证据写清，才有资格准备一次同范围读回。 这里的“准备”只表示课堂记录完成，不代表账户、商品、复核或预算已经被操作。
不要粘贴客户、订单、登录信息、令牌或其他敏感数据；角色和非敏感证据位置已经足够用于课堂练习。
课堂结论：继续补齐范围、来源、证据、角色和下次读回。
已完成 0/9 个课堂记录条件。
07 Feed 问题压力判断练习
最容易出错的不是不会修，而是压力一来就跳过证据。
遇到价格、图片、库存、商品标识或落地页问题时，先按五条路由读取 issue detail 字段，再按对应顺序修复，最后确认复核或放量条件。
我建议你把这一段当成排错会来读：不要先问怎么让 Merchant Center 的红点消失，而要先问这个红点会不会影响展示资格、是不是源字段又漂移、页面承接是不是一致、复核证据能不能被下一位同事复查。红点消失只是结果，证据闭环才是排错。
工具不是重点，重点是链路能不能跑通。 Merchant Center 看到的是结果，真正要修的是源字段、同步、页面和复核证据。
当前排错压力
红点刚出现，团队想马上 request review
08 比如一款宠物出行水杯演练
价格不一致先恢复资格，再追重复原因。
比如一款宠物出行水杯本周发现 12 个主推 SKU 价格与落地页不一致。这个问题不能放进月度优化，也不能只在 Merchant Center 手工改。
标记 P0
12 个主推 SKU 价格与落地页不一致，先恢复展示资格。
查源字段
核对 Shopify price、compare-at price、Feed 同步应用 sale_price 规则。
保留证据
保存问题详情、Feed 行、商品页截图和修复前后状态。
等待同步
修复规则后等待重新抓取，再截图复核。
升级重复问题
同类问题再次出现，升级为源字段缺陷，进入负责人和变更验收。
10 快速自测
不要把 P0 当普通字段优化。
比如一款宠物出行水杯发现 12 个主推 SKU 价格与落地页不一致。团队想直接在 Merchant Center 手工改价格并提交复核。你应该先要求什么？
11 停止/继续
没有证据，不算关闭。
Merchant Center 排错的目标不是让红点消失，而是让商品数据链路更稳定。每个问题都要留下级别、源头、页面一致性和复核证据。
P0 影响展示资格
当天修复并复查
问题详情、源字段、落地页、复核时间都保存
问题来源不清
暂停，先追溯唯一真相源
确认 Shopify、Feed 同步应用、补充 Feed、页面或规则来源
只在 Merchant Center 手工改字段
不算关闭，回源字段修
源字段和同步规则已经更新
缺截图和复核日期
不算关闭
保存修复前后截图、抓取时间和下次复查日期
同类问题重复出现
升级为源字段缺陷
进入字段负责人、变更日志和月度路线图
红点消失后仍要抽查下一次同步；没有回读，就只有状态变化，没有关闭证据。
12 复制笔记总结
把排错结论变成复制笔记总结。
复制出去的是问题级别、字段来源、页面一致性、规则、复核状态、当前压力和下一步动作，不是一句"已修复"。
复制笔记的关闭条件是：下一位同事能看懂范围、证据、禁止动作和下次读回；“已处理”不构成关闭。
Merchant Center Feed 排错分流表
本课结论
Merchant Center 排错不是让红点消失，而是把问题级别、源字段、页面承接、同步和复核证据闭环。
第一证据
问题详情、受影响 SKU、源字段或规则、商品页截图、结构化数据、同步/重新抓取时间。
禁止动作
不要没读 issue detail 就 request review；不要把 automatic item updates 当主数据治理。
下一课入口
Feed 排错闭环后，再进入 Meta Catalog、集合与产品集治理。