电商数据抓取：产品经理老板关心什么：字段设计能否解决重复数据多

电商数据抓取项目最容易制造一种假繁荣：任务日志显示抓到了 120 万条商品记录，数据库也在持续增长，但产品经理真正拿去做竞品分析时，可能只剩下 68 万个可识别商品；再往下看，其中还有一部分是同一商品的不同链接、不同采集批次或不同促销状态。我的判断是，重复数据多，通常不只是爬虫抓重了，而是系统没有定义清楚“什么叫同一个商品”。字段设计能够显著降低重复识别的成本，但它无法替代主键规则、商品匹配、SKU建模和历史版本管理。

一、先说核心结论：字段设计能解决重复，但不能单独解决重复

1. 老板真正要买的不是采集量，而是可使用的数据量

在项目汇报中，“本周新增 50 万条数据”往往比“有效商品增加 8 万个”更容易被展示，但后一个数字更接近经营价值。老板关心的是这批数据能不能支持选品、定价、竞品监控、渠道分析和销售预测，而不是服务器里多了多少行记录。

如果同一件商品被当成十件商品，商品数量会被高估，价格均值会被扭曲，销量排序会出现偏差，运营人员还要不断导出表格人工清洗。表面上看，采集任务完成了；实际上，数据团队只是把重复劳动从网页复制转移到了数据处理环节。

因此，我在评估电商抓取项目时，通常会先把“采集量”拆成四个层级：原始记录数、规范化记录数、独立商品数、可用于业务分析的有效商品数。这四个数字如果没有同时呈现，单看采集量几乎没有判断意义。

这也是为什么我不建议把“去重率”作为唯一的项目成绩。去重率很高，可能意味着系统删除得很激进；去重率很低，也可能说明平台商品本来就分散。只有把独立商品数、错误合并率、漏合并率、字段完整率和数据新鲜度放在一起，结论才可靠。

2. 字段是证据，不是去重按钮

一个字段能不能帮助去重，取决于它在业务上是否稳定、是否唯一、是否可解释，以及它是否能与其他字段共同构成商品身份。商品标题看起来信息量很大，但标题经常包含促销词、关键词堆叠、颜色、容量和套装描述，单独使用时反而容易误判。

平台商品ID通常比标题更适合做精确识别，但平台ID也不一定等于“商品实体”。有的平台ID代表一个商品页面，有的平台ID代表一个销售单元，还有的平台会把不同规格挂在同一个商品ID下。产品经理必须先确认ID的业务含义，再决定它放在商品表、SKU表还是来源映射表中。

更准确的说法是：字段设计解决的是“我能拿什么证据判断两条记录是否相同”，去重规则解决的是“这些证据达到什么条件才允许合并”。前者缺失，后者无法执行；后者缺失，字段越多也只是堆积信息。

3. 先定义商品身份，再讨论字段数量

我见过最常见的顺序错误，是技术团队先列出几十个字段，再让业务方从中挑选。正确顺序应该反过来：先问系统要统计什么、比较什么、追踪什么，再决定商品、SKU、页面和历史状态分别需要哪些字段。

如果业务要回答“某品牌有多少个独立商品”，商品主键可能需要品牌、型号和平台关系；如果业务要回答“某商品每个颜色的价格变化”，就必须下沉到SKU层；如果业务要回答“某个链接在过去三个月是否断货”，采集快照和状态变化又必须单独保存。

二、为什么电商数据抓取特别容易出现重复

1. 一个商品在系统里可能有四种身份

在真实电商环境中，同一件商品至少可能同时拥有四个身份：平台页面身份、店铺销售身份、商品实体身份和SKU销售身份。这些身份彼此有关，但不是同一个概念。

例如，一款 500 毫升黑色保温杯可能在平台上有一个商品ID，在店铺后台有一个SPU编码，在前台又有多个推广链接；如果它还有黑色、白色两个颜色和 500 毫升、750 毫升两个容量，就会继续拆出多个SKU。抓取系统如果把这些层级全部塞进一张表，重复和误合并几乎不可避免。

