2023年下半年，我帮一个做家居品类的卖家做账号体检。他有14个亚马逊店铺、3个品牌备案主体、在售SKU大约1170个。见面第一句话他跟我说：“UPC这块我早就全部豁免了，最省心。”三周之后，他6个店铺的新品被批量下架，原因不是侵权，也不是绩效指标，而是平台判定存在“重复商品创建”和“GTIN使用异常”。他反复强调的那句“我已经豁免了”，恰恰是问题的起点，他把豁免理解成了“不用管编码”，而平台理解的是“你必须用另一种方式证明这个商品是唯一的”。

这篇文章想解决的问题很具体：在UPC码方案设计里，当你要走豁免申请这条路，同时又要管理几十甚至上百个店铺时，编码体系到底该怎么搭。我会先给结论，再把我实际踩过的坑、见过的失败样本、以及目前在用的三层映射模型完整拆开讲。

一、先给结论：豁免不是“免码”，而是把验证责任转移给了你

如果你只记住一句话，我希望是这句：GTIN豁免不是取消了商品唯一性要求，而是把唯一性的举证责任从GS1数据库转移到了你自己的台账上。这一点想不清楚，后面所有的操作都是碰运气。

1. 豁免的真实机制：码没了，唯一性还在

平台允许你在上传商品时不填UPC/EAN这类GTIN编码，但平台必须有一个东西来区分“A商品”和“B商品”。这个替代物通常是品牌名加商品名的组合标识。也就是说，编码字段空了，但平台在后台仍然为这个商品生成了一个唯一键。

这个唯一键的生成逻辑决定了三件事。第一，品牌名必须是稳定的，你今天叫A品牌明天改成B品牌，唯一键就会变，历史listing和库存会对不上。第二，商品名必须是有区分度的，如果你的商品名都是“Storage Box Large”这种通用词，多个店铺之间极易撞车。第三，这个唯一键是跨店铺全局比对的，不是店铺内部比对的。

很多人以为豁免是“店铺级别”的权限，实际上是“品牌+商品”级别的比对。这就是店群场景下所有麻烦的根源。

2. 店群管理真正要维护的是三张表

我在2022年之后接手的所有店群编码项目，最后都收敛到三张表上。不是因为我喜欢做表，而是因为出问题的环节永远落在这三张表里。

• 商品身份表：记录这个物理商品是谁，厂商、型号、规格、颜色、尺寸、包装数量。这是商品在现实世界里的唯一身份。
• 编码映射表：记录这个商品在各平台各店铺用的是哪种编码，GS1官方UPC、第三方购买UPC、还是豁免标识。同一商品在不同店铺可能用不同编码，这张表负责记住。
• 店铺主体表：记录每个店铺背后的营业执照、品牌授权关系、收款主体、注册邮箱。豁免申请和品牌备案都挂在这一层。

三张表之间必须能互相查。我给你一个判断标准：如果我问你“这个SKU在几个店铺上架过、分别用了什么编码、属于哪个品牌授权”，你需要在30秒内答出来。答不出来，你的UPC方案就是不合格的。

3. 为什么店群比单店难十倍

单店铺的编码管理是线性的：一个商品，一个编码，一个店铺。出错概率低，出错后影响面小。

店群是组合爆炸的。5个店铺、3个品牌、200个SKU，理论上存在3000种“商品-店铺-品牌”的组合关系。每一种组合都有自己的编码状态。而豁免申请是按品牌和类目走的，一旦某个品牌下的豁免被撤销，挂在这个品牌下的所有店铺listing都会受影响。

这就是为什么我一直不建议店群卖家把豁免当作“省事方案”。它省的是买码的钱和填码的时间，增加的是台账维护成本和系统性风险。

二、背景与真实场景：豁免申请在店群模式下为什么会失控

要讲清楚这个问题，得先把豁免申请的规则边界说清楚。我见过太多卖家把豁免当成一个“开关”，点了就完事，实际上它是一个持续性的合规状态。

1. GTIN豁免的规则边界

平台提供GTIN豁免的初衷，是给那些确实没有GTIN的商品（比如手工艺品、定制商品、自有品牌小批量商品）一条上架通道。它不是为了让卖家规避买码成本。

豁免申请通常需要提供品牌名称、商品类目、以及品牌归属证明。部分类目支持豁免，部分不支持。豁免通过后，上传商品时编码字段会以豁免标识呈现，平台用品牌加商品信息生成内部唯一键。

这里有三个容易被忽略的边界。

