上个月帮一个做家居品类的朋友做数据体检，他的店铺在美国站有 2100 多个在架 SKU，表面指标看上去挺健康：评分 4.3 星，退货率 6.8%，广告 ACOS 稳定在 22% 左右。但我把商品主表、变体关系表和广告投放表三张表拉到一起做了一次 UPC 码绑定核对，结果发现 137 个 UPC 码被两个以上的 SKU 共用，另有 41 个 SKU 的 UPC 字段是 12 位纯数字但校验位算不通的”假码”。更麻烦的是，这 137 个复用码里有 63 个跨了两个父体，导致变体合并逻辑在后台根本跑不通。
他当时的反应很典型：”UPC 不就是上架时填的一串数字吗？能上架不就说明没问题？”这正是我想写这篇文章的原因。UPC 码检查不是一个合规动作，而是一次运营精细化程度的切片检查，你怎么管码，基本就等于你怎么管商品资产。这篇文章会把我自己做过的检查方法、验证过的指标口径、踩过的坑，以及不同规模卖家的取舍逻辑，完整拆开讲一遍。
我先把结论摆在前面，后面再用场景和数据一步步论证。如果你时间有限，只看这一段也能拿到可执行的东西。
反常识一：UPC 检查最该看的不是”码是否正确”，而是”一个码绑了几件商品”。绝大多数卖家做的检查止步于”这个码在 GS1 数据库里能不能查到”，但真正的风险几乎全部发生在绑定层。一个合法的、从 GS1 正规渠道买来的码，如果被三个 SKU 共用，它造成的破坏力和一个假码是一样的。
反常识二：UPC 问题暴露的不是合规风险，而是运营流程断点。我复盘过的所有码复用案例，根因几乎都不是”故意作弊”，而是某个环节的流程缺失：批量表格复制粘贴时没清空列、多店铺共用一套上传模板、供应商给的码本身就重复、运营助理误把父体码填到子体上。码混乱是症状，流程断层才是病因。
反常识三：码的绑定混乱程度，通常和类目管理成熟度成反比，而不是和公司规模成反比。我见过年 GMV 八位数、SKU 上万的卖家，一码一品率做到 99.4%；也见过只有 300 个 SKU 的小团队，复用率高达 14%。规模不决定质量，管理颗粒度才决定质量。
把”UPC 检查”做成一件事，前提是它能被量化。我最终固定下来的是六个指标，覆盖从码本身到运营结果的全链路。
这六个指标里，前四个是静态快照，后两个是时间序列。只看静态快照会漏掉最危险的一类问题，历史漂移。一个 SKU 的码被改过三次，意味着它可能已经积累了三次评论、三次排名权重的断裂，而这种断裂在单次快照里完全看不出来。
要理解为什么码的绑定会乱，得先看清楚大多数卖家的成长路径。我把这条路径拆成三个阶段，每个阶段对 UPC 的定位都不一样，而断层恰好发生在阶段切换的那一刻。
铺货期的典型状态是：一天上 200 个 listing，运营助理从供应商的 Excel 里整列复制 UPC，粘贴到平台批量上传模板里。这个阶段没人在意一个码绑了几件商品，因为商品本身也不被当成资产，今天上架，明天可能就下架了。
这个阶段的问题不大，因为 SKU 生命周期短，复用带来的副作用还没积累起来就随着下架消失了。但它埋下了一个坏习惯：UPC 被当成一个可复制的文本字段，而不是一个具有唯一约束的主键。
切到精品模式之后，单个 SKU 的投入变大，评论、排名、广告历史全都要长期维护。这时候 UPC 的角色就变了，它成了平台侧识别这个商品的唯一锚点，评论挂在它上面，历史销量挂在它上面，广告的学习期数据也挂在它上面。
问题是，很多团队的业务模式转了，数据流程没转。上传模板还是那张批量表格，复制粘贴的习惯还在，只不过从”一天 200 个”变成”一周 5 个”。数量降下来了，但错误率没降，因为错误率从来不是由数量决定的，是由流程约束决定的。
到了这个阶段，同一款产品往往要在三四个平台、七八个店铺同时上架。运营为了省事，习惯用同一套 UPC 表格跨平台复用。短期看效率很高，长期看是在给自己挖坑。
我梳理过的风险至少有这么几类：比价工具抓取同码商品做价格对比，导致跨平台价格踩踏；平台风控识别到同码多店铺，触发关联审查；站内广告的归因被跨店铺数据稀释，ACOS 失真；库存归属混乱，出现超卖或缺货。
我印象最深的一次，是一个卖家在四个平台用同一个 UPC 上架同一款收纳盒，被第三方比价工具抓取后，三个平台的售价在两周内被迫拉平到最低价，整体客单价下调了约 11%。他后来跟我说，省的注册码钱大概几百块，损失的是六位数的毛利。
下面这六个误区，我在不同卖家那里几乎都见过至少一次。它们的共同点是，看起来都很有道理，但都会让检查失效。
这是最普遍的一个。很多人打开 GS1 的查询页面，输入 UPC，看到有记录、有品牌名、有厂商信息，就认为检查通过了。
但这只验证了第一层。一个完全合法、缴费正常的 UPC 码，照样可以被五个 SKU 共用。GS1 的系统里不存在”这个码被哪个卖家绑到了哪件商品”这个字段，它只负责发放和登记，不负责绑定关系的唯一性。指望它来发现复用问题，方向就错了。
很多人脑子里的模型是：UPC → 上架 → 完成。但真实链路要长得多。
UPC 会向下游至少五个环节传递：变体关系（父体与子体的归属）、评论聚合、广告归因、库存与 FBA 货件、平台的商品目录匹配。任何一环出现码的错位，都会向下游传导。
我举个具体例子。一个子体的 UPC 被误填成了父体的码，平台在合并变体时会把两个子体的评论池混在一起。结果就是，A 颜色的差评显示在 B 颜色的详情页上，B 颜色的好评被 A 颜色吃掉。这种问题在后台不会报错，只会表现为”转化率莫名下降”。
变体场景是复用码的高发区，因为好几个人会本能地觉得”这是同一款产品的不同颜色，用一个码应该没关系”。
但平台的变体机制恰恰依赖子体各自独立的标识符。子体共用父体码，或者两个子体共用同一个码，都会导致变体关系在系统层面无法正确建立。表现可能是：变体合并失败、变体在搜索页只展示一个、变体切换时价格错乱。
省的是注册费，赔的是定价权和账号安全。跨平台同码最直接的后果是被比价系统抓取，其次是平台关联识别。
我的建议很明确：如果一款产品在不同平台的定价策略不同，就一定不要共用 UPC。如果定价完全一致、且你不在意被比价，那可以接受，但要把它当成一个清醒的决策，而不是省事的默认选项。
生成器码的问题有两层。第一层是合规，平台的品牌备案和类目审核越来越严，异常码段会被识别。第二层是内部管理，生成器码的重复概率远高于正规码，因为很多生成器用的是相似的算法和号段。
更隐蔽的一点是：生成器码往往缺少稳定的厂商前缀，导致你在做多平台数据匹配时失去一个关键的关联维度。这会让后续所有的交叉校验都变难。
这是最容易被忽略、又最难补救的一个。我在做数据体检时，一定会要求拉出 UPC 字段的历史变更记录，但很多团队的 ERP 根本不记录这个字段的修改日志。
没有变更日志意味着什么？意味着你不知道哪些 SKU 换过码，也就不知道哪些 SKU 的评论和排名历史经历过断裂。一个换过三次码的 SKU，它的历史数据其实是三段互不相连的碎片。
前面讲了误区和根因，这一节讲我实际在用的判断逻辑。它的核心思路是把检查分成三层，每一层有独立的判定标准和退出条件。
这一层做的是纯格式和算法层面的检查，不涉及业务。具体包括：位数是否为 12 位、是否全部为数字、校验位计算是否正确、是否落在明显异常的号段（如全 0、连续递增、常见生成器号段）。
校验位的算法很简单，我自己写过一个脚本批量跑，几万行数据几秒钟就能出结果。这段逻辑不值得用现成工具，自己写反而更可控。
def check_upc_checksum(upc: str) -> bool:
"""校验 UPC-A 的校验位是否正确"""
if not isinstance(upc, str) or len(upc) != 12 or not upc.isdigit():
return False
digits = [int(c) for c in upc]
odd_sum = sum(digits[i] for i in range(0, 11, 2)) # 第1,3,5,7,9,11位
even_sum = sum(digits[i] for i in range(1, 11, 2)) # 第2,4,6,8,10位
total = odd_sum * 3 + even_sum
check_digit = (10 - (total % 10)) % 10
return check_digit == digits[11]
常见占位码黑名单，遇到直接标记为无效
PLACEHOLDER_PATTERNS = {
"123456789012", "000000000000", "111111111111",
"123456789000", "999999999999"
}这一层开始进入业务判断。检查项有三个：一个码是否只对应一个 SKU、一个 SKU 是否只有一个码、父子变体的码是否各自独立。
我通常用一个分组计数的方式来做，把 UPC 作为分组键，统计每组的 SKU 数量，然后筛出 count 大于 1 的组。这个操作在任何数据处理环境里都是几行代码的事，真正难的是数据源要拉全。
这里必须强调一点：数据源一定要覆盖所有店铺和所有平台，不能只查主力店铺。我见过不止一次，问题码恰好都藏在已经被遗忘的次要店铺里，因为那边的上架操作更随意、更没人复核。
这是最关键、也最少有人做的一层。它的逻辑是：如果绑定真的健康，那么它应该在运营结果上留下可验证的痕迹。
我通常会把码的绑定表和三张业务表做关联：广告投放表、库存货件表、评论汇总表。如果某个 UPC 对应的 SKU 在广告表里同时出现在两个广告组，在库存表里对应两个货件编号，在评论表里聚合了两套评论，那基本可以断定绑定出了问题，即使第二层看起来是干净的。
这一层的价值在于，它能抓住”码字段正确但业务关系错位”的隐性故障。
手工做上面的三层校验，最大的瓶颈不是算法，是数据采集。你要把七八个店铺的商品主表、变体表、库存表全部导出来，还要保证字段口径一致，这件事本身就消耗掉大部分时间。
我现在的工作流是先在一个跨境数据平台（我常用的是数跨境，官网 https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）里把多店铺的商品数据统一采集落地，把 UPC、SKU、ASIN、父体标识这几个关键字段对齐到一张宽表，然后再在这张宽表上跑校验脚本。
这么做的好处有三个。第一，省掉了逐店铺导出和字段清洗的时间，我实测过，同样是七店铺的样本，手工整理一次大概需要 4 到 6 小时，走采集落地后压缩到 40 分钟以内。第二，数据有历史留存，能做到我前面说的”码漂移率”这个时间序列指标。第三，多平台字段映射有统一规则，比我以前用 Excel 手工匹配可靠得多。
我要提醒的是，工具解决的是数据获取和一致性问题，判断逻辑还是得自己定。工具不会告诉你”一码多品率超过 2% 就要介入”，这个阈值必须根据你自己的类目和 SKU 规模来调。
下面这张表是我目前用的默认阈值，你可以直接拿去改。
| 指标 | 健康区间 | 预警区间 | 必须介入 |
|---|---|---|---|
| 一码一品率 | ≥ 98% | 95% – 98% | < 95% |
| 一码多品率 | ≤ 2% | 2% – 5% | > 5% |
| 无效码率 | ≤ 0.5% | 0.5% – 2% | > 2% |
| 跨店铺重复率 | 0% | 0% – 1% | > 1% |
| 跨平台重复率 | ≤ 5% | 5% – 15% | > 15% |
| 90 天码漂移率 | ≤ 1% | 1% – 3% | > 3% |
跨平台重复率的阈值之所以给得比跨店铺宽松，是因为同码跨平台本身不违规，风险来自定价策略和比价抓取。如果你在多平台做差异化定价，那这个指标的阈值应该直接压到 0。
下面这四组样本来自我过去一年多帮朋友和客户做的数据体检，涉及不同规模和不同类目。数字我做了脱敏处理，量级和比例保持真实。
背景：三个平台、七个店铺、12480 个在架 SKU，以家居小商品为主。团队 12 人，其中运营助理 6 人。
检查结果：一码多品率 8.7%，也就是约 1000 个码被重复使用；无效码率 3.2%，主要是占位码；跨店铺重复码 1096 个；90 天码漂移率 4.1%。
根因排查下来，最集中的是上传模板复用，团队有一张”基础模板”，新品类上架时在上面改字段，但 UPC 那一列经常只覆盖前半段，后半段还是旧数据。12480 个 SKU 里，有超过 400 个 SKU 的 UPC 是同一个值，这个值来自两年前一次模板复制。
后续影响是渐进的：变体合并失败率上升到 12%，广告归因错位让部分 SKU 的 ACOS 虚高 6 到 9 个百分点，最直接的是两个店铺因为同码关联被平台做了合并审核。
背景：单一平台，家居收纳类目，348 个父体、1960 个子体，团队 5 人，运营体系相对规范。
问题出在一次大促前的批量改版。运营为了让新上线的子体快速拿到评论，把几个表现好的老码复用到了新子体上。结果 47 个子体被错误合并，评论池混在一起。
表现是什么？A 颜色（新品，差评多）的差评出现在 B 颜色（老品，口碑好）的详情页上，B 颜色的转化率在大促期间不升反降了约 18%。发现的时候已经是活动第三天。
修复过程很麻烦。因为码已经进过平台目录，改码等于重新建立商品身份，评论归零。最后他们的选择是把错误合并的子体下架重建，损失了三周的自然流量积累。
背景：同一款产品在四个平台销售，其中两个平台共用同一套 UPC，另外两个平台各自独立注册。
被第三方比价工具抓取后，三个平台的售价在两周内被拉平到最低价。原本在其中一个平台可以维持的溢价，被迫下调约 11%。
更麻烦的是，因为共用码的两个平台的库存数据被打通识别，出现了跨平台超卖，处理了大约两周才把差额补上。这个案例里，省下来的码钱大约是几百元，损失是六位数的毛利和一个季度的定价主动权。
这是我最想讲的一个样本，因为它验证了”把检查变成固定动作”的价值。
背景：一个中型精品卖家，SKU 约 5000，三平台五店铺。原来的做法是”出问题再查”，平均从问题产生到被发现需要 23 天左右。
后来我们一起做了一件事：把商品主表通过数跨境统一采集落地，建立了 UPC 码台账，并且把六个指标做成每周自动跑一次的检查任务，异常直接推送到运营群里。
结果是，问题发现周期从 23 天压缩到 4 天左右，一码一品率从最初的 93.1% 提升到 99.2%，跨店铺重复码清零。这个改善不是因为团队变强了，而是因为检查从”事件驱动”变成了”节拍驱动”。
讲完方法论和案例，这一节给具体动作。我按 SKU 规模分成三档，每档给一套能落地的最小可行方案。
这个规模不需要上系统。你需要的是两张表：一张商品主表（含 SKU、UPC、父体标识、平台、店铺），一张变更记录表。
每季度做一次全量检查，内容是：拉出主表，按 UPC 分组计数，筛出 count 大于 1 的组；跑一遍校验位脚本；核对跨平台重复。整个过程熟练的话两个小时以内能完成。
关键是把变更记录表用起来。每次改 UPC 都记一行，写清日期、SKU、旧码、新码、原因。这张表是你后续做码漂移分析的唯一依据，成本极低但回报很高。
这个规模手工做已经吃力，尤其是多店铺场景。建议把 UPC 提升到 ERP 的主数据层级，并且设置唯一性约束，同一个 UPC 不允许同时关联两个有效 SKU，系统层面直接拦截。
同时把检查频率提到月度。具体步骤我整理成了一个清单，可以直接照着执行。
这个规模必须把 UPC 当成资产来管。核心是建立一张全量的码台账，字段包括码本身、归属 SKU、归属平台店铺、激活时间、状态（在用/停用/待分配）、变更历史。
检查要做到节拍化，我建议每周一次，把六个指标全部跑出来，设定阈值自动预警。预警必须推到具体的人，而不是发到一个没人看的群里。
另外要预留码池管理。新品的码分配要有唯一入口，不能让人随手上网买一批就填进去。码池失控是多店铺卖家最常见也最难追责的问题，因为事后再查也查不出是谁填的。
任何方案都有代价，这里把几组最常见的取舍摊开讲清楚，方便你按自己的情况选。
自购正规 GS1 码的成本按年费计，单个码的边际成本随数量下降，好处是稳定、可追溯、支持多平台差异化注册。缺点是前期有门槛，需要公司主体资质。
平台豁免码只适用于特定平台和特定品牌备案状态，跨平台无法通用。它的优点是零成本，缺点是绑死在单一平台，一旦你要扩张平台就得重来。
第三方代购码的风险在于码段的来源和历史归属不透明，你无法确认这个码在别处有没有被用过。如果你打算长期做品牌，我不建议走这条路，因为码是品牌资产的地基。
全量重刷的意思是给所有 SKU 重新分配干净的新码。好处是彻底，坏处是评论、排名、广告历史全部归零，代价极大。我只建议在复用率超过 15% 且涉及核心类目时考虑。
增量修正只处理有问题的码，保留大部分商品的既有资产。这是绝大多数情况下应该选的路。判断标准很简单：如果某个码上的 SKU 已经积累了不可替代的评论和排名，就不要动它，只处理它周边新增的错误绑定。
自动化工具适合处理数据量大的格式校验、分组计数、跨表关联这些确定性任务。人工适合做根因分类、流程回溯、优先级排序这些需要判断的任务。
我的经验是，把这两件事混在一起做，效率最低。常见错误是让人去查几万行码的重复情况，既慢又容易漏，同时让工具去做根因判断，结果输出一堆没人看的报表。
| 你的情况 | 推荐检查频率 | 推荐工具组合 | 优先级最高的一件事 |
|---|---|---|---|
| SKU < 500，单平台单店铺 | 每季度一次 | Excel + 校验脚本 | 建立 UPC 变更记录表 |
| SKU 500-5000，多店铺 | 每月一次 | ERP 主数据 + 数据采集平台 | 在 ERP 里给 UPC 加唯一性约束 |
| SKU > 5000，多平台多店铺 | 每周一次 | 码台账 + 自动预警 + 采集平台 | 建立统一码池与分配入口 |
| 正在从铺货转精品 | 切换期每月两次 | 全量盘点 + 增量修正 | 先冻结新码分配，再清理存量 |
| 准备申诉平台关联审查 | 立即全量 | 全量导出 + 跨店铺比对 | 先出清洗报告，再谈申诉材料 |
我见过团队把六个指标全部跑出来，每周产出一份十几页的报告，第三周就没人看了。检查的深度要和团队的修复能力匹配，否则检查本身会变成负担。
我的建议是分阶段上。第一阶段只跑两个指标：一码多品率和无效码率，跑稳三个月。第二阶段加入跨店铺和跨平台重复率。第三阶段才加码漂移率和结果一致性校验。
这样做的理由是，前两个指标的问题最容易修复，修复成功率也最高，能快速建立团队信心。后两个指标涉及的流程改造更复杂，需要在有信任基础之后再推。
回到文章开头那个朋友。我们最后花了大约三周做增量修正：把 137 个复用码里的 63 个跨父体码全部拆开，重新分配；41 个无效码替换；同时把上传模板里的 UPC 列改成必填校验，复制粘贴时如果检测到重复会直接报错。三个月的跟踪下来，一码一品率从 91.4% 回到 99.1%，广告归因错位带来的 ACOS 虚高基本消失。
我想强调的独特观点是：UPC 码检查的价值，从来不在码本身，而在于它是唯一一个能同时穿透商品、店铺、平台、广告、库存五个系统的标识符。正因为它穿得深，所以它的绑定质量天然就是运营精细化的一个高精度切片。你不需要看一百个指标，只要看这一个标识符被管得怎么样，就能大致判断出这家公司的流程成熟度。
另一个判断是，大多数卖家不需要更复杂的工具，而是需要一个更固定的节拍。我复盘过的所有改善案例里，真正起作用的不是换系统，而是把”检查”从”出事了才做”变成”每周都做”。这件事的成本极低，但需要有人对它负责。
优先解决数据采集问题，而不是先写检查逻辑。因为检查逻辑本身并不复杂，复杂度全部来自数据分散和口径不一。先用采集工具把多店铺、多平台的商品数据统一落到一张宽表上，把 UPC、SKU、ASIN、父体标识这几个关键字段对齐，后面的校验、比对、趋势分析才有意义。
然后按第三阶段的路径走：先跑两个指标跑稳三个月，再逐层加深度。不要一开始就追求六个指标全绿，那只会让团队在第一周就放弃。
最后一句：UPC 码是跨境电商里最便宜也最被低估的资产。一个码的成本可能只有几块钱，但它背后挂着的是评论、排名、广告历史和库存流转。把它当成主键来管，而不是当成文本字段来填，这就是精细化运营的分水岭。
我之前一直以为UPC只要长度对、能通过校验位就没问题，直到有次Listing被下架、广告跑偏，才发现是UPC绑错了SKU。现在做多店铺多类目，我很想知道检查顺序到底怎么排，才不会白忙。
先查绑定关系，再查码本身。具体做法是拉一份全量SKU-UPC映射表，字段至少包括SKU、UPC、ASIN或Listing、店铺、站点、类目、变体关系、创建时间、最近修改人。第一步跑绑定异常：一码多SKU、一SKU多码、变体父子共用UPC、UPC与ASIN不匹配、跨店铺或跨站点复用。
第二步再查码质量：12或13位、GS1校验位、前缀是否自有或授权、是否回收码。判断依据是绑定异常对流量、库存、Review和广告结构的影响远大于单码无效，因为一个错绑会把历史权重和库存错配到另一个商品上。精细化团队通常把SKU-UPC映射唯一率做到99.5%以上，异常24小时内闭环。
我每次看报表只盯缺失和无效，感觉问题不大，但广告结构总是乱，库存也经常对不上。后来怀疑是重码和变体绑定在作怪，可又不知道具体该查哪些隐蔽异常。
最容易被忽略的有五类：一是UPC回收或转售导致历史权重串号；二是变体父子绑定时子体共用父体UPC；三是同款不同颜色或尺寸错绑同一UPC；四是UPC和ASIN映射被覆盖后没有留痕；五是跨店铺或跨站点复用同一UPC。
检查方法很直接：按UPC分组看count(SKU)是否大于1，按SKU分组看count(UPC)是否大于1，按变体父ASIN分组检查子ASIN的UPC是否唯一，再按站点分组检查UPC地域唯一性。判断口径建议是重复绑定率为0、父子共用率为0、跨店复用率为0。
发现后先暂停相关广告和补货，再改映射，并保留修改日志。
老板让我用数据说明运营精细化水平，我不想只讲GMV和转化率，因为这些受流量影响太大。UPC绑定是我能控制的底层数据，但我不清楚怎么量化成一个能服众的分数。
可以搭一个UPC绑定健康分。核心指标包括：UPC缺失率，即缺失SKU数除以在售SKU数，目标低于0.5%；无效码率，即校验位、长度或前缀异常SKU数除以在售SKU数，目标低于0.2%；重复绑定率，即一码多SKU的UPC数除以总UPC数，目标为0；
映射唯一率，即唯一SKU-UPC对除以总映射对，目标高于99.5%；变体绑定异常率，即父子共用或子体缺失UPC数除以变体子体数，目标为0；修复时效，即异常到修复的中位数，目标小于24小时。每项按权重扣分，重复绑定和变体异常权重最高，缺失和无效次之。
连续3周分数高于95且异常闭环，才说明精细化不是口号。
我们平时靠上新时人工填，结果大促前批量改价、换图、加变体，UPC和SKU就乱了。等平台报错已经来不及。我想知道日常检查频率和大促前的检查清单该怎么定。
日常节奏是：新品上架前100%检查，每周一次全量比对，任何Listing变体、品牌或类目修改后24小时内复查。大促前按T-14、T-7、T-1三档执行：T-14拉全量映射表跑异常；T-7修完并二次验证；T-1只做冻结校验，不再大改。
SOP可以固定为从ERP或后台导出SKU、UPC、ASIN、店铺、站点、变体关系，用公式或脚本查重复、缺失、校验位，再人工抽查高销量和高广告花费SKU。通过标准建议是：在售SKU映射唯一率高于99.5%、重复绑定为0、变体异常为0、无效码率低于0.2%。没通过就不放量，先修数据。
读者评论
一码一品率98%这条线，我觉得得按品类分开看。服装、饰品这类颜色尺码多的类目，供应商给的码本身就常带复用，硬拉到98%要反复申请新码，时间和费用不低。小团队做精品，反而可能比铺货型万级SKU更容易达标。建议给出分品类分阶段的阈值，单一数字容易误伤，也容易让人放弃执行。
码漂移率这个指标方向我认同，但落地前提是系统留了变更日志。我们后台导出和内部ERP都不记UPC修改记录，只能靠每月自己拉快照比对，工作量不小。另外90天这个窗口偏主观，节日调整和真流程失控其实是两回事。想了解具体怎么取数，是有接口还是人工留存版本？
跨平台共用码那段我有不同看法。有些平台的目录匹配就认同一编码，主动换掉反而丢掉已有评论和排名权重；还有一部分是供应商指定条码，卖家根本没得选。所以“定价不同就别共用”判断没错，但前提是自己有申请码的能力和预算。中小卖家更多是在约束条件下做的取舍。