因此，产品经理在需求文档中至少要写清楚三句话：一条记录代表页面、商品还是SKU；同一商品不同规格是否分别统计；价格变化是更新当前记录，还是新增一条历史快照。没有这三句话，后面的“去重率”没有统一口径。

2. 页面链接变化，不代表商品变化

链接是最容易获得的字段，也是最容易被高估的字段。推广链接、短链、带参数链接、活动页链接和自然搜索链接，可能都指向同一个商品。若系统直接把完整URL作为唯一键，营销参数一变化，就会生成一条新记录。

我通常会把URL拆成至少三个字段：原始URL、规范化URL和页面来源类型。原始URL用于追溯，规范化URL用于基础去重，来源类型用于判断它是商品页、活动页、搜索页还是推广跳转页。这样既不会丢失审计证据，也不会让链接参数制造虚假商品。

但URL规范化也有边界。一个店铺可能在不同页面使用不同链接展示相同商品，也可能在同一链接下动态切换SKU。因此，规范化URL只能作为证据之一，不应该成为跨页面同款合并的唯一条件。

3. 标题相同，也不代表商品相同

标题去重是最直观的做法，却经常造成两类错误。第一类是把不同型号误合并，例如“无线耳机标准版”和“无线耳机降噪版”只差几个词；第二类是把同一商品拆开，例如同一型号因为“新品”“官方正品”“限时优惠”等营销词不同而被识别成多个商品。

标题清洗不能只做空格删除和大小写转换。更实用的处理方式，是把标题拆成品牌、系列、型号、规格、颜色、容量、套装数量和营销词等部分，再分别制定规则。能被识别为营销词的内容可以降权，型号和规格则应提高权重。

如果没有可用的型号或规格字段，系统宁可把一部分疑似同款暂时保留，也不要为了追求表面上的低重复率而强行合并。在商品库里，漏合并通常增加清洗成本，错合并却可能直接污染经营判断。

4. 历史快照会被误认为重复商品

同一个商品每天采集一次，三十天后自然会出现三十条价格和库存记录。如果数据模型只有一张商品表，团队就会面临两个错误选择：要么不断覆盖历史，失去价格趋势；要么把每次快照都当成新商品，导致商品数量膨胀。

更合理的设计是把“商品身份”和“商品状态”分离。商品主表只描述它是谁，状态表记录某个时间点的价格、库存、销量、评价数和促销状态，原始采集表则保留当时从页面获得的字段。这样，当前状态、历史变化和源站证据都能被分别使用。

三、常见误区：为什么“加字段”之后重复仍然很多

1. 误区一：字段越多，去重效果一定越好

字段数量增加，确实能提供更多匹配线索，但也会带来空值、格式不一致、来源冲突和维护成本。比如“品牌”字段可能有中文名、英文名、简称和店铺自定义名；“规格”字段可能把颜色、容量和套装数量混在一段文本里。

当字段没有定义口径时，新增字段只是新增了几种不一致的表达。产品经理要关注的不是字段数量，而是每个字段是否有明确用途：它是主键组成部分、匹配特征、展示字段、追溯字段，还是仅供人工审核参考。

2. 误区二：用商品标题作为唯一键

标题适合做搜索和初步召回，不适合直接承担唯一身份。标题会随活动、关键词策略、类目规则和店铺运营习惯变化，同一商品在不同时间可能出现完全不同的标题。

如果业务预算有限，无法马上建设复杂的商品匹配模型，我建议至少采用“平台、店铺、品牌、型号、规格”的组合规则，再把标题相似度作为辅助条件。对于没有型号的商品，可以加入图片、条码、规格组合和店铺关系等证据，但要把结果标记为“疑似同款”，不要直接写成“已合并”。

3. 误区三：平台商品ID可以跨平台通用

平台商品ID的价值通常局限在它所属的平台和店铺范围内。两个平台都出现“商品ID 10001”，并不代表它们是同一个商品；甚至同一平台不同店铺的ID，也未必能直接比较。

比较稳妥的做法是把来源范围写进唯一标识，例如使用“平台ID、店铺ID、商品ID”的组合。跨平台匹配另行生成内部归一商品ID，不要修改原始平台ID，也不要让内部归一ID取代来源身份。