边界一：豁免是按品牌加类目粒度授予的，不是账号级别的通用权限。你在这个类目拿到豁免，不代表另一个类目也能用。新开一个类目做新品，可能要重新申请。

边界二：豁免状态是可被撤销的。平台在例行审核中如果发现商品信息与豁免申请信息不符，或者发现同一品牌下存在大量高度相似的商品，豁免可能被收回，已上架的listing会进入审核。

边界三：豁免不能解决跨店铺的唯一性冲突。两个店铺卖同一个物理商品，即使用同一个品牌申请了豁免，平台依然可能判定为重复商品创建。豁免解决的是“没有编码怎么上架”，不解决“多个店铺能不能卖同一个东西”。

2. 店群的三重复杂性：主体、品牌、产品线

我把店群的复杂性拆成三个维度，你可以对照自己的情况看看中了几条。

• 主体维度：多个店铺是否共用同一营业执照？是否有亲属或员工身份注册的店铺？收款账号是否交叉？这一层主要影响账号关联风险，但会间接影响豁免审核，因为平台会核验品牌备案主体与店铺主体的关系。
• 品牌维度：你是“一品牌多店”还是“多品牌多店”？前者是重复商品创建的高发区，后者是豁免申请工作量最大、管理成本最高的场景。
• 产品线维度：同一个商品是否有变体（颜色、尺寸、套装数量）？变体是编码管理里最容易出错的地方，因为变体之间既要有区分，又要保持父子关系正确。

我做过一个粗略统计：在“一品牌多店+多产品线变体”这个组合下，UPC相关问题的发生率大约是中位数场景的3倍以上。这不是平台刁难，而是这个结构的唯一性冲突概率天然更高。

3. 一次完整的翻车复盘

回到开头那个家居卖家。他的结构是“3个品牌、14个店铺、1170个SKU”。问题出在三个环节的叠加。

第一，他用品牌A在4个店铺申请了豁免，然后把这4个店铺当“同一盘货”来铺。同一个物理商品，在4个店铺创建了4条listing，标题只有细微差异。平台的重复商品检测在3周后触发。

第二，他的编码映射表根本不存在。团队里没人能说清楚某个SKU到底在哪些店铺用了什么编码。出了问题只能一个个店铺翻后台。

第三，他没有区分“豁免商品”和“买码商品”。早期买的UPC和后来的豁免商品混在同一个SKU表里，字段只有一个“编码”，没有来源标识。等到要排查哪些商品是豁免状态时，完全无法筛选。

最后的结果是6个店铺的约180条listing被下架，申诉周期平均19天，错过了整个旺季备货窗口。直接损失我不好估，但他自己算的是六位数。

这场事故的核心不是豁免用错了，而是豁免之后没有建立与之匹配的管理结构。豁免降低了上架门槛，同时抬高了台账管理门槛。门槛不会消失，只会转移。

三、拆解常见误区：五个把店群送进风控的想当然

下面这五条，是我在咨询过程中听到频率最高、也最容易造成实际损失的错误认知。每一条我都会说清楚“为什么这么想是合理的”以及“为什么它仍然会出事”。

1. 误区一：豁免通过了就等于永久有效

合理之处在于，豁免通过后确实能立即上架，体验上像是拿到了一个永久通行证。问题在于豁免是一个可被复核的状态。

平台的审核逻辑是“先信任，后抽查”。当你的商品量、店铺量、投诉量上来之后，被抽查的概率会显著上升。抽查时看的不是你有没有豁免标识，而是你的商品信息是否与豁免申请时的描述一致。

我见过最典型的情况是：申请豁免时填的品牌名是“ABC Home”，后来运营为了SEO把品牌名改成“ABC Home Official”，listing上的品牌字段也跟着改了。系统比对不上，豁免直接失效。

豁免通过之后，品牌字段、商品核心属性、类目这三个东西就应该被冻结，任何改动都要走变更流程。

2. 误区二：同一套UPC可以跨店铺复用

这是最危险的一条，也是造成损失最大的一条。

有些卖家觉得，UPC只是一个商品编号，同一商品在不同店铺用同一个编号，天经地义。从物理世界看确实如此，但在平台规则里，一个GTIN对应一个商品创建记录。同一个GTIN在多个店铺出现，平台的第一反应是“这可能是同一个商品被重复创建”，或者是“这个码被滥用了”。

后果分两种。轻的是后上架的listing被压制或被要求提供授权证明。重的是两个店铺的listing同时进入审核，甚至触发账号层面的关联调查。

