商品条码栏里填的那串数字，是变体ID的后八位

摘要：131个站里，商品数据出口那侧填了条码的只有11个站共141条，其中25条经不起校验位一算，而这25条集中在4个站。挖下去发现那些数字根本不是条码：brooklinen填的是平台变体ID的后八位，六条逐个吻合；fahertybrand填的那串跟变体ID同步递增，步长都是32768；everlane把两个编号用逗号塞进同一栏，前一个是真条码，后一个校验位应该是3却写了9。

上一篇按SKU对齐四份价格副本得出了一个让人意外的结论：审计工具反复报的价格不一致，519条报价里真正对不上的是0条。这一篇接着往下问一个更靠底层的问题。

能对齐的前提，是两边至少有一个共同的编号。价格会变、库存会变，这些字段对不上还情有可原；可有一类字段是绝对不该变的——商品的身份编号。SKU、条码、商品ID、网址里那截handle，它们存在的全部意义，就是让两台互不相识的机器指着同一件东西说，对，就是这个。

那么问题来了：那个编号本身，两边写的是同一个吗？这一轮量下来，答案比价格那一轮难看得多。有意思的是，这一层几乎没有任何审计工具会报警。

一件商品身上到底挂着几个编号？

先数清楚有几个。一个跑在Shopify上的商品，身上同时挂着五个编号，分配者各不相同。

这五个里，前三个是平台生成的，改不了也不会错；后两个靠人填，也就只有这两个会出问题。而恰恰是这两个，承担着最要紧的活儿：SKU是你自己系统之间对账的钥匙，条码是你和外部世界对账的钥匙。给产品填对GTIN这件事讲了很多年，这次是头一回把它放到实测里量。

量法沿用上一篇：131个站单线程采集、间隔2秒，商品页能正常打开的181个，把页面结构化数据里的每个Product节点、以及平台两个数据出口里的每个变体记录，逐条摘出编号来对。

结构化数据里那个SKU，出口里找得到吗？

SKU这一层的底子其实不差。数据出口给出的1085个变体记录里，填了SKU的1040个，填写率95.9%，剩下45个空着——多半是礼品卡、赠品这类本来就没进仓库的东西。

问题出在页面这一侧。摘出来的Product节点里，SKU能在出口的变体清单里找到对应的531个，写了SKU却在出口里查无此项的171个，压根没写SKU的241个。也就是说，接近一半的商品声明，机器拿到手之后没办法确认它到底在说哪一件货。

查无此项那171个，绝大多数不是写错，而是那些节点本来就不属于这个商品——推荐位、搭配购买的卡片各自带着自己的结构化数据，它们的SKU当然不在本商品的变体清单里。这一点上一篇已经量过。真正扎眼的是没写SKU那241个：它们既不是别人的商品，也没留下任何可对账的编号，就是一份没有身份证的商品声明。

这里要说句公道话。规范上SKU不是必填字段，不写不算违规。Google关于商品变体的说明里，真正被强调的是变体之间怎么区分、父子关系怎么表达。但不写的代价是实打实的：没有编号，跨系统对账就只能靠标题模糊匹配，而商品标题是最容易被改的东西。

出口那边空着的45个也值得看一眼。翻回原始记录，它们几乎清一色是礼品卡、赠品和服务类条目——这类东西不进仓库、不需要盘点，没有SKU反而是正常的。换句话说，SKU这一层真正的缺口不在出口，在页面。平台自己生成的那份数据把编号管得挺严，是往页面搬运的路上丢的。这跟页面标记与数据源的分类要对上是同一类问题：同一件事在两个地方各存一份，只要没有一条流水线把它们绑在一起，早晚会分家。

一串十三位数字，不上网也能验真假

条码这一层要先解决一个方法问题：怎么在不查任何数据库的情况下，判断一串数字是不是一个合法条码。

答案是校验位。GTIN这一族编码，无论8位、12位、13位还是14位，最后一位都不是内容，而是前面所有位算出来的校验数字。GS1给出的算法只有三步：从右往左，去掉最后那一位，剩下的位依次乘3和乘1，全部加起来，再拿10减去这个和的个位数，得到的就是校验位。

拿一条真实数据走一遍。dreametech那台扫地机的条码是00850075093816，去掉末位6之后，剩下的11位从右往左依次乘3、1、3、1……加总之后个位是4，10减4得6，与末位的6吻合，这就是一条合法条码。

这个算法的价值在于它完全离线。不需要联网、不需要查GS1数据库，二十行代码就能把全站的条码字段过一遍，算不对的那些可以直接判定为不是条码。判定不了的只有一种情况：一串数字校验位恰好蒙对了，概率是十分之一，样本量大的时候可以接受。这跟哈希与校验和是同一类工具——用极低的成本把明显错的挑出来。