4. 误区四：把重复行删除，就算完成去重

删除重复行只适合处理完全相同的技术性重复，不能覆盖业务重复、SKU差异和历史状态。尤其是价格监控项目，过去的价格本身就是业务资产，删除它会让系统无法解释价格波动。

我更推荐记录“合并关系”而不是只保留“合并结果”。每次自动合并都应保存原记录ID、目标商品ID、匹配规则版本、匹配分数、处理时间和处理人。这样发生误合并时，可以回滚；规则升级时，也可以重新计算。

5. 误区五：只看自动匹配率，不看错合并率

自动匹配率高，说明系统敢于做决定，不代表决定是正确的。一个系统可以通过放宽阈值，把大量商品自动合并，但如果型号和规格差异被忽略，最终的价格对比和竞品排名会严重失真。

项目验收至少要抽样检查两类结果：系统合并的记录中有多少确实是同款，以及系统没有合并的记录中有多少其实应该合并。前者对应错合并率，后者对应漏合并率，二者必须分别统计。

四、专业判断逻辑：如何判断字段是否真的能解决重复

1. 第一步：明确业务中的“同一商品”

商品去重没有脱离业务的绝对答案。对于竞品数量分析，同一型号的不同店铺商品可能应当合并；对于渠道价格监控，不同店铺的商品必须保留；对于库存管理，同一商品不同仓库或不同包装规格又可能是不同的库存单位。

因此，产品需求中不应只写“去除重复商品”，而应写成可判断的规则。例如：“同一平台、同一店铺、同一商品ID下，不同采集时间的记录视为同一商品的状态变化；同一品牌、同一型号、同一规格在不同链接下视为同款候选，但不同店铺记录仍需保留。”

这类规则虽然看起来比一句“去重”复杂，却能让产品、开发、数据和业务人员在验收时使用同一套语言。

2. 第二步：给字段分配角色

字段设计时，我会要求团队为每个字段写出角色，而不是只写字段名。角色至少包括：唯一定位、精确去重、模糊匹配、业务展示、历史追溯和异常审核。

3. 第三步：区分精确去重和疑似同款匹配

精确去重的目标是消除技术性重复，规则应尽量稳定、可解释。例如同一平台、同一店铺、同一商品ID、同一SKU ID、同一采集批次重复写入，通常可以直接拦截。

疑似同款匹配则是另一类问题。它往往涉及不同页面、不同店铺甚至不同平台，需要结合品牌、型号、规格、条码、标题和图片等信息。匹配结果不应只有“是”和“否”，而应设置高置信度、中置信度和低置信度三个区间。

• 高置信度：平台明确提供统一商品编码，或品牌、型号、规格和条码均一致，可以自动归并。
• 中置信度：品牌和型号相似，规格部分一致，但存在标题差异或字段缺失，应进入人工审核。
• 低置信度：只有标题或图片相似，缺少稳定身份字段，应暂时保留为不同记录。

4. 第四步：保留原始值、标准值和判定结果

最容易被忽略的设计是原始字段的保留。清洗后的品牌、型号和规格可以用于分析，但如果只覆盖原始值，后续出现误匹配时就无法知道系统最初看到了什么。

我建议至少保留三套信息：源站原始值、标准化后的值、系统判定结果。判定结果还应带上规则版本和匹配依据。这样，数据质量团队可以回答“为什么这两条记录被合并”，而不是只能说“系统算出来的”。

5. 第五步：用错误成本决定自动化程度

不同业务对错合并和漏合并的容忍度不同。竞品数量看板可能更怕重复统计，愿意接受一部分漏合并；价格监控则更怕把不同型号的价格合并在一起，因为这会直接影响定价判断；商品搜索可能更关注召回率，允许疑似同款先展示。

所以，自动化阈值不应由技术团队单独决定。产品经理需要把两类错误的成本说清楚：错合并会造成什么损失，漏合并会增加多少人工处理。只有把错误转化成业务成本，才能决定哪些记录自动处理，哪些记录进入审核池。

五、一个可落地的案例：用分析看板识别“采集量增长”背后的重复

1. 案例背景：看板显示增长，业务却觉得数据变差