如果你确实要在多个店铺卖同一个物理商品，正确的做法是每个店铺使用独立的、来源合法的编码，或者使用品牌授权的方式让平台明确知道这两个店铺的关系。而不是共用一个码，指望平台看不出来。

3. 误区三：豁免申请信息随便填，反正是自己用

豁免申请表单看起来很简单，很多人几分钟就填完了。但这份表单实际上是后续审核的唯一依据。

我建议把豁免申请当成一份“具有法律意义的声明”来对待。品牌名称要与商标注册信息完全一致，商品描述要能准确对应到实际售卖的商品，类目选择要与实际发布类目一致。

一旦后期运营为了优化listing去改动这些字段，就会形成“申请信息”和“实际信息”的偏差。偏差达到一定程度，豁免就危险了。

4. 误区四：有豁免就不用建内部编码体系

这是认知层面最根本的误区。豁免去掉的是“外部编码”，不是“内部编码”。

你自己内部必须有唯一标识，否则你连自己有多少个商品都数不清。我见过的极端案例是，一个卖家认为自己的SKU数量是800，实际去重后只有610，中间190个是重复登记。这190个重复登记在店铺层面就变成了重复上架。

内部编码体系（内部SKU）和外部编码体系（UPC或豁免标识）是两套东西，不能互相替代。内部SKU负责你自己认得出，外部编码负责平台认得出。豁免场景下，外部编码变弱了，内部编码的重要性反而更高。

5. 误区五：豁免额度可以无限申请

豁免申请虽然不像买码那样有明确单价，但它有隐形额度，你的品牌可信度和历史合规记录。

一个新品牌短期内提交大量豁免申请，或者频繁修改申请信息后重新提交，都会消耗这个额度。表现是审核时间变长、要求补充材料的概率上升，严重时直接驳回。

我的建议是：豁免申请要有节奏，按产品线分批推进，每批之间留出足够的销售数据沉淀期。一个品牌先跑通20到30个SKU，有了稳定的销售和评价记录，再申请下一批，通过率会明显好于一次性提交几百个。

四、专业判断逻辑：UPC方案的“三层身份映射”模型

讲完误区，说方法论。我目前给店群卖家做编码方案设计时，用的是“三层身份映射”模型。它不是理论框架，是一套能在Excel或者管理系统里落地的字段结构。

1. 第一层：产品实体身份

这一层回答的是“这个东西到底是什么”。字段包括：内部SKU、厂商、型号、规格参数、颜色、尺寸、包装数量、生产批次。

核心原则是：一个物理上不可区分的商品，只能有一个实体身份编号。什么叫物理上不可区分？同一工厂、同一型号、同一颜色、同一尺寸、同一包装数量。只要有一项不同，就是不同的实体身份。

这一层最容易犯的错是“按店铺建身份”。A店铺建一个SKU叫ABC-001，B店铺建一个SKU叫XYZ-001，实际上是同一个商品。这就是重复登记的源头。

2. 第二层：平台编码身份

这一层回答的是“这个商品在平台上用什么标识”。字段包括：编码类型（GS1官方UPC、授权转售UPC、豁免标识）、编码值、申请时间、生效店铺范围、状态。

关键点在于，一个实体身份可以对应多个平台编码身份，但每个平台编码身份必须绑定到具体的店铺范围。不能出现“一个UPC对应全部店铺”这种记录。

豁免标识也要当作一种编码类型来登记，记录它的有效期、覆盖品牌、覆盖类目、以及关联的店铺。很多人的台账里豁免是一个备注字段，这远远不够。

3. 第三层：店铺主体身份

这一层回答的是“谁在卖”。字段包括：店铺名称、店铺ID、经营主体、营业执照编号、品牌授权链、收款账号标识。

这一层的价值在于排查关联和验证豁免资格。当你申请豁免时，平台会关注品牌备案主体和店铺主体之间的关系。如果两者不一致，需要有授权链条来补足。

我建议把品牌授权链单独做一列，记录“品牌方 → 一级授权 → 二级授权 → 店铺”这个路径。当豁免审核要求补充材料时，你能直接调出这条链。

4. 三层之间的校验规则

光有三张表不够，还要有校验规则。以下是我实际在用的几条，你可以直接参考。

