GTIN、UPC 和 EAN 有关系,但不是 Shopify 里三个可以随便互换的商品字段。GTIN 是全球商品标识体系,UPC 通常指北美零售常见的 12 位 GTIN-12,EAN 通常指许多其他市场使用的 13 位 GTIN-13。Shopify 把已经分配给商品或变体的标识放在 Barcode 字段,SKU 则是商家自己管理库存、履约和报表的内部编码。
先确认商品身份,再讨论数字格式。如果制造商或品牌方已经给这个具体商品和变体分配了 GTIN,就使用真实分配的值。如果商品没有 GTIN,就按销售渠道对无标识商品的规则填写。不要编一个号码,也不要把相似商品的号码复制过来,更不能把校验位正确的测试值放进正式 Feed。Ecomwith GTIN 工具只负责开发和 Feed 质检中的格式、长度和校验位,它不分配商业 GTIN,也不能证明号码归属。
这篇文章面向需要整理 Shopify Barcode、SKU、MPN、Merchant Center 和结构化数据的运营团队。变体、白牌商品、定制品、组合包、箱级 GTIN-14,以及大批量改字段前该保留什么证据,都会放进同一条检查路径。
1. 先把商品标识、条码图形和内部编码分开
GTIN 是数据,条码是承载数据的机器可读图形,SKU 是企业内部编码。它们经常同时出现在包装和商品记录中,所以团队很容易把三者混为一谈。问题在于,不同系统拿这些值做的判断完全不同。
GS1 把 GTIN 用于标识会被定价、订购或开票的贸易项目。供应链、零售商和平台可以用同一个号码指向同一个商品。UPC-A、EAN-13、ITF-14 等条码把号码编码成扫描器能读取的图形。印出一组黑条不会自动创造商品身份,它只是展示一个已经有分配关系和责任人的标识。
Shopify SKU 服务于自己的经营流程。商家可以把款式、颜色、尺码、仓库或其他规则放进 SKU,方便拣货、退换、库存同步和报表。Shopify 建议每个变体使用唯一 SKU,也提醒条码扫描器通常读取 Barcode 字段,不是 SKU 字段。SKU 可以自行设计,商业 GTIN 不能因为一组数字通过了校验位就被当作正式分配。
2. 改 Shopify 字段前先看这张表
| 字段 | 谁负责分配 | 主要用途 | Shopify 位置 | 常见错误 |
|---|---|---|---|---|
| GTIN | 品牌方或制造商,通过对应 GS1 路径管理 | 零售、Feed 和平台之间匹配同一商品 | 变体 Barcode | 格式正确,但号码属于其他商品 |
| UPC / GTIN-12 | 商品标识责任方 | 北美常见的零售消费单元 | 变体 Barcode | 把 UPC 当成另一套内部编码 |
| EAN / GTIN-13 | 商品标识责任方 | 许多北美以外市场的消费单元 | 变体 Barcode | 丢失前导零或错误转换格式 |
| GTIN-14 | 商品标识责任方 | 箱规、贸易项目组合或特定多包装场景 | 仅在它确实标识当前贸易项目时使用 | 把箱级代码挂到单件零售商品 |
| SKU | 商家自己 | 库存、履约、客服和报表 | 变体 SKU | 重复或频繁变化导致系统对不上 |
| MPN | 制造商 | 制造商内部的型号或零件匹配 | 渠道或商品数据集成字段 | 没有依据地用商家 SKU 顶替 |
| Shopify variant ID | Shopify | Shopify 和集成里的技术身份 | 平台记录 | 集成只映射商品,没有映射具体变体 |
来源证据、Shopify 字段、渠道数据和页面标记必须描述同一个商品身份。
这张表要从左往右读。先确认谁有权分配,再决定字段放在哪里。很多团队反过来做,看到 Shopify 的 Barcode 为空,就先找一个数字填进去。更安全的问题是,这个具体商品和变体有没有被正式分配标识,证据在哪里。
3. 从商品来源判断,不要从销售渠道倒推
经销商品的标识通常来自制造商、供应商文件、包装或经过验证的商品目录。运营要做的是准确录入,并且匹配到正确变体。一件蓝色 M 码上衣和蓝色 L 码上衣可能各有一个 GTIN。父商品存在一个有效号码,不代表所有颜色和尺码都能复用。
白牌和自有品牌需要另一条证据路径。品牌方已经申请和分配 GTIN 时,要把分配记录保留在商品主数据里。尚未分配时,不要为了 Merchant Center 编一个像条码的值。Google 说明,部分自有品牌和白牌商品可能没有 GTIN,这时 brand 和 MPN 会更重要,具体仍要以商品类型和当前字段规范为准。
定制品、手工品和独一件商品可能没有标准标识。Google 提供 identifier_exists 字段,用来说明商品是否有唯一商品标识。只有在商品确实没有相关标识时,才能设为 false。用 false 绕过真实存在的 GTIN,可能收到警告或拒登。这个字段是在陈述商品事实,不是绕过审核的开关。
二手、古董、兼容件、翻新商品、组合包和个性化商品要按具体规则处理。有些商品继续使用制造商 GTIN,有些商家自组套装按 Google 的 bundle 规则提交主商品标识,制造商创建的套装则可能有独立分配。商品标题、condition、bundle、brand 和标识必须描述同一个 Offer。
4. 导入或批量编辑前,先做变体级映射
Shopify 的 SKU 和 Barcode 都在变体层。商品选项多时,这一点最容易被忽略。批量导入前先做变体表,每行至少包含商品 handle、颜色尺码等选项、variant ID、SKU、Barcode 或 GTIN、brand、MPN、来源文件、来源日期和复核人。
一行只对应一个可销售变体。四种颜色、三个尺码的 T 恤应有十二行变体,Shopify 建议配十二个唯一 SKU。制造商如果为每个变体分配了 GTIN,Barcode 也要逐一匹配。把一个父商品号码整列向下复制,看起来很整齐,实际可能把十二个商品身份写成同一个。
传输时把标识字段当文本保存,避免表格删除前导零、转成科学计数法或四舍五入。校验位可以发现部分输入错误,但无法恢复被表格改掉的数字,也不能证明商品归属。
导入后不要只抽查最简单的商品。样本应覆盖主力 SKU、新品、多变体商品、刚换供应商的商品、Merchant Center 报错商品,以及多市场销售的商品。逐个比较 Shopify 变体和包装或供应商证据,再比较 Shopify 与渠道导出行。检查必须落到具体 item,不能停在商品标题。
5. Merchant Center 到底在检查什么
Google 的 gtin 字段支持多种格式,包括 UPC 对应的 GTIN-12、EAN 对应的 GTIN-13、JAN、ISBN-13,以及适用于对应贸易项目的 ITF-14。当前规范接受 8、12、13 或 14 位数字,并要求正确校验位,同时限制特定前缀、优惠券范围、猜测值和错误变体匹配。
校验位通过只解决算术。号码没有分配给这个商品、brand 或 MPN 冲突、变体重复使用标识、落地页展示了另一个 Offer,仍可能导致拒登或限制。只修 checksum,不修商品身份,目录问题不会消失。
商品存在已分配 GTIN 时,要按渠道要求提交正确值。Google 说明,已有 GTIN 却没有提供,商品可见度可能受限。商品没有 GTIN 时,使用平台支持的无标识路径,并填写适用的其他标识。不要因为内部 SKU 也具有唯一性,就把它塞进 GTIN 字段。
Shopify 的 Google & YouTube 集成会读取 Shopify 商品数据,但同步前可能还需要补充字段。渠道出现 GTIN 问题时,要从集成记录追到 Shopify 变体,再追到供应商、包装和分配证据。如果只改 Merchant Center 最后一层,而源字段没有修,下次同步还会把旧值覆盖回来。
6. GTIN 生成器能做什么,不能做什么
生成器可以计算校验位,并生成结构正确的测试值。这对软件开发、表单校验、扫描流程、导出测试和 Feed 质检很有用。开发者可以验证字段是否接受十四位数字,校验器能否拦截错误 check digit,CSV 是否把标识保留为文本。
结构正确不等于正式分配。它不能证明 GS1、制造商或品牌方发放了这个号码,不能证明号码属于眼前商品,也不能保证 Merchant Center、Amazon、零售商或仓库接受。因此,Ecomwith 明确把生成结果标为测试值,把商业分配放在工具之外。
工具有两种安全用法。第一,在开发或数据质检前验证格式和校验位逻辑。第二,把真实来源提供的 GTIN 做长度和校验位检查,作为完整复核中的一步。之后仍要回到分配来源、包装、供应商记录、Shopify 变体和渠道诊断。绿色结果表示算术通过,商品声明还需要证据。
自己制造商品,需要商业标识时,应走所在市场对应的 GS1 成员组织路径。经销商品则向制造商或经过验证的供应商获取。商品确实没有 GTIN 时,记录无标识事实并使用渠道支持字段。三条路径解决的问题不同,不要把它们压成搜索免费号码。
7. 先做一次 20 个 SKU 的标识审计
目录有几千个变体时,不用第一天就全查。先选二十行高风险样本:五个畅销品、五个 Merchant Center 标识问题商品、五个新品或刚修改的变体,再加五个供应商数据较弱的商品。某一组连续出现问题,再扩大同类样本。
- 导出 Shopify 商品和变体字段。
- 把 SKU、Barcode、brand、MPN、handle 和选项拆成独立列。
- 为每行收集包装、供应商、制造商或分配证据。
- 检查长度和校验位,但不把结果当作所有权证明。
- 对照 Merchant Center 或市场平台里的具体变体。
- 检查落地页、Product 结构化数据、价格、库存和默认变体。
- 给每项修复指定负责人和唯一来源字段。
- 修复后重新导出,确认下一次同步没有恢复旧值。
问题可以分四类。格式问题包括位数、非数字字符和校验位。身份问题包括号码属于其他商品或变体。来源问题是 Shopify、供应商和渠道互相不一致。政策问题是商品没有标识,但 identifier_exists、brand、MPN、bundle 或 condition 处理错误。
不要用填满了多少单元格衡量结果。一个空值如果有明确无标识路径,可能是正确状态。一个填入的猜测值反而更危险。有效结果是每个标识都有责任人、具体变体、可信来源和可追溯记录。
8. 页面标记和 Feed 要说同一件事
Google 可以通过页面结构化数据、Merchant Center Feed 或两者一起读取商品信息。Search Central 建议在适用时同时使用,因为不同表面可以帮助系统理解和核验商品。前提是数据一致。Product markup、页面可见内容、Shopify 变体和 Feed 必须对商品身份、价格、库存和当前变体给出同一个答案。
只有当号码确实属于页面里的商品,才在 Product 结构化数据里使用 gtin8、gtin12、gtin13 或 gtin14。变体切换页面应以可抓取且受支持的方式输出正确变体数据。不要为了让验证器看起来完整,把一个父级 GTIN 写进所有变体 markup。
数据冲突时,先定来源责任,再改代码。商品团队负责标题和变体结构,品牌或供应商记录负责 GTIN、MPN,Shopify 负责当前可销售变体和库存,主题应该读取这些字段,不应再硬编码一份。Merchant Center 按自己的格式接收同一套商品事实。
修复后检查页面渲染、结构化数据、Shopify 导出和渠道 item。平台诊断需要时间刷新,Google 也说明部分问题状态不会立刻变化。记录提交时间和复查时间,避免系统还在处理上一次修改时,团队又反复改写字段。
9. 保留一条商品标识决策记录
重要标识变更至少保留商品和变体、旧值、新值、字段、修改原因、来源证据、复核人、影响渠道、修改时间和验证状态。供应商换文件、员工批量编辑或集成重新同步时,这条记录能防止旧数据悄悄回来。
记录里要分开三个结论。格式有效表示结构和校验位通过,分配已验证表示证据能把号码连接到具体商品或变体,渠道已接受表示某个平台处理了当前记录,且不再出现相关问题。任何一个结论都不能替代另外两个。
小店用表格就够,大团队可以放进 PIM 或数据质检流程。工具复杂度不是重点,纪律才是重点:一个变体一行,一个字段责任人,一个来源,一个带日期的判断,最后从渠道读取结果。
10. Shopify GTIN 最终清单
- 确认具体商品和变体是否存在正式分配标识。
- 把 SKU 和 Barcode 放在各自的 Shopify 变体字段。
- 使用制造商或品牌方 GTIN,不生成商业号码。
- 传输时保留前导零,并把标识字段作为文本处理。
- 商品分配规则要求时,每个变体使用自己的标识。
- 只有商品确实没有唯一标识时才使用 identifier_exists。
- 让 brand、MPN、GTIN、condition 和 bundle 描述真实 Offer。
- 对照 Product 结构化数据、Shopify 和渠道 item。
- Ecomwith 仅用于格式、校验位、开发和 Feed 质检。
- 问题关闭前保留分配证据和平台 readback。
如果团队说不清号码由谁分配、对应哪个具体变体,就先停止发布这个字段。空值可以继续调查,错误值却可能把商品匹配到别人的目录记录,引发拒登,并通过集成扩散到所有渠道。
11. 边缘场景要在批量出错前处理
Dropshipping 和供应商目录导入要先给来源分级。供应商文件里有 Barcode 列,不等于数据一定可靠。要确认对方是制造商、授权经销商,还是另一层转售商,再用包装、制造商记录或验证过的商品数据抽样。来源说不清号码从哪里来,就把字段标为未验证,不要整库导入。
ERP、PIM 和仓库迁移需要字段映射契约。明确 SKU、GTIN、MPN、variant ID 和 inventory 分别由哪个系统负责,切换时保留旧值、新值和固定样本。迁移技术上成功,也可能交换 SKU 与 Barcode,或者删除前导零。问题往往在后续错拣、目录错配和渠道拒登时才暴露。
组合包要先定义卖的是什么,再决定标识。制造商创建的组合包可能有独立 GTIN,商家自组 bundle 则按另一套渠道规则处理,不能随便继承某个组件号码。记录 Offer、包装内容、创建方和当前渠道要求,标识跟着商品定义走。
两个平台判断不一致时,不要把先通过的平台当成真源。一个平台可能接受了另一个平台拒绝的字段,也可能读取了旧目录。先回到分配证据和具体变体,再按渠道格式提交。平台接受是运营证据,不能转移所有权,也不能把错误号码变成正确号码。
打印还多一层边界。商业 GTIN 正确,不代表任意条码图形都能用。symbology、尺寸、quiet zone、对比度、材料和实际扫描都要按用途验证。SVG 或 PDF 生成成功只证明文件存在,不能证明在目标仓库或零售环境能扫描。打印 QA 和标识分配要分开记录。
交给代理商和 freelancer 也执行同一规则。不要发一张 Barcode 为空的表,让对方去搜索填满。应提供商品来源、允许字段、无标识规则、抽样方法和升级负责人,并要求 change log 和 Shopify、渠道 readback,避免承包方好心地把猜测值批量写入。
这些场景最终都靠一条控制:任何标识进入生产前,都要有具体 item、命名来源和责任人。小店用表格能做到,大目录也能把它写进系统。以后做自动化时,自动化才能保留证据,而不是替商品事实补空白。