下面的案例采用脱敏后的情景数据，重点用于说明分析方法，不代表某个企业的公开经营数据。某家经营家居用品的企业，从多个电商渠道采集竞品商品数据，最初的管理看板只展示新增记录数、商品总数和抓取成功率。

项目上线第一个月，系统新增 18 万条记录，抓取成功率达到 96%。管理层据此认为项目进展良好。但运营团队抽取一批商品进行价格分析时发现，很多商品被不同活动链接重复记录，部分颜色和容量也被混在一起，导致同款价格区间异常宽。

问题不在于采集任务没有完成，而在于看板把“记录”当成了“商品”。团队后来增加了平台、店铺、商品ID、SKU、标准品牌、标准型号、规格组合、采集批次和归一商品ID等字段，并把商品主表、SKU表和状态快照表分开。

2. 采用九数云进行分析看板拆解

在这类项目中，九数云更适合承担数据连接、指标加工和业务看板呈现的分析角色，而不是被当成自动识别同款商品的唯一工具。我们可以把采集原始表、标准商品表、SKU表和商品状态表接入同一分析流程，再用分组、关联和计算字段观察重复来源。

这里有一个重要边界：分析平台可以帮助团队看清哪些平台、店铺、类目和采集批次重复率更高，也可以帮助产品经理比较字段完整率和有效商品率；但“两个商品是否应该合并”仍然需要业务规则、标准词表和匹配逻辑。不要把看板能力误解成商品主数据治理能力。

在看板中，我通常会设计四个层次。第一层展示原始记录、独立商品和有效商品；第二层展示重复来源；第三层下钻到具体店铺、商品ID和链接；第四层保留原始页面与处理批次，方便复核。

3. 案例数据：同样是18万条记录，结论可以完全不同

在情景模拟中，第一版系统把 18 万条记录全部作为商品总数。经过精确去重后，剩余 14.6 万条；进一步按商品ID、SKU和标准化字段识别后，得到 10.9 万个独立销售单元；剔除关键字段缺失、下架过久和更新时间超限的数据后，可用于竞品分析的商品只有 9.7 万个。

这组数据并不意味着“系统失败”。相反，它帮助管理层看清了每一层数据损耗来自哪里。技术性重复主要来自任务重试，同款候选主要来自活动链接和不同标题，失效数据则与抓取周期和页面状态有关。

4. 看板如何定位重复数据的真正来源

如果只看整体重复率，团队很难知道该改采集程序、字段映射还是匹配规则。我们可以在分析看板中按平台、店铺、类目、任务批次、解析版本和链接来源类型切分，观察重复率的分布。

例如，某个店铺的重复率突然升高，且集中出现在活动期间，优先排查URL参数和推广链接；某个类目的同款候选率长期偏高，可能是型号字段缺失或规格表达不统一；某个采集批次出现完全相同记录，通常应排查任务重试和数据库幂等机制。

这种分析方式的价值在于，它把“重复很多”变成了可定位的问题。产品经理不需要凭感觉要求开发“再加一个去重规则”，而是可以根据重复来源决定投入方向。

5. 案例中的关键改变：从“删除重复”改成“管理关系”

团队最终没有简单删除重复记录，而是建立了三个关系字段：归一商品ID、来源商品ID和父级商品ID。归一商品ID用于跨来源识别同款，来源商品ID用于保留平台身份，父级商品ID用于连接不同SKU。

这样处理后，运营可以看到某个归一商品在不同店铺的价格，产品可以看到各SKU的库存，技术可以回溯原始页面，管理层则可以按统一口径查看独立商品数量。不同角色使用的是同一批底层数据，但不再被迫使用同一张混合表。

六、字段设计的具体方案：从最小可用到完整治理

1. 最小可用字段：先解决来源内精确去重

如果项目刚开始，预算和开发资源有限，不必一次性建设复杂的跨平台商品识别系统。第一阶段至少应保证来源内身份清楚，建议包含平台名称、店铺ID、平台商品ID、SKU ID、原始链接、采集时间、任务批次和数据状态。