1. 实体唯一性校验：同一个实体身份编号，不允许在两个店铺以“新品创建”的方式重复上架，除非走品牌授权通道。
2. 编码唯一性校验：同一个UPC值，不允许出现在两条以上的平台编码记录里。
3. 品牌一致性校验：豁免记录里的品牌名，必须与品牌备案记录、以及listing实际品牌字段三者一致。
4. 主体可追溯校验：每条平台编码记录，必须能追溯到具体的店铺主体和授权链。
5. 状态同步校验：豁免状态变更（通过、失效、撤销）必须在台账中同步，并触发关联listing的复查。

这五条校验如果能自动化执行，你在上架前就能拦截掉大部分风险。如果只能手工做，至少每周跑一次全量比对。

# 编码映射台账的推荐字段结构（YAML示例）
entity:

internal_sku: HOME-BOX-L-WHITE-2PK

manufacturer: "某家居用品厂"

model: "HB-L-2"

attributes:

color: white

size: L

pack_qty: 2

platform_codes:

type: gtIN_exemption # 豁免标识

value: "BRAND_A::HOME-BOX-L-WHITE-2PK"

brand: "BrandA"

category: "Home & Kitchen"

status: active

effective_shops: ["shop_us_01", "shop_us_02"]

applied_at: "2024-03-11"

type: gs1_upc

value: "0198765432105"

source: "GS1 US"

status: active

effective_shops: ["shop_us_03"]

applied_at: "2024-03-18"

shop_entities:

shop_id: shop_us_01

legal_entity: "深圳某贸易有限公司"

license_no: "9144**"

brand_authorization:

brand: "BrandA"

level: 1

valid_until: "2026-12-31"

这份结构的核心思想是：把“商品是谁”和“在哪个店卖”和“用什么码”三件事彻底分开，再用关联字段连起来。只要这个结构在，不管平台规则怎么变，你都能快速定位受影响的范围。

五、具体案例与数据观察：用系统化管理替代表格堆叠

讲完模型，说落地。三层映射模型用Excel也能做，但当店铺数和SKU数上来之后，Excel的维护成本和出错率会快速上升。我自己的经验是，超过5个店铺或者超过500个SKU，就应该考虑用系统承载。

1. 样本说明与数据口径

先说明数据来源。以下数据来自我2023年1月至2024年6月期间接触的37个跨境电商卖家样本，以亚马逊为主，少量涉及其他平台。样本筛选标准是“店铺数≥3且SKU数≥200”。这不是行业普查数据，样本量也不足以代表整个市场，它反映的是我接触到的问题分布。

37个样本中，有完整UPC或豁免台账的只有9个，占比24%。出现过UPC相关listing下架、驳回或审核的22个，占比59%。其中问题归因分布是：同品牌跨店铺重复创建11个，豁免信息与listing不一致8个，编码来源不可追溯3个。

我还观察到一个规律：问题发生率与店铺数呈非线性关系。3到5个店铺时，问题发生率约31%；6到10个店铺时升到52%；超过10个店铺时达到78%。原因不是平台对店群有针对性，而是组合数量增长带来的管理复杂度增长。

2. 用数跨境承载编码映射台账的实操路径

2023年底开始，我把一部分店群客户的编码台账从Excel迁到了数跨境上。选择它的原因很实际：这类多店铺管理工具天生就要维护“店铺-商品-编码”的对应关系，我需要的三层映射正好可以挂在这个结构上，不用再从零搭一套系统。

具体路径分四步。

第一步，把商品实体身份作为主数据导入。在系统里建立统一的商品主档，用内部SKU作为主键。这一步的关键是先去重，把跨店铺重复登记的商品合并成一个实体，再分配新的内部SKU。我一般会先导出全部店铺的商品清单，按厂商型号加规格做一次去重，通常能压掉15%到25%的冗余。

第二步，建立编码字段并区分来源。在商品主档上挂两类编码字段：一类是UPC/EAN，一类是豁免标识。每条编码记录都要标注来源、生效店铺范围、状态和生效日期。这一步做完，你就能按“编码类型”筛选出所有豁免商品，排查效率比翻后台高一个量级。

第三步，绑定店铺主体和授权关系。把每个店铺对应到具体经营主体，再把品牌授权链挂上去。这样当某个品牌需要重新申请豁免时，你能立刻知道涉及哪些店铺、哪些SKU、哪些营业执照。

第四步，建立变更触发机制。当豁免状态变更、编码被替换、或者店铺新增时，系统应该触发一次范围提醒。我在实操里会要求运营在改动品牌字段或类目前，先在系统里发起变更登记。这一步是流程约束，看起来麻烦，但它能挡住后面大部分审核问题。

