电商数据抓取项目最危险的时刻，往往不是任务报错，而是任务显示“成功”。我曾在一次商品价格监测项目复盘中看到：采集任务成功率达到 99.6%，每日入库商品数也基本稳定，但业务方抽查 120 个商品后，发现 17 个价格抓取成了划线价，9 个商品把不同 SKU 合并到了一起，另有 14 个已下架商品仍被标记为在售。技术上是“抓到了”，业务上却是“不能用”。

所以，电商数据抓取的质量校验，不能从“页面有没有返回数据”开始，而要从“这批数据能不能支撑业务判断”开始。对产品经理而言，真正需要设计的不是一套复杂的爬虫程序，而是一套能够回答抓了什么、是否抓对、何时有效、出了问题谁处理的质量方案。

一、先讲核心结论：质量校验不是验收附加项

1. 抓取成功与数据可用是两件事

抓取成功通常只说明请求完成、解析程序运行结束，或者系统拿到了某个页面的返回内容。它不代表字段含义正确，也不代表数据符合业务口径，更不代表下游报表、选品模型或价格策略可以直接使用。

产品经理应该把“任务成功”拆成四个彼此独立的判断：

• 有没有采集到：任务是否执行、页面是否访问成功、记录数量是否达到合理范围。
• 字段是否完整：商品 ID、标题、价格、店铺、状态、采集时间等关键字段是否缺失。
• 含义是否正确：价格是页面价、活动价还是券后价，销量是累计销量还是近期销量，库存是精确值还是“有货”状态。
• 数据是否仍然有效：采集时间是否满足业务要求，旧数据是否被错误地当成当前数据。

这四个判断中，第一项最容易被监控系统捕捉，后面三项却更容易造成隐蔽损失。一个商品列表有 10 万条记录，并不意味着它能用于竞品排名；如果其中 20% 的价格口径不一致，数量越大，错误扩散得越快。

2. 质量目标要服务于业务决策

数据质量指标不能脱离使用场景。一个商品详情页中的“评价数”对竞品舆情分析很重要，但对只关注价格波动的项目可能只是辅助字段；商品图片缺失对商品主数据管理可能是阻断问题，对每日价格监测却可能只是提示问题。

因此，产品经理不能直接复制一套通用阈值，而要先回答三个问题：

1. 这个字段会被谁使用，最终影响什么决策？
2. 字段出错时，业务能否通过其他来源或人工方式修正？
3. 错误的成本是暂时少一条数据，还是会导致整批分析结论失真？

如果价格字段用于自动调价，错误价格可能直接造成经营损失，应设置更严格的阻断规则。如果价格只是用于人工参考，可以将少量异常放入待复核队列，避免因个别特殊促销页面阻断整批数据。

3. 产品经理的核心产出不是“爬虫需求”，而是“正确数据定义”

研发可以解决页面访问、接口调用、解析和入库问题，但“什么才算正确”必须由产品经理组织业务共同定义。PRD 中写“抓取商品价格”远远不够，至少要补充价格来源、价格类型、单位、币种、促销状态、采集时间和异常处理。

我通常把质量方案压缩成一句验收口径：关键字段必须可追溯，业务含义必须可解释，异常记录必须可处理，历史数据必须可比较。这四点比单纯写一个“完整率达到 99%”更有指导价值。

二、背景和真实场景：为什么电商抓取特别容易“看起来正确”

1. 同一个页面可能同时存在五种价格

电商页面经常同时展示原价、划线价、当前售价、活动价、会员价和领券后价格。不同平台、不同活动、不同登录状态下，页面展示内容还可能发生变化。采集程序只要选错一个 DOM 节点，最终就可能稳定地抓错价格。

这类错误最麻烦的地方是，它通常不会触发程序异常。系统拿到了一个合法的数字，例如 199 元；但业务真正想要的是券后 159 元，或者统一比较口径下的活动价 179 元。数字本身没有坏，坏的是数字的业务含义。

在价格监测项目中，我建议产品经理不要使用“商品价格”这种模糊字段，而是至少拆成以下字段：

