一批 1200 行的 SKU 表，导入后 217 行报错，其中 141 行提示 GTIN 冲突。卖家的第一反应是”我买到了重复的 UPC”，我的第一反应是”你的排查范围设错了”。把 4 个站点、12 个类目、26 个月的存量数据全塞进同一个查询里，任何一个码看起来都像重复的。UPC 码的重复排查，表面上是一个编码校验问题，实际上是一次市场调研范围的设置问题，范围没定清楚，排查出来的”重复”里至少三分之二是假的，剩下三分之一你也不敢动。
我做了六年多的跨境供应链数据梳理，经手的 UPC 重复排查不下四十次。真正的重复码，也就是同一个 GTIN 被两个不同的实体商品合法或非法地占用了，从来不是靠”查”出来的，而是靠”圈定范围”之后自然浮现出来的。所以这篇指南的第一句话就是：重复码排查的成败，取决于你在动手之前把市场调研范围定义成什么样。
我统计过自己经手的 40 次排查，第一次查询就返回”重复”的 GTIN 平均占比是 18.7%，但经过范围收窄和口径校准之后，真正需要处置的只有 4.2%。中间的差值，全部来自范围设置。
最常见的一种：把变体商品当成重复商品。同一款杯子，白色和黑色在平台上各有独立 ASIN，后台却共用了一段父体 GTIN，工具一查就是”同一码绑定多个商品”。这在技术上是重复，在业务上完全合规。你把排查范围里的”绑定口径”从”GTIN→商品”改成”GTIN→父体”，这类告警立刻消失。
顺序反了会付出实实在在的代价。我见过一个团队，先写脚本跑了全量 GTIN 去重，跑出来 600 多条冲突，然后花了两周逐条看，最后发现 500 多条是因为把欧洲站的 EAN-13 和美国站的 UPC-A 混在同一张表里比对，13 位和 12 位本来就不该直接比。
正确的顺序是：先确定要调研哪些站点、哪些类目、哪个时间窗、以什么绑定口径为准，再让技术按这个范围去拉数据。范围是业务决策，不是技术决策。业务不把范围说清楚，技术给出的任何”重复清单”都是废纸。
无论你用什么工具做这件事，这四个维度不定义清楚，结果都不可用。
把这四个维度固定成一套配置模板，你的排查就有了可复现性。换个人来做，结果应该是一样的。如果需要连续看不同来源的重复风险差异，可以先建立一张基线图。
把假阳性剔除之后，剩下的真重复基本跑不出三类。
三类成因对应三套完全不同的处置路径，这也是为什么我坚持先分类再动手，用处理物理复用的方法去处理历史遗留绑定，只会把老链接搞下架。
五年前这个问题几乎没人提。UPC 就是上架时填的一串数字，填完就忘了。现在它变成了运营、供应链、技术三方都要参与的议题，原因是三个变量同时发生了变化。
我在梳理卖家编码体系时，会把所有在用的 UPC 按来源分成四类，每一类的风险特征完全不同。
第一类是 GS1 官方自购码。企业向 GS1 申请厂商识别代码，前缀归企业独有，理论上不可能和别人撞。这类码的重复只会来自企业内部：同一个码被运营分配给两个 SKU。我在一次内部审计里发现，一家年销八千万的卖家，用同一批码给同一个产品的两个包装规格上架，两年没人发现，直到两个 ASIN 的评价开始互相串。
第二类是品牌方授权分销码。做分销的卖家用的就是这类码，品牌方按渠道或区域分配编码段。风险在于串货：不同代理商把货卖到同一个站点，各自用自己那一段码上架，本来是合规的，但在平台看就是两个 ASIN 卖同一件东西。
第三类是第三方批量转售码。这是重灾区。一包五千个码的价格可以低到几百块，代价是同一包码可能被卖给过好几拨人。我经手过一个案例，卖家买了 3000 个转售码，用在北美站，上架三个月后陆续有 34% 的码出现绑定冲突。
第四类是 GTIN 豁免后的自编码。豁免本身是合规的，但自编码没有全局唯一性约束。品牌方自己定规则，规则只在自己内部有效，撞号时平台不会帮你预警。
从 2021 年开始，主流平台对 GTIN 的校验明显变严：不只看格式，还看校验位、看前缀归属、看是否已经被其他 ASIN 占用、看与品牌名是否匹配。以前能蒙混过去的码，现在会在批量上传时直接报错。
这个变化带来的直接后果是：你在过去三年里”成功”用掉的码，在下一轮批量更新时可能集体失败。很多卖家第一次做重复码排查，不是因为主动想查，而是因为一次常规的库存表更新触发了上百行报错。
单站点运营时，编码表是运营自己维护的 Excel，几十行，肉眼能看。开到第五个站点时，同一批 SKU 要在五套码制之间转换，Excel 变成几千行，人眼彻底失效。
更麻烦的是，不同站点对”同一个商品”的定义不一样。北美站按颜色分 ASIN，欧洲站按尺寸分，日本站按套装组合分。你在做跨站点 GTIN 比对之前，如果不先把”商品粒度”统一，比对出来的重复全是噪音。
这也是为什么我一直建议：跨站点 UPC 排查要作为一次独立的市场调研项目来做，有明确的范围、明确的口径、明确的输出格式，而不是顺手在运营表里加一列公式。我做这类项目时常用的外部数据侧工具是数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys），原因是它能把站点、类目、时间窗这几个设置维度摆在明面上让你选，而不是默认全量拉一遍。
后面第五章我会用一个具体案例完整演示这套设置怎么配。
下面五个误区，我在别人的排查报告里全都见过，其中前三个我自己也踩过。
这是最根本的一条。一个 GTIN 绑定两个 ASIN，可能是重复商品，也可能是变体关系、可能是历史归档、可能是平台侧的合并结果。
我见过运营看到工具报”该 UPC 已被某 ASIN 使用”就直接放弃这个码，重新买码上架。结果新码上架后又被报同一个错，因为真正的问题不是码，是那个商品本身已经被系统判定为已有商品，你的新链接只是触发了平台的匹配逻辑。
判断方法：看到重复告警时先问一句，这两个 ASIN 是同类目吗？如果是，大概率是商品匹配；如果跨类目，才需要怀疑码本身有问题。
很多卖家觉得站点之间是隔离的，其实不是。同一个 GTIN 在北美站和欧洲站的绑定关系，在品牌层面是可以通过全球目录关联起来的。
我在一次排查中发现，某卖家欧洲站上架失败，原因是一个 UPC 在北美站绑定的 ASIN 标题与欧洲站要上架的商品不一致，平台做了跨站点匹配。解决办法不是换码，而是先把两边的商品信息对齐。
所以调研设置里，”站点范围”这一项必须至少包含你实际在售的全部站点。只查一个站点的排查报告，可信度大概只有六成。
GTIN 豁免确实能解决”我没有正规码”的问题，但它解决不了”我的码是重复的”这个问题。豁免之后你用的是自编码，平台仍然会在自己内部做唯一性校验，撞号照样报错。
而且豁免有代价：部分类目不允许豁免，部分广告和促销工具的准入会受影响，部分站点之间的商品关联会变弱。我的建议是把豁免当成过渡方案，用 6 到 12 个月的时间窗口去把正规编码体系搭起来，而不是当成终局。
这个误区最隐蔽，也最容易让人白忙一周。UPC-A 是 12 位，如果你的原始码是 0 开头的，用 Excel 打开 CSV 时会自动变成 11 位数字，或者干脆变成科学计数法 1.23E+11。
导入平台后，系统拿到的是一个格式不完整的 GTIN，校验失败，报错信息里可能带着”无效码”或”已存在”字样。运营看到”已存在”，第一反应就是重复，于是开始漫长的排查。
校验动作很简单：把报错清单里的码全部转成文本格式，补足 12 位，重新算校验位。算不过的就是格式问题，不是重复问题。这段校验逻辑可以写成几行代码固化下来。
def upc_a_check_digit(first_11: str) -> str:
"""UPC-A 校验位：奇数位(1,3,5,7,9,11)加权 3，偶数位加权 1"""
if len(first_11) != 11 or not first_11.isdigit():
raise ValueError("需要 11 位纯数字")
digits = [int(c) for c in first_11]
odd_sum = sum(digits[0::2]) * 3
even_sum = sum(digits[1::2])
return str((10 - (odd_sum + even_sum) % 10) % 10)
def normalize_gtin(raw: str) -> str:
"""归一化：去空格、补前导零到 12 位，去掉 Excel 科学计数法残留"""
s = str(raw).strip().replace(" ", "").replace("-", "")
if "E+" in s.upper():
s = f"{float(s):.0f}"
s = s.zfill(12)
return s
示例
print(normalize_gtin("12345678901")) # -> '012345678901'
print(upc_a_check_digit("01234567890")) # -> 校验位把归一化和校验做成上架前的强制前置步骤，能砍掉大概三分之一的无意义排查工单。这是我自己团队里的硬性规定。
新上架的 ASIN 在 7 到 30 天内，绑定关系还在沉淀，平台有时会先建立临时绑定再调整。如果你把时间窗设成”最近 30 天”，会捞出一堆还没稳定的绑定关系。
反过来，时间窗设太长，比如三年，又会把早已归档的 ASIN 拉进来，制造大量失效冲突。我的经验值是90 到 180 天，具体取决于你的上新频率：月上新超过 200 个 SKU 的，用 90 天；上新平缓的，用 180 天。
下面这张图把重复告警的真实归因拆开看，你会发现前两位加起来占了大半，而它们都不是”码真的重复”。
前面讲的是”不要做什么”，这一章讲”应该怎么做”。这套框架我在不同规模的卖家那里用过，从年销三百万到年销三个亿都适用，区别只是执行工具和数据量级。
在排查之前，先做一次来源盘点。把所有在用 UPC 按前面说的四类来源打标签，同时记录三个字段：前缀归属、校验位是否合法、首次分配时间。
前缀归属可以通过 GS1 的公开前缀查询确认。如果前缀不属于你自己的公司，也不是你签约品牌方的前缀，那这个码就是转售码，风险等级直接拉到最高。校验位不合法的一律单独归为一类，不要和重复混在一起处理。
这一步的产出是一张编码来源台账。没有这张表，后面的所有排查都缺少判断依据。我通常要求台账覆盖率不低于 95%，剩余 5% 标注为”来源不明”，单独走一个处置流程。
这是整篇指南最核心的一步。我把它拆成一张配置表，你可以直接照着填。
| 设置维度 | 推荐配置 | 打开条件 | 误报影响 |
|---|---|---|---|
| 站点范围 | 全部实际在售站点 | 始终打开 | 关闭会导致漏检，跨站点冲突完全看不到 |
| 类目范围 | 本类目 + 相邻类目 | 存在跨类目铺货时扩大到全站 | 全站打开会把不相干的撞号拉进来，误报上升约 40% |
| 时间窗口 | 90 至 180 天 | 上新频率高用 90 天 | 过短误报上升，过长会捞到已归档 ASIN |
| 绑定口径 | 以父体为单位 | 变体商品多时必须以父体为准 | 以子 ASIN 为准会把正常变体判为重复 |
| 品牌口径 | 本品牌 + 授权分销品牌 | 做分销时打开 | 不打开会漏掉代理商串货造成的冲突 |
这张表里，绑定口径是最容易被忽略、但对结果影响最大的一项。我做过对比测试：同一批 1200 个 SKU，以子 ASIN 为口径查出 217 条冲突，以父体为口径只查出 43 条，差出来的 174 条全部是正常变体关系。
不同范围设置在几个关键维度上的表现差异，可以用一张雷达图看得很清楚。
直接把全量 GTIN 丢进去做精确匹配，结果一定又吵又乱。我习惯用三层漏斗，每层输出一个候选集，逐层收窄。
三层走完，1200 行输入一般会收敛到 40 到 60 条需要人工确认的记录，其中真正要换码的通常在 10 条以内。漏斗的价值不在于查得全，而在于让最后人工介入的那几十条都是值得看的。
排查出来之后不要一次性全改。编码变更会触发链接重建、评价清零、广告重启，代价很大。我按风险等级分三级处置。
| 等级 | 判定标准 | 处置方式 | 建议时限 |
|---|---|---|---|
| A 级 | 同一 GTIN 绑定两个不同品牌、不同实物商品 | 立即停售其中一个，申请新编码重建链接 | 24 小时内 |
| B 级 | 同一 GTIN 跨站点指向不同商品，或来源为转售码 | 先对齐商品信息，仍冲突则更换编码 | 7 个工作日内 |
| C 级 | 变体共用、历史归档残留、格式问题 | 修正口径或走解绑流程，不换码 | 30 天内批量处理 |
这个分级的意义在于把有限的人力放在 A 级上。我见过太多团队花两周时间处理 C 级问题，A 级的两条链接一直挂着，最后被平台合并，损失的是真金白银的排名。
前面讲的都是框架。这一章我用一个真实案例，把”市场调研设置”这一层落到具体操作上。案例来自 2024 年下半年我协助梳理的一个家居类目卖家，卖家授权我脱敏后使用数据。
这家卖家年销售额在 4000 万人民币左右，主营家居收纳，在北美、欧洲、日本、澳洲四个站点销售，在售 SKU 约 1200 个。他们的编码体系是历史堆积出来的：2019 年刚起步时买过一批转售码，2021 年申请了 GS1 前缀，2022 年做欧洲站时又用了一批品牌方给的授权码。
触发排查的原因是一次季度库存表更新，批量上传后 217 行报错。运营的判断是”这批码重复了”，准备全部换新码。我介入的时候先拦下了这个决定，因为全量换码意味着 217 条链接全部重建。
我用的外部数据侧工具是数跨境。选它的原因很实际：它把”站点、类目、时间窗、数据维度”这几个设置项放在查询入口，不需要我写 SQL，也不需要导出到本地再二次加工。对做重复码排查来说，能在查询阶段就把范围收窄，比事后再筛要省一半时间。
我的配置过程分四轮，每一轮只改一个变量，观察结果变化。
第一轮，全量粗查。站点全选，类目选全站，时间窗设为 3 年。返回冲突记录 891 条。
第二轮，收敛类目。把类目范围从全站收窄到家居收纳及其相邻三个类目。冲突降到 412 条。这一步砍掉的 479 条，全部是跨类目的编码撞号，与卖家的实际商品无关。
第三轮，调整时间窗。从 3 年改成 180 天。冲突降到 268 条。减少的部分主要是早已归档的 ASIN 残留绑定。
第四轮，切换绑定口径。从子 ASIN 切到父体。冲突直接从 268 条掉到 51 条。这一轮的变化最大，也最能说明问题，绝大部分”重复”其实是正常的变体结构。
时间窗这一项对检出率和误报率的影响，可以单独拉出来看，因为它最容易调错。
把范围收敛到 51 条之后，逐条人工确认，最终结论是这样的。
另外一个值得记录的发现是重复问题的类目分布极度不均。51 条里有 33 条集中在收纳箱和置物架两个子类目，占比 64.7%。这两个子类目恰好是这家卖家 SKU 最密集的地方，SKU 数量占比只有 28%，重复问题占比却是 64.7%。
这意味着排查资源不应该平均分配，而应该按 SKU 密度加权。SKU 越密集的子类目，内部编码分配出错、变体结构混乱的概率越高。下一次排查，我会直接把类目范围优先锁定在这两个子类目上。
说清楚我为什么在排查流程里引入这类工具，以及它做不到什么。
它能做的是：把站点、类目、时间窗这些范围设置变成可视化选项，让你在查询阶段就完成范围收敛；提供跨站点的商品维度数据，便于做品牌、型号、标题层面的比对；输出结果可以直接进人工复核环节，不需要在 Excel 里再做一轮清洗。
它做不到的是：判断哪些重复是业务合规的变体关系；替你做 A/B/C 分级；确认编码的合法来源。这些必须靠业务判断，工具只能把候选集缩小到你判断得过来的规模。
我在这个案例上的实际感受是：工具的价值主要体现在把 891 条噪音压到 51 条的过程中，而不是在最后那 51 条的判断上。如果你的排查结果一直停在几百条的量级，问题不在工具，在范围设置。
框架讲完了，案例讲完了。这一章按场景给可直接执行的建议，你可以对号入座。
上架前的排查成本最低，收益最高。我的建议是做三件事。
上架前的排查做到位，后续所有环节的成本都会下降。我服务过的卖家里，坚持做上架前校验的，季度批量上传的报错率平均只有没做校验的六分之一。
报错当天的第一件事不是排查，是分类。把报错清单按错误代码分组，格式类、重复类、匹配类分开。这一步做完你会发现，能靠改格式解决的往往占一半以上。
第二件事是把重复类的那部分先做格式归一化，再重新提交一次。很多人卡在这一步，是因为直接把原始报错清单当成结论，没有做二次提交验证。
第三件事才是真正的重复排查，用第三章的四步框架走一遍。整个流程如果顺利，当天能出结论；如果需要跨站点核对，安排三到五个工作日。
这类店铺的问题不是”有没有重复”，而是”根本不知道自己有什么”。我的建议是分两阶段。
阶段一，盘点优先于排查。先把所有在用码的来源标签建起来，覆盖率做到 90% 以上再开始排查。这一步大概需要一到两周，取决于 SKU 数量。
阶段二，分批清洗。按类目分批，先从 SKU 最密集的两个子类目开始，因为重复问题大概率集中在那里。每批处理完出一份结论文档，避免重复劳动。
来源不明的码，我的处理原则是存量不动，增量不用：已经在售的链接不轻易换码，但新上架的商品一律不再使用来源不明的码。这样既避免了大面积重建链接的风险，又切断了问题继续扩大的路径。
扩张期最大的风险是商品粒度不统一。上架之前先定义清楚：同一个商品在四个站点分别按什么维度拆 ASIN，拆完之后编码怎么对应。这份映射表要在上架前完成，不是上架后补。
我的做法是建立一张”商品粒度映射表”，行是实物商品，列是各站点，单元格填 ASIN 拆分维度和对应的编码段。这张表维护好了，跨站点重复排查就变成了简单的行内比对。
这种情况下的重复告警往往是结果而不是原因。链接被合并说明平台已经判定两个 ASIN 是同一商品，此时换码通常无效，应该走申诉或品牌备案路径解决。
我的建议是先确认合并的触发点：是编码相同，还是标题主图高度相似，还是品牌归属相同。三种触发点对应三套完全不同的处理方式。在原因没确认之前换码，等于在伤口上贴创可贴同时继续流血。
不同场景下的处理投入差异很大，用一张图对比会更直观。
所有建议都有代价。这一章讲清楚在什么情况下应该放弃什么。
自购码的成本是明确的：GS1 的年费加上首次申请费，按企业规模从几千到几万元不等，套下来单个码的成本远高于转售码。转售码便宜，一个码可能只要几毛钱。
但转售码的隐性成本是排查工时。我在第五章那个案例里算过一笔账：3000 个转售码里 34% 出现冲突，处理这 1000 多条冲突记录，前后投入了大约 25 人天。按人力成本折算，早就超过了自购码的费用差额。
我的判断标准很简单：如果你计划在同一个类目做三年以上，自购码；如果只是短周期测款，转售码可以用，但必须接受它带来的排查负担。中间地带，也就是长期经营却用转售码，是最不划算的组合。
豁免的好处是快：提交品牌和商品资料，通过后即可上架，不需要申请厂商识别代码的等待周期。代价是后续的商品关联能力弱、部分工具权限受限、跨站点扩张时需要重新申请。
我的建议是看你的商品结构。单品爆款、SKU 数量少、短期打法，豁免是合理的；SKU 数量超过 200 个、有跨站点规划、要走品牌化路线，一定要走正规 GTIN。
我见过的最差组合是：用豁免上架了两千多个 SKU，两年后想开新站点，发现所有商品都要重新申请编码。这时候的迁移成本是当初直接申请的好几倍。
精度不是免费的。前面那张折线图已经说明，把误报率从 21% 压到 12% 需要把时间窗和类目范围都放开，人工复核耗时从 6 小时涨到 20 小时以上。
我的取舍原则是分场景：A 级问题相关的排查，精度优先，宁可多花时间；C 级问题的批量清洗，效率优先，接受一定的漏检，靠后续的定期复查来兜底。
把这个原则落成配置就是：做新品上架校验时用全站点宽口径，做存量清洗时用单站点窄口径分批走。
一次性清洗听起来很痛快，但对大多数卖家不现实。两千个 SKU 的全量清洗，按第五章的节奏需要两到三个月，期间运营的正常工作会被挤占。
我更推荐的是分批清洗加持续监控：先把 A 级问题在今天之内处理掉，然后按月对新增 SKU 做上架前校验，按季度对存量做一次范围收敛的复查。
持续监控的关键是把范围配置模板固化下来，每次复查直接套用。这样单次复查的耗时可以控制在两个小时以内，而不是每次都从头摸索。
第一，重复码排查本质上是范围定义问题，不是编码技术问题。你定义的市场调研范围决定了你能看到什么，也决定了你会不会被噪音淹没。范围定义是业务决策，把它交给技术去猜，结果一定跑偏。
第二，绑定口径的切换是性价比最高的一次设置调整。从子 ASIN 切到父体，在本案例中直接让冲突量下降 80.2%，耗时增加却不到一小时。所有排查都应该从这一步开始试。
第三，编码来源的合法性决定了你的排查上限。转售码构成的编码池，无论你怎么排查都清不干净，因为源头还在被别人使用。这类问题的解不是排查，是换池子。
如果你现在手上就有一份报错清单，按这个顺序走。
这套流程我自己跑过很多次，正常情况下三天能出第一版可用结论。如果你的 SKU 数量超过三千，把第三步的类目范围再收窄一层，分批推进。
最后一句提醒：不要在原因确认之前批量换码。每一次换码都是一次链接重建，代价远超你的直觉。先把范围定清楚，让问题自己浮出来，再动手。
我做跨境 listing 时，经常遇到同一个 UPC 被多个 SKU 共用，但老板只说先查重。我一开始只按 ASIN 查，结果漏掉不同站点、不同国家渠道的重复。后来才意识到市场调研设置没定清楚，查重口径就乱。
先锁定五个维度：目标市场或站点，例如 US、CA、UK、DE 等；销售渠道，例如平台自营、第三方、独立站；GTIN 类型，例如 UPC-A、EAN-13、GTIN-14、ISBN 等；产品层级，例如单个销售单元、组合装、多件装、箱规；变体关系，例如颜色、尺码、容量、口味等。
判断依据是 UPC 的唯一性通常按可单独销售单元加目标市场加渠道成立，不是按内部 SKU 成立。
做法是在市场调研表里建字段：marketplace、country、channel、gtin_type、gtin_value、selling_unit、parent_child、variant_axis、supplier、brand_owner、effective_date。
先填全这些字段，再做去重，否则同一个码在 US 和 EU 可能被误判为重复，或者不同包装层级被误判为冲突。
我之前查重时，把父子变体、组合装、箱规都算成重复，结果删掉了很多其实没问题的码。运营又问我为什么变体 listing 建不起来，我才发现查重规则和市场调研设置没对齐。
判断真重复看三个条件：是否同一目标市场、是否同一销售单元、是否同一渠道且没有授权例外。父子变体通常共享父体关系但不共享子体 UPC；每个可单独购买的变体应有自己的 UPC。组合装、多件装、箱规如果作为独立销售单元，需要独立 UPC；如果只是内部物流包装，不对外销售，则不要占用销售 UPC。
可复用场景包括：同一产品在不同国家因 GS1 前缀或平台要求不同，通常应分配当地或合规码；同一产品在独立站与平台渠道，若平台允许且不冲突，可用同一 GTIN，但要在市场调研表里标记渠道授权。
做法是在调研表加复用类型字段，选项为独立销售单元、父子变体、组合装、箱规、渠道专用、市场专用，然后按市场加渠道加销售单元分组查重，不按内部 SKU 分组。
我做过美国站和欧洲站，发现同一个 UPC 在美国站能过，到欧洲站就提示无效或冲突。当时我以为码错了，后来才知道 GS1 前缀、EAN 与 UPC 转换、平台校验规则都会影响。市场调研如果只记一个 UPC 字段，根本不够。
至少记录六类规则字段：国家或地区、GS1 前缀归属、可接受的 GTIN 长度与类型、平台是否强制品牌备案或 GTIN 豁免、平台是否允许同一 GTIN 多卖家跟卖、平台对变体和组合装的 GTIN 要求。判断依据是 UPC-A 是 12 位，EAN-13 是 13 位，GTIN-14 常用于箱规；
美国常用 UPC-A，欧洲更常见 EAN-13，但平台可能要求转换或补零。做法是在市场调研表中为每个目标市场建一行规则，填允许 GTIN 类型、长度、是否需 GS1 证书、是否允许豁免、重复码判定范围，例如同站点、同店铺或全网。
排查时先按市场规则过滤，再用 GTIN 标准化后比对：UPC-A 前补 0 变 13 位，EAN-13 去掉校验位或统一转 GTIN-14 做比对。这样能避免把格式差异误判为重复。
我刚开始查重就是 Excel 里条件格式标重复，但数据一多就乱：前后空格、前导零丢失、大小写混用、多站点混在一起。后来发现必须先把市场调研设置变成结构化字段，再做标准化和分组查重，不然结果没法给运营和采购用。
执行分五步。第一，统一数据源：从市场调研表、产品主数据、供应商表、平台后台导出 GTIN 相关字段，保留原始值和清洗值两列。第二，标准化：去除空格和不可见字符，UPC-A 统一补前导零到 13 位或转 GTIN-14，数字字段设为文本避免科学计数法。
第三，分组：按目标市场、销售渠道、销售单元、变体关系分组，不要跨市场直接查重。第四，查重与标记：用 COUNTIFS 或数据库 GROUP BY 统计标准化 GTIN 加市场加渠道加销售单元出现次数，大于 1 标记为疑似重复；再人工判断是否属于变体、组合装、箱规或渠道授权。
第五，输出：重复码清单、冲突原因、建议动作，例如保留、替换、申请豁免、拆分变体、补 GS1 码，以及责任人和截止时间。数据口径建议：重复率等于疑似重复 GTIN 数除以有效 GTIN 总数；冲突解决率等于已处理重复码除以疑似重复码。这样排查结果能直接用于 listing 修复和采购补码。
读者评论
%降到4.2%这个数字挺震撼，但我做家居类目时误报率没那么夸张，大概一半左右。感觉跟类目和铺货模式关系很大，铺货型卖家确实容易踩。单站点精品卖家直接套这个结论，可能会低估真实重复的比例，得按自己的数据重新算一遍基线。
前导零那段太真实了，我们去年因为CSV导入丢零白排查了四天。但补充一点：补足12位、校验位算过之后，平台照样可能报“已存在”，这时候基本是商品匹配逻辑而不是码本身的问题，跟文里第三节讲的对得上。所以校验位只能筛格式类，剩下的还是得分类看。
跨站点比对这块我持保留态度。四个维度定清楚理论上就万事大吉，但实际执行时商品粒度的定义权不在一个人手里，北美运营和欧洲运营对“同一个商品”的判断本来就不一样，范围很难真正统一。这套模板小团队能跑通，多站点大团队可能得先把主数据归属定下来。