在电商数据抓取项目中，最容易被低估的成本，不是请求发送失败，也不是解析器偶尔报错，而是数据“看起来抓到了、实际上用不了”。我曾见过一批商品数据：价格字段里同时出现“￥1,299”“券后价”“到手价”，销量字段里混着“已售10万+”和“近30天售出”，库存字段则把“有货”“仅剩少量”“预售”全部当成文本保存。采集任务显示成功，真正进入分析环节后，却需要开发人员连续几天补清洗规则。
电商数据抓取的核心，不是把页面内容搬进数据库，而是在采集入口建立一份能被下游理解的数据契约。
开发人员通常先看请求成功率、页面解析成功率和任务完成率。这些指标当然重要，但它们只回答了“数据有没有被拿回来”，没有回答“拿回来的数据能否参与计算、比较和行动”。如果一条记录成功入库，却因为价格类型不明、时间口径不清、销量无法量化而被分析系统丢弃，那么这条记录对业务的价值仍然接近于零。
我更愿意把采集结果拆成四层：请求成功、字段提取成功、字段标准化成功、业务动作可执行。前两层属于技术完成度，后两层才决定数据产品是否真正可用。例如，商品页面提取到“券后￥1299”，只能说明文本被识别；只有当系统同时知道它是促销后价格、币种为人民币、采集时间是什么时候，并能和历史价格比较时，它才具备业务价值。
| 层级 | 核心问题 | 常见判断指标 | 失败后的表现 |
|---|---|---|---|
| 请求层 | 页面或接口是否返回 | 请求成功率、超时率 | 任务直接失败 |
| 提取层 | 目标字段是否被识别 | 字段提取率、选择器命中率 | 字段缺失或空值增加 |
| 标准化层 | 字段能否被统一计算 | 类型转换成功率、单位一致率 | 清洗脚本分支变多 |
| 行动层 | 能否触发业务判断 | 预警命中率、报表可用率 | 分析结果延迟或无法执行 |
这四层中，最常被忽略的是标准化层。很多团队把它当成数据分析师的后置工作，结果是每个报表、每个项目、每个分析人员都重复处理一遍价格、时间和状态。字段设计的价值，就是把一次性的清洗规则前移为可复用的数据结构。
一次性清洗几十万条数据，可能只需要一个脚本；但电商数据每天都在变化，页面结构、促销方式、商品属性和平台展示口径都会变化。更高昂的成本往往来自重复返工：同一个价格字段被不同任务分别解析，同一个“已售10万+”被不同团队解释成不同数值，页面改版后多个报表同时失效。
因此，评估字段设计是否有效，不能只问“这次清洗花了几小时”，还要观察后续三件事：新增平台时是否需要复制大量规则，页面变更后是否能快速定位影响字段，业务人员提出新分析需求时是否能直接复用标准字段。如果每次都从原始文本开始处理，系统就会不断积累隐形债务。
字段名只是数据契约的表面。完整的契约还应说明字段的业务含义、类型、单位、必填性、来源、时间语义、允许值、异常处理方式和版本。比如“price”这个字段看似清楚，实际上可能代表页面原价、实时售价、促销价、会员价、券后价或含税价。没有口径说明，字段名越简洁，误用风险反而越高。
我在设计字段时会先问一个问题：这个字段最终要支持什么动作？如果要做价格预警，就必须保存可比较的数值、价格类型、采集时间和历史版本；如果要做商品详情展示，原始文本可能更重要；如果要做跨平台比价，还需要规格、单位和商品匹配关系。用途不同，字段结构就不应强行共用。
电商页面并不是为数据分析设计的，它首先服务于消费者展示和转化。价格可能需要突出优惠，销量可能需要制造社会证明，库存可能需要营造紧迫感，规格则可能随着类目变化。页面上的文字是给人看的，不是给数据库直接计算的。
例如，以下四种内容都可能表达价格，但它们的业务含义完全不同：
如果解析器只保留一个名为 price 的数值，开发人员看似完成了结构化，实际上把多个价格语义压扁了。后续分析无法判断不同商品的价格是否处于同一口径，预警系统也可能因为价格类型变化产生大量误报。
电商数据抓取中最危险的主键错误，是把商品链接或商品名称当成唯一标识。一个商品可能有多个 SKU，不同颜色和容量对应不同价格与库存；同一个商品链接还可能因为活动参数、渠道参数或页面跳转发生变化。商品名称则更不稳定，商家可以随时修改标题，甚至在标题中加入促销词。
至少要区分以下对象：
| 对象 | 建议标识 | 主要用途 | 容易犯的错误 |
|---|---|---|---|
| 商品 SPU | 平台商品 ID | 商品级趋势、详情聚合 | 把商品名称当主键 |
| SKU | 平台 SKU ID | 规格级价格、库存、销量 | 把多个规格合成一条记录 |
| 店铺 | 平台店铺 ID | 商家维度分析 | 只保存店铺名称，不保存稳定 ID |
| 采集事件 | source_id + collected_at | 历史追踪和回溯 | 覆盖旧值，失去时间序列 |
如果业务只关心商品列表展示，SPU 级别可能足够；如果业务要监控某个容量或颜色的价格，SKU 级别就是必要的。数据粒度不明确，是比字段命名不规范更严重的问题。
页面改版本身并不可怕，可怕的是系统没有告诉你哪个字段受到了影响。某个平台把价格从 HTML 文本改成异步接口返回，可能导致价格字段全部为空；如果没有完整性检查，任务仍然会显示成功，直到运营发现价格趋势图突然变成一条直线。
我建议为每个关键字段增加三个辅助信息：来源定位、解析版本和质量状态。来源定位用于追查数据来自哪个页面区域或接口；解析版本用于判断哪一版规则生成了数据；质量状态则用于区分正常、缺失、解析失败和口径不确定。这样，页面变化才不会被隐藏在一批“看起来正常”的空值里。
“已售10万+”不是精确销量，而是一个下限或区间表达。若系统直接保存为100000，后续人员很容易误以为这是精确数值。类似地，“好评率98%”可能经过平台聚合、时间窗口处理或展示四舍五入，不一定能与另一个平台的评分直接比较。
更稳妥的字段设计是同时保存原始表达、标准化结果和确定性标记。例如，销量可以拆成 sales_raw、sales_value_min、sales_value_max 和 sales_is_exact。当平台只给出“10万+”时，系统可以保存下限100000，并明确标注它不是精确值，而不是假装获得了一个不存在的真实销量。
为了让下游使用方便，有些团队会在采集阶段直接覆盖原始文本。例如，把“券后￥1,299.00”转换为1299后只保存一个 price 字段。这种做法短期看起来很干净，长期却不利于回溯。出现异常时，开发人员无法判断是页面原文变化、解析规则错误，还是转换逻辑丢失了信息。
正确做法不是原始值和标准值二选一，而是分层保存。原始字段负责可追溯，标准字段负责计算，派生字段负责业务动作。三者可以在同一张宽表中实现，也可以拆到原始层、标准层和应用层，但不能把所有语义压缩成一个值。
空字符串看似统一，实际上掩盖了多种完全不同的情况。商品没有库存字段、页面没有展示库存、请求超时导致未抓取、解析规则失效，这四种情况都不能被写成同一个空字符串，否则质量监控无法定位问题。
| 状态 | 业务含义 | 建议存储方式 | 是否可直接参与统计 |
|---|---|---|---|
| 不存在 | 该商品或类目没有这个属性 | null + absent | 通常不可作为零值 |
| 未展示 | 页面没有提供该信息 | null + not_displayed | 需要排除或单独统计 |
| 解析失败 | 页面有内容但规则未识别 | null + parse_failed | 不可直接使用 |
| 请求失败 | 本次没有获得有效页面 | null + request_failed | 应进入重试流程 |
| 未知 | 内容存在，但语义无法确认 | 原始值 + unknown | 只能谨慎使用 |
数据标准化的目标是可比较，不是制造虚假的精确。把“1万+”直接转换为10000，把“约两小时发货”转换为2，把“少量库存”转换为1，都可能让报表看起来更整齐，却损害决策可靠性。
我会把字段分成三类：可精确转换、可区间转换、只能保留文本。金额、评分和明确数量通常属于第一类；“10万+”属于第二类；“近期热销”“少量库存”则可能属于第三类。对第二类字段，应保存区间边界和确定性；对第三类字段，应建立状态枚举，而不是随意赋值。
字段字典如果只有字段名和类型，仍然不足以保障质量。价格是小数并不代表它合理，库存是整数也不代表它代表真实库存。数据质量需要同时包含格式校验和业务校验，例如促销价通常不应高于原价，评分通常应处于约定范围，采集时间不能晚于入库时间。
校验规则最好与字段定义放在同一份配置中，而不是散落在多个脚本里。这样，开发、数据分析和运营对字段口径的理解才会一致，字段变更时也能明确知道哪些报表和任务需要同步修改。
抓取几十个字段并不意味着系统更专业。字段越多，解析维护、存储、质量检查和平台差异处理的成本越高。如果这些字段没有明确的使用场景，最后只会形成难以维护的“字段墓地”。
更好的方式是建立字段优先级：关键字段支持核心行动，辅助字段支持解释和诊断，探索字段暂时保留在原始层。新增字段前先回答三个问题：谁会使用、用于什么判断、缺失后是否影响业务动作。无法回答的问题，通常不值得立即加入标准层。
我通常不会从“页面上能抓到什么”开始设计，而会先列出系统需要支持的动作。例如，价格监控要发现异常降价，库存预警要发现连续缺货，竞品分析要比较相同规格的价格和评价，选品分析要观察类目、销量和价格带。每个动作都对应一组最小字段集合。
| 业务动作 | 最低字段集合 | 关键口径 | 最容易误判的地方 |
|---|---|---|---|
| 价格异动预警 | 商品ID、SKU、价格值、价格类型、采集时间 | 比较同一价格类型 | 把券后价与日常售价直接比较 |
| 连续缺货提醒 | SKU、库存状态、采集时间、连续次数 | 按采集时点判断 | 把页面未展示库存当成缺货 |
| 竞品价格带分析 | 品牌、类目、规格、单位价格 | 先解决商品可比性 | 忽略规格导致低价假象 |
| 评价趋势分析 | 评价数、评分、评价时间、统计口径 | 区分累计值与周期值 | 把累计评价数当成新增评价 |
这个方法可以避免“为了抓取而抓取”。如果一个字段无法影响任何判断，也无法帮助解释异常，它就不一定需要在标准层中占据位置。
三层字段设计是降低清洗成本的关键。原始字段尽量忠实保存页面或接口返回内容，不追求直接计算；标准字段负责类型、单位和基础语义统一；派生字段则根据标准字段计算出预警、区间、变化率和质量标签。
{
"product_id": "P10086",
"sku_id": "SKU-RED-256",
"price_raw": "券后￥1,299.00",
"price_value": 1299.00,
"currency": "CNY",
"price_type": "coupon_after",
"sales_raw": "已售10万+",
"sales_value_min": 100000,
"sales_value_max": null,
"sales_is_exact": false,
"stock_raw": "仅剩少量",
"stock_status": "low_stock",
"collected_at": "2026-09-13T09:30:00+08:00",
"parser_version": "product_parser_v3",
"quality_status": "valid_with_uncertainty"
}
这里最重要的不是字段数量，而是每个字段的责任边界。price_raw 负责回溯，price_value 负责计算，price_type 负责解释，collected_at 负责时间定位，quality_status 负责提醒使用者不要过度解读。
字段类型不是数据库层面的形式要求，而是业务规则的第一道门槛。金额应使用数值类型，时间应使用带时区的标准时间，状态应使用枚举或映射表，数量应明确整数或小数。若所有字段都以字符串入库，下游每一次查询都要重新判断格式。
但类型统一必须建立在语义明确的基础上。比如“库存”如果只是页面展示状态，就不应强行定义成整数；“销量”如果是区间表达，就不应只设置一个精确数值字段。先确认字段代表什么，再决定它应该用什么类型。
跨平台分析最常见的错误不是价格解析失败，而是比较对象根本不在同一口径。一个平台按件销售，另一个平台按套销售；一个平台显示含税价，另一个平台显示未含税价；一个平台的重量用克，另一个平台用千克。如果没有单位字段和口径字段，所谓“统一价格”只是把数字放在了一起。
对可能发生单位变化的字段，我建议至少保存标准值、标准单位、源值和源单位。例如规格可以保存 quantity_value=500、quantity_unit=g，同时保留页面原文“500克装”。需要换算时，系统可以基于单位规则生成单位价格；无法确认单位时，则将记录标记为不可比，而不是默默参与排名。
很多系统不愿意保存“不确定”，因为这会让报表看起来不够整齐。但在数据工程中，显式的不确定比虚假的确定更有价值。可以使用 is_exact、confidence_level、quality_status 或区间字段，告诉下游哪些数据可以精确比较，哪些数据只能用于趋势观察。
例如，“已售10万+”可以用于判断商品进入较高销量区间，却不适合与“已售100023件”进行精细排序。字段设计若保留了这种差异，运营人员会知道结论的边界；如果所有数据都被转换成整数，系统会制造不必要的精确感。
九数云更适合作为本文的业务案例，是因为电商数据的价值通常不止停留在数据库中，而要进一步进入可视化分析、经营看板、异常监控和团队协作。对于这类场景，数据是否能被稳定识别、关联和聚合，直接影响分析人员能否快速从数据走到判断。
这里需要说明：下面的数字是示意性情景数据，用于解释字段设计前后的过程差异，不代表九数云官方统计，也不代表任何特定客户的实际结果。案例重点在方法：开发人员如何把采集数据整理成分析平台可以持续使用的数据结构。
假设一个团队每天抓取多个平台的商品价格、销量、库存和评价数据，并将结果交给分析人员。最初的数据可能如下：
{
"商品名称": "某品牌无线耳机 Pro版",
"价格": "券后￥1,299",
"销量": "已售10万+",
"库存": "仅剩少量",
"规格": "黑色/256G",
"更新时间": "昨天",
"店铺": "官方旗舰店"
}
这份数据对人眼是可读的，但对经营分析并不友好。价格类型不清楚，销量不精确，库存不是数量，规格被拼成文本，更新时间也无法转换成明确时间点。若直接导入分析平台，图表可能可以生成，但图表背后的比较逻辑并不可靠。
例如，价格趋势图可能把原价、日常价和券后价连成一条线；销量排行可能把“10万+”统一当作100000；库存预警可能把“仅剩少量”当成库存数量1。图表看起来正常，结论却可能偏离真实业务含义。
在实际项目中，我会把数据拆成至少四类：商品主数据、价格快照、库存快照和质量日志。商品主数据保存相对稳定的商品、品牌、类目和规格；价格快照保存每次采集时的价格；库存快照保存状态和采集时点；质量日志记录字段缺失、解析失败和规则版本。
| 数据表 | 核心字段 | 更新方式 | 适合支持的分析 |
|---|---|---|---|
| 商品主数据 | 商品ID、SKU、品牌、类目、规格 | 变更时更新 | 商品结构、类目分布、规格比较 |
| 价格快照 | 商品ID、价格值、价格类型、采集时间 | 按采集批次追加 | 价格趋势、降价幅度、促销周期 |
| 库存快照 | 商品ID、库存状态、配送状态、采集时间 | 按采集批次追加 | 缺货次数、连续缺货、恢复时间 |
| 质量日志 | 批次、字段、错误类型、解析版本 | 异常时追加 | 数据质量、页面变更、修复优先级 |
这种拆分有一个重要好处：分析平台可以按业务主题取数，而不必每次从一张混杂所有字段的宽表中重新理解数据。价格趋势使用价格快照，商品分类使用主数据，页面改版排查则使用质量日志。不同分析不再重复执行同一套基础清洗。
假设业务动作是“当某 SKU 的标准售价在24小时内下降超过10%，且该价格不是一次性优惠券价格时，通知运营人员”。这个动作至少需要以下字段：
如果采集系统只提供一个 price 字段，分析人员即使在九数云中搭建了趋势图，也无法可靠地判断价格变化是否真实。字段越少不一定越简单，关键是是否包含动作所需的语义。
字段设计不应在开发上线时一次性结束。分析人员使用看板后，往往会暴露出采集阶段没有考虑的问题。例如，运营发现同一商品在不同平台的价格无法比较，原因可能不是价格字段错误，而是规格字段没有拆分；又或者库存预警误报频繁，原因是“预售”和“缺货”被映射成同一个状态。
这时，团队应把分析反馈转化为字段契约的版本变更，而不是在看板中增加越来越复杂的临时公式。比如新增 fulfillment_status 区分现货、预售和缺货，新增 spec_normalized 支持规格匹配，新增 price_eligibility 标记价格是否适合跨平台比较。成熟的数据管道不是不变化，而是变化有记录、有版本、有影响范围。
字段字典应在解析代码之前完成。它不需要一开始就覆盖所有页面字段，但必须覆盖核心业务动作涉及的字段。至少应包含字段名、含义、数据类型、单位、是否必填、来源、空值策略、校验规则和版本。
| 字段 | 业务定义 | 类型 | 必填 | 校验规则 | 空值处理 |
|---|---|---|---|---|---|
| sku_id | 平台规格级稳定标识 | 字符串 | 是 | 同平台内唯一 | 缺失则进入异常队列 |
| price_value | 指定价格类型下的数值 | 小数 | 是 | 大于等于0 | 解析失败不可替换为0 |
| price_type | 原价、售价、促销价等 | 枚举 | 是 | 必须在映射表中 | 无法确认则unknown |
| stock_status | 标准化库存状态 | 枚举 | 否 | 现货、缺货、预售等 | 未展示与解析失败分开 |
| collected_at | 本次数据采集完成时间 | 带时区时间 | 是 | 不得晚于入库时间 | 缺失则整条记录降级 |
字段清洗再完善，如果粒度错了，最终结果仍然不可靠。首先要明确一条记录代表什么：一个商品、一个 SKU、一个店铺，还是一次采集快照。价格和库存通常属于 SKU 与采集时点的组合，而品牌和类目可能属于商品主数据。
推荐使用业务主键与事件时间共同定位记录。例如，价格快照可以使用 platform_id + sku_id + collected_at 作为逻辑唯一组合；若同一时间窗口内可能多次采集，还要增加批次号或采集任务 ID。不要简单使用商品名称覆盖历史记录，否则无法分析价格变化和库存持续时间。
转换成功不应只是一个无声结果。对于每个关键标准字段，可以记录转换状态，例如 valid、missing、parse_failed、ambiguous 和 not_applicable。这样，质量报表可以统计“有多少数据缺失”和“有多少数据虽然存在但无法解释”，两者的修复方式完全不同。
价格转换示例可以采用如下逻辑。这里展示的是字段处理思路，不依赖某个平台的页面结构：
function normalizePrice(rawText, priceType, currency) {
if (!rawText) {
return {
value: null,
status: "missing",
raw: rawText
};
}
const numberText = extractNumber(rawText);
if (!numberText) {
return {
value: null,
status: "parse_failed",
raw: rawText
};
}
if (!currency) {
return {
value: Number(numberText),
status: "ambiguous_currency",
raw: rawText
};
}
return {
value: Number(numberText),
status: priceType ? "valid" : "ambiguous_price_type",
raw: rawText
};
}示例中的重点不是函数名称，而是不要让所有异常都返回0。0可能意味着免费、缺货、未售出或解析失败，直接替换会让错误数据进入统计结果。缺失值、零值和未知值必须保持语义区分。
平台状态不可能天然一致。一个平台写“无货”，另一个平台写“暂时缺货”，还有平台写“预计7天发货”。统一层可以建立标准枚举，但原始状态必须保留，以便后续新增映射或解释异常。
| 平台原始文本 | 标准状态 | 可否触发缺货预警 | 处理说明 |
|---|---|---|---|
| 有货 | in_stock | 否 | 表示页面明确显示可购买或可配送 |
| 仅剩少量 | low_stock | 可选 | 适合做紧张度提醒，不等于真实库存数量 |
| 暂时缺货 | out_of_stock | 是 | 可以进入连续缺货统计 |
| 预售 | pre_sale | 否 | 不能与现货和缺货混为一谈 |
| 未展示 | not_displayed | 否 | 页面没有明确库存信息 |
| 解析异常 | unknown | 否 | 应进入质量处理队列 |
质量检查不应等到报表出现异常后才启动。最少需要设置四类检查：完整性、格式、业务逻辑和变化监控。完整性检查字段是否存在，格式检查类型和范围，业务逻辑检查字段之间是否矛盾，变化监控则关注某个批次与历史基线的差异。
质量检查的输出最好不要只有“通过或失败”，而应包含字段、批次、错误类型、样本值、解析版本和责任人。这样，开发人员可以直接定位问题，分析人员也能判断当前报表是否需要降级使用。
这类项目不必一开始搭建过于复杂的数据平台。优先保证商品或 SKU 主键稳定、价格和库存字段可追溯、采集时间明确，并保留原始值与标准值。只要未来可能做趋势分析，就不要用最新值覆盖历史快照。
建议先完成以下最小闭环：
这一阶段最重要的取舍是：少抓字段，但确保关键字段稳定。比起抓取几十个暂时不用的属性，不如把价格类型、采集时间和 SKU 标识设计准确。
跨平台项目的难点不是把不同来源的数据放到一张表，而是确认它们是否真的可比。商品名称相似不代表规格相同，价格数字相同也不代表含义相同。必须增加平台标识、商品匹配状态、规格标准化字段、币种和单位。
建议把商品匹配单独作为一个关系，而不是在抓取脚本中直接覆盖。匹配结果可以分为 exact、probable、manual_confirmed 和 unmatched。只有达到业务允许的匹配等级，记录才进入价格比较和排行。
| 匹配状态 | 含义 | 适合用途 | 风险 |
|---|---|---|---|
| exact | 平台 ID 或明确型号一致 | 自动比价、价格预警 | 仍需检查包装和单位 |
| probable | 名称、品牌和规格高度相似 | 候选池、人工复核 | 可能存在同名不同规格 |
| manual_confirmed | 业务人员确认过 | 重点商品长期监控 | 需要维护确认关系 |
| unmatched | 暂时无法确定对应关系 | 保留待处理 | 不应直接参与横向比较 |
高频采集项目更需要区分事件数据与当前状态。库存状态必须保留每次采集的时间，否则无法计算连续缺货时长、恢复时间和波动频率。对于高频任务，数据量会快速增长，可以采用明细快照加状态汇总的方式：原始快照用于追溯，汇总表用于看板和告警。
这时，质量告警的优先级也应高于字段数量。一次页面改版造成库存字段全部为空，可能比单个商品采集失败更严重。建议设置字段级空值率阈值，并区分“少量商品缺失”和“整个平台字段失效”。
面向九数云等分析平台时，建议优先提供清晰的主题数据表，而不是把所有原始页面字段直接暴露给分析人员。商品主数据、价格快照、库存快照和质量日志应有明确关联关系，字段名称也应尽量体现业务含义。
可以采用“标准层稳定、应用层灵活”的原则。标准层只放经过确认的核心字段，应用层根据价格监控、库存分析或竞品分析生成不同数据集。这样既避免每个看板重复清洗，也避免为了一个临时报表修改底层采集结构。
小团队不需要一开始实现完整的数据治理体系，但必须做三件事：保留原始数据、保留采集时间、保留质量状态。这三项成本不高，却能显著降低未来排查问题的难度。
如果只能选择一个优先事项，我会选择稳定主键和历史快照。没有主键，无法知道两条记录是不是同一商品；没有历史快照，无法判断价格和库存到底发生了什么变化。字段数量可以逐步增加，数据的可追溯性却很难事后补回。
保留原始值会增加存储，但能够提高可追溯性。对于价格、库存、销量、促销文案等关键字段，我通常建议保留原始文本；对于体积很大的页面内容，则可以只保留必要原文、哈希值或外部对象存储地址。不是所有字段都需要完整复制，重点是关键业务字段不能失去证据。
如果存储压力较大，可以采用分层保留策略：热数据保留完整原始值，冷数据压缩存储；标准字段长期保留，临时探索字段按周期清理。这样能在成本和回溯能力之间取得平衡。
统一枚举有利于跨平台分析，但过度统一会损失平台特有语义。例如“预约抢购”“预售待定”和“预计发货”都可能被粗略归为预售，却对应不同的运营动作。更稳妥的做法是同时保留源平台状态和标准状态，标准状态用于通用分析，源状态用于专业场景和异常排查。
标准枚举也应允许 unknown 和 other，但不能把它们当成垃圾桶。每次出现新的未知值，都应进入映射维护流程；如果未知值持续增加，说明平台状态模型发生了变化。
校验过于严格，可能丢弃大量有价值但不完整的数据；校验过于宽松，又会让错误数据进入业务模型。我的判断原则是：核心动作字段严格，解释性字段宽松。价格监控中的 SKU、价格值和采集时间应严格要求；商品卖点、促销文案等字段即使缺失，也不必阻止整条记录进入基础分析。
可以把数据分成可用等级，而不是简单二元判断。例如，A级记录可以直接进入自动预警，B级记录可以进入趋势分析但不参与精确排序，C级记录只保留在原始层等待复核。这样既不会因少数字段缺失丢掉全部信息，也不会把低质量数据伪装成高质量数据。
高频采集可以更快发现价格和库存变化，但也会增加请求压力、数据量和异常噪声。并不是所有字段都需要同样的更新频率。库存和促销状态可能需要较高频率，品牌、类目和规格则可以低频更新。
| 字段类型 | 建议更新频率 | 原因 | 主要代价 |
|---|---|---|---|
| 价格与促销状态 | 按业务敏感度定时采集 | 短期变化可能影响竞争判断 | 数据量和规则维护增加 |
| 库存与配送状态 | 高于主数据更新频率 | 需要识别缺货和恢复 | 页面波动可能造成误报 |
| 商品名称与类目 | 每日或按变更更新 | 变化相对较慢 | 更新过低会延迟类目修正 |
| 品牌与规格属性 | 首次采集加变更检测 | 适合维护主数据 | 变更识别需要比对逻辑 |
自动化不等于取消人工。对于明确的金额、日期和状态转换，可以自动处理；对于模糊销量、复杂规格和新出现的页面状态，应保留人工复核入口。真正成熟的系统不是让人工永远不参与，而是让人工只处理机器无法安全判断的少数边界情况。
人工复核结果还可以反哺映射规则。例如，运营人员连续确认“预计7天发货”属于预售而不是缺货，系统就应把这个判断沉淀为新的规则版本，而不是每次继续依赖人工。这样，人工成本会逐步从重复劳动转化为规则建设。
脚本运行从两小时缩短到一小时，并不一定说明清洗成本下降。如果系统因此漏掉更多异常，或者开发人员需要人工修复更多数据，整体成本可能反而上升。清洗成本应同时包含计算时间、开发维护时间、人工复核时间、业务等待时间和错误修复时间。
我建议每个项目至少记录以下指标：
如果没有真实项目统计，不要直接宣称“清洗成本下降了百分之多少”。可以先用两周或四周作为基线期，记录原始方案的处理耗时、异常数量和恢复时间，再逐步上线字段契约，继续用相同口径比较。
对照时要保持样本规模、平台数量、采集频率和字段范围尽量一致。否则，新增平台导致的复杂度可能被误认为字段设计失败，或者样本减少导致耗时下降却被误认为自动化效果。
字段设计完善后，问题数量不一定立即下降，因为系统可能把过去隐藏的问题暴露出来。比如新增质量状态后，团队第一次发现有大量“未展示”和“解析失败”记录。此时不能简单认为数据变差，而要看问题是否更早被发现、是否能准确定位、是否能在业务使用前被拦截。
一个好的指标是平均发现时间和平均恢复时间。页面改版后，如果系统在第一批数据就发出字段缺失告警，并能定位到具体字段和解析版本，那么即使问题没有减少，风险也已经显著降低。
电商数据抓取的传统思路，是先把页面数据尽可能多地拿回来，再交给下游慢慢清洗。但在长期项目中，这种方式会把成本不断推迟并放大。每一次格式变化、每一个平台差异和每一条模糊状态，都会在下游生成新的分支、脚本和人工流程。
更稳健的思路是：在采集入口明确数据粒度，在标准层统一类型和单位，在应用层绑定业务动作，同时保留原始值、质量状态和版本信息。这样做不会让所有数据自动变得完美，却能让不完美变得可识别、可追溯、可处理。
如果你正在维护一个电商数据抓取项目，不必先重写所有代码。可以从一条最关键的业务链路开始，例如“价格采集，价格趋势，价格预警”，完成以下动作：
字段设计不是数据抓取的附属工作，而是从数据走向行动的最短路径。当开发人员开始为字段定义口径、为不确定性留下位置、为业务动作提前设计数据结构时，清洗成本才会从不可控的返工，变成可以测量、优化和持续复用的工程过程。
我以前总觉得抓取项目最难的是处理反爬、分页和异步加载，字段设计可以边做边补。后来在一次商品价格监控测试中，页面能正常抓下来，但分析阶段不断返工，我才发现真正拖慢项目的不是采集，而是字段没有提前定义清楚。
字段设计的价值，不是让数据看起来整齐，而是提前规定“这条数据以后要如何被使用”。如果先写解析代码，开发者通常会按照页面展示方式保存数据；但页面展示是给消费者看的，数据结构却应该服务于比较、统计和预警。
我曾经为了让数据表更干净，直接把“￥99.9”“99.90元”和“券后99.9”都转换成数字后入库。短期看报表确实简单，但后来价格口径出现争议时，已经无法判断这个数字到底来自哪个页面文案，也无法解释转换过程。
原始字段和标准字段分离，是为了同时满足“可使用”和“可追溯”。只保留标准值会让数据表变得整洁，却牺牲了发现解析错误、处理口径争议和应对页面变化的能力。
我在测试销量和库存字段时，最容易踩的坑就是把页面上的近似文案强行转换成精确数字。比如把“1万+”直接写成10000，把“仅剩少量”直接写成库存为5，结果看似方便排序，实际却制造了虚假的精确性。
面对不确定数据，正确做法不是强行清洗成一个数字，而是保留不确定性。数据能否计算，取决于它的统计口径和精度；把区间值伪装成精确值，可能比保留文本更危险。
很多项目上线后会说“字段已经标准化了”，但我发现字段变多并不等于清洗变少。有一次对比两个采集版本时，第二版字段数量增加了不少，可人工修复记录和规则分支并没有下降，原因是新增字段没有绑定校验规则，也没有明确业务用途。
降低清洗成本不能靠字段数量衡量，而要观察数据从采集到使用的总处理代价。好的字段设计应减少重复判断、缩短问题定位时间，并让页面变化能够被及时发现，而不是单纯增加一层数据表。
读者评论
文章把“抓取成功”和“数据可用”区分开来，这一点很有实际价值。尤其是价格、销量、库存等字段，如果只保存页面文本，后续分析确实容易反复返工。
对商品、SKU、店铺和采集事件分别设计标识的建议比较实用。电商场景中规格差异明显，若只用商品名称或链接做主键，很容易造成数据覆盖和统计偏差。
保留原始值、标准值和质量状态的做法值得借鉴。销量区间、促销价格等内容本身存在不确定性，强行转换成精确数值反而可能误导业务判断。
文中的情景模拟能够说明数据从请求成功到业务可用会持续损耗，但这些比例并非真实平台统计，实际项目仍需结合自身数据建立质量指标和监控规则。