2. SPU、SKU 和平台商品 ID 不等价

商品主数据项目中，最常见的结构性错误不是漏抓，而是把不同层级的数据强行合并。一个商品 SPU 下可能有多个 SKU，不同颜色、容量、套餐和规格对应不同价格与库存。如果产品经理只要求“按商品去重”，研发很可能用商品标题或详情页链接去重，导致多规格商品被合并。

正确做法是先定义业务主键。平台商品 ID 通常用于识别平台上的商品实体，SKU ID 用于识别具体规格，内部商品 ID 则用于跨平台归一化。三者可以关联，但不应该互相替代。

例如，同一款 500 毫升洗发水有单瓶、两瓶装和家庭装。它们的标题高度相似，甚至共用详情页，但价格、库存和促销条件完全不同。如果用标题去重，系统可能只保留其中一个价格，后续的竞品比较和毛利分析都会失真。

3. “销量”可能只是页面上的一段文本

销量字段看起来比价格简单，实际却存在“1000+”“近 30 天售出 5000 件”“已售 10 万+”等多种表达。产品经理需要确认采集结果应保存原始文本、标准化数值，还是两者都保存。

我的建议是同时保留三个字段：原始销量文本、标准化销量值、标准化规则版本。这样当业务方质疑“为什么这个商品销量变少了”时，可以追溯是页面展示变化，还是解析规则变化。

“1000+”不应被直接存成 1000 并假装精确。更稳妥的方式是将它存为区间、下限值或带精度标识的估算值。数据模型必须诚实地表达不确定性，而不是用一个看似精确的整数掩盖页面本身的模糊表达。

4. 下架、无货和页面异常不是同一种状态

商品页面打不开，不一定代表商品下架；页面显示“暂时无货”，也不一定代表商品已经下架；平台触发访问限制时，返回的可能是一个结构完整但内容为空的页面。若产品经理只设计“在售”和“下架”两个枚举，系统很容易把技术异常误判成商品状态。

至少建议区分：在售、有货、无货、已下架、页面不可访问、解析失败、状态未知。状态未知是很重要的保护性状态，它可以避免系统在证据不足时做出过度判断。

三、常见误区：这些验收方式会让项目进入假稳定

1. 误区一：只看任务成功率和入库条数

任务成功率适合衡量系统运行情况，不适合单独衡量数据质量。入库条数也只是数量指标，无法说明记录是不是重复、字段是不是错位、价格是不是抓错。

更危险的是，数量可能在页面结构变化后仍然保持稳定。例如页面中商品卡片的标题节点没有变化，但价格节点已经从页面价切换成划线价。程序仍然能找到价格元素，记录数也没有减少，监控系统就会认为一切正常。

产品经理至少要同时看四类指标：任务状态、记录数量、关键字段质量、抽样语义正确率。前两类发现“有没有运行”，后两类才判断“是否值得使用”。

2. 误区二：把非空率当成完整率

一个字段有值，不等于字段完整。例如价格字段抓到了“到手价 159 元”，但系统要求的是页面活动价；商品标题有值，但被截断到只剩下“新款夏季”；采集时间有值，但记录的是入库时间而不是实际采集时间。

因此，完整性应至少拆为字段存在、字段格式、字段长度和字段业务可解释性四个层次。非空率只能覆盖第一层，不能代替其他校验。

3. 误区三：用一个阈值管理所有字段

“所有字段完整率必须达到 99%”听起来很专业，实际可能不适用。商品 ID 缺失 1% 可能已经导致数据无法去重，图片链接缺失 5% 也许并不影响价格分析，评价标签缺失 10% 则要看业务用途。

质量阈值应按字段重要性分级。关键主键、价格、采集时间和商品状态通常属于高优先级字段；图片、卖点文本和推荐标签可以根据场景设为中优先级或低优先级。

4. 误区四：把异常数据直接删除

删除异常数据会让主表看起来更干净，却会损失问题证据。后续研发无法判断异常是页面变化、解析错误、网络失败还是业务本身的特殊情况。