填了条码的有多少，算得对的又有多少？

把这把尺子架上去之后，数字并不好看。

先看填写率：出口那一侧1085个变体记录里只有141条填了条码，八成七的商品在平台自己的数据里压根没有条码。页面那一侧稍好，但也只是把没写的比例从87%降到77%。

页面那一行的943条要说明一下口径：采集时每个页面最多只留了前60个Product节点，181个页面里有3个因此被截断，真实节点总数是1026个。少掉的83个集中在那3页上，它们是整批样本里节点最多的几页，所以这一行的分母偏小，填写率的分子分母同时受影响，比例仍然可比。

再看质量：填了的那141条里，25条经不起校验位一算，占17.7%；页面那一侧219条里18条算不对，占8.2%。换句话说，每六个填了条码的商品里，就有一个填的不是条码。

把长度摊开看，问题几乎全在八位那一档

光看合法率还不够，把这141条按长度和真伪拆开，规律一下子就浮出来了。

八位那一档一共20条，只有2条是真的。GTIN编码族的定义里，八位的那一种是给包装面积实在太小的商品用的，本来就稀少，日用百货和服装几乎用不上。所以判据可以再简化一步：看到八位条码先怀疑，它十有八九不是条码。另外141条里有38条以0开头，这个数字提醒着另一个隐患，后面自查那一节会讲到。

还有一个视角比条数更能说明问题：131个站里，出口那一侧填了条码的只有11个站，而这11个里有4个填的东西经不起校验。不合法的25条全部来自fahertybrand、brooklinen、everlane、peakdesign这四家，前三家各自贡献了一种典型错法。

但也别把这事说得太绝望，反面还站着几个正面例子。reebok一家就贡献了45条条码，一条不合法的都没有；stanley1913、allbirds、tentree、snowpeak这几家同样干干净净。这说明填对条码不是什么技术难题，只是有没有把它当回事的差别。有意思的是这几家有个共同点——都是靠自有工厂或者固定供应商供货的品牌，条码本来就是从供应链那头一路带过来的，不需要谁去补。而出问题的那几条，几乎清一色出在礼品卡这类根本不该有条码、却又被系统硬塞了一个值的条目上。

最刺眼的是第三个数。把两侧能按SKU配对上的记录拉出来，一共205条，两边条码完全相同的只有8条，出口那边空着的197条，两边都写了却不一样的0条。页面上写着条码、出口里却是空的，这种状态占了96%。同一个平台、同一个商品、同一套后台，两份数据在这个字段上几乎完全不重叠。

这个96%值得多想一层。两边都写了却写得不一样的是0条，说明没有人在两个地方各填了一遍还填岔了；真实情况是页面那一份条码根本不是从商品数据里读出来的，而是主题模板或者某个应用另外拼出来的。schema.org里gtin13这个字段该从哪儿取值，规范没有规定，于是各家实现自己发挥。这也解释了为什么很多店主在后台把条码改了，页面上那个数纹丝不动。

那些算不对的数字，原本是什么？

校验位只能告诉你这不是条码，不能告诉你这是什么。挖了三个站，三个都挖出了不同的东西，而且每一个都比想象中整齐。

它是变体ID的后八位

brooklinen的礼品卡商品，六个变体的条码分别是54099546、41115226、54132314、41541210、41573978、41705050，八位数字，校验位一个都不对。

把它们和同一条记录里的变体ID摆在一起看，谜底就出来了：变体ID是39366654099546，条码是54099546。条码就是变体ID的后八位，六条逐个吻合，无一例外。大概率是某次数据导入的时候，字段映射写错了一格，或者有人用截取函数临时凑了一列填进去。

它和变体ID同步递增

fahertybrand那张礼品卡更隐蔽。条码是24714309、24747077、24779845、24812613这么一串，看不出和变体ID有任何字面关系。

但把两列各自的差值算出来就露馅了：条码序列的相邻差值是32768、32768、32768……变体ID序列的相邻差值也是32768、32768、32768，两串数字步调完全一致。这说明它们出自同一次批量生成，条码那一列是跟着变体一起递增出来的另一套内部顺序号。顺便说一句，礼品卡本来就不该有条码，这一栏最合适的填法是留空。

它是两个编号被逗号粘在一起

everlane那件牛津衬衫的条码字段长这样：0-00000-76427-8,0-00001-31945-9。一个字段里塞了两个带连字符的编号，中间用逗号隔开。