3. 迁移前后的一组对比数据

我记录了6个从Excel迁到系统化管理的客户在迁移前后各3个月的数据。这6个客户的店铺数在6到18之间，SKU数在400到1500之间。数据是客户自己提供的运营日志汇总，属于样本推演性质，不是平台官方统计。

这组数据里我最看重的不是“耗时下降”，而是“单次编码事故平均影响SKU数”从46降到11。它说明问题不是不出，而是出问题的时候你能快速圈定范围，把影响控制住。店群管理里，可控性比零事故更现实。

六、不同情况下的行动建议

方法论讲完，接下来是分场景的行动建议。我按店群结构分五类，每类给出具体动作。你可以直接对号入座。

1. 单店单品牌：先解决编码来源，不要急着豁免

如果你的店铺数只有1到2个，品牌也只有1个，我的建议是不要一上来就申请豁免。

理由很简单：这个规模下，买GS1官方UPC的成本是可控的，而官方UPC能带来两个好处。一是编码在全球GS1数据库可查，平台无法质疑来源。二是未来如果要拓展到其他平台或线下渠道，编码是通用的，不用重新折腾。

具体动作：到GS1官方或授权渠道购买公司前缀，自行分配UPC。数量按未来12个月预计上新的1.5倍准备。同时建立一份基础台账，记录UPC与内部SKU的对应关系。

2. 同品牌多店：核心是解决重复创建

这是风险最高的一类结构。核心矛盾在于：同一品牌、同一商品、多个店铺，平台容易判定重复创建。

我的建议是采取“主店铺+差异化”策略。

1. 指定一个主店铺作为该商品的首发店铺，其他店铺上架时间与主店铺错开至少14天。
2. 不同店铺的listing在主图、标题结构、卖点排序、套装组合上做实质差异化，不是改几个词。
3. 如果商品完全相同且无法差异化，改用品牌授权方式，明确让平台知道店铺之间的授权关系，而不是靠编码隐藏。
4. 每个店铺使用独立的编码或独立的豁免记录，禁止共用同一个UPC值。

3. 多品牌多店：核心是授权链和豁免节奏

这类结构的难点在于豁免申请工作量大，且品牌授权关系复杂。

我的建议是分层推进。先把品牌按“自有品牌”和“授权品牌”分开。自有品牌的豁免可以主动申请，节奏控制在每批20到30个SKU，间隔至少30天。授权品牌则要先确认授权链完整，再申请豁免，否则容易在审核环节卡住。

具体动作：为每个品牌建立独立的豁免档案，记录申请时间、覆盖类目、覆盖店铺、当前状态、下次复核时间。这份档案每季度更新一次。

4. 无品牌铺货型：优先解决编码来源

这类卖家通常没有品牌备案，走的是铺货路线。这一类最突出的问题是编码来源不可追溯。

我的建议很直接：停止使用来源不明的第三方UPC码池。这类码池的典型风险是一个码被卖给多个买家，或者码根本不在GS1数据库里。一旦被平台核验，影响的是整个店铺。

替代方案有两个。一是转向有品牌备案的自有品牌路线，走豁免或官方编码。二是如果坚持铺货，至少使用可追溯的授权转售渠道，并保留购买凭证。

5. 已有大量历史UPC：先做全量审计，再决定迁移

如果你已经在多个店铺用了大量UPC，不要急着全部替换。替换编码本身会触发listing变更，风险不小。

我的建议是分三步走。

1. 全量审计：导出所有店铺的编码数据，做一次重复值检测，找出同一个UPC被用在多个商品或多个店铺的情况。
2. 风险分级：把重复使用的编码按销量和店铺权重分级。高销量高权重的listing优先处理，低销量的可以观察。
3. 渐进替换：对高风险记录，通过新店铺新品上架的方式逐步替换，避免直接在原listing上改编码。

七、不同情况下的取舍

前面讲的是“怎么做”，这一节讲“怎么选”。编码方案没有绝对最优，只有匹配当前阶段的取舍。我把常见的四组取舍列出来。

1. 买码 vs 申请豁免：成本与风险的结构差异

很多人只比较“买码要花钱、豁免不花钱”，这是不完整的比较。我把三条路径的成本结构拆开看。

我的判断逻辑是这样的：如果你的商品生命周期超过18个月，或者要跨平台经营，官方编码的综合成本更低。如果商品是短周期测试型，且你有能力维护豁免台账，豁免更划算。第三方转售码在任何情况下都不是长期方案。