这组字段主要解决两个问题：同一个来源实体能否稳定定位，以及同一批任务重复写入时能否被识别。它不能解决跨平台同款，但可以先消除大量技术性重复，让后续治理建立在相对干净的基础上。

2. 标准化字段：解决“同一种商品多种写法”

第二阶段要增加品牌、型号和规格的标准化字段，并保留对应的原始值。标准化并不是简单删除符号，而是建立一套可回溯的转换规则。例如，型号中的连字符、空格和大小写可以统一，但型号主体不能被随意截断；容量单位可以统一为毫升或克，但套装数量不能被忽略。

建议至少把商品标题拆成原始标题、清洗标题、品牌原值、标准品牌、型号原值、标准型号、规格原值和标准规格。对于规则暂时无法识别的内容，应记录“待处理”，而不是用空值掩盖不确定性。

标准化字段还需要版本。今天的品牌词表可能把某个简称归入品牌A，明天业务规则变化后可能归入品牌B。如果没有规则版本，历史结果无法解释，数据团队也无法比较规则升级前后的影响。

3. 完整字段：支撑跨平台商品关系和历史状态

当项目需要做跨平台竞品分析、价格趋势和库存监控时，应进一步增加内部归一商品ID、匹配置信度、匹配规则版本、审核状态、首次发现时间、最近更新时间、失效时间和状态快照ID。

其中，内部归一商品ID是企业自己的商品身份，不应直接复用任何一个平台的ID。它的作用是把多个来源商品映射到统一业务实体上，同时保留每个来源的独立信息。

匹配置信度和审核状态尤其重要。它们能把“系统已经自动做出的判断”和“业务人员确认过的判断”区分开，避免所有归一关系都被误认为同等可靠。

4. 推荐的数据分层

为了避免一张大表承载所有信息，我建议采用原始层、标准层和应用层三层结构。原始层只负责完整保留来源数据，标准层负责字段映射和身份加工，应用层面向竞品、价格、库存或运营场景输出稳定指标。

• 原始层：保留页面原值、原始URL、采集时间、任务批次、解析版本和响应状态。
• 标准层：完成品牌、型号、规格、类目、平台和店铺的统一表达。
• 关系层：维护来源商品、来源SKU、归一商品和父子商品之间的映射。
• 应用层：输出当前商品、价格快照、库存趋势、竞品对比和质量看板。

这种分层的优点不是“架构更高级”，而是每层承担不同责任。业务规则变化时，可以重新加工标准层和关系层，不必重新抓取所有页面；源站异常时，也能通过原始层回溯问题。

5. 精确去重的实现示意

下面的示例只表达字段组合和幂等思路，不对应某个具体平台。实际项目中，唯一键组合必须根据来源ID的真实含义确认，不能直接复制。

CREATE UNIQUE INDEX uk_source_sku
ON source_product (

platform_code,

shop_id,

source_product_id,

source_sku_id

);

INSERT INTO source_product (

platform_code,

shop_id,

source_product_id,

source_sku_id,

raw_url,

collected_at,

batch_id

)

VALUES (

:platform_code,

:shop_id,

:source_product_id,

:source_sku_id,

:raw_url,

:collected_at,

:batch_id

)

ON CONFLICT (

platform_code,

shop_id,

source_product_id,

source_sku_id

)

DO UPDATE SET

raw_url = EXCLUDED.raw_url,

collected_at = EXCLUDED.collected_at,

batch_id = EXCLUDED.batch_id;

这段逻辑只能解决同一来源实体的重复写入，不能判断两个不同平台的商品是否同款。把技术性幂等和业务性同款匹配混在一起，是很多项目后期难以维护的根源。

七、不同业务情况下，应该采用什么行动方案

1. 如果目标是竞品数量统计

竞品数量统计最重要的是统一商品口径，而不是保留每一个链接。建议先建立“归一商品ID”，再按品牌、型号、规格和类目进行同款识别。不同店铺的来源记录可以保留，但统计独立竞品数量时不应重复计数。

这类项目可以接受一部分漏合并，因为后续可以通过人工审核和周期性规则优化修正。但必须重点防止同一商品在活动链接、搜索页和详情页被反复计入。

