提交商品 Feed 前的标识检查
商品 Feed 离开店铺前，应该把标识检查当作一次发布检查，而不是只看 Shopify 的 Barcode 栏有没有数字。真正要回答的是：这条 Feed 对应哪个可售商品和哪个变体？这个标识由谁负责、是否有可追溯来源？导出规则是否把它送到了正确的渠道字段？最终页面、Feed 和目标渠道是否描述同一个商品？如果其中一环无法证明，就应暂停受影响的发布范围。
简短结论是：格式检查只能发现机械错误，校验位通过也不能证明商业分配、归属、包装层级或渠道接受。源字段有值，只能证明源字段有内容；它不能证明最终 payload 使用了这个值，更不能证明目标渠道已处理或接受。
本文只处理“提交前如何作出放行或暂停决定”。它不同于 B01 对 GTIN 的定义，B02 对不同渠道所需标识的选择，B03 对已经出现的 Missing GTIN 警告进行诊断，也不重复宽泛的 Feed QA 文章。本文是博客入口场景，不是教程课程。
先看发布决定表
| 检查对象 | 应保留的证据 | 决定 |
|---|---|---|
| 商品与变体身份 | 商品 ID、变体 ID、SKU、尺寸、颜色、数量、容量 | Feed 无法对应一个明确变体时暂停 |
| 标识责任 | 品牌、制造商、GS1 或商品主数据责任人 | 候选号码没有责任人时暂停 |
| 包装身份 | 单件、多件装、箱装、组合包、实际发货配置 | 标识属于另一包装层级时暂停 |
| 字段映射 | 映射版本、输入样本、输出样本 | 只凭字段名称推断映射时暂停 |
| 机械检查 | 长度、结构、允许字符、校验位 | 失败就修正或暂停；通过不代表归属正确 |
| 品牌与 MPN | 权威值、变体关系、更新时间 | 空值、串值或矛盾时暂停 |
identifier_exists |
商品事实与当前渠道规则 | 被用来掩盖错误时暂停 |
| 页面与 Feed | 同一变体的 URL、页面属性、payload | 身份或关键属性不一致时暂停 |
| 发布证据 | 导出时间、版本、样本、审核人、回读计划 | 无法复盘时暂停 |
一、先锁定准确的商品和变体
不要从标题开始。标题适合人眼快速浏览，却不适合在多个变体之间做唯一关联。先记录稳定键：商品 ID、变体 ID、SKU、offer ID，或者项目中正式定义的其他映射键。再记录使这个变体成为独立可售商品的属性，例如尺寸、颜色、香味、重量、容量、套装数量、型号和浓度。源导出、转换记录、最终 payload 和发布记录必须使用同一个键。
商品模型中有时把标识放在商品级，有时放在变体级。只要客户可以分别购买两个变体，就应先按变体逐条核对，除非商品主数据责任人已经书面定义了不同的身份关系。不能因为标题相同，就把第一个变体的 Barcode 复制给所有变体。也不能因为某个默认变体在页面上显示正常，就认为其他变体也正常。
一个小型电商例子
一家店销售蓝色马克杯：单只商品 SKU 是 MUG-BLU-1，双只装 SKU 是 MUG-BLU-2。两个标题几乎一样，但发货配置不同，商品主数据中的身份也不同。一个按标题连接的导出器把单只商品的 GTIN 发送给双只装。两个号码都可能通过长度和校验位检查，可发布结果仍然错误，因为标识与可售配置不匹配。安全处理是修复源记录或映射规则，保存前后样本，再重新检查；不是再生成一个看起来合理的号码。
二、先确认来源责任，再看 Feed
标识必须有来源责任人。这个责任人可能是品牌、制造商、GS1 会员组织或企业正式维护的商品主数据团队。运营人员可以录入，工程师可以转换，但“录入过”或“导出过”本身都不能证明这个值由正确责任方分配给这个商品。
发布记录至少写清楚：值来自哪个系统、哪条记录、谁负责确认、何时确认、是否存在包装或地区差异。可用证据包括批准的商品主数据、制造商目录、包装稿件、受控的标识登记表或品牌方确认记录。不要把搜索结果、市场平台上一条相似商品、邻近 SKU 的号码当成权威来源。找不到负责人时，把状态写为 assignment_unverified，暂停受影响商品。
GS1 页面负责标准定义和分配背景；Google Merchant Center 文档负责 Google 对商品数据的处理边界；本地工具可以帮助做结构和校验位检查。三者不是同一层证据。Ecomwith 的 GTIN 工具不能分配商业 GTIN，不能证明所有权，也不能保证 Merchant Center 接受。
三、检查变体、组合包和包装层级
包装身份是发布检查的一部分。单件、多件装、箱装、组合包或实际发货配置，可能是不同的可售商品。逐项比较数量、尺寸、净含量、型号、颜色、配方、容量和客户看到的其他差异。不要把父商品的一个标识默认视为所有子 offer 的标识。
如果 Feed 生成的是组合包，要先确认渠道应把它当作一个 offer，还是应发送组成商品。若导出器生成了商品主数据中根本不存在的组合配置，应先暂停并修复商品事实。一个字符串“看起来有效”，不能回答“它是否属于这个 offer”。
可在检查表增加三列：source_packaging、submitted_packaging、packaging_evidence。当三列无法对齐时，状态不应是“已检查”，而应是“包装身份待确认”。这样做能避免运营人员把包装差异误写成格式问题。
四、检查真实映射，而不是只看源字段
对一个已知正常商品和一个刚修改的商品，沿着完整链路取样：
- 源商品与源变体记录；
- 导出器真正读取的规范字段；
- 连接器或 Feed 规则；
- 中间标准化记录；
- 最终渠道 payload；
- 目标渠道处理结果和诊断行。
保存映射版本、导出时间和去除敏感信息后的样本。确认目标字段实际来自 Shopify Barcode、商品主数据、PIM、补充 Feed，还是人工覆盖。字段叫 barcode、gtin 或 identifier 都不是证明；必须阅读实际映射合同或观察真实输出。
常见缺陷包括：用商品级字段代替变体级字段；把长数字当作数值导致前导零消失；遇到空值时自动取默认变体；补充 Feed 覆盖主 Feed；或者把一个父商品值传播给整组子商品。标识应作为字符串保存。发布前要逐字符比较最终值，包括前导零，而不是只比较“看起来像同一个号码”。
五、把四种验证严格分开
发布记录不要只写一个绿色勾。至少区分以下四类：
| 类型 | 能证明什么 | 不能证明什么 |
|---|---|---|
| 格式 | 长度、字符和基本结构符合要求 | 商业分配、归属、包装和渠道接受 |
| 校验位 | 算术校验位与前面数字一致 | 号码属于商品、品牌或具体变体 |
| 分配/归属 | 有责任来源确认值识别这个商品 | 连接器确实把它发送出去 |
| 渠道处理 | 目标收到了并处理了该 payload | 其他国家、其他 offer 或下一次导出仍然一致 |
因此，工具结果通过只是一个门。可以把 Ecomwith GTIN 工具用于开发和 Feed QA 的结构检查，然后单独保存来源责任、变体匹配和 payload 对照。不要把“格式通过”缩写成“已验证”。更准确的状态包括 format_pass、assignment_confirmed、payload_match、destination_pending。
六、一起检查 identifier_exists、品牌和 MPN
标识决定是商品事实集合，不是一个可以随意切换的开关。如果商品确实没有适用 GTIN，当前渠道可能允许真实的无标识处理。但这不意味着品牌和 MPN 可以空着、乱填或从相邻商品复制。确认这些字段由谁负责、是否适用于这个变体、当前渠道规则是否允许该声明。
不要因为源字段暂时为空、分配记录缺失或导出器出错，就把 identifier_exists 设为 false。这些情况是未解决的数据或流程问题。只有商品事实确实表明没有适用标识，且当前渠道规则允许如实声明时，才考虑无标识处理。自有品牌、定制商品和其他特殊商品也需要记录事实和所采用的规则版本，而不是凭感觉填值。
品牌和 MPN 不能悄悄从父商品或邻近变体继承，除非商品主数据明确规定这种关系。若不同型号或变体的 MPN 不同，映射必须表达差异；若字段确实不适用，要记录“不适用”的原因，不能用占位文本制造完整感。
七、核对页面和 Feed 是否描述同一个 offer
落地页与 Feed 是两个需要一致的表面。按同一变体比较标题、品牌、MPN、标识（如果页面展示或结构化表达）、包装数量、尺寸、颜色、价格和其他渠道相关属性。页面 Schema 正确，不会修复 Feed 映射；Feed 有值，也不代表页面打开后选择了同一变体。
使用 Feed 实际提交的规范商品或变体 URL。检查 URL 是否可访问、目标变体是否可见、默认选择是否把用户带到另一个商品、缺货选项是否改变身份。页面检查和 payload 检查必须分别记录。“页面看起来正常”不能证明目标渠道收到的就是这一条记录。
如果页面结构化数据与 Feed 不同，先区分哪个系统是这个属性的责任源，再修复最早发生不一致的边界。不要为了让一个表面看起来一致，就同时改动多个源系统。每次只修一个责任边界，才有机会在发布后解释结果。
八、制作可复盘的发布证据包
提交前保存一个小而完整的证据包：
- 范围：涉及的商品、变体、国家、语言和渠道；
- 源快照时间、数据负责人和主数据版本；
- 连接器与映射版本；
- 一个已知正常样本和一个变更样本的前后 payload；
- 格式、校验位检查结果和所用工具版本；
- 品牌、MPN、
identifier_exists的决定和依据； - 页面 URL、目标变体和页面回读时间；
- 审核人、审核时间、发布 ID 和导出时间；
- 已知例外、暂停原因、重新导出或回滚路径。
不要在证据包里写入凭据，也不要添加不必要的客户个人资料。连接器的“上传成功”只能证明传输完成，不能证明渠道接受。目标渠道需要处理时间；在确认同一个商品、同一个变体和同一个值已经被目标读取前，不应写“已修复”“已接受”或“已完成”。
九、设定最小范围的安全暂停规则
暂停应该尽量小，但系统性缺陷必须扩大范围。一个变体源字段为空，可以暂停一个变体；多个变体收到默认值，应暂停对应商品族或映射规则；前导零在全量导出中消失，应暂停受影响的整个 Feed；品牌和 MPN 无责任人，应暂停受影响商品；渠道规则刚变化且尚未复核，应暂停相关国家和渠道。
不要通过手工编辑几百个商品字段来掩盖一个连接器缺陷。先冻结发布，保存失败样本，找出第一个断裂边界，使用既有的上一个导出或回滚路径。暂停只是“证据不足”的决定，不是“目标渠道一定会拒绝”的预测。发布日志要把这两句话分开。
十、提交后仍要读回同一条记录
提交后用稳定键读取同一商品，确认目标收到了预期值、关联到了预期 offer，并处理了当前版本。若出现警告或拒批，保存原文和时间。不要把“导出完成”改写成“已接受”。如果处理仍在等待，使用 destination_pending；如果目标明确清除了同一条记录的诊断，才可以写入对应的直接证据。
本文章的 Semrush 记录是 Informational，KD 为 20，volume 为 n/a，状态为 volume_not_available。这不构成流量、排名、收录、点击或经营结果的证明。本文也不保证任何店铺、商品、国家或渠道获得 Merchant Center 接受；它提供的是可复盘的发布边界。
常见问题
审核人可以怎样走完一遍检查
审核人应当不用依赖口头记忆，就回答五个问题：这条记录究竟是哪一个 offer？标识事实由谁负责？哪个转换步骤产生了最终值？哪个页面代表这个 offer？提交后将用什么证据证明目标处理了同一条记录？只要答案是“应该有人知道”，这条记录就不应被标为无条件放行。
先看发布范围，再从每一种映射路径、商品类型、包装层级和国家中抽取样本。一个样本不能代表拥有多个连接器或补充 Feed 的全量发布。对每个样本，把源键写在最终 item 键旁边；如果两个键无法直接关联，就要把关联规则本身作为发布风险处理，而不是凭标题猜测。
接着检查空值行为。源字段为空、输出字段缺失、输出了占位文字、从父商品继承值，是四种不同状态。导出器不能静默地把其中一种变成另一种。除了数字本身，还要检查前导零和字符编码。如果系统会做标准化，发布记录要写清楚具体规则、责任人以及为什么允许这样做。
再检查例外。无标识商品、多件装、自有品牌商品可能有不同处理路径，但“例外”必须描述商品事实，不能只是运营快捷方式。没有负责人、规则依据和复核条件的例外应当暂停。这样下一次发布才可以比较，而不会让旧例外慢慢变成无人维护的隐藏逻辑。
最后把状态分开记录：source_checked 表示看过源记录，mapping_checked 表示追过导出规则，payload_checked 表示最终行一致，submitted 表示发生传输，destination_pending 表示目标仍待处理，destination_readback 表示同一条记录已经直接读回。不要把这些状态压缩成一个绿色栏。顺序本身就是证据。
发现不一致时，先保存原始样本再编辑。写清楚第一次发生分歧的边界、该边界的责任人和最小暂停范围。一份好的发布证据包能让团队只修复一个边界，再用同一组对照重新检查；它不应要求任何人猜上一版导出了什么。
把发布清单写成明确的 manifest
对于反复提交的 Feed，即使渠道没有强制要求，也建议为每次发布建立一个简短的 release manifest。它不是第二套商品目录，而是这次提交所使用的输入和判断的索引。写入发布编号、源快照时间、导出时间、映射版本、渠道、国家范围和审核人。可以记录抽样覆盖了哪些路径，但不要把抽样数量写成流量、效果或接受保证。
manifest 应该指向源快照和经过脱敏的 payload 样本，而不是把全量商品复制到邮件里。写清楚标识字段、保留字符串的规则、包装层级规则，以及主 Feed 和补充 Feed 同时有值时的优先级。如果不同渠道有不同规则，要把渠道边界单独列出。审核人需要知道两次看起来相似的导出是否使用了同一份合同。
建议使用稳定而且含义清楚的状态：planned 表示范围已定义；source_reviewed 表示责任人检查了商品事实；mapping_reviewed 表示追踪过转换；payload_reviewed 表示样本输出一致；submitted 表示发生了传输；destination_pending 表示目标还没有直接读回；closed_with_readback 表示同一个 offer 已经被直接确认。这些词描述证据，不是预测结果。
用记录比较 payload，不要只比截图
截图可以帮助人眼理解警告，却不适合当作发布比较的唯一工具。每个样本应保存一条经过脱敏的结构化记录，至少包含源键、变体属性、源标识、转换后标识、目标字段、品牌、MPN、identifier_exists、落地页 URL 和映射版本。比较两次发布时，分别显示新增、删除和改变的字段。字段缺失与字段保持空值不是一回事。
特别检查软件容易改变的内容：前导零、空白、Unicode 标点、数字强制转换、null 和重复键。导出排序改变时，先按稳定 offer 键排序再比较。连接器如果生成新的 item ID，要保留源键到目标键的关联，才能证明两边是同一个商品。如果一个标识出现在多个 offer 上，不要只凭 payload 下结论；应让商品主数据负责人确认这是有记录的包装关系，还是重复使用造成的错误。
一个完整的发布例子
假设一家店在同一个下午修改商品主数据和 Feed 连接器。目录里有黑色背包的 20 L 与 30 L 两个变体。20 L 源记录有已确认的标识和 MPN；30 L 的 MPN 已有，但标识仍等待责任人确认。连接器测试显示“导出成功”。
审核人不会直接放行整个商品族。先把两个源变体分别关联到 offer 键，确认 20 L payload 携带的是 20 L 的属性。随后发现 30 L 因为映射按商品 ID 而不是变体 ID 关联，继承了 20 L 的标识。机械检查通过了这个继承值，但这恰好说明工具结果不能代表身份正确。审核人暂停 30 L，指定映射责任人；20 L 只有在 manifest 明确限定范围后才可以独立继续。
映射修复后，用保存的失败样本与新 payload 对照。30 L 的标识仍要等责任人确认分配；品牌和 MPN 另行检查。打开选中 30 L 的商品页，记录 URL 和页面可见属性。状态先变为 payload_reviewed，再变为 submitted；目标直接读回同一个 offer 之前，仍保持 destination_pending。在整个过程里，“检查器通过”和“连接器成功”都不能被改写成“已接受”。
回滚与暂停矩阵
响应范围要跟随最早断裂的边界。一个源记录错误，就修复或恢复这一行并暂停该 offer；变体关联错误，就暂停相关商品族，恢复可解释的映射版本，不要先批量改商品事实；整个导出丢失前导零，就暂停受影响的渠道 Feed，回到最后一份可以解释的导出；补充 Feed 覆盖主 Feed，就按既有回滚方案隔离这条优先级路径；目标渠道规则不清楚，就暂停相关国家和渠道，直到当前规则完成复核。
回滚记录要写清恢复了什么、替代哪个发布编号、哪些商品仍在暂停、重新开放需要什么证据。不要通过删除历史让失败发布消失，也不要覆盖唯一的失败 payload 样本。可逆的发布应该同时解释错误行和修复行，让下一位审核人能够复现判断。
提交前每次都要跑 GTIN 检查工具吗？
当字段应包含 GTIN，尤其是导入、映射或序列化规则发生变化后，机械检查很有用。但它只是一个门。来源责任、变体身份、包装层级、页面一致性和渠道处理仍要单独核对。
SKU 可以替代 GTIN 吗？
不能自动替代。SKU 通常是店铺内部库存键，GTIN 是具有不同身份和责任范围的商业商品标识。应使用渠道文档规定的字段和商品真实事实，不能把 SKU 改名成 GTIN。
目标渠道还在处理中，可以放行吗？
如果发布制度允许，可以记录“已传输”，但必须保留 destination_pending，直到同一条商品记录被直接读回。处理等待不等于接受，也不等于修复完成。
连接器刚改完，第一步检查什么？
同时抽取一个正常样本和一个变更样本，从源记录追到最终 payload。重点检查变体关联、前导零、空值处理、包装层级和补充 Feed 优先级。样本无法解释时，先暂停全量发布。
已经出现 Missing GTIN 警告怎么办？
转入按警告类型、变体和 payload 回溯的诊断路径。本文的作用是让提交前留下完整证据，帮助后续诊断定位，而不是替代已经发生的目标渠道诊断。
来源
- GS1 Global GTIN standard
- GS1 support：What is a product identifier?
- Google Merchant Center Help：Find a GTIN
- GS1 Canada：Global Trade Item Numbers
这些来源用于标准术语、商品标识背景和渠道商品数据边界；它们不构成某个店铺、商品、国家或发布批次的接受保证。