更好的做法是将原始数据、清洗后数据和异常记录分层保存。业务使用层可以过滤异常，但原始层和异常层必须保留足够的追溯信息，包括来源链接、采集时间、规则版本、错误类型和处理结果。

5. 误区五：抽查几个商品就宣布上线

抽样检查是必要的，但抽样方法不合理时，很容易得到虚假的安全感。只抽查搜索结果第一页、只抽查普通商品、只抽查没有促销的商品，无法覆盖真正高风险的场景。

抽样应覆盖不同平台、类目、价格区间、促销状态、商品状态和页面模板。新接入平台或刚改过解析规则时，抽样比例应明显高于稳定运行阶段。

6. 误区六：只设计发现异常，不设计处理异常

“发现价格缺失后发送告警”并不是完整方案。告警发给谁、是否自动重试、重试几次、是否阻断入库、业务能否继续使用、修复后如何补数，这些都必须写清楚。

如果异常没有负责人和关闭标准，告警数量越多，团队越容易产生告警疲劳。最终大家会把告警当成背景噪音，真正严重的问题反而被忽略。

四、专业判断逻辑：先分层，再定规则和动作

1. 第一步：建立“业务用途，字段，风险”关系

我在设计抓取质量方案时，不会先从字段列表开始，而会先问业务最终要做什么。如果用途是价格监测，价格、商品 ID、SKU、采集时间和促销状态是核心；如果用途是商品主数据管理，标题、品牌、类目、规格和图片完整性的重要性会明显上升。

可以使用下面的判断表将字段分成三类：

字段分级的价值在于，它让团队可以在数据不完美时做出有依据的取舍，而不是陷入“所有字段都必须绝对正确”的不现实要求。

2. 第二步：把质量目标拆成四个维度

完整性回答“应该有的数据有没有”。它包括关键字段非空、记录数量合理、批次没有大面积缺失，也包括分页是否完整、店铺和类目是否出现整段消失。

准确性回答“拿到的值是不是原本的值”。这不仅是字符层面的准确，也包括价格类型、销量口径、商品状态和规格关系的准确。

一致性回答“不同时间、不同平台或不同来源的数据能不能比较”。金额单位、时间时区、类目编码、状态枚举和 SKU 关系都属于一致性问题。

时效性回答“数据在业务使用时是否还有效”。日更项目关注是否按时完成，实时预警项目则要关注延迟、重试耗时和最后成功时间。

这四个维度不应简单加总成一个总分。一个批次即使整体质量评分为 95 分，只要价格字段发生大面积口径错误，也不能直接交付给调价系统。

3. 第三步：区分阻断型、告警型和观察型规则

阻断型规则适合处理无法安全使用的数据。例如商品主键为空、价格为负数、采集时间缺失、数据来源无法确认，或者关键字段整体解析失败。阻断的目的不是追求零异常，而是防止错误数据进入下游。

告警型规则适合处理数据可能有问题、但仍需要结合上下文判断的情况。例如单个店铺商品数下降 30%、某类目价格整体上涨、少量商品缺少图片或销量文本发生变化。

观察型规则适合记录低风险变化。例如某些标题出现格式调整、非核心标签缺失、少量字段长度变化。观察型规则也要保留统计趋势，否则低风险问题可能逐步积累成高风险问题。

4. 第四步：给每条规则绑定证据

没有证据来源的规则，很容易在评审时变成个人偏好。比如“价格波动超过 20%就告警”，产品经理需要说明这个阈值来自历史波动、业务容忍度，还是仅仅来自经验。

常见证据包括：

• 历史数据分布：查看过去 30 天或 90 天的正常波动范围。
• 业务规则：例如促销期允许价格快速变化，但非促销期不应频繁跳变。
• 来源页面证据：保存页面截图、原始文本或结构化响应，便于比对。
• 下游影响：明确异常会影响报表、预警、调价还是人工浏览。
• 人工抽样结果：用一定数量的原页面核对结果验证规则。

5. 第五步：为异常设计闭环，而不是只设计一个告警按钮