• 优先建设商品、SKU和来源商品三层关系。
• 按商品ID做来源内精确去重。
• 按品牌、型号、规格做高置信度同款合并。
• 对中置信度记录保留审核池，不要直接删除。
• 看板同时展示来源商品数和独立商品数。

2. 如果目标是价格监控

价格监控不能只保留当前价格。价格变化、促销状态、原价、券后价和库存状态本身就是分析对象。建议建立价格快照表，以商品或SKU为主体，以采集时间为时间轴，保存每次采集到的状态。

价格监控更怕错合并。一个型号的标准版和高配版如果被合并，价格趋势会失去意义。因此，型号、容量、规格和套装数量的完整性优先级高于单纯降低重复率。

3. 如果目标是选品和市场分析

选品分析通常更关注商品层级、品牌、类目、价格带、销量和评价等指标。此时可以把SKU数据聚合到商品层，但聚合规则必须明确。例如价格是取最低SKU价格、主推SKU价格还是价格区间，销量是取商品总销量还是规格销量。

如果不先定义聚合口径，同一商品不同规格会在市场规模、销量和价格带中被重复计算。产品经理要在字段设计阶段写清楚“展示层级”和“统计层级”，否则数据团队会在每张报表里重新猜规则。

4. 如果目标是库存和供应链分析

库存分析通常不能把不同包装、不同仓库和不同规格简单合并。一个商品在商品展示层可以是同款，但在库存层可能对应不同的SKU、仓库和库存单位。此时，商品归一ID只能用于关联，不能直接作为库存统计主键。

建议将库存记录至少拆分为商品、SKU、仓库、库存状态和时间五个维度。缺少仓库和库存单位字段时，即使商品去重做得很好，库存周转率仍然可能被错误计算。

5. 如果目标是建设长期商品库

长期商品库不能只围绕当前页面设计。平台会改版，商品会下架，链接会失效，店铺会迁移，品牌和型号标准也会变化。系统必须保留首次发现时间、最近更新时间、失效时间和来源变更记录。

我建议把“当前可见”与“历史存在过”分开。下架商品不一定应该删除，因为它可能仍然是价格趋势、竞品生命周期和市场变化的重要样本。

八、项目成本与准确率之间，应该如何取舍

1. 低成本方案：规则优先，人工兜底

适合商品数量较少、来源平台有限、同款关系相对清晰的项目。做法是使用来源ID精确去重，再通过品牌、型号、规格组合进行规则匹配，中置信度记录进入人工审核。

这种方案上线快、可解释性强，适合验证需求和建立第一版指标。但它依赖标准词表维护，面对标题变化、规格缺失和跨平台差异时，人工审核量会逐步增加。

2. 中成本方案：规则加相似度模型

适合来源较多、商品量较大、业务已经有一定标注数据的项目。可以先用规则筛选候选集，再使用标题、品牌、型号、规格和图片等特征计算相似度，最后设置高、中、低置信度处理路径。

这种方案的关键不是模型名称，而是是否保留人工反馈。审核人员确认的合并和拆分结果，应回流为标注样本，用于调整规则和阈值。没有反馈闭环的模型，很容易在商品结构变化后失效。

3. 高成本方案：商品主数据与实体匹配体系

适合多平台、多类目、长期运营的企业。除了采集和匹配，还需要建设品牌词表、型号词表、规格单位标准、商品关系、审核权限、规则版本和回滚机制。

这类方案投入较大，但它解决的是长期数据资产问题。企业不再每次做报表时重新清洗，而是把商品身份和来源关系沉淀成可复用基础能力。

4. 不要为了一个漂亮指标牺牲业务可信度

如果管理层只要求“重复率降到最低”，团队很可能通过扩大合并范围来完成目标。但商品库的核心不是行数变少，而是每一条关系都能解释、复核和用于决策。

更稳妥的做法是同时设置质量指标和风险指标。例如要求技术性重复率低于某个目标，同时规定错合并率不能超过业务容忍线；要求有效商品率提升，同时要求关键型号字段完整率达到最低标准。

九、产品经理和老板的验收清单

1. 产品经理应该问的十个问题

