验证执行 / feed-campaign-governance
Feed／GMC／投放交接 Playbook：用状态门槛代替口头确认
商品源、Feed、GMC、Campaign 和页面各有负责人；交接必须带版本、范围、证据与未解决风险。
先把本篇问题写成一句话，再确认它影响的是流量、Feed、页面、结账、EDM 还是数据复盘。
围绕商品字段、网站事实、诊断状态、审核反馈和广告理解留下证据；稳定原则。
直接判断：“Feed 已更新”“GMC 没问题”“广告已经在跑”都不是可交接状态。有效交接必须说明哪一批商品、哪个版本、在哪一层完成了什么验证、还有什么风险，以及下一负责人能否安全继续。
先做判断
先把商品链分成五个状态：
- 源数据就绪：商品身份、属性、价格、库存和变体在业务系统中真实完整。
- Feed 已转换：规则按预期生效，字段级 diff 与异常计数通过。
- GMC 已处理：目标商品的处理状态和已处理值经过回读。
- 投放可用：商品进入正确产品集合，没有已知重叠或错误排除。
- 页面已验证：展示商品、落地变体、交易条件和结账能够兑现。
这五个状态不是同义词。只有前一层有证据，后一层才可以接手。
决策框架：谁对什么负责
商品负责人拥有源事实，包括新品资料、合法标识符、变体、库存和价格。Feed 负责人拥有映射、规则、补充数据、更新、diff 与回滚。GMC 负责人拥有处理状态、网站一致性、政策问题与复核证据。投放负责人拥有商品范围、查询、渠道、预算与 Campaign 决策。站点和履约负责人拥有页面、结账、配送、退货和真实服务能力。
负责人可以是同一个人，但责任证据不能合并成一句“我看过了”。若出现异常，应按 Feed、GMC 与 Campaign 责任边界 回到真正能改变事实的层；团队共同语言来自 Feed 到 AI Shopping 的商品知识链。
交接包的最小内容
每次交接至少包含：变更目的、商品集合或筛选条件、源版本与输出版本、字段 diff、受影响市场、已完成验证、未解决风险、回滚位置、下一步动作和负责人。若变更涉及平台动态能力，还要附当前官方资料的核验日期。
状态描述应使用“已生成、已提交、已处理、已批准、已进入投放、已前台验证”等明确词，不用“搞定”“同步了”或“应该没问题”。例如“Feed 已生成”不能推导为“GMC 已处理”，“GMC 已批准”也不能推导为“Campaign 已有稳定流量”。
周度运营节奏
先看异常：大比例商品变化、身份变化、拒登、价格库存不一致和站点不可用优先。再看目录质量：新品完整度、变体、标题、图片和分类。然后看 GMC：处理状态、网站一致性、促销配送退货信号。最后才看投放：商品覆盖、查询、渠道、预算和利润。
周度会议不应变成报数字。每个问题都要写成“症状—证据—责任层—下一动作—验证时间”。对于 AI 商品发现或自动化投放，还要额外确认网站可读内容与 Feed 没有冲突；具体 AI 能力、报告和字段要求按当前官方资料复核。
常见误判
- 商品团队说“资料齐了”，但没有定义哪些字段和变体通过。
- Feed 工具显示成功，就直接交给投放负责人放量。
- GMC 批准后忽略页面、配送和退货的兑现能力。
- 投放异常时所有团队同时修改，导致无法定位变化来源。
- 交接只发截图，没有商品集合、版本、时间和可复查数据。
- 把平台自动修正当成 Feed 团队已完成修复。
验证清单
- 每个状态都有负责人、完成标准和可回读证据。
- 交接包包含范围、版本、diff、风险、回滚与下一动作。
- 对新品、促销、缺货和多变体商品做代表性抽检。
- 将目录与 Campaign 变更放到同一时间线。
- 区分生成、提交、处理、批准、投放和页面验证。
- 异常先归责任层，再允许相关负责人修改。
- 平台政策、界面、报告和 AI 能力标记核验日期。
适用边界
本文适合小团队和跨职能团队管理 Feed、GMC、Shopping 与自动化投放，也可用于外包交接。它不是项目管理工具模板，团队可以用表格、工单或代码化状态实现。若组织很小，一人兼任多层仍然可用；关键是保留证据边界。涉及生产写入、账户复核或大批量目录变更时，还应遵循各自的审批与回滚规则。