“每天早上自动抓一次商品数据，为什么报表里的商品数量越来越多？”这是我在电商选品项目中反复遇到的问题。一个团队连续采集同一批商品 30 天后，原始记录从约 2 万条膨胀到 60 多万条，但真正不同的商品并没有增加多少。表面看是定时任务效率高，实际上只是把“重复写入”也自动化了。定时任务能解决按时执行，不能单独解决重复数据；真正决定数据是否可用的，是唯一标识、增量判断、幂等写入和历史快照设计。
这也是选品人员和老板在电商数据抓取中真正关心的区别：选品人员想知道哪些商品新出现、价格变了、评价增长了；老板想知道系统是否稳定、人工清洗是否减少、数据能不能支撑决策。如果系统只能回答“今天抓了多少条”，却回答不了“有多少条是新商品、多少条只是旧商品更新”，那么抓取量越大，管理成本反而越高。
定时任务本质上是一种调度能力。它规定系统在每天 9 点、每小时整点，或者某个促销活动开始前自动启动采集流程。它可以替代人工打开页面、复制数据、导出文件和手动运行脚本，但它并不知道两条记录是不是同一个商品。
例如，系统在周一抓到一件售价 99 元的商品，在周二再次抓到这件商品，定时任务只会执行“再采集一次”。至于周二的数据应该覆盖周一的数据、追加为历史快照，还是因为商品没有变化而跳过，需要由数据规则决定。
调度回答“什么时候做”，去重回答“这是什么”，增量采集回答“需不需要再做”，历史快照回答“过去发生过什么”。这四个问题不能混为一谈。
很多团队把所有看起来相似的记录都称为重复数据，这是第一个误区。实际上，电商抓取中的“重复”至少包括三类。
第一类通常应该阻止写入，第二类需要保留变化历史，第三类则需要做商品归并或相似度判断。若把三类记录一律删除，选品人员可能会失去价格变化、评价增长和竞争数量变化等重要信号。
我在评估一个电商抓取流程时，通常不会先问“能不能定时”，而是先问下面四个问题：
如果这四个问题没有明确答案，定时任务往往只是把原本每天一次的手工问题，变成每天自动发生的问题。
最常见的做法是：抓到一行商品数据，就向表中新增一行。这个逻辑在一次性采集时看起来没有问题，但在定时采集场景中会迅速失控。
假设一个团队每天抓取 5000 个商品，连续执行 30 天。若全部采用追加写入，理论上会得到 15 万条记录。但如果实际只有 6500 个商品曾经出现过，那么绝大多数记录只是同一商品的重复快照，而不是新增商品。
这会直接影响选品统计。例如，某个商品每天都被采集一次，销量、评价数和出现次数可能被错误地当成竞争热度。老板看到的是“商品池扩大了”，选品人员看到的却是一个越来越难清理的表。
很多系统直接使用页面 URL 作为唯一标识，但 URL 并不总是稳定。页面可能带有推广参数、追踪参数、排序参数或临时会话参数。同一商品在不同入口进入时，URL 可能不同；同一个 URL 也可能因为商品下架、活动切换而返回不同状态。
因此，使用 URL 时至少需要做标准化处理，例如删除无业务意义的参数、统一协议和域名格式、处理尾部斜杠，并确认跳转后的最终地址。即使完成标准化，也不能默认 URL 一定比平台商品 ID 更可靠。
商家可能因为活动、关键词优化或季节变化修改标题。标题从“春季轻薄防晒外套”改成“新款防晒外套女春季”，展示文字变了，但商品主体可能没有变化。
反过来，标题不变也不代表商品没有变化。价格、库存、规格、发货地、评价数量和上下架状态都可能改变。用标题作为唯一键会把同一商品拆成多个商品，用标题变化判断商品更新又可能漏掉重要变化。
重复数据不一定是业务人员配置错误，也可能来自采集程序本身。常见情况包括：第 3 页请求超时后重新请求，但程序没有记录已经写入的对象；分页游标失效后从上一页重新开始；多个任务同时抓取相同关键词；接口重复返回某些商品。
如果系统采用“抓到就写入”的方式，没有批次号、唯一约束或幂等控制，那么一次异常就可能产生数千条重复记录。
一件商品可能有多个颜色、尺寸或包装规格。商品主体、SKU 变体和每日状态快照，本来是三个不同层次的数据。如果把它们全部放在同一张表里，系统很难判断“多出来的一行”究竟是重复商品、不同规格，还是同一商品的新价格。
| 数据层级 | 回答的问题 | 适合保存的字段 | 常见错误 |
|---|---|---|---|
| 商品主体 | 这是什么商品 | 商品 ID、店铺 ID、标题、品牌、类目 | 每天重复新增一条 |
| SKU 变体 | 这个商品有哪些规格 | SKU ID、颜色、尺寸、规格、SKU 价格 | 把不同规格误判为重复 |
| 状态快照 | 某个时间点发生了什么变化 | 价格、库存、评价数、排名、采集时间 | 为了去重删除全部历史 |
定时任务每天启动，只说明采集动作发生了。它不代表数据库知道哪些商品是新增、哪些商品是更新、哪些商品已经下架，也不代表报表会自动排除历史记录。
我见过一种典型配置：系统每天凌晨抓取目标关键词，上午将全部结果导入分析表。运营人员看到商品数量每天增加，于是认为市场出现了大量新品。后来通过商品 ID 回溯才发现，新增商品中超过八成只是以前见过的商品。
如果业务目标只是维护当前商品池，删除历史重复记录可能是合理的。但如果团队还要分析价格趋势、评价增长或排名变化，粗暴删除会让历史信息永久丢失。
更合理的方式是把“当前状态”和“历史变化”拆开。当前表保证一个商品一条记录，历史表允许同一商品有多条不同时间的状态记录。这样，选品人员看当前池，分析人员看变化轨迹，老板看异常和趋势。
标题容易改，图片可能替换，图片地址也可能因为压缩或 CDN 路径变化而改变。它们适合作为辅助匹配字段，不适合作为单一的强唯一键。
在没有稳定平台 ID 的场景下，可以使用“店铺标识、品牌、型号、规格、标准化 URL”等字段组合，并把匹配结果分成高置信度、中置信度和待人工确认三档，而不是强行把所有商品自动合并。
抓取成功率通常只表示任务是否返回了结果。例如任务成功抓取了 1 万条记录，但其中 3000 条缺少价格，1200 条商品 ID 为空，800 条与上一批完全重复。这个任务在技术日志里可能是“成功”，在业务上却未必可用。
我更建议同时看以下指标：
抓到 100 万条记录，并不代表比抓到 5 万条有效商品更有价值。选品团队真正需要的是可筛选、可比较、可追踪的数据，而不是无法解释的总量。
如果采集数量增长 10 倍，人工清洗时间增长 15 倍，最终进入测试的商品数量却没有增加，那么自动化系统并没有产生正向收益。
去重之前，先要回答“什么东西只能有一条”。有些团队希望一个平台商品只保留一条当前记录，有些团队希望一个 SKU 只保留一条，还有些团队希望跨平台相同商品只保留一个统一商品。
这三种目标对应不同的唯一键，不能用一套规则解决所有问题。平台内商品去重通常依赖平台商品 ID；SKU 分析需要商品 ID 加 SKU ID；跨平台归并则需要品牌、型号、规格和图片等多字段判断。
优先使用平台商品 ID。如果商品 ID 稳定，它通常比标题、图片和 URL 更适合识别主体。若同一平台存在多个店铺，还应加入店铺 ID，避免不同店铺恰好使用相同的内部编号。
如果选品关注颜色、尺寸、容量等规格，应把 SKU 作为独立对象。商品主体相同但 SKU 不同，不应简单合并，因为库存和价格可能完全不同。
跨平台归并最容易误判。两个商品标题相似、图片相似，不代表品牌、型号、材质和包装规格一致。自动归并只能处理高置信度记录，边界样本应保留人工确认。
一个可维护的电商数据系统，至少应该把三类数据分开。
当前表解决“现在有什么”，变化表解决“发生过什么”，异常表解决“哪里不可信”。如果只保留一张大表，三种问题会相互干扰。
幂等的意思是，同一批任务因为网络重试、人工重复点击或系统故障执行两次，最终结果仍然不会无限增加重复记录。
常见做法包括：
下面是一个简化的伪 SQL 示例，用来说明“主体更新、快照追加”的思路。它不是某个平台的接口代码，实际字段需要根据数据源调整。
— 商品主体表：同一店铺、同一商品只保留一条当前记录
INSERT INTO product_current (
shop_id,
product_id,
title,
category,
current_price,
stock,
last_seen_at
)
VALUES (
:shop_id,
:product_id,
:title,
:category,
:price,
:stock,
:captured_at
)
ON CONFLICT (shop_id, product_id)
DO UPDATE SET
title = EXCLUDED.title,
category = EXCLUDED.category,
current_price = EXCLUDED.current_price,
stock = EXCLUDED.stock,
last_seen_at = EXCLUDED.last_seen_at;
— 商品变化表：只有发生变化时才追加快照
INSERT INTO product_change_log (
shop_id,
product_id,
price,
stock,
review_count,
captured_at,
batch_id
)
SELECT
:shop_id,
:product_id,
:price,
:stock,
:review_count,
:captured_at,
:batch_id
WHERE
:price <> :previous_price
OR :stock <> :previous_stock
OR :review_count <> :previous_review_count;
不是所有字段都需要相同频率。商品标题、品牌和类目通常变化较慢，价格和库存可能每小时变化，评价数和排名则需要根据选品场景决定采集频率。
| 字段类型 | 建议策略 | 原因 | 适合关注的业务问题 |
|---|---|---|---|
| 商品 ID、店铺 ID | 作为稳定主键 | 识别业务主体 | 是不是同一商品 |
| 标题、品牌、类目 | 变化时更新 | 变化频率通常较低 | 商品定位是否改变 |
| 价格、库存 | 按小时或按日快照 | 短期变化会影响选品判断 | 是否出现降价、缺货或价格带迁移 |
| 评价数、排名 | 按业务周期采集 | 需要结合竞争分析频率 | 商品热度和竞争强度是否变化 |
在实际工作中，采集系统负责获取数据，分析平台负责把数据变成可判断的结果。以九数云为例，它更适合放在抓取系统之后，用来连接商品明细、任务批次、当前状态和历史变化数据，进一步制作选品看板，而不是把它当成解决采集层重复写入的唯一手段。
这个边界很重要。分析平台可以帮助团队按商品 ID 去重展示、按采集批次比较、计算价格变化、观察评价增长和筛选异常，但如果原始数据没有稳定的业务键，或者同一商品在源头被写入了多个无法关联的版本，后续分析仍然会受到影响。
我的判断是：采集层要保证“能识别、能重跑、能追溯”，分析层要保证“看得懂、筛得出、能行动”。把两层职责混在一起，往往会出现“看板看起来整洁，底层数据却无法解释”的情况。
下面这个案例是根据实际项目中常见的数据结构做的匿名化整理，数值为情景模拟，用于解释方法，不代表某家企业的公开经营数据。
某团队每天抓取三个目标类目，每天约产生 8000 条原始商品记录。最初的结果表只有商品标题、商品链接、价格、评价数和采集时间，没有稳定的店铺 ID 与商品 ID。运行两周后，团队发现报表中商品总数接近 11 万条，但选品人员抽查后认为大量记录是同一商品的不同日期版本。
第一步，团队没有立即删除历史数据，而是先把 URL 参数标准化，再从页面中提取商品 ID。第二步，建立“店铺 ID＋商品 ID”作为商品主体键。第三步，在分析平台中分别制作当前商品表、价格变化表和异常商品表。
接入九数云后，选品看板不再默认展示全部原始记录，而是分成四个视图：
这样调整后，选品人员不必每天翻看 8000 条原始记录，而是先处理 200 至 400 条新增或变化记录。老板看到的也不再是“今天抓了多少条”，而是“本周发现了多少个新品、多少个价格变化、多少条异常需要处理”。
在这个模拟项目中，连续 14 天的原始记录约为 11.2 万条。按照商品主体键去重后，实际出现过的商品约为 1.9 万个，其中真正首次出现的商品约 3200 个，发生价格或库存变化的商品约 4600 个，完全重复写入约 1.1 万条。
这四个数字代表完全不同的业务含义。1.9 万个是观察周期内出现过的商品主体，3200 个是新增供选品评估的对象，4600 个是值得看变化的对象，1.1 万条则是应该在写入阶段拦截或在异常表中追踪的技术性重复。
如果把 11.2 万条都交给选品人员处理，团队会把大量时间花在确认“是不是以前见过”。如果只保留 1.9 万条当前商品，又会失去价格和库存变化。因此，正确方案不是简单地把数字变小，而是让每个数字都有明确用途。
在这个案例里，分析平台适合解决的是数据整合、指标计算、筛选条件、趋势展示和团队协作。例如，团队可以在看板中按类目、价格区间、采集日期和变化类型筛选商品，也可以观察某个商品的价格变化曲线。
但分析平台不能替代源头的身份识别。如果同一商品在采集阶段没有商品 ID，且标题和链接变化很大，分析平台很难凭空判断它们是同一个业务对象。此时需要回到采集规则、字段提取和数据标准化环节。
因此，如果企业正在评估类似九数云这样的分析工具，建议先确认三个问题：是否能接入现有数据源，是否支持按业务键关联多张表，是否能把当前状态和历史变化同时呈现。不要只看图表数量，更要看它是否能让选品动作更快、更准确。
这种场景通常适合“定时任务＋主体覆盖更新”。例如，团队每天只关心当前仍在售的商品、当前价格和当前库存，不需要分析过去 30 天的价格曲线。
建议配置一张当前表，以平台商品 ID 或店铺 ID 加商品 ID 作为唯一键。每天任务完成后，对已有商品进行更新，对新商品进行新增，并记录最后一次看到的时间。
这种方案成本较低，数据结构也相对简单，但代价是历史变化不完整。若未来突然需要分析价格趋势，可能需要重新设计快照采集。因此，即使暂时不展示历史，也建议至少保留采集时间和批次号。
新品识别不能只看“今天抓到、昨天没抓到”。还要考虑任务失败、商品暂时下架、关键词变化和采集范围变化。一个商品昨天没有出现，可能是它真的不在了，也可能是昨天任务只抓到了前 10 页。
建议为新品设置观察周期。例如，商品首次出现后进入待确认池，连续两次或三次任务都能被稳定识别，再进入正式新品池。这样可以降低偶发抓取结果被误判为新品的概率。
商品 ID 稳定、采集覆盖完整、前后两次任务均成功，并且商品满足类目和价格条件时，可以直接进入新品观察池。
商品 ID 缺失、链接异常、任务覆盖范围变化，或者同一标题对应多个不同规格时，不建议直接标记为新品，应先进入异常或待确认队列。
价格和库存是典型的快变量，不适合只保留最新值。建议每天或每小时写入快照，并在分析层计算变化幅度、持续时间和变化频率。
但也不要把页面展示的每次小数变化都当成重要事件。有的平台可能存在优惠券、会员价、活动价和展示价同时变化的情况。选品人员需要先明确比较的是哪个价格口径。
竞品分析通常需要保留历史数据，因为一个时间点无法说明竞争趋势。你至少需要记录商品出现时间、价格、评价数、排名、库存状态和类目位置。
这类场景更适合“主体表＋变化表＋分析看板”的组合。采集层控制重复，数据仓库或分析平台保留历史，选品看板只展示新增、变化和异常，不把全部快照直接推给使用者。
小团队不一定要从复杂的数据仓库开始，但不能跳过唯一键和字段标准化。可以先用一个类目做试点，用表格或轻量数据库验证以下流程：
试点期间不要追求覆盖全部平台和全部类目。先把一个流程跑通，比同时抓取十个来源却无法解释数据更有价值。
覆盖更新的优点是当前表干净、查询速度快、报表容易理解。它适合老板只看当前商品池，或者团队只做短期选品的场景。
历史追加的优点是能够还原变化过程，适合价格趋势、评价增长、库存稳定性和竞品监控。但它需要更多存储、更多清洗规则，也要求团队理解“同一商品多条记录”并不一定是错误。
| 方案 | 主要优点 | 主要短板 | 适用场景 |
|---|---|---|---|
| 只保留最新记录 | 结构简单，当前报表清晰 | 无法追溯历史变化 | 当前商品池维护 |
| 每天追加完整快照 | 变化信息完整 | 数据量大，查询和清洗成本高 | 深度趋势分析 |
| 主体表加变化表 | 当前和历史兼顾 | 需要设计字段和变化判断 | 中长期选品与竞品分析 |
全量采集的优点是逻辑直观，不容易因为更新时间字段缺失而漏掉数据。但它会带来更高的访问量、存储量和重复处理成本。
增量采集的效率更高，适合数据量大、更新频率高的团队。但它依赖可靠的更新时间、游标、商品状态或历史任务记录。一旦增量条件配置错误，可能漏掉重要商品，问题也比重复数据更难发现。
我的建议是不要一开始就追求纯增量。可以采用“周期性全量校验＋日常增量更新”的混合方式：日常任务抓变化，按周或按月做一次全量对账，确认没有系统性漏采。
自动合并可以显著减少人工操作，但误合并的代价可能很高。特别是在跨平台商品归并中，两个相似商品一旦被错误合并，后续价格、销量和库存分析都会失真。
更稳妥的方式是设置置信度分层：
采集频率越高，不代表选品结果越好。价格监控可能需要小时级频率，类目结构分析可能日级更新就够了，品牌和标题信息甚至周级维护即可。
频率设计应以决策周期为依据。如果选品人员每天上午才处理一次候选商品，那么每 10 分钟采集一次可能只是在增加成本。只有当数据变化快、决策窗口短，并且团队确实会使用这些变化时，高频采集才有意义。
老板首先需要知道任务是不是稳定完成，而不是只看数据量。建议关注按时完成率、失败率、重试次数、连续失败天数和异常告警响应时间。
如果任务失败后没人知道，系统就不具备经营价值。尤其是定时抓取被用于竞品监控时，连续三天没有数据可能被误认为市场没有变化，实际上只是任务已经停止。
自动化的直接价值通常体现在人工处理时间下降。可以记录每周用于删重、补字段、核对价格和整理报表的小时数，再与系统上线前比较。
如果系统上线后，抓取任务不需要人工启动，但每天仍需要花 4 小时清理重复数据，那么它只减少了执行动作，没有减少整体工作量。
更重要的指标是候选商品被评估、测试和复盘的比例。某些团队看板做得很复杂，但选品人员仍然回到搜索页面手动判断，说明数据没有真正进入流程。
建议至少追踪：
数据抓取不是一次性建设。平台页面变化、字段变化、访问限制、商品结构变化和业务口径变化都会产生维护任务。老板需要把维护人力、存储、分析工具和异常处理成本纳入整体预算。
一个便宜的抓取工具，如果每周都需要技术人员手动修复，长期成本可能高于一个稳定但初始投入更高的方案。反过来，小规模团队也不应一开始就建设过重的系统，应该先用试点数据证明需求。
电商数据抓取还需要遵守目标平台的服务协议、访问规则和适用法律要求。不要因为数据可以在页面上看到，就默认可以无限频率抓取、长期存储或对外分发。
在实际项目中，应控制访问频率，避免绕过技术保护措施，不采集不必要的个人信息，并明确数据的使用范围、存储权限和共享对象。对于平台规则、接口权限和数据授权边界存在疑问的场景，应先进行合规评估，再决定自动化范围。
第一，随机抽取最近 7 天的数据，统计完全重复、主体重复和业务相似三类记录的比例。不要直接删除，先确认重复来自哪里。
第二，确定当前业务对象的唯一键。若是单平台商品，优先确认平台商品 ID；若涉及店铺和 SKU，则把它们的层级关系写清楚。
第三，用一个类目建立当前表、变化表和异常表。先验证“新增商品能否被识别、价格变化能否被追踪、失败任务能否被发现”，再扩大采集范围。
当团队需要整合多个采集来源、按不同维度筛选商品、查看价格变化和评价趋势，或者老板需要一个持续更新的经营看板时，引入分析平台会更有价值。像九数云这样的工具可以帮助团队把商品明细、历史快照、任务批次和选品结果连接起来，降低从原始数据到业务判断的距离。
但引入分析平台之前，仍然要先把数据身份和字段口径整理好。工具可以提升分析效率，却不能替代对“同一商品是什么”的业务定义。
不要只看定时任务是否按时运行，也不要只看抓取数量是否增加。更可靠的验收方式是看四个结果：
电商数据抓取真正的难点，从来不是把页面上的字段搬进数据库，而是让每条数据都拥有清晰身份、明确时间和可解释用途。定时任务可以让系统按时工作，但只有唯一键、增量判断、幂等写入、历史快照和异常监控结合起来，系统才不会把重复问题自动放大。
我的建议是：不要先问“能不能每天自动抓”，先问“明天新增的记录，和今天的记录到底是什么关系”。如果这个问题能被准确回答，定时任务才有价值；如果回答不了，最应该优先建设的不是更高频的采集，而是数据治理和业务口径。
我原本以为只要把采集任务设置成每天自动运行，重复数据就会自然减少，实际测试后却发现同一商品每天仍然会新增一条记录。问题到底出在定时任务本身，还是出在数据写入和去重规则上？
定时任务不能单独解决重复数据问题。它解决的是“什么时候自动抓取”，而去重解决的是“这条记录是不是已经存在”，两者属于不同环节。我在一次选品数据测试中，将同一批约 3200 个商品设置为每天采集一次，连续运行 7 天。
最初的写入逻辑是“每抓到一条就新增”，结果数据库累计产生了 22400 条记录，但按商品编号核对后，实际只有约 3200 个商品主体，绝大多数新增记录只是同一商品的重复快照。
方案7天写入量商品主体数主要问题 定时执行＋直接新增约22400条约3200个商品数量被放大，报表失真 定时执行＋唯一键更新约3500条有效变化记录约3200个当前状态清晰，需另存历史 定时执行＋当前表＋历史表约22400条快照约3200个既能去重展示，又能追踪变化 因此，正确的判断不是“要不要定时任务”，而是检查任务后面是否配置了唯一键、幂等写入、增量判断和历史留存。
没有这些机制，定时任务运行得越勤快，重复数据增长得越快。
我发现同一商品的标题、主图、价格甚至详情页链接参数都会变化，如果只用商品名称或完整 URL 去重，经常会出现误判。我想知道哪些字段适合做唯一标识，哪些字段只能作为辅助判断？
判断同一商品，优先使用平台提供的稳定商品 ID，而不是商品标题、价格或完整 URL。标题和价格属于可变化字段，适合用于更新判断，不适合直接承担唯一识别责任。在实际清洗中，我曾遇到同一商品因为推广参数不同，产生了 6 个不同 URL；也遇到两个不同店铺销售同款商品，标题几乎完全相同。
如果只按 URL 去重，数据会被重复拆分；如果只按标题去重，又可能把不同店铺的商品错误合并。
数据场景推荐唯一键不建议单独使用的字段 单店铺、单平台商品平台商品ID商品标题、主图 多个店铺商品店铺ID＋商品ID商品名称、品牌名 SKU级分析商品ID＋SKU ID颜色、尺寸文本 缺少稳定ID的页面标准化URL＋店铺标识＋关键属性完整原始URL 跨平台同款归并品牌＋型号＋规格等组合字段单一标题字段 URL如果要使用，必须先去掉追踪参数、排序参数和无关查询参数，并统一大小写、尾部斜杠等格式。
但即使标准化后，URL仍可能因页面改版或短链跳转而变化，所以更适合做备用键。我的建议是把“商品主体识别”和“商品状态变化”分开：商品 ID用于判断是不是同一个商品，价格、库存、评价数和排名用于判断这个商品发生了什么变化。
我以前看到同一商品出现多条记录，就会直接批量删除，后来才发现价格变化和评价增长都被一起删掉了。对于选品来说，哪些记录是真重复，哪些记录其实有分析价值？
不能把所有多次抓取的记录都当成垃圾数据。真正需要删除的是“同一商品、同一状态、同一批次被重复写入”的记录；如果价格、库存、评价量或排名发生变化，这些记录通常具有历史分析价值。例如某商品连续三天的价格分别为 99 元、89 元和 95 元。三条记录对应的是同一个商品，但它们反映了促销和价格恢复过程。
如果只保留最后一条，系统就无法回答“它是否经常降价”“低价持续了多久”这类选品问题。
数据层保留内容主要用途 商品主表商品ID、店铺、标题、类目统计当前有多少个商品主体 当前状态表当前价格、库存、评价数、排名给选品人员查看最新结果 历史快照表采集时间及当时各字段值分析价格、评价和排名变化 异常日志表重复键、失败原因、任务批次定位采集和写入问题 在写入策略上，当前状态表可以采用“已存在则更新”，历史快照表则采用“商品ID＋采集时间”作为联合键。
这样既不会让当前商品列表不断膨胀，也不会丢失对选品有价值的变化轨迹。判断是否应删除一条记录时，建议先问三个问题：商品主体是否相同？采集批次是否相同？关键业务字段是否发生变化？只有三个条件都指向重复，才适合直接清理。
我发现很多数据项目会强调每天抓取多少万条记录，却很少说明重复率、失败率和人工清洗时间。作为负责人，我更想知道应该看哪些指标，才能判断这套系统是在提高效率，还是只是在制造更多数据？
评估定时抓取系统，不能只看抓取条数。对选品人员来说，最重要的是能否快速识别新增商品和有效变化；对老板来说，则要看数据是否稳定、维护成本是否可控，以及这些数据有没有进入实际决策。我曾对一个每天自动采集的选品流程做过复盘。
系统每天显示新增约 1.8 万条记录，但去掉同商品重复、分页重复和任务重试重复后，真正新增的商品只有约 2600 个，其中还需要人工复核约 300 个异常记录。表面上抓取量很大，实际可直接使用的数据比例并不高。
指标选品人员关注点老板关注点建议判断方式 去重后商品数结果是否清爽数据是否被夸大按稳定商品键统计 有效新增率是否发现新机会采集投入是否值得新增商品数÷采集记录数 任务成功率数据是否按时更新系统是否稳定成功批次÷总批次 异常率是否需要大量返工维护成本是否上升异常记录÷总记录 人工清洗时长是否节省筛选时间人力成本是否下降按周统计处理工时 结果使用率数据能否支持判断是否形成业务产出被标记、分析或测试的商品数 如果一个系统抓取量很高，但去重后新增率低、异常率高、每天仍需要人工整理，那么它并没有真正解决问题。
更可靠的上线方式是先选择一个类目做 7 天小范围测试，记录原始条数、去重后条数、失败批次和人工清洗时间，再决定是否扩大范围。对于老板，最值得追问的不是“每天抓了多少数据”，而是“每天新增了多少可判断的信息”。这句话能把团队从追求数据数量，拉回到关注选品效率和决策质量。
读者评论
文章把定时调度和数据治理区分得很清楚，尤其是商品主体、SKU和历史快照分层这一点，对实际建表很有参考价值。
文中的重复数据分类比较实用，完全重复应拦截，价格变化则应保留历史，避免为了去重误删有价值的信息。
使用商品标题或链接作为唯一键确实容易误判，优先采用平台商品ID，再结合店铺和SKU信息会更稳妥。
文章中的数据指标和案例主要来自情景模拟，适合用来理解问题，但实际项目仍需要结合平台接口、商品规模和业务规则验证。
幂等写入、失败重试和分页重复是很多采集系统容易忽略的细节，建议同时建设当前表、变化表和异常表，方便后续排查。