完整闭环至少包含发现、记录、通知、处理、复核和复盘六个环节。产品经理要让研发和数据团队知道异常发生后系统要做什么，而不是只留下“出现异常时提醒”的模糊描述。

1. 系统识别异常，并生成唯一异常编号。
2. 记录平台、商品、字段、批次、规则版本和原始证据。
3. 按照严重程度通知负责人或进入异常队列。
4. 执行自动重试、降级、隔离或人工复核。
5. 修复后重新采集或重新计算，并核验结果。
6. 关闭异常并记录根因，必要时更新规则和测试样本。

五、具体案例：以商品价格监测项目为例拆解检查点

1. 项目背景与目标

下面使用一个脱敏后的价格监测场景进行说明。某团队需要每日采集多个电商平台的重点商品，用于竞品价格对比、促销跟踪和运营人员人工复核。项目第一阶段覆盖 8 个类目、约 2.4 万个商品实体，每日计划采集一次，促销期间对重点商品增加采集频率。

这里的数字是情景模拟数据，用于展示产品方案如何落地，不代表任何平台的公开统计。之所以采用这个规模，是因为它足以呈现批量采集中的分页、SKU、促销和异常处理问题，又不会掩盖规则细节。

如果团队使用九数云等数据分析工具承接后续分析，产品经理更应该提前把字段口径和数据层级定义清楚。分析工具可以帮助团队观察价格趋势、类目分布和异常波动，但不能替代采集端对原始字段含义的确认。九数云官网可作为后续数据分析与可视化环节的了解入口，但采集质量仍需在源头和入库环节完成治理。

2. 先建立商品主键关系

案例中，平台商品 ID 用于识别平台商品，SKU ID 用于识别具体规格，内部标准商品 ID 用于跨平台归一化。一个平台商品可以对应多个 SKU，一个内部标准商品也可能对应多个平台商品，但这种映射必须有明确的维护规则。

建议在数据模型中至少保存以下字段：

3. 再定义价格字段和转换逻辑

案例中的业务方最初只提出“每天抓商品价格”。经过评审后，团队将价格拆成页面展示价、活动价、券后价、币种、价格单位和价格状态。对于无法确认价格类型的页面，系统不得直接把数值写入统一比较价。

统一比较价的计算过程必须可追溯。例如：

{
"display_price": 199.00,

"promotion_price": 179.00,

"coupon_price": 159.00,

"comparison_price": 179.00,

"price_type": "promotion_price",

"currency": "CNY",

"price_captured_at": "2026-09-13T10:30:00+08:00",

"rule_version": "price_rule_v3"

}

这个示例的关键不在 JSON 格式，而在于不要只留下一个 179 或 159。如果未来业务改变比较口径，保留原始价格和规则版本，才能重新计算历史数据；如果只保存最终价格，团队就必须重新访问历史页面，而历史页面通常已经变化或不可访问。

4. 设置字段级质量规则

案例中可以将规则分为结构校验、业务校验和跨批次校验。结构校验处理字段是否存在，业务校验处理字段含义是否合理，跨批次校验处理整体趋势是否异常。

5. 用跨批次波动发现“静默错误”

静默错误是最值得产品经理重视的一类问题。它不会让程序报错，也不会让记录数归零，却会导致结果逐渐偏离真实情况。例如某平台更换页面结构后，价格节点仍然存在，但取到的都是划线价。

跨批次监控可以从以下角度发现问题：

• 全量商品数较过去 7 天均值下降多少。
• 各平台、店铺和类目的商品量是否同步下降。
• 价格为空比例是否突然上升。
• 价格为整数、带小数或极端值的比例是否发生变化。
• 在售、无货和下架状态的分布是否出现异常跳变。
• 相同商品的价格变动是否集中发生在同一采集批次。

6. 设计抽样方案，而不是随意抽几个样本

案例中可以将每日抽样分成固定样本和风险样本。固定样本用于观察长期稳定性，风险样本用于覆盖高价商品、促销商品、近期规则异常商品、新接入店铺和多 SKU 商品。