产品经理的职责不是把所有字段都写进需求，而是确保每个字段都对应一个业务判断。以下问题可以作为需求评审和供应商沟通时的基本清单。

1. 一条记录究竟代表商品、SKU、页面还是采集快照？
2. 同一商品不同规格是否分别统计？统计层级是什么？
3. 平台商品ID代表什么对象，稳定性如何验证？
4. 不同店铺的同款商品是否合并，合并后是否仍保留店铺来源？
5. 不同平台疑似同款的判断依据是什么？
6. 标题、品牌、型号和规格是否分别存储？原始值是否保留？
7. 价格变化是更新当前记录，还是写入历史快照？
8. 自动匹配的规则版本和匹配分数能否追溯？
9. 发生错合并时能否回滚到原始记录？
10. 项目最终按采集量、有效商品数还是业务分析结果验收？

2. 老板应该看的五组指标

老板不需要深入理解每个解析器或数据库索引，但需要看到数据从采集到决策之间发生了什么。建议管理看板至少展示五组指标。

• 规模指标：原始记录数、独立商品数、有效商品数。
• 准确指标：错合并率、漏合并率、抽检通过率。
• 完整指标：品牌完整率、型号完整率、规格完整率。
• 时效指标：最近更新时间、更新成功率、失效数据占比。
• 成本指标：人工审核耗时、重复计算量、存储与处理资源消耗。

这些指标最好按平台、店铺、类目和任务批次下钻。整体平均值很容易掩盖局部问题，尤其是一个高重复率店铺可能被大量低重复率店铺稀释。

3. 建议设置一组人工抽检样本

不要只让系统自报准确率。可以按高置信度自动合并、中置信度待审核和低置信度未合并三个区间分别抽样，再由熟悉商品的业务人员判断是否同款。

抽检结果要记录四种情况：正确合并、错误合并、正确拆分、应该合并但未合并。这样才能分别计算精确率和召回率，而不是用一个模糊的“准确率”掩盖不同错误。

4. 一次完整验收应该包含哪些材料

一份合格的项目验收材料，不应只有数据总量截图。至少应包含字段字典、主键规则、去重规则、匹配阈值、抽检结果、异常记录、历史快照说明和回滚方案。

如果供应商只承诺“抓取成功率”和“数据量”，却无法解释同款合并、SKU拆分和历史数据处理方式，产品经理应谨慎评估。采集成功不等于数据可以用于经营决策。

十、常见问题与直接判断

1. 只增加商品ID字段，能不能解决重复数据？

只能解决一部分来源内重复。商品ID可以帮助识别同一平台、同一来源实体，但不能自动判断跨店铺或跨平台同款，也不能区分商品、SKU和历史快照。必须先确认ID代表的对象，再与店铺、平台和SKU字段组合使用。

2. 商品标题清洗后，能不能直接做唯一键？

不建议。清洗后的标题适合做搜索召回和相似度计算，不适合单独做唯一键。标题可能缺少型号、规格和套装信息，也可能因为营销词变化而产生多个版本。至少应结合品牌、型号、规格和来源身份。

3. 同一商品不同店铺应该合并吗？

要看业务目标。统计市场上的独立商品时，可以建立同款关系；分析店铺价格、库存和销量时，必须保留不同店铺记录。更好的做法不是二选一，而是同时保留来源商品ID和内部归一商品ID。

4. 历史价格是否属于重复数据？

不是。历史价格是同一商品在不同时间的状态记录，不应直接删除。应通过采集时间、快照ID和状态表区分“同一商品的新状态”与“新商品”。只有完全相同且没有业务价值的重复写入，才适合直接清理。

5. 分析平台能不能自动完成商品去重？

分析平台可以帮助连接数据、加工字段、搭建看板和定位重复来源，但商品去重仍需要业务主键、标准词表、匹配规则和审核机制。以九数云为例，它可以用于观察平台、店铺、类目和批次层面的数据质量变化，但不能替代企业对“同一商品”的业务定义。

6. 什么时候值得建设复杂的匹配模型？

