Google 商品中心怎么接给 AI，让它每天自动检查拒登、Feed 和流量？

朋友们，如果你是跨境电商运营、独立站负责人或卖家，有没有遇到过这种情况：商品被拒登几天后才发现，或者免费商品流量已经下降，团队却一直没人打开后台？把 Google 商品中心接给 AI 后，它可以每天检查商品、Feed、配送和流量，只在异常时通知运营。

Google 商品中心常简称 GMC，负责把商品信息送进免费商品列表和 Shopping 展示位。你可以把 API 当作一扇受控的数据窗口：AI 能查看后台，但不能随便修改设置。这篇会讲清 Merchant API 能查什么、如何从零接通、怎么变成每日监控，以及哪些修改必须由人批准。

先复制这段 Prompt，让 AI 从 0 带你搭起来

如果你不想先读技术细节，可以把下面这段直接发给 Codex，也就是能帮你编写和运行代码的 AI 助手。Claude Code、Cursor 或 OpenCode 也可以。它会先确认环境，再从权限申请做到每日自动检查。

你是我的 Google Merchant Center API 自动化搭建助手。
目标：从 0 开始完成 Google 权限申请、Merchant API 接通、只读审计、
每日异常检查和每周报告。每完成一个阶段先验证，再进入下一阶段。
开始前先问我：

使用 Windows、macOS 还是 Linux？本地是否能运行 Python？
我是否能登录 Google Merchant Center？是管理员还是普通用户？
这是只管理自己公司的 Merchant Center，还是给客户/外部商家使用？
Merchant Center account ID 是什么？不要把 token、私钥、client secret 或密码发进聊天。
是否已有 Google Cloud 项目？如果有，项目 ID 是什么？
日报希望保存在哪里、通过什么方式通知？

按以下阶段执行：
阶段 1：权限与项目

检查 Merchant Center 账号权限，不足时告诉我需要账号所有者完成什么。
创建或选择 Google Cloud 项目。
按 Google 当前官方指南选择认证：只管理自己公司的账号，优先 service account；
给客户或外部商家使用，走 OAuth 2.0。
service account 路径：创建 service account 与 JSON 私钥，把它的邮箱加入
Merchant Center 用户；注册阶段需要 Admin 权限。
OAuth 路径：配置 consent screen 和 OAuth client，下载 client secret JSON。
两种路径都使用 https://www.googleapis.com/auth/content。
指导我把凭证 JSON 放进本地私密目录并加入 .gitignore。
启用 merchantapi.googleapis.com。
如果返回 GCP_NOT_REGISTERED，解释 registerGcp 的账号影响，停止并请求批准；
获批后才执行 developer registration。

阶段 2：只读客户端

创建无资源写入的客户端。账号、数据源、商品和配送用 GET 读取；
Performance 可以按官方 Reports API 用 POST 查询，但不能修改账号资源。
不实现商品或设置的新增、修改、删除。
OAuth 路径支持 token 自动刷新；service account 路径安全读取私钥。
token 和私钥只保存在本机，不打印到日志。

阶段 3：审计

读取 account、autofeedSettings、dataSources、processed products、
itemLevelIssues、shippingSettings 和 product performance。
输出商品总数、Feed 数、Autofeed 数、拒登商品数、问题代码、影响国家、
商品链接、价格、币种、库存和最近检查时间。
同一商品跨 reporting context 必须去重。
生成脱敏 audit.json；不得保存 token、client secret、邮箱或完整账号标识。

阶段 4：自动监控

提供 authorize、audit、daily、weekly 四个命令。
daily 保存日期 snapshot 和 latest.json，只在商品数、Feed、拒登、国家或字段异常时报警。
weekly 比较历史趋势；Performance 排除最近 2 天的回填窗口。
根据我的系统生成可实际运行的定时任务，并做一次 smoke test。

阶段 5：验收

当场证明：能读商品总数、拒登原因、影响国家、Feed 来源、最近成功时间；
能保存历史快照，并能用模拟异常触发通知。
遇到 SERVICE_DISABLED 时检查 API 是否启用；遇到 GCP_NOT_REGISTERED 时
解释 developer registration；不要把所有错误都猜成 token 失效。
最后给我 README、运行命令、文件清单、验收结果、尚未验证范围和撤销授权方法。