这一条最值得细说，因为它同时是对的和错的。把逗号前那一段的连字符去掉得到000000764278，按GS1算法验算，校验位正好是8，这是一条完完全全合法的UPC条码；而逗号后那一段000001319459，校验位应该是3，实际写的是9，不合法。所以这一栏里，一个真条码和一个假条码并排躺着，任何按整个字段取值的程序读到的都是一串没法解析的字符。

这三个案例合起来说明一件事：条码栏里装的东西，可能是平台内部ID的一段、可能是和ID同步生成的另一串号、也可能是几个编号被粘在一起。它们的共同点是都长得像条码——一串数字，长度也差不多。不算校验位的话，肉眼看过去毫无破绽。

店主填的编号，和厂商给的那个是同一个吗？

把上面几条串起来，能看出一个更根本的错位：SKU和条码这两样东西，被很多店当成了同一类字段在填。

它们的区别在于谁说了算。SKU是你自己定的，爱怎么编怎么编，只要在你的系统内部不重复就行；条码是厂商向GS1申请的，全球唯一，你没有权力发明一个。跨境卖家申请条码这件事之所以要走流程、要花钱，就是因为它的价值恰恰在于不是你自己编的。

一旦把自编的号填进条码栏，后果不在你的站上显现，而在别人的系统里显现。Merchant Center对商品标识符的要求写得很直接：提交的GTIN必须是有效的，无效的会导致商品被拒。免费商品收录走的是同一套校验，同样过不去。

没有条码的商品怎么办？规范给了出路——用品牌加上厂商零件号这一对来代替，或者在自有品牌的情况下明确声明没有条码。正确的做法是留空并声明，而不是随手填一串数字进去。填空的坏处是少一条匹配线索，填错的坏处是整条商品数据被判无效，后者严重得多。

productID这一栏，各家填的不是同一类东西

顺着编号这条线往下看，还有两个字段值得单独拎出来。

第一个是productID。943个Product节点里，填了这个字段的只有72个，871个空着，空置率92.4%。而那72个填了的，内容清一色是平台的数字ID——也就是说，它填的是这个商品在你自己数据库里的主键，对外部系统而言没有任何可对账的价值。

第二个是节点标识符。空着的608个，填成整条网址的234个，填成路径的101个。Schema官方公布的全网使用统计里也能看到类似的分布：字段的存在率和字段的有效率是两码事，越是不影响页面显示的字段，越容易被随手填。

这两个字段的实际影响没有条码那么直接，但它们是同一个病灶的不同症状——但凡一个字段填错了页面也不会出问题，它迟早会被填错。页面显示的东西错了，运营第二天就来找你；机器读的东西错了，可能三年都没人发现。

handle、规范地址和og:url指的是同一个地址吗？

最后一个身份编号是网址本身。这一层的实测结果比前面几层好，但也有值得注意的地方。

181个商品页里，og:url与规范地址一致的153个，结构化数据里的网址与规范地址一致的124个、不一致的30个，还有3个页面压根没有规范地址。规范地址指向别处的42个，其中大部分并不是错——比如buckmason把每个颜色单独做成一个网址，规范地址统一收敛到主商品那一个，这是变体URL治理的标准做法。

另一类就得看情况了：aloyoga、glossier这几个站的规范地址带着地区前缀，指向带en-sg的那一版。地区版本各自声明各自的规范地址本身没问题，但如果同一件商品在不同地区版本上的结构化数据用的是同一份内容、只有网址不同，就会出现同一个SKU对应多个规范地址的局面。规范地址你说了不算这件事的根子就在这儿——你给的是提示，采不采是搜索引擎的事。

认不出是同一件商品，具体会丢什么？

把账结一下。身份编号这一层出问题，损失不像页面报错那样立刻可见，它是慢慢渗出来的。

第四条正在变重。购物代理读你的站的时候，判断两个网页说的是不是同一件商品，最省事的办法就是比对条码——比标题、比图片都不如比一串全球唯一的数字可靠。你没有这串数字，它就只能靠标题去猜，猜错的代价是你的商品被归到别人的条目底下。

第三条也值得说一句。给零流量商品再来一次机会的前提，是你还能把这个商品的历史数据串起来；编号一断，之前攒的评价、排名、投放历史就都成了孤儿。百万SKU的站点地图里，进出场管理的关键同样是编号的连续性。

一次盘清自己站上的商品身份编号

这套检查比上一篇那套还简单，因为它完全不需要联网核对，一个脚本跑一遍全站就有结论。

第一步，把出口那一侧的条码全部导出来，逐条算校验位：

curl -s "https://你的域名/products.json?limit=250" \
  | grep -o '"barcode":"[^"]*"' | sort -u | head -50

拿到列表之后，按前面那三步算一遍。算不对的，先别急着改，去后台看看这些商品是什么类型——如果清一色是礼品卡、赠品、服务类商品，那多半是历史遗留，直接清空最省事；如果混着正经在售的实物商品，那就得回源头查数据导入的映射。