一个可执行的起步方案是：

1. 每个平台固定抽取 20 个商品，连续观察一周。
2. 每个平台再抽取 20 个风险商品，包括促销、无货、多 SKU 和高波动商品。
3. 规则变更后的前三个采集批次，将抽样数量提高到平时的 2 至 3 倍。
4. 发现同类错误后，不只复核单条记录，而要扩大到同一页面模板、店铺或类目。

抽样结果要记录字段级结论，而不是只写“抽样通过”。建议记录原页面值、系统值、差异类型、是否影响业务、处理结果和规则版本。这样抽样才会从一次性验收变成持续的质量证据。

六、把方案写进 PRD：产品经理可直接使用的结构

1. 先写业务目标和数据范围

PRD 开头不要直接进入技术实现。先明确数据用于什么业务、覆盖哪些平台和类目、采集频率是什么、结果由谁使用，以及哪些数据不在本期范围内。

例如：

• 业务目标：每日监测重点商品的统一比较价与促销状态。
• 覆盖范围：指定平台、指定店铺、指定类目和商品清单。
• 更新频率：普通商品每日一次，重点促销商品按业务需要提高频率。
• 使用方式：供人工分析、报表和价格异常提醒使用，不直接驱动自动调价。
• 本期不包含：未授权的登录后数据、个人信息和无法确认来源的数据。

特别要写清“不直接驱动自动调价”这类边界。它会直接影响质量阈值、异常处理和上线策略。如果未来要接入自动决策系统，必须重新评估质量标准，不能默认沿用人工分析项目的规则。

2. 用字段定义表替代模糊描述

3. 写清验收标准，而不是只写“功能完成”

验收标准要能让产品、研发、数据和业务共同判断结果是否达标。可以按“上线前验收”和“运行中监控”分开写。

上线前验收：

• 业务已确认价格、销量、库存和状态的定义。
• 核心字段均有来源说明和异常处理方式。
• 商品 ID、SKU ID 和内部标准商品 ID 的关系能够追溯。
• 抽样记录已与来源页面完成逐字段比对。
• 页面不可访问、解析失败和状态未知能够区分。
• 原始数据、清洗数据和异常记录具备查询路径。

运行中监控：

• 任务执行状态和最后成功时间可查询。
• 批次记录量能够与历史基线对比。
• 核心字段缺失率能够按平台、类目和店铺拆分。
• 异常达到阈值时能够通知指定负责人。
• 失败批次具备重试、补采或人工处理流程。
• 规则变更后能够执行回归抽样并保留结果。

4. 为规则设置版本和变更记录

价格解析、状态识别和类目映射都会发生变化。如果系统只保存最新规则，后续很难解释历史数据为什么改变。建议为关键规则设置版本号，并在数据记录中保存使用的规则版本。

规则变更记录至少包含变更原因、影响范围、上线时间、测试样本、预期变化和回滚方式。产品经理不需要编写全部技术细节，但必须推动这些信息进入项目文档，否则每次页面变化都会变成临时救火。

七、不同情况下的行动建议：不要用同一套方式处理所有异常

1. 发现单条商品关键字段缺失

如果只是单条商品缺少图片、卖点或非核心标签，可以保留记录并进入提示队列。但如果缺少商品 ID、采集时间或主价格，就不应直接进入业务主表。

建议动作是：

1. 保留原始记录和来源链接。
2. 标记具体缺失字段，而不是笼统标记“数据异常”。
3. 根据字段级别决定隔离、重试或降级。
4. 统计同一平台、类目和页面模板是否存在同类问题。

2. 发现一批数据量突然下降

不要立刻认定平台页面减少了商品。先检查任务是否只采集到第一页、分页是否中断、访问是否被限制、筛选条件是否变化，以及是否误把状态未知的商品过滤掉。

如果下降集中在某一个平台或类目，优先查看页面模板和请求链路；如果所有平台同时下降，优先查看调度、网络、公共依赖和上游商品清单。问题定位顺序应从范围最小、证据最直接的环节开始。