安全边界：

任何关闭 Autofeed、修改配送、商品或账号设置的动作都必须停止，
先给出 intent、范围、pre-state、版本标记、验证和 rollback 方案，等我单独批准。
不要让我把任何完整凭证粘贴到聊天里，不要上传到 Git，不要写进截图。

现在先问我开始前的 6 个问题，不要一次性把后续所有步骤都甩给我。

为什么只靠运营手动看 GMC，很容易漏问题？

GMC 的问题往往不会主动跑到你面前。商品被拒登、某个国家缺配送、库存字段丢失，通常要等人打开后台，再逐层展开“Needs attention”才看得到。

这对跨境电商团队的影响会直接落到曝光、流量和排查时间上：

• 商品没有通过审核，就可能失去免费商品曝光和 Shopping 流量。
• Feed 数量或商品记录突然下降，可能代表某种语言、市场或数据源已经断了。
• 价格、币种、库存或配送国家不一致，会让商品在部分国家无法展示。
• 团队发现得越晚，排查窗口越长，也越难判断流量下降从哪一天开始。

一个典型场景是：商品显示 Not approved，页面本身有库存，GMC 记录里却缺少 availability，也就是库存状态；商品链接还指向语言首页，而不是正确的商品页。这个场景来自我的一个真实 Shopify 店。

只发截图给 AI，它只能看到截图那一层。接通 API 后，同时检查所有数据源和 processed product 记录，才发现正式 Shopify Feed 没问题，额外的 Autofeed 才是异常来源。

Feed 是商店提交给 Google 的商品清单。Autofeed 是 Google 从网站自动抓出的另一份清单。processed product 则是 Google 合并数据与规则后，真正用于审核和展示的商品记录。

这段经历对运营真正有用的地方，不是“我修好了一条商品”，而是暴露了人工检查的盲区：你在后台看到的是一个结果，API 能让你同时检查结果背后的数据来源。

Merchant API 接通后，AI 到底能查什么？

Merchant API 是 Google 当前用于读取和管理 Merchant Center 的接口。只读模式已经足够覆盖大部分日常运营检查。

GMC 看商品、Feed、审核和 Shopping 表现；GSC 看网页、查询词、自然搜索点击和排名。我的实际数据里，GMC 点击明显少于 GSC，因为它只覆盖商品及购物场景，而 GSC 还包含博客等页面。两边可以比较趋势，但对象和口径不同，不能直接相加或当成渠道归因份额。

运营看 GMC 表现时，我建议按这个顺序判断：

1. 展示下降：先看商品是否被拒登、目标国家是否减少、Feed 或商品记录是否突然下降。
2. 展示正常但点击下降：再看标题、主图、价格与搜索意图是否匹配。
3. 点击正常但订单下降：回到 Shopify、GA4 和站内转化检查。GMC 数据本身不能证明销售下降发生在哪一步。

怎么把 Google 商品中心接给 AI？

代码本身不难，真正容易卡住的是三层授权。少一层，请求都会失败，但报错原因完全不同。

1. 判断用途。 自用后台用 service account；让外部商家授权则用 OAuth 2.0。
2. 准备项目和凭证。 service account 要下载 JSON 私钥文件，也就是本地身份凭证，并把服务账号邮箱加入 Merchant Center；OAuth 要配置 consent screen 和 client。凭证不能上传 Git 或粘贴进聊天。
3. 设置授权范围。 两条路径都使用 https://www.googleapis.com/auth/content，目前没有单独的只读 scope。
4. 启用 API。 在 Google Cloud 启用 merchantapi.googleapis.com。返回 SERVICE_DISABLED 时先查服务开关。
5. 登记项目。 返回 GCP_NOT_REGISTERED 时，登记调用 API 的 GCP 项目：

POST accounts/YOUR_MERCHANT_ID/developerRegistration:registerGcp

registerGcp 会增加 API developer 身份，属于账号级动作。首次执行前须由账号所有者批准，并使用 Admin 身份。

接着做无资源写入的客户端。账号、Feed、商品和配送通过 GET 读取；表现报告用 POST 查询，但不修改账号资源。

from google.auth.transport.requests import AuthorizedSession
from google.oauth2 import service_account