第二步，看两侧对不对得上。把页面结构化数据里的条码和出口里的条码按SKU配对，重点不是找不一样的，而是找一边有一边没有的。页面上写着、出口里空着，说明这个字段是主题或者某个应用凭空生成的，而不是从商品数据里读出来的。这种情况下你在后台怎么改都不会生效，得去改那个生成它的地方。

第三步，查几个容易被忽略的形态问题：字段里有没有逗号、有没有连字符、有没有前导空格、是不是被存成了数字类型导致前导零丢失。这一步用结构化数据审计工具把字段扒出来之后再过一遍脚本，效率最高。

前导零丢失是这里面最阴的一种。保哥经手过一次迁站，新站条码栏看上去填得满满当当，导出来一算全是错的：旧站那一列存的是文本，导入新站的时候被识别成了数字，以0开头的十二位码统统掉了头一位，变成十一位。判据是把长度分布拉出来看，如果十一位那一档突然冒出一批，基本就是它。这次实测的141条里有38条以0开头，占了四分之一还多，也就是说这个坑的覆盖面相当广，只是平时没人去踩罢了。

还有一类容易被忽略的场合是同一个站上跑着两套结构化数据。插件和主题各写一份的时候，条码字段很可能一份有一份没有，机器读到哪一份完全看它们在页面上的先后。归并之前，改哪一边都是碰运气。

做完这三步，顺手把产品数据源那边的同名字段也对一遍。很多站的商品数据源不是从站上读的，而是单独维护的一份，两边各错各的，改一边不管用。

常见问题解答

我的商品没有条码，这一栏该怎么填？

留空，然后把品牌和厂商零件号这一对填全。自有品牌、手工制品、定制商品本来就没有GTIN，规范对此有明确的处理方式，不需要编一个。实测中那些算不对的条码，绝大多数出在礼品卡和赠品这类根本不该有条码的商品上，填空反而是最正确的做法。

校验位算不对，会不会只是我的算法写错了？

这个担心是对的，任何判定之前都该先验尺子。验法很简单：拿几条肯定是真条码的数据先跑一遍，比如包装上印着的、或者从品牌方拿到的那些。这一轮里dreametech、jackery、monos的条码都顺利通过，说明算法本身没问题，剩下算不对的才是真的算不对。

条码填错了，Google会直接惩罚我的自然排名吗？

不会直接影响自然排名，它影响的是商品数据源那条线：无效标识符会导致商品在购物渠道被拒，富媒体结果也可能因此不展示。这两件事都不表现为排名下降，而表现为该出现的地方没出现，所以特别容易被漏掉。

页面上写了条码但出口里是空的，改哪边？

改生成它的那一边。这种状态说明条码不是从商品数据里读出来的，而是某个主题片段或者应用凭空拼出来的，你在后台商品编辑页怎么改都不会反映到页面上。先定位是谁生成的，再决定是让它去读真实字段，还是干脆不输出。

SKU一定要写进结构化数据吗？

不是必填，但强烈建议写。它是你把页面声明和自己的商品数据对起来的唯一钥匙，没有它，任何跨系统核对都只能靠标题模糊匹配。实测中241个Product节点没写SKU，这些声明对机器来说是没有身份的，出了问题也无从追查。

变体商品，每个变体都要有自己的条码吗？

是的。条码标识的是具体的可售单元，不同尺码、不同颜色是不同的单元，各有各的条码。共用一个条码会让不同规格在外部系统里被合并成同一件商品，价格和库存也就跟着串了。这也是为什么条码这一栏应该在变体层填，而不是在商品层填。

迁站换平台，编号怎么保住？

条码天然跟着商品走，只要导出导入时字段映射别错就行——brooklinen那个后八位的例子，多半就是映射错了一格。SKU要靠自己守：迁站前先把旧站的SKU全量导出留底，新站建好之后逐条比对，别让系统自动生成一套新的。平台ID是保不住的，也不需要保。

这批数字能代表我的站吗？

比例不能，形态能。八成七没填条码、六分之一填错，只是这131个站在这一次采集里的样子，你的类目、你的供应链决定了你的数字会完全不同。但那三种填错的形态——填成内部ID的一段、填成同步生成的顺序号、几个编号粘在一起——是跨站通用的，值得照着自查一遍。

为什么审计工具不报这一层的问题？

因为工具的强项是比对和查缺。字段缺了它能报，两个字段不一样它能报，但一个格式正确、长度正确、只是校验位算不对的数字，它默认是合法内容。要发现这一层，得主动把校验规则跑上去，而这一步目前还得自己动手。

权威参考资料