当商品量、来源数量和人工审核成本已经达到一定规模，且企业拥有稳定的品牌、型号、规格和审核样本时，复杂模型才有投入价值。如果项目还没有明确商品层级和字段口径，直接上模型往往只是把不清楚的业务规则自动化。

十一、最后的行动建议：先做一周字段审计，再决定是否重构

1. 第一天：把重复记录分成四类

从最近一批数据中随机抽取样本，分别标记完全重复、同款不同链接、不同SKU误合并或误拆分、历史快照重复。不要一开始就改规则，先确认重复的主要来源。

2. 第二天：确认每个ID的真实含义

向来源接口、页面结构和业务人员分别确认平台商品ID、店铺ID、SKU ID和页面链接代表什么。很多项目的问题不是字段缺失，而是字段名称与真实含义不一致。

3. 第三天：建立字段角色表

为每个字段标注它属于身份字段、标准化字段、状态字段、追溯字段还是审核字段，并补充是否必填、更新频率、来源、格式和异常处理方式。

4. 第四天：分离商品表、SKU表和快照表

如果当前只有一张混合大表，先完成数据层级拆分。哪怕第一版只使用简单规则，也要让商品身份、规格信息和历史状态各自有明确位置。

5. 第五天：建立精确去重和疑似匹配两条流程

来源内精确去重可以优先自动化，跨来源疑似同款则设置置信度和审核状态。不要用同一条规则同时处理两种不同问题。

6. 第六天：搭建质量看板

可以使用九数云等分析平台，将原始记录数、独立商品数、有效商品数、重复来源、字段完整率、更新成功率和人工审核耗时放在同一看板中，并支持平台、店铺、类目和批次下钻。

7. 第七天：用抽检结果决定下一步投入

如果主要问题是任务重试和重复写入，优先改幂等机制；如果主要问题是标题和规格不统一，优先做标准化；如果主要问题是跨平台同款识别，才考虑扩大匹配模型和人工标注体系。

十二、独特结论：重复数据问题，本质上是企业对商品身份的管理能力

1. 字段设计不是技术细节，而是经营口径

当企业决定用什么字段定义商品时，实际上也决定了市场规模如何计算、竞品如何比较、价格如何聚合、库存如何统计。字段名看似属于数据库，背后却对应管理层对业务对象的定义。

因此，字段设计评审不能只邀请开发和数据工程师。产品经理、运营、采购、财务或供应链人员都应参与，尤其要对商品、SKU、店铺、页面和历史状态的边界达成一致。

2. 最有价值的字段，往往不是展示字段

商品标题、主图和价格很容易被看到，却未必能稳定支撑去重。真正帮助系统建立可信关系的，往往是平台、店铺、商品ID、SKU ID、型号、规格、采集批次、解析版本和归一商品ID。

这些字段不一定出现在最终看板上，却决定了看板上的数字能否解释。没有来源和版本字段，团队无法追查异常；没有规格字段，团队无法判断同款；没有时间字段，团队无法区分商品变化和重复记录。

3. 数据越多，越需要先控制身份混乱

小规模项目可以依靠人工删除重复，大规模项目则必须把商品身份、来源关系和历史状态沉淀为系统规则。数据量增长以后，问题不会只是重复行变多，而是错误会被同步放大到报表、模型和经营决策中。

我的建议是，不要从“如何抓更多数据”开始，而要从“业务需要哪些独立商品、哪些SKU和哪些历史状态”开始。先建立有效商品口径，再扩展采集范围，通常比先堆采集量更省成本。

最终结论很明确：字段设计能解决重复识别所需的证据问题，但不能单独解决商品身份、同款匹配和历史版本问题。产品经理应先定义统计对象，老板应重点看有效商品数、错合并率、漏合并率、字段完整率和数据新鲜度，数据团队则应通过原始层、标准层、关系层和应用层把这些口径真正落地。

下一步可以先选一个平台、一个类目和一周数据，完成字段审计与人工抽检。用这批小样本确认重复来源，再决定是优化采集幂等、补充字段标准、拆分SKU模型，还是建设跨平台匹配能力。只有先知道重复数据为什么产生，字段设计才不会变成一张越来越长、却越来越难用的字段清单。

免费注册

咨询方案

扫码咨询方案