SCOPE = "https://www.googleapis.com/auth/content"
merchant_id = "YOUR_MERCHANT_ID"
creds = service_account.Credentials.from_service_account_file(
    "service-account.json",
    scopes=[SCOPE],
)

session = AuthorizedSession(creds)
url = f"https://merchantapi.googleapis.com/products/v1/accounts/{merchant_id}/products"
response = session.get(url, params={"pageSize": 1000}, timeout=45)
response.raise_for_status()

for product in response.json().get("products", []):
    print(product.get("offerId"), product.get("productStatus", {}))

这段代码只演示自用后台的认证和商品读取。外部商家改用 OAuth 2.0；完整客户端还要处理翻页、错误、字段脱敏和其他接口。

运营负责人不用逐行验代码。交付时只看 6 件事：商品总数、拒登原因和国家、Feed 来源、最近成功时间、历史快照，以及模拟异常能否触发通知。

一次查询不够，怎么变成每日自动检查？

脚本只打印一次结果，运营仍要每天主动运行。真正省时间的做法，是每天保存 snapshot，也就是当天状态的快照，再和前一天比较。

我的每日检查会保存这些指标：

• processed product 总数；
• Shopify API Feed 和 Autofeed 数量；
• 拒登商品数、问题代码和影响国家；
• 商品链接、价格、库存和目标国家的异常；
• 最近一次检查时间与任务是否成功。

latest.json 给 Daily Digest 读取，历史 snapshot 用于周报。运行时重点注意 4 件事：

• 同一商品问题可能按多个 reporting context 返回，必须按商品去重。
• GMC Performance 会延迟回填，周报应排除最近 2 天，避免误报暴跌。
• processed product 不是实体商品数；同一商品在不同语言或市场 Feed 里可能形成多条记录。
• 定时任务返回 code 0 只代表当次运行结束，仍要监控授权过期、API 空响应和通知失败。

定时时间应避开 Shopify Feed 的同步窗口，并留在团队当天还能处理异常的时段。数字没变化时保持静默，只有商品数、Feed 或集中拒登等异常才通知运营。

AI 可以每天检查，但不要让它自动乱改

Merchant API 授权范围较宽。即使当前代码只读取，私钥或 refresh token 仍可能被其他代码用于写入，所以必须把安全边界写进流程。

日常读取可以自动运行；关闭 Autofeed、修改配送或归档数据源等线上变更必须单独批准。

确实需要修改时，我会按这个顺序做：

1. 写清修改范围，保存完整状态和 etag 版本标记。
2. 账号负责人批准后，只改目标字段。
3. 写后重新读取并比较原设置，等待异步处理，不重复提交。
4. 保留 rollback，也就是恢复修改前状态的方法。

一次真实修复能说明这条边界：

• 一批商品只在某个欧洲国家被拒登，最后定位到 GMC Shipping Settings 漏配。
• 补齐配送规则后，其他设置未变，相关拒登消失；但这只是一次成功样本，不能复制到所有拒登。
• 标题、价格和库存通常应回 Shopify 源头修改，避免下次同步再次冲突。

哪些店值得做，下一步从哪里开始？

如果你只有几件商品、只做一个市场，一个月才看一次 GMC，手动检查可能更划算。API 有授权、脚本和维护成本，不是接得越多越好。

出现下面任意两种情况时，只读监控开始有价值：

• 同时经营多个国家或语言 Feed；
• 商品拒登曾经几天后才被发现；
• 团队没人固定巡视 GMC；
• 商品数、Feed 数或免费商品流量需要周度汇报；
• 你已经在用 AI 处理日报，希望把 GMC 也接进去。

第一步不要自动修改设置。先建立 authorize、audit、daily、weekly 四个动作，稳定回答商品、Feed、拒登和影响国家 4 个问题。

先把只读检查跑稳，排除漏数、误报和通知失败，再考虑写操作。对大部分团队来说，当天看到拒登和流量异常，已经解决了 GMC 最麻烦的一部分。

后面还可以继续写什么？

目前，我还把 GSC、GA4、Shopify 和 Google Ads 接进同一套自动化看板，每天更新，不再逐个后台抄数。大家如果感兴趣，我后面可以继续写 GSC 或 GA4 的接入过程。

Google 官方资料

• Merchant API Overview
• Merchant API authentication
• Register a GCP project
• List processed products
• Search Merchant Center reports