3. 发现价格整体上涨或下降

整体变化可能是真实促销，也可能是解析口径变化。产品经理应同时对比促销状态、价格类型分布、原始价格文本和历史采集批次。如果所有商品都在同一时间以相似幅度变化，尤其要警惕字段节点变化或单位转换错误。

在没有完成抽样核对前，不建议直接把价格趋势发布给业务方。可以先将结果标记为“待确认”，或者只展示已通过质量校验的商品集合。

4. 发现平台页面结构发生变化

页面结构变化是抓取项目的常态，不应被当作偶发事故。处理时需要冻结受影响批次，保留变化前后的样本，并比较字段缺失率、值分布和页面截图。

修复后不能只验证一个商品。应覆盖不同商品卡片、详情页模板、促销状态和 SKU 结构，完成回归抽样后再恢复正常发布。

5. 数据需要进入自动决策系统

如果数据只供人工查看，少量低风险异常可以通过提示和人工复核处理；如果数据将驱动自动调价、库存补货或投放策略，质量方案必须升级。

自动决策场景通常需要：

• 更严格的核心字段阻断规则。
• 更短的异常发现和处理时限。
• 历史版本和原始证据的完整留存。
• 异常时的安全降级策略。
• 人工审批或二次校验机制。
• 明确的责任边界和审计记录。

八、不同情况下的取舍：质量、时效、覆盖率和成本如何平衡

1. 要不要追求全量覆盖

全量覆盖听起来最理想，但在平台限制、页面变化和采集成本都存在的情况下，盲目追求全量可能降低整体稳定性。对于重点商品监测，可以优先保证核心商品、重点店铺和高风险类目的准确率，再逐步扩展覆盖范围。

如果业务的主要目标是发现价格趋势，稳定覆盖 80% 的重点商品可能比覆盖 100% 但质量波动很大的商品更有价值。产品经理应把“覆盖率”和“可用率”分开汇报，不能用覆盖率掩盖错误率。

2. 要不要阻断整批数据

整批阻断可以保护下游，但也可能因为少量异常导致业务无法使用。是否整批阻断，取决于异常范围、字段重要性和业务替代方案。

3. 要不要保存全部原始数据

保存原始数据会增加存储和管理成本，但对解析规则迭代、异常复盘和争议处理非常有价值。我的建议不是无限保存所有内容，而是根据字段重要性设置分层留存。

• 核心字段：保留原始值、标准值、规则版本和采集时间。
• 关键异常：保留原始页面证据、错误日志和处理结果。
• 普通字段：保留必要的原始文本，设置合理留存期限。
• 敏感或不必要的信息：不采集，或在进入分析层前完成脱敏。

数据留存还要考虑平台规则、权限、访问频率和使用范围。公开可见不等于可以无限制采集和长期保存，产品方案必须把合规边界放在技术可行性之前。

4. 要不要投入自动化质量平台

当项目只有少量商品、低频采集且主要供人工查看时，使用表格、抽样清单和基础告警也许足够。随着平台、商品和采集频率增加，人工核对会迅速失控，这时应投入自动化校验、异常队列和质量看板。

可以按照三个阶段推进：

1. 起步阶段：先建立字段字典、人工抽样表和核心异常清单。
2. 扩展阶段：将非空、类型、范围、重复和批次波动检查自动化。
3. 规模阶段：增加规则版本、异常闭环、历史趋势、跨平台对比和质量评分。

不要一开始就建设复杂平台，却没有确定业务口径。自动化只能放大明确的规则，也会放大模糊的规则。先把最容易造成误判的价格、主键、状态和时间定义清楚，再决定工具投入。

九、如何用数据观察验证质量，而不是靠感觉

1. 建立最小质量看板

质量看板不必一开始就做得复杂。对大多数入门项目，先展示以下指标就能发现大量问题：

• 任务成功率与最后成功时间。
• 每批次原始记录数和有效记录数。
• 核心字段缺失率。
• 重复记录率与主键异常率。
• 价格口径分布和价格异常率。
• 在售、无货、下架和未知状态占比。
• 抽样正确率和未关闭异常数。
• 从异常发现到处理完成的平均时长。