2. 集中管理 vs 各店自治

集中管理的优点是数据统一、排查快、变更可控。缺点是流程变长，运营的灵活性下降。各店自治的优缺点正好相反。

我的经验分界线在店铺数5个。5个店铺以内，各店自治加一份通用台账是可行的。超过5个，尤其是跨品牌之后，集中管理的收益会明显超过流程成本。

一个折中做法是：编码和品牌字段集中管理，listing内容和定价各店自治。这样既保证了合规层面的统一，又不牺牲运营层面的灵活。

3. 合规寿命 vs 短期周转

这是一个更底层的取舍。合规做得越扎实，短期周转速度越慢，因为你要花时间做去重、做授权链、做台账。但合规寿命越长，账号和listing的稳定性越高。

我的建议是分阶段。启动期可以容忍一定的不规范，快速跑通模型。一旦某个商品或某个店铺被验证有销量，立刻补齐合规动作，把它纳入规范管理。

最忌讳的是“永远处在启动期”，所有商品都在裸奔状态，等到平台审核的时候一起出事。

4. 一套表格 vs 一套系统

这是投入决策。表格的启动成本几乎为零，但维护成本随规模非线性上升。系统的启动成本高，但边际维护成本低。

我给客户的建议是：先用表格把三层映射的字段结构和校验规则跑通，验证逻辑正确之后，再迁移到系统。反过来做，先上系统再想逻辑，通常会把错误的结构固化下来，后面改起来更痛苦。

迁移的时机判断标准是：当你每个月在编码核对上花的时间超过15小时，或者问题排查需要超过1天，就该考虑迁移了。

八、可落地的执行清单

最后给你一份可以直接照着做的清单。我把它分成“本周做”“本月做”“本季度做”三档，按优先级排列。

1. 本周可以完成的动作

1. 导出所有店铺的在售商品清单，字段至少包含：店铺、内部SKU、商品名称、品牌、UPC或豁免标识、类目。
2. 对UPC字段做一次重复值检测，标出所有被使用两次以上的编码值。
3. 对内部SKU做一次去重，按厂商型号加规格比对，标出跨店铺重复登记的商品。
4. 列出所有正在使用豁免标识的商品，核对品牌字段是否与豁免申请时一致。

2. 本月可以完成的动作

1. 建立三层映射的字段结构，把本周的检测结果填入。
2. 为每个品牌建立独立的豁免档案，记录申请时间、覆盖类目、覆盖店铺、当前状态。
3. 梳理品牌授权链，对授权品牌补齐授权文件，确保授权路径可追溯。
4. 对高风险重复编码记录制定替换计划，按销量和店铺权重排序。

3. 本季度可以完成的动作

1. 把三层映射台账迁移到系统承载，优先承载编码字段和豁免状态。
2. 建立上架前的编码校验流程，把校验作为新品上架的必经环节。
3. 建立豁免状态的定期复核机制，建议每季度一次。
4. 根据实际使用情况，重新评估买码与豁免的比例结构。

4. 三条不要做的事

• 不要把同一个UPC用在两个店铺的同一个商品上。这是最高频、损失最大的错误。
• 不要在豁免通过后随意改动品牌字段和类目。任何改动都可能让豁免失效。
• 不要用来源不明的第三方码池补充编码缺口。短期省下的成本远低于一次账号事故的代价。

回到最开始那个卖家。他后来花了大约两个月，把14个店铺的商品重新做了一次去重，把1170个SKU压缩到940个真实实体，重新整理了3个品牌的豁免档案，并把编码台账迁到了系统上。他跟我说的一句话，我记到现在：“以前我以为豁免是把UPC这件事删掉了，现在才发现是把UPC这件事换成了另外一件更麻烦的事。”

这个认知转变，就是UPC码方案设计在豁免申请场景下的全部关键。豁免不是一个动作，是一种需要长期维护的状态。而在店群结构下，维护这种状态的能力，取决于你有没有把商品身份、编码身份、店铺主体这三层关系理清楚。

如果你现在正准备给店群申请豁免，我建议你先做一件事：打开你的商品清单，找出所有跨店铺重复登记的商品，看看这个数字是多少。如果这个数字超过你SKU总数的10%，那么在申请豁免之前，先把去重做完。否则你只是把问题从“买码”这一层，搬到了“重复创建”那一层，而后者付出的代价通常更高。

免费注册

咨询方案

扫码咨询方案