我会先回答“为什么”，再回答“如何验证”和“该怎么改”，让新手也能按步骤完成一次小范围排查。
当运营人员说“商品被录了两遍”，我不会马上打开商品名称进行肉眼比对。因为名称只是展示属性，可能受到品牌写法、促销词、规格顺序、空格、大小写和平台标题规则影响。真正应该优先比较的是能够稳定指向同一个经营对象的字段组合，例如内部 SKU、条码、SPU、品牌、型号、规格值、仓库货号和渠道商品 ID。
如果这些字段没有明确的主次关系，团队就会产生多个“看起来合理”的商品身份：商品表里有一条，平台导入模板里有一条，仓库表里又有一条。每一条都能被继续编辑，于是重复不是一次错误，而是下一次错误的起点。
这也解释了为什么很多团队清理过一次商品表，几周后重复数据又出现。清理只改变了结果，没有改变流程；如果新增商品仍然允许绕过校验，旧问题就会被新的导入文件重新复制。
建议同时观察的身份字段：SKU、条码、SPU、规格、渠道 ID。
定位链路：数据结果、操作过程、管理规则，不能只看最后一张表。
示例排查窗口，适合新手先做小范围验证，不代表所有企业的固定周期。
最终主数据出口，团队可以有多个协作表，但只能有一个权威来源。
我先把常见业务动作还原出来，很多问题在流程图里比在结果表里更容易看清。
大促前一天，运营从供应商表格复制了“蓝色保温杯 500ml”，在系统中找不到完全相同的名称，就新建了一条商品。实际上，原有记录的名称是“保温杯-蓝-500毫升”，SKU和条码都没有变化。
这类问题的关键不是运营不认真，而是搜索只支持名称模糊匹配，或者商品检索页面没有把 SKU、条码、规格等高价值字段放到醒目位置。人在赶时间时会选择最快完成任务的路径，系统就应该把安全路径设计得更快，而不是把责任全部交给个人记忆。
同一款商品在自营商城、第三方平台和直播渠道分别维护。各渠道使用自己的商品 ID，运营人员把平台导出的文件再次整理进内部表格时，没有建立“渠道 ID—内部 SKU”的映射，于是每个平台记录都被当成一个新商品。
这个场景中，平台 ID 不应该直接充当内部主键。平台 ID 用来识别渠道上的发布对象，内部 SKU 用来识别企业经营对象，二者需要通过映射关系连接，而不是互相替代。
同一款衣服的黑色、白色、M码和L码可能是一个 SPU 下的多个 SKU。若表格没有“父商品”和“子规格”的概念，员工就会把每个组合都录成一条完全独立的商品。
复制功能可以提高录入效率，但如果复制同时保留了原 SKU、条码或外部 ID，系统就可能产生两条可编辑记录。复制应当只继承描述属性，唯一身份必须重新生成并经过校验。
采购、仓库和运营各自维护一份 Excel，月底再汇总。汇总时只按商品名称拼接，规格和条码未参与匹配，造成“同名不同物”和“同物不同名”同时存在。
影响不一定马上表现为销售损失，也可能先表现为对账时间、库存准确率和决策信心下降。
第一层是数据层：商品数被高估，新增、下架、有效商品等指标失真。第二层是流程层：库存、订单、广告和活动报名可能分别关联到不同记录，人员需要额外手工核对。第三层是经营层：同一商品的销量、毛利、退货和投放成本被拆散，负责人很难判断真实表现。
在仓配环节，重复身份可能引起可售库存重复计算或库存分配错误；在财务环节，商品编码不一致会使成本和收入无法顺利归集；在分析环节，管理者看到的是多个“表现一般”的商品，而不是一个真实表现稳定或需要优化的商品。
因此，我建议不要只问“重复了多少条”，还要问“重复记录被哪些业务表引用”“哪些指标已经被拆散”“修复后是否会影响历史订单”。删除记录很容易，安全合并需要明确主记录、从记录、字段继承规则和引用迁移范围。
下面是用于内部评估的示例公式，不代表某家企业的真实数据：
例如，假设某团队发现 240 条疑似重复记录，每条需要 6 分钟核对，另有 80 笔订单需要重新确认，每笔耗时 8 分钟，那么仅核对和修复就约为 2,080 分钟，约 34.7 小时。这个数字只是示例，实际估算应使用自己的工时和订单范围。
建议把“人工时间”与“业务风险”分开记录，避免为了追求一个漂亮的节省数字而忽略历史数据迁移的风险。
很多重复问题反复出现，并不是团队没有做过治理，而是治理动作只覆盖了表面。
名称适合帮助人理解，不适合单独承担唯一识别。相同名称可能对应不同规格，不同名称也可能指向相同 SKU。我的做法是先用强标识精确去重，再用名称、品牌和规格组合生成疑似重复名单。
直接删除会破坏订单、库存、广告和报表的引用关系，也可能损失历史变更记录。安全动作应该是先冻结新增、建立主从关系、保留审计轨迹，再根据引用情况做合并、停用或更正。
审批只是增加一道门，如果审批人看不到重复候选、来源渠道和历史记录，审批仍然依赖经验。真正有效的是让校验结果可见、规则可解释，并把高风险情况自动拦截。
把采购、库存、订单、营销和平台字段全部堆进一张表，看起来信息完整，实际更难维护。字段含义混杂、更新责任不清、重复列大量出现，最终会让“谁是主数据”更加模糊。
更稳的方式是保留商品主表、规格表、渠道映射表、状态变更表等清晰结构，再通过分析工具按业务需要关联查看。表可以多张，但身份关系必须明确。
当前商品表只能告诉我“现在有几条”，不能解释“什么时候多出来的、谁创建的、从哪个文件导入的”。没有时间、人员和来源维度，就很难判断是一次性的历史遗留，还是每天都在发生的流程缺陷。
至少要保留创建时间、最后更新时间、创建人、导入批次、来源渠道、状态和变更原因。若暂时没有完整日志，可以先在汇总表中补充这些字段，再逐步完善系统能力。
判断不是越复杂越专业，而是要让不同角色按照同一标准得出相近结论。
先说明本次排查的对象是 SPU、SKU、渠道发布商品，还是仓库可拣货单位。它们的粒度不同，不能混在一个“重复商品”指标里。服装的 SPU 可以代表一个款式，SKU 则通常还包含颜色和尺码；如果不区分粒度，误判几乎不可避免。
我通常把字段分成强标识、辅助标识和描述字段。强标识用于精确判断，辅助标识用于提高召回，描述字段用于人工确认。字段优先级应该形成书面规则，不应由当班人员临时决定。
| 字段层级 | 示例 | 主要用途 |
|---|---|---|
| 强标识 | 内部 SKU、有效条码 | 精确判断同一经营对象 |
| 辅助标识 | SPU、型号、渠道 ID | 建立关联和候选集合 |
| 描述字段 | 名称、卖点、图片标题 | 帮助人工理解，不单独定案 |
把重复记录按来源分组：手工创建、批量导入、接口同步、复制生成、历史迁移。不同来源需要不同的治理动作。手工创建重点看检索和权限，批量导入重点看模板与导入前校验，接口同步重点看映射与幂等规则，复制生成重点看新身份生成。
两个名称相似的记录不一定应该合并。若包装、税率、仓库属性、供应商或销售渠道不同，强行合并可能带来更大风险。判断时要同时看身份、业务用途、历史引用和当前状态。
我会把结论分为四类：确认重复并合并、疑似重复待业务确认、同名不同物需保留、历史停用记录不再参与新增但保留追溯。这样比简单输出“重复/不重复”更适合实际协作。
以下数字全部为演示排查方法的示例，不代表 E数通客户或任何真实企业的经营数据。
示例口径：将每个流程阶段发现的疑似重复记录数除以该阶段处理的商品记录数，形成相对风险指数。指数用于比较流程，不等同于真实损失率。
示例中，批量导入占比最高并不意味着导入工具一定有问题，还要继续检查模板是否带有唯一标识、导入前是否执行匹配，以及失败记录是否被重复提交。
| 观察信号 | 可能含义 | 下一步验证 | 优先动作 |
|---|---|---|---|
| 导入阶段风险突然升高 | 模板字段缺失、重复提交或导入前未匹配 | 抽取批次号、文件名、导入人和失败日志 | 增加导入预览与强标识校验 |
| 手工新增长期偏高 | 搜索不可用、商品权限边界过宽或培训不足 | 观察新增前搜索关键词和页面路径 | 优化搜索并提示候选商品 |
| 平台同步出现集中重复 | 外部 ID 映射失效或同步接口缺少幂等判断 | 对比内部 SKU、渠道 ID 和同步时间 | 建立稳定映射和重复同步保护 |
| 复制商品风险较低但影响大 | 少量复制记录被订单或库存引用 | 查复制来源和引用业务单据 | 限制唯一字段继承，保留审计链路 |
这里使用的是一个虚构的业务演示场景，用来说明分析思路；具体字段、连接方式和权限需结合实际系统确认。
假设一家经营家居用品的电商团队，同时维护商品主表、仓库 SKU 表、自营商城导出表、平台商品导出表和活动报名表。团队希望知道：过去一个月新增商品中，有多少可能重复；重复主要来自哪种操作；哪些记录已经影响订单或库存；下周应该先修复哪一类问题。
我会优先建议团队在 E数通中建立一张分析主题表，连接五类来源，但不急着改写原始业务数据。主题表可以保留来源名称、来源记录 ID、内部 SKU、条码、SPU、商品名称、规格、状态、创建人、创建时间、渠道 ID 和导入批次等字段。
接着建立三个层次的视图：第一层是管理总览，展示新增量、疑似重复量、确认重复量和受影响单据数；第二层是来源分析，按照渠道、人员、批次、操作方式和日期拆解；第三层是明细核验，允许业务人员回到原始记录确认是否合并或保留。
新增商品、疑似重复、确认重复、受影响单据。
渠道、创建方式、操作人、时间段和批次。
展示候选记录、强标识差异和业务引用。
示例中，我会把字段分为“识别字段”“运营字段”和“审计字段”。识别字段用于匹配，运营字段用于判断能否合并，审计字段用于复盘来源。字段名称可以根据团队现有表头调整，但不要为了方便把多个含义拼成一个字段。
识别字段内部SKU条码SPU渠道ID
运营字段规格品牌仓库税率
审计字段来源批次创建人创建时间
假设分析页面显示：某月新增 1,200 条，精确重复 28 条，疑似重复 86 条，其中 60% 来自批量导入。这个结果不能直接得出“批量导入有问题”，但足以让我把第一轮验证范围放在导入模板、重复提交和批次失败重跑上。
如果明细进一步显示 28 条精确重复都来自同一个模板版本，就优先修正模板和导入校验；如果重复分散在多个模板和多人操作中，则更可能是主数据规则或系统入口设计的问题。数据分析的价值，是把“感觉有问题”变成可验证的假设。
对电商新手来说，最重要的是先建立闭环，再逐步提高自动化程度。
下面是一个示例治理计划的完成度，不代表实际项目进度。它的作用是把抽象目标拆成可以讨论的工作包。
| 阶段 | 主要动作 | 优点 | 取舍 |
|---|---|---|---|
| 第一阶段：看清 | 统一字段、建立重复候选清单、保留来源 | 投入小，快速发现高风险位置 | 仍需人工确认，不能完全自动拦截 |
| 第二阶段：管住 | 限制新增入口、增加强标识校验、规范模板 | 减少新增重复，形成标准流程 | 初期可能降低录入速度，需要培训 |
| 第三阶段：联动 | 打通主数据、渠道映射、订单库存引用 | 减少跨系统手工同步，追踪更完整 | 项目周期更长，对接口和权限要求更高 |
没有一种治理方案适用于所有团队，关键是让风险、成本和业务节奏匹配。
如果商品量只有几百条、渠道不多，我会优先建立一份权威商品主表、统一 SKU 命名规则和人工核对清单。此时不必一开始就做复杂自动化，但必须把唯一字段和维护人写清楚。
取舍：用少量人工换取低建设成本，同时设置每周抽查，避免随着商品增长失控。
如果每天都有多个渠道文件进入系统，应优先治理映射关系和导入前检查。将平台商品 ID 和内部 SKU 分开存储，并给每个导入批次配置可追踪信息。
取舍：导入前增加校验会占用几分钟，但通常比事后排查订单和库存更划算。
不要为了追求整齐而全量合并。先锁定仍在售且被高频引用的商品，建立主从映射，历史停用记录保留可追溯状态，再分批处理低频和无引用数据。
取舍：数据表短期内不会非常“干净”，但能降低历史单据断链的风险。
大促前最稳妥的动作是冻结高风险字段的批量修改，建立临时新增审批，优先处理影响库存和活动报名的重复记录。不要在上线前夕做全量编码迁移、删除商品或重构全部数据模型。
可以先用 E数通或现有分析工具做监控视图，列出新增商品、强标识重复和高价值商品的异常清单，等活动结束后再做系统性治理。
没有日志不等于无法排查。可以先使用文件名称、导入批次、创建人、更新时间和来源渠道等现有字段构造一份临时审计表。对无法确认的记录标记为“待核验”，不要用猜测填补事实。
同时把日志字段列入后续需求：谁在什么时候以什么方式创建、修改或停用了什么对象。只要每次治理都补齐一个缺口，后续分析就会越来越可靠。
每个问题都给出判断边界和实践路径，便于直接带回团队讨论。
如果 SKU 是经过验证、在企业内部唯一且没有被历史重复使用的强标识，那么相同 SKU 通常可以作为精确重复的强信号。但我不会只凭一个字段直接删除记录，还会检查规格、仓库属性、状态、创建来源和订单引用，确认是否存在 SKU 复用或数据迁移遗留。更安全的做法是先标记主记录与疑似从记录，再按引用关系执行合并或停用。
平台 ID 识别的是平台内发布对象，内部 SKU 识别的是企业经营对象，两者粒度和生命周期可能不同。同一商品在不同平台拥有多个平台 ID 是正常情况，真正需要排查的是这些平台 ID 是否正确映射到同一个内部 SKU，以及是否因为渠道、价格或包装差异而应该分别管理。我会保留渠道映射表，不把平台 ID 强行当成内部主键。
通常不建议直接关闭，因为复制描述、图片和公共属性可以显著提高新品录入效率。问题在于复制操作是否错误继承了 SKU、条码或渠道 ID，以及新记录是否经过唯一性校验。我的建议是保留复制功能，但只继承非唯一字段；新商品身份必须重新生成，复制后弹出需要确认的差异项，并记录复制来源以便追溯。
SPU 更接近款式或产品族，例如“某型号保温杯”；SKU 更接近可销售、可库存管理的具体组合，例如“蓝色、500ml、礼盒装”。如果团队把颜色、容量和包装都当成独立 SPU，商品数量会被夸大；如果把不同仓库或不同包装的可拣货单位都合并成一个 SKU，又会影响库存和履约。排查前必须先约定粒度，再决定哪些字段参与匹配。
没有日志时，不应该把责任直接归因于某个人。可以利用创建时间、文件名、导入批次、修改人、来源渠道和平台同步时间等间接线索建立候选范围，但要明确标注为推断而非事实。更重要的是先定位流程缺口，例如某个模板反复产生重复、某类入口没有校验，然后补充审计字段和权限规则，让下一轮分析能够基于证据。
Excel 适合做小范围抽样、字段清洗和首次盘点，但单纯按名称查重无法覆盖规格、渠道 ID、订单引用和变化过程。对于多来源、多人协作和持续更新的商品数据，我会把 Excel 作为原始检查或临时补充，而不是长期唯一出口。可以用 E数通等分析工具连接不同来源，形成按时间、渠道、创建方式和商品明细分层的可追踪视图，再把确认后的规则回写到业务流程。
三种动作适用条件不同。没有业务引用且确认是误建的记录，才适合在保留审计信息的前提下删除或作废；有订单、库存或财务引用的记录，通常先建立主从关系并迁移可迁移引用；同名但规格、税率、仓库或包装不同的记录则应保留。我的判断顺序是先看身份，再看引用，最后看当前经营状态，不能为了减少条数而牺牲可追溯性。
系统设置应围绕“让正确操作更容易”展开：在新增前提供 SKU、条码和名称的组合搜索；展示高相似候选商品；对强标识重复执行拦截；对疑似重复提供人工确认；复制商品时不继承唯一字段；批量导入时先预览错误和重复行；同时保留来源、创建人和批次信息。工具能够降低概率，但最终还要有主数据负责人和定期复盘机制。
商品重复录入的表象是“多了一条记录”，本质是企业没有把商品身份、渠道映射、变体关系和录入责任连接成统一规则。名称相似只能作为线索，SKU、条码、SPU、规格和外部 ID 的关系才是判断基础。治理不能停留在删除重复项，还要追问重复来自哪里、影响了哪些业务，以及如何让下一次新增更安全。
如果团队正在使用多张表、多个平台或多个录入入口，我建议优先做可视化的来源分析和明细核验。以 E数通为例，可以先把分散数据连接起来，建立总览、诊断和明细三层视图，让团队在不立即改动原始业务数据的情况下看清问题，再决定系统改造的优先级。
当重复问题已经跨越商品、库存、订单和营销多个环节，或者团队需要每天花大量时间人工对表，就不应只靠个人经验维持。此时建设电商运营管理系统、明确主数据规则，并使用 E数通等工具做跨表分析，会比继续堆叠临时表格更有长期价值。系统建设不必追求一次完成，先建立统一身份和可追溯分析，再逐步推进自动校验、权限控制和接口联动，通常更符合业务节奏。