这些指标应支持按平台、店铺、类目、采集任务和日期筛选。只看全量平均值会掩盖局部问题，例如某平台整体只占 10% 的数据量，但它可能承担了业务最重要的高端类目。

2. 不要只看平均值，要看分布和尾部

平均价格波动、平均缺失率和平均处理耗时都可能掩盖极端情况。一个平台的平均缺失率是 2%，并不代表每个店铺都稳定；有可能 90% 的店铺缺失率接近 0%，另有 10% 的店铺接近 20%。

因此，建议同时查看中位数、最大值、分位数和异常集中区域。对于价格监测，还可以观察同一商品连续多次采集的价格轨迹，而不是只看当天平均价格。

3. 用“业务可用率”替代单一完整率

业务可用率可以定义为：在指定时间窗口内，同时满足核心字段完整、口径可解释、主键可关联且数据未过期的记录，占原始目标记录的比例。

这个指标不应直接作为跨项目排名工具，而应作为当前项目的运行参考。它能够帮助产品经理解释为什么原始采集 2.4 万条，最终可用于分析的是 2.16 万条，也能进一步追踪损耗发生在哪个环节。

十、下一步怎么做：从一张检查表开始

1. 第一天：先确认四个业务口径

不要先找工具，也不要先讨论页面解析技术。先召集业务、数据和研发确认商品主键、价格口径、状态枚举和采集时间。只要这四件事没有明确，后续所有完整率和准确率都缺乏判断基础。

2. 第二天：给字段分级并写异常动作

把字段分成核心、重要和辅助三类。每个核心字段都要写清非空规则、格式规则、业务规则、异常等级和处理负责人。不要只写“发现异常后告警”，要写清楚是否阻断、是否重试、是否隔离和如何恢复。

3. 第三天：准备一组有代表性的样本

样本不能只选正常商品。至少加入促销商品、多 SKU 商品、无货商品、下架商品、价格带小数的商品、标题较长的商品和页面结构不同的商品。每条样本都应有来源页面和人工确认结果。

4. 上线前：完成四道质量门禁

1. 业务口径已确认，字段字典已冻结。
2. 关键规则已实现，异常记录能够被隔离。
3. 样本已逐字段核对，问题有修复记录。
4. 监控、告警、重试和补采流程已经演练。

5. 上线后：用前两周建立真实基线

很多阈值不能在项目开始时凭空确定。上线后的前两周，可以观察各平台、店铺和类目的正常数据分布，再调整批次波动、价格变化和缺失率的告警阈值。阈值应该随着业务和平台变化迭代，而不是永久写死。

同时，建议每周复盘一次异常：哪些是页面变化，哪些是规则错误，哪些是业务口径不清，哪些是可以通过自动化提前发现的问题。复盘结果要回写到字段字典、样本集和验收标准中。

十一、结语：真正成熟的抓取项目，敢于说“这批数据暂时不能用”

电商数据抓取的专业性，不体现在抓取工具有多复杂，也不体现在每天入库了多少条记录，而体现在团队能否准确区分“有数据”“有正确数据”和“有可以支撑决策的数据”。

产品经理最应该建立的，不是一张永远追求 100% 的指标表，而是一套有业务边界的判断系统：核心字段出错时阻断，局部问题发生时隔离，低风险变化持续观察，所有关键结论都能回溯到来源、时间和规则版本。

如果你现在正准备启动一个电商数据抓取项目，下一步可以直接做三件事：先写出价格、主键、状态和时间的字段定义；再为每个核心字段指定校验动作和异常负责人；最后用 20 至 50 个包含促销、SKU、下架和无货场景的真实样本完成一次逐字段核对。

先把“什么是正确数据”说清楚，再讨论如何抓取；先让异常可被发现和解释，再追求更高的覆盖率。这通常比一开始投入更多采集任务、更多接口和更多报表，更能决定电商数据项目最终是否真正可用。

免费注册

咨询方案

扫码咨询方案