电商数据抓取项目最容易失败的地方，往往不是页面打不开，也不是程序不会解析，而是项目结束后才发现：业务要的是“可比较的竞品价格”，研发交付的是“页面上看见的一个价格”；运营要的是“某个 SKU 的可售状态”，数据表里却只有商品标题。产品经理如果只写“抓商品信息、价格、销量、评价”，这还不能算采集需求，最多算一组待澄清的关键词。真正可执行的标准，是让业务、研发、数据分析和验收人员对每个字段的含义、粒度、来源、时间和异常处理达成一致。
电商数据抓取：产品经理标准化教程：用字段设计复制明确采集目标
本文讨论的不是某种编程语言，也不是如何绕过平台限制，而是产品经理如何把一句模糊的“帮我抓一批电商数据”，转化为一份可开发、可验收、可复用的数据采集任务。我的核心判断是：电商数据抓取的第一交付物不是数据，而是数据定义；字段设计不是表格整理工作，而是把业务目标复制给整个项目团队的沟通协议。
在电商项目中，“抓取成功”通常只说明程序访问到了页面，或者接口返回了内容。但业务真正关心的是：这条数据能不能支持定价、选品、竞品监控、库存判断或活动复盘。
例如，页面上同时出现“原价 399 元”“到手价 299 元”“券后价 279 元”和“某规格 329 元起”。如果产品经理只定义一个字段叫“价格”，程序即使准确提取了页面文字，后续分析仍然无法回答“竞品当前实际销售价格是多少”。
我在需求评审中通常会先问一句：“这条数据最终要支持哪个动作？”如果答案是“调价”，就必须区分可比价格、促销价格和 SKU 价格；如果答案是“选品”，还要关注销量周期、评价质量、店铺属性和库存状态。字段不是页面元素的复制品，而是业务决策所需事实的结构化表达。
如果上述问题没有答案，直接进入技术方案，往往会把不确定性隐藏到开发过程中。等数据交付后，业务才开始补充口径，返工成本通常高于前期多花的一次需求澄清时间。
这里的“复制”不是把网页内容复制到表格，而是把产品经理脑中的采集目标，复制给研发、测试、数据分析和业务使用者。一个字段只有同时具备名称、定义、类型、来源、时间口径和验收规则，才具备可传递性。
| 模糊表达 | 研发可能的理解 | 业务真正可能需要的定义 |
|---|---|---|
| 抓商品价格 | 抓页面中最显眼的数字 | 记录采集时默认 SKU 的当前展示价，并拆分原价、活动价、券后价 |
| 抓销量 | 提取“已售”或“销量”文字 | 保留原始展示值、标准化值和统计周期，无法确认时标记为区间或估算 |
| 抓库存 | 提取“有货”“售罄”等文字 | 记录 SKU 级可售状态，并保留无库存、预售、区域不可售等状态 |
| 抓评价 | 抓评价总数 | 分别记录评价总数、评分、好评率和评价文本是否采集 |
假设某团队想监控 50 个竞品商品，每天采集一次，用于调整自有商品价格。业务最初可能只提出“抓商品名、价格和销量”。但真正开始设计报表时，通常会出现一连串追问：这个价格是哪个 SKU 的？是否包含优惠券？页面上的划线价有没有意义？不同规格是否共用一个价格？采集时商品是否处于秒杀或直播活动中？
如果这些问题没有在字段设计阶段解决，后续的“竞品最低价”很可能把不同规格、不同促销条件和不同采集时间的数据混在一起。表面上报表有很多行，实际上每行数据都无法公平比较。
一个更可靠的设计，会把价格拆成多个字段，并把采集时间绑定在同一条快照记录上。这样业务才能区分“长期价格下降”和“活动期间短时降价”，也能避免把某个 SKU 的低价误判为整个商品的常态价格。
“销量”看起来是最有价值的字段，实际上也是误读风险较高的字段。页面可能展示“已售 10 万+”“近 30 天销量”“月销 5000”“累计评价 2 万”，这些数字的时间范围和统计口径并不相同。
如果产品经理要求直接输出一个数值，研发可能会把“10 万+”转换成 100000，也可能转换成 100001，甚至只保留字符串。三种结果都可能看似合理，但都不能证明是真实精确销量。
我的处理方式是保留三个层次：第一层是页面原始展示值，第二层是可比较的标准化值，第三层是统计周期和估算标记。对于“万+”这样的区间值，可以用于排序，但不应在报告中写成精确销量。
评价总数能够反映一定的销售积累，但不能直接说明商品质量。一个商品有 10 万条评价，可能是长期销售的结果，也可能包含大量历史评价；一个新商品只有 500 条评价，未必意味着竞争力弱。
如果业务要分析消费者痛点，字段就不能只停留在评价数量，还要明确是否采集评价文本、评价时间、评分、规格、情感标签和图片视频标记。若只需要判断社会证明强度，则评价数量和评分可能已经足够，没必要采集全部文本。
字段范围应由决策动作决定，而不是由页面上能看到多少内容决定。抓得越多并不等于信息价值越高，过度采集还会增加清洗、存储、合规和后续解释成本。
多个平台的商品名称、价格和销量看似可以直接对齐，实际上经常存在不同对象层级和展示口径。某个平台以商品为中心，另一个平台以 SKU 为中心；某个平台展示券后价，另一个平台展示活动前价格；某个平台的销量是近 30 天，另一个平台可能是累计销量。
因此，我更推荐“统一主字段加平台扩展字段”的方式。主字段用于跨平台分析，例如商品链接、采集时间、当前展示价；扩展字段保留平台独有信息，例如活动标签、配送承诺、会员权益和销量周期。
页面元素是技术视角，业务字段是决策视角。页面上可能有多个价格节点、多个销量节点和多个评价模块，产品经理不能只把节点名称复制进需求表。
例如，“页面顶部价格”可能是默认规格价格，“规格选择区价格”可能是具体 SKU 价格，“订单确认页价格”可能已经包含优惠。三者都是真实页面元素，却对应三个不同的业务事实。
字段定义至少要写清楚：取哪个位置、代表什么对象、在什么条件下有效、是否需要保留原始文本。如果业务无法用一句话解释字段含义，字段名称通常还不够成熟。
“销量”“价格”“库存”“评分”这些词看上去简洁，实际上信息密度很低。相同字段名可能对应完全不同的统计方式，数据分析人员只能在后期猜测，或者反复找业务确认。
| 字段名 | 必须补充的口径 | 常见异常 |
|---|---|---|
| 当前售价 | 默认 SKU 还是全部 SKU；是否含券；货币单位；采集时间 | 区间价、起售价、会员价、活动价覆盖 |
| 销量 | 累计还是周期；原始展示还是标准化值；是否允许估算 | “万+”、近 30 天、页面不展示、动态刷新 |
| 库存状态 | 商品级还是 SKU 级；可售、预售、缺货如何区分 | 区域限制、登录后显示、库存随时间变化 |
| 评价数 | 总评价还是有效评价；是否含追评；采集时间 | 评价与晒单分开、数量延迟、展示口径变化 |
商品是一个展示或销售集合，SKU 是具体规格组合，店铺是销售主体，活动是影响价格和权益的条件。它们之间存在关联，但不是同一个对象。
如果一张表同时记录商品标题、店铺名称、每个 SKU 价格和多个活动，最常见的结果是商品标题重复、店铺信息重复，活动字段被覆盖，SKU 关系也无法还原。
更稳妥的方式是先确定主记录粒度。如果目标是价格监控，建议以“商品，SKU，采集时间”为核心快照键；如果目标是店铺经营分析，则可以另建店铺日快照；如果目标是活动复盘，则需要把活动作为独立对象保存。
价格、库存、销量、评价数都不是静态属性。没有采集时间，团队无法判断这条数据何时有效，也无法解释两次采集之间发生了什么变化。
我通常把采集时间分成两个概念：一个是页面数据对应的业务时间，如果页面明确展示“截至某日”；另一个是系统实际访问页面的时间。两者不能混为一谈，因为页面可能存在延迟，业务时间也可能无法获取。
页面没有显示销量，不代表销量为零；页面没有显示库存，不代表缺货；价格无法解析，也不代表价格为零。空值、未展示、无权限、解析失败和业务上确实为零，应该使用不同状态。
这几个状态会直接影响后续分析。例如库存缺失和库存为零的经营动作完全不同，不能在清洗时简单地全部转换成 0。
我建议产品经理先用一句话描述数据要支持的决策，而不是先打开页面列字段。模板可以写成：
为了支持某项业务决策，需要在某个时间范围内，采集某类对象的关键指标，用于某个分析或动作。
例如：“为了支持竞品调价，需要每天采集指定商品各 SKU 的当前展示价、活动状态和库存状态，用于识别可比价格和短期促销变化。”这句话已经隐含了对象、时间、字段和用途，比“抓竞品商品信息”更接近可开发需求。
业务决策句写完后，要把名词拆成对象。常见对象包括商品、SKU、店铺、品牌、活动、评价、类目和时间快照。
| 对象 | 回答的问题 | 常见标识 | 是否适合作为主记录 |
|---|---|---|---|
| 商品 | 用户看到和比较的是什么 | 商品 ID、商品链接 | 适合商品信息采集 |
| SKU | 具体规格和可售组合是什么 | SKU ID、规格组合 | 适合价格、库存采集 |
| 店铺 | 谁在销售或提供服务 | 店铺 ID、店铺名称 | 适合店铺经营分析 |
| 活动 | 价格或权益为何发生变化 | 活动 ID、活动名称 | 适合促销归因 |
| 时间快照 | 数据在何时有效 | 采集时间、业务时间 | 适合动态指标追踪 |
对象拆分的价值在于避免“一个表解决所有问题”。如果团队暂时不具备复杂建模能力，也至少要在一张宽表中保留对象 ID 和粒度说明，而不是仅保留商品标题。
数据粒度是“每一行究竟代表什么”。这是字段设计中最容易被跳过、却最影响后续分析的环节。
以竞品价格监控为例，推荐主键至少包含“平台、商品 ID、SKU ID、采集时间”。如果 SKU ID 不可获取，就必须明确采用商品级价格，并在结果中标注“非 SKU 精确价格”，不能假装已经实现了 SKU 级比较。
一份字段字典不应只是字段名和示例值。我建议至少补齐以下六类定义：业务含义、数据类型、来源位置、时间口径、异常规则和验收方式。
| 字段 | 业务定义 | 类型 | 来源 | 异常规则 | 验收方式 |
|---|---|---|---|---|---|
| product_id | 平台内用于识别商品的唯一标识 | 字符串 | 详情页链接或页面结构 | 缺失时记录页面链接，不自行生成替代 ID | 同平台同来源下重复率不超过约定阈值 |
| sku_id | 具体规格组合对应的标识 | 字符串 | SKU 选择区域或数据结构 | 未展示时允许为空，但需标记粒度降级 | 与商品 ID 建立关联 |
| current_price | 采集时对应对象的当前展示价 | 数值 | 价格区域 | 区间价、券后价需进入异常或扩展字段 | 随机抽样与页面对照 |
| sales_raw | 页面原始销量展示文本 | 字符串 | 销量区域 | 保留“万+”等原始表达 | 检查原文可追溯 |
| sales_value | 基于明确规则转换后的可比较数值 | 数值或区间 | 由原始值转换 | 估算值必须标记估算状态 | 检查转换规则和周期 |
| collected_at | 系统实际完成采集的时间 | 时间 | 系统生成 | 不允许为空，统一时区和格式 | 检查任务日志与数据记录一致 |
对于价格、销量和评价等容易发生口径变化的字段，我不建议只保存清洗后的结果。更稳妥的结构是同时保存原始值、标准值和状态值。
这种设计会增加一些字段，但能显著降低后期争议。业务问“为什么销量是 100000”，团队可以回到原始值“10 万+”；分析人员问“哪些价格不是精确价格”，可以通过状态值筛选；研发调整转换规则时，也不必重新访问所有历史页面。
下面以一个情景案例说明。某消费品团队希望每天监控 120 个竞品商品，用于判断价格差异、活动影响和缺货风险。这里的数字是项目演示用的样本规模，不代表任何平台的行业平均水平。
业务目标不是“尽可能多抓数据”，而是回答三个问题：竞品当前是否比我方低价；价格变化是长期变化还是活动造成；竞品是否因缺货暂时失去可比性。
因此，采集范围应限定为公开可访问的商品详情、SKU 规格、价格展示、活动标签、库存状态、店铺信息和采集时间。评价文本、用户昵称和其他与当前决策无关的个人信息不在首期范围内。
| 字段类别 | 字段 | 用途 | 首期是否必需 |
|---|---|---|---|
| 身份 | platform、product_id、sku_id、shop_id | 确定来源对象与去重关系 | 是 |
| 描述 | product_name、category、brand、sku_spec | 支持检索、分组和人工核对 | 是 |
| 价格 | list_price、current_price、campaign_price、coupon_note | 区分标价、当前价和促销条件 | 是 |
| 促销 | campaign_name、campaign_start、campaign_end | 解释价格变化来源 | 视业务需要 |
| 库存 | stock_status、delivery_note | 判断价格是否具备实际可售意义 | 是 |
| 销量 | sales_raw、sales_value、sales_period、sales_status | 支持选品或辅助判断商品热度 | 视业务需要 |
| 追溯 | source_url、collected_at、parser_version、task_id | 保证来源可复核、规则可追踪 | 是 |
这里有一个容易被忽视的判断：库存状态是价格监控的重要辅助字段。某竞品显示低价，但商品实际缺货或仅支持预售，直接拿这个价格与我方现货价格比较，可能会产生错误的调价建议。
价格字段不能脱离 SKU、库存和活动单独解释。一个推荐的数据关系是：商品包含多个 SKU，SKU 在某个采集时间产生一条价格和库存快照，活动作为影响该快照的条件记录。
如果团队使用表格工具或数据分析平台进行首期验证，可以先用宽表落地，但必须增加“记录粒度”字段，并在表头明确“一行代表一个 SKU 在某次采集时的状态”。后续数据量扩大后，再拆成商品表、SKU 表、活动表和快照表。
字段设计完成后，我会先用一小批样本验证，而不是立即扩大采集规模。可以选择 20 个商品、连续 3 个采集时点，观察以下内容：同一 SKU 是否稳定识别；价格字段是否出现多种口径；活动标签是否能解释价格变化；缺货记录是否被误认为低价记录。
如果团队使用九数云这类数据分析平台，可以把采集结果与字段字典一起接入，通过关联、筛选、分组和趋势分析验证字段结构。这里平台的价值不在于替代采集程序，而在于帮助产品经理尽早发现“字段虽然抓到了，但无法形成分析关系”的问题。
例如，可以建立一个简单的竞品价格分析视图：横轴为采集日期，纵轴为当前售价，颜色区分活动状态，筛选条件区分 SKU 和库存状态。若价格折线频繁断裂，通常说明 SKU 标识不稳定；若所有商品在活动日同时出现异常低价，可能是促销字段未拆分；若缺货商品长期位于最低价区间，说明库存状态没有纳入比较条件。
以下是一个不依赖具体平台页面结构的分析伪代码示例，用于说明业务规则如何转化为可执行判断。它不是采集代码，也不代表某个平台的接口实现。
if stock_status in ["在售", "部分可售"]:
comparable_price = current_price
else:
comparable_price = None
if sales_status in ["估算", "区间"]:
sales_is_exact = False
else:
sales_is_exact = True
price_change = current_price – previous_current_price
if campaign_name is not None and price_change < 0:
change_reason = "可能由活动导致"
else:
change_reason = "需要进一步核查"
这个示例体现了一个产品判断：分析指标不是凭空计算出来的，它依赖字段状态和字段关系。如果没有库存状态，无法定义可比价格；如果没有销量状态，无法区分精确销量和区间销量；如果没有活动字段，无法解释价格变化原因。
字段字典是数据定义层，主要回答每个字段代表什么。它适合由产品经理、业务负责人和数据负责人共同维护。
字段字典不必一开始就覆盖所有页面内容，但核心字段必须完整。尤其是价格、销量、库存、评价和时间字段，不能只写名称。字段定义一旦改变，必须记录版本和变更原因，否则历史数据无法解释。
采集任务单是执行层，主要回答从哪里采、采集范围是什么、多久执行一次、失败如何处理以及数据保存到哪里。
验收不能只写“数据已导出”。建议同时设置完整性、准确性、唯一性、及时性和可追溯性五类指标。
| 验收维度 | 检查问题 | 示例标准 | 不通过时的动作 |
|---|---|---|---|
| 完整性 | 必填字段是否缺失 | 商品 ID、来源链接、采集时间不得为空 | 区分页面未展示与解析失败 |
| 唯一性 | 同一快照是否重复 | 平台、商品 ID、SKU ID、采集时间组合不重复 | 检查翻页、重试和主键规则 |
| 准确性 | 字段值是否与来源一致 | 抽样记录与页面展示逐条核对 | 回看原始值和解析版本 |
| 一致性 | 格式和口径是否统一 | 价格统一为数值，时间统一格式 | 修订转换和标准化规则 |
| 时效性 | 数据是否按业务需要更新 | 日监控任务在规定时间窗口内完成 | 检查调度、访问限制和失败重试 |
| 可追溯性 | 能否回到来源和任务 | 每条记录包含来源链接、任务编号和采集时间 | 补充元数据和日志 |
“数据准确”无法验收，因为没有定义准确的对象和方式。更好的写法是：“随机抽取 30 条商品级记录，与采集时间对应的来源页面进行核对；商品 ID、商品名称和当前展示价逐条检查，价格存在促销条件时同时核对活动字段。”
验收样本不一定要很大，但必须覆盖正常页面、多 SKU 页面、缺货页面、活动页面和字段缺失页面。只抽正常页面，无法发现真正影响上线的边界问题。
一次性调研的重点是快速获得可分析样本，不必一开始就建立复杂的长期数据模型。但商品 ID、来源链接、采集时间和价格口径仍然不能省略，否则调研结果无法复核。
建议采用“最小可用字段集”：商品名称、商品链接、店铺、类目、当前展示价、规格信息、销量原始值、评价数、采集时间和异常状态。对暂时不参与决策的评价文本、物流承诺和活动历史，可以暂不采集。
取舍是速度更快，但历史追踪能力较弱。若后续很可能转为长期监控，应提前保留稳定 ID 和任务编号，避免一次性调研表无法接入后续系统。
长期任务最重要的不是首日抓多少条，而是数据能否在数周或数月后保持可比较。必须优先设计快照粒度、主键、采集时间、规则版本和异常状态。
建议把商品基础信息与动态快照分开考虑。商品名称、品牌和类目变化相对慢，可以作为基础信息；价格、库存、销量和活动状态需要按采集时间记录。这样既能节省重复存储，也能避免基础信息变化覆盖历史事实。
取舍是前期建模和维护成本更高，但后续可以回答价格趋势、活动持续时间、缺货时长和平台差异等问题。
高频监控必须先确认业务是否真的需要实时。价格预警、库存告警和活动开始监控可能需要较短周期；类目趋势和评价数量分析通常不需要分钟级更新。
在高频场景中，应把“采集频率”与“页面可访问性、任务成本、数据变化速度和业务响应时间”一起评估。并非访问越频繁，业务价值越高。频率过高可能增加失败率、系统压力和合规风险，也可能产生大量重复数据。
建议采用分层频率：核心竞品或高风险商品高频采集，普通商品按小时或日采集，低变化字段低频更新。对于没有发生变化的字段，可以采用变化检测减少重复处理。
多平台任务不要先追求所有字段完全一致，而应先确定跨平台真正可比的主指标。比如价格比较需要统一 SKU 规格、货币单位、促销条件和库存状态；销量比较需要统一统计周期或明确不能直接比较。
建议采用三层字段结构：第一层是跨平台通用字段，第二层是平台扩展字段，第三层是转换后的分析字段。通用字段保障横向分析，扩展字段保留平台差异，分析字段则明确转换规则。
取舍是模型会比单平台任务复杂，但可以避免为了“统一”而丢失平台特有信息。真正的标准化不是让平台看起来一样，而是让差异被明确记录。
管理层看板通常不需要展示所有原始字段，但必须具备指标口径、更新时间和异常提示。产品经理要避免直接把采集明细表当成看板数据源。
建议增加指标层，例如可比竞品数量、有效价格覆盖率、活动价占比、缺货商品占比和价格异常数量。每个指标都要能追溯到明细字段，并在看板上显示数据更新时间。
如果使用九数云等分析工具构建看板，应先完成字段字典和明细验证，再做可视化。工具可以帮助快速观察趋势和分布，但不能替产品经理决定“券后价是否可比”“估算销量能否进入排名”等业务口径。
每增加一个字段，不只是增加一列。它可能带来新的解析规则、异常类型、存储成本、测试样本和合规审查。尤其是评价文本、图片、用户信息和复杂活动规则，维护成本通常高于商品名称和价格。
我会把字段分成三类：决策必需字段、分析增强字段和探索性字段。首期先保证决策必需字段稳定，再根据真实使用情况扩展，而不是因为页面上存在某个模块就把它加入采集范围。
| 字段层级 | 判断标准 | 处理建议 |
|---|---|---|
| 决策必需字段 | 缺失会导致核心动作无法执行 | 优先保证定义、稳定性和验收 |
| 分析增强字段 | 有助于解释结果或细分人群 | 在核心字段稳定后加入 |
| 探索性字段 | 暂时不知道如何使用 | 先保留少量样本验证价值，不直接扩大规模 |
技术上能够访问，不等于业务上可以任意采集、保存、传播或商业化使用。产品经理至少要让项目明确数据来源、访问方式、使用范围、保存周期和权限控制。
需要特别谨慎处理登录态数据、用户评价中的个人信息、联系方式、收货信息、身份标识和其他与业务目标无关的内容。即使页面公开展示，也不代表可以无限制地批量保存和对外分发。
平台服务条款、访问规则、数据再利用限制和所在地法律环境都可能影响具体方案。本文不对任何具体平台的采集行为作合法性判断，实际项目应由法务、合规或安全负责人结合数据类型和使用目的进行核验。
一个字段可能技术上能抓到，但不稳定；也可能稳定可抓，但业务上没有价值。产品经理应在字段字典中增加“可得性等级”，例如稳定可得、条件可得、需人工核验和暂不建议采集。
这能避免研发为了满足需求，把一个经常变化的页面展示值包装成稳定指标。对于条件可得字段，验收时应明确允许的缺失比例、缺失原因和替代方案，而不是用“尽量完整”这种无法执行的表述。
第一天不要讨论工具选型，先确认业务要做什么决策、谁使用结果、多久需要更新、数据是否只做内部分析。选择少量有代表性的样本，最好同时包含普通商品、多 SKU 商品、活动商品和缺货商品。
输出物应是一页业务目标说明和一份样本清单。样本不需要追求数量，但必须覆盖可能导致口径变化的页面类型。
把样本中的对象拆开，画出商品、SKU、店铺、活动和快照之间的关系。然后建立字段表，先写核心字段，再标注字段是否必需、是否动态、是否可得。
如果团队争论“价格到底取哪个”，不要马上投票，应回到业务动作：用于调价就要明确可比价格；用于展示市场价格带，可能需要保留价格区间；用于促销分析，则必须拆出活动价和优惠条件。
这一天重点不是扩大采集，而是把最容易出错的字段跑通。价格、销量、库存和评价各选几种异常样本，规定原始值如何保存、标准值如何转换、状态值如何标记。
建议让业务人员直接查看样本结果，而不是只看字段文档。很多口径问题只有在具体数据出现时才会暴露，例如“当前售价”到底是否包含页面默认优惠。
将小批量采集结果接入分析工具或测试表，制作至少一个趋势视图、一个明细核验视图和一个异常统计视图。趋势视图检验字段能否支持业务判断，明细视图检验来源是否可追溯，异常视图检验失败是否可解释。
随后编写验收样本，明确正常、边界和失败三类页面。验收人员应能够依据表格独立判断，不需要反复询问需求提出者。
首版方案不必完美，但必须冻结一个可执行版本。将字段字典、任务单、验收表和样本结果关联起来，并记录版本号、生效时间和责任人。
后续平台页面变化时，不要直接修改历史字段含义。应新增规则版本或字段版本，说明变化原因和历史数据是否需要回算。只有这样，长期趋势才不会因为一次规则调整而失去连续性。
如果项目只有几十个商品、短期验证业务价值，可以用一张宽表快速落地。宽表的优点是直观，业务人员容易查看，分析工具也容易接入。
但宽表必须写清一行的粒度，并保留商品 ID、SKU ID、采集时间和状态字段。否则它只是把不同层级的信息横向堆在一起，短期看起来方便，后续很难去重和追踪。
如果需要观察价格和库存变化，不能只保留最新值。每次采集都应形成时间快照，或者至少记录字段变化历史。
这种方式会增加存储量，但可以回答“什么时候发生变化”“变化持续多久”“活动结束后是否恢复”等问题。对长期监控而言，历史可解释性通常比减少几列数据更重要。
商品、SKU、店铺和活动关系复杂时，建议拆成相互关联的数据表。商品表保存相对稳定的描述信息，SKU 表保存规格和标识，快照表保存动态状态，活动表保存促销条件。
分层模型的缺点是建模和关联成本更高，业务查看也不如宽表直观。它适合数据量较大、任务长期运行、多个分析场景复用同一份数据的团队。
| 方案 | 优点 | 短板 | 适用情况 |
|---|---|---|---|
| 宽表 | 开发快、查看直观、适合小样本 | 重复多、粒度容易混乱 | 一次性调研、概念验证 |
| 快照明细 | 适合趋势、变化和追溯 | 数据量增加、需要主键设计 | 长期价格或库存监控 |
| 分层模型 | 关系清晰、可复用、便于扩展 | 建模和维护成本较高 | 多平台、多对象、长期数据产品 |
当新增字段无法对应任何明确业务决策，或者只能通过复杂推断解释时，就应该暂停扩展。一个很实用的判断方法是：让需求提出者为每个新增字段写出“使用场景、计算方式和缺失后的影响”。写不出来的字段，可以先进入观察清单，而不是立即加入生产任务。
电商数据抓取项目真正的难点，通常不在于把页面内容搬进数据库，而在于建立一套稳定的事实定义。价格要绑定对象和时间，销量要保留统计周期，库存要区分不可售原因，活动要能够解释价格变化，空值要能够说明原因，历史数据要能够追溯来源。
我更愿意把字段字典看成一种“业务合同”。它约定了业务想知道什么，研发需要实现什么，数据分析可以如何计算，测试人员如何验收，以及项目在平台规则和数据权限下能够做到什么程度。
下一步可以从一个真实项目开始：选 20 个竞品商品，明确商品级还是 SKU 级，连续采集 3 个时间点，至少拆分价格、库存、活动和采集时间四类字段。然后用一张分析视图检查：数据能否比较、变化能否解释、异常能否追溯。
如果这 20 个样本都无法稳定回答业务问题，就不要急着扩大到 2 万个商品。先修正字段定义，再扩大采集规模。电商数据项目的专业性，不由抓取条数决定，而由数据能否支持正确决策决定。
我以前接到过“抓竞品商品信息”的需求，第一版字段表里只有商品名、价格、销量和链接。开发很快交付了数据，但运营拿到后发现无法比较不同 SKU 的价格，也不知道销量对应哪个时间段。为什么看起来抓了很多字段，最后还是不能用？
“抓商品信息”不是采集目标，而是一个没有验收边界的口号。它至少可能包含商品、SKU、店铺、活动、评价和时间快照六个层级。如果产品经理不先拆对象，研发通常会按照页面上最容易识别的文字抓取，结果是数据量很大，但分析问题没有被回答。
我在梳理竞品价格监控需求时，曾把同一份需求拆成三种粒度：商品级记录商品名称和类目，SKU 级记录规格和实际售价，快照级记录某个时间点的价格、库存和销量展示值。这样设计后，商品主数据、规格变化和历史价格才不会混在一张表里。
模糊写法可执行写法缺少定义时的风险 抓商品价格记录商品级标价、SKU 当前售价、优惠后展示价，并保留采集时间无法解释不同规格为什么价格不同 抓销量保留页面原始销量文本、标准化数值和统计周期“万+”被误当成精确销量 抓活动记录活动名称、开始结束时间、优惠条件和适用 SKU无法判断价格变化是否由促销造成 我的判断是：字段数量不是需求清晰度的指标，能否回答业务问题才是。
写需求时可以使用这句话作为约束：“为了支持什么决策，在什么时间范围内，采集什么对象的哪些指标，并用什么规则验收。”如果这句话说不完整，就不应该直接进入开发。
我看过不少字段表，只有“字段名、字段类型、示例值”三列，研发能照着做，但业务和测试都不知道什么算正确。比如“价格”到底是划线价、促销价，还是券后价？字段字典怎样写才能真正指导采集和验收？
字段字典不应只是数据库字段的目录，它更像业务口径、采集规则和验收标准之间的合同。一个字段至少要说明“它代表什么、从哪里取、什么时候取、能否为空、异常时怎么办”。少了其中任何一项，后续都容易出现同名不同义。
以价格字段为例，我不会只写 price，而会拆成 list_price、current_price、promotion_price 和 coupon_condition。
因为这几个值在页面上可能同时存在，且用途不同：竞品横向比较通常看当前售价，研究促销力度则需要原价和活动价，评估用户实际支付成本还要进一步确认优惠券是否满足使用条件。
字段业务定义是否必填异常处理验收示例 current_price采集时页面对当前选中 SKU 展示的售价是无法识别时记录解析异常，不用 0 代替数值大于等于 0，保留统一小数位 sales_raw页面原始销量展示文本否保留“万+”等原始形式与页面截图或原始响应可追溯 sales_period销量对应的统计周期视平台而定页面未说明时填 unknown不得把近 30 天销量标成累计销量 collected_at数据实际采集完成时间是由系统生成，不允许业务手填统一使用时区和时间格式 我建议把“来源位置”和“空值规则”放进必填列。
来源位置可以写成价格区域、SKU 选择器、活动模块或页面元数据；空值规则则要区分“页面没有展示”“需要权限”“解析失败”和“业务上不适用”。这四类情况如果都填空值，数据团队后面几乎无法定位问题。
我最困惑的是数据粒度：同一个商品有多个颜色、容量和套餐，页面却只给一个商品链接。如果按商品抓，价格会被覆盖；如果按 SKU 抓，记录数量又会迅速增加。产品经理应该用什么标准决定粒度，而不是凭感觉选一张表？
选择粒度的标准不是“哪种表更简单”，而是业务决策发生在哪一层。如果业务只分析类目覆盖和店铺数量，商品级可能够用；如果要比较规格价格、库存或套餐差异，就必须下沉到 SKU 级；如果要研究价格变化，还要增加时间快照级，否则历史状态会被最新数据覆盖。
我在设计价格监控表时，采用过“主数据加快照”的结构：商品表保存相对稳定的商品名称、品牌和类目；SKU 表保存规格组合和 SKU 标识；价格快照表保存采集时间、售价、库存状态和活动信息。这样一件商品有 20 个 SKU，也不会把商品名称重复写入 20 次后再靠人工去重。
业务问题推荐粒度关键主键常见错误 竞品有多少商品和店铺商品级platform + product_id把不同店铺的同名商品合并 不同规格价格是否不同SKU 级platform + product_id + sku_id只保留页面默认规格价格 价格何时变化快照级sku_id + collected_at用最新值覆盖历史记录 一个实用判断方法是问：“如果这个字段发生变化，我需要知道变化的是谁？
”商品名称变化通常是商品主数据问题，颜色对应的价格变化是 SKU 问题，今天与昨天的库存变化则是快照问题。只要这个问题答不上来，说明粒度还没有定义清楚。需要注意的是，SKU 级采集会显著增加数据量和维护成本。
若业务只需监测最低展示价，可以先采集商品级最低价，但必须在字段定义中标注“页面展示最低价”，不能把它误称为所有 SKU 的统一售价。
我以前验收数据时只看总行数，觉得导出了几万条记录就算完成。后来抽查才发现，部分商品 ID 重复，价格字段把促销标签一起抓进来了，采集时间也没有统一，导致分析结果完全无法复现。除了检查字段是否为空，还有哪些更可靠的验收方法？
数据验收不能只看抓了多少行，而要验证四件事：是否抓到了目标对象，字段含义是否正确，记录之间是否能关联，数据是否能被复现。行数只能说明程序产生了结果，不能证明结果符合业务口径。我通常把验收拆成“结构检查、规则检查和抽样比对”三层。结构检查关注必填字段、主键和数据类型；
规则检查关注价格范围、时间格式、商品与 SKU 关联；抽样比对则回到来源页面，逐项核对原始展示值。三层中最容易被忽略的是抽样比对，但它往往最能发现字段映射错误。
检查层级检查内容示例标准 完整性必填字段是否缺失product_id、source_url、collected_at 不为空 唯一性主键是否重复同平台同商品 ID 不重复；
快照需允许不同时间重复 一致性关联和格式是否统一SKU 必须能关联到商品，金额统一为数值 准确性与来源页面抽样比对随机抽取页面，核对名称、价格、活动和规格 时效性是否满足业务更新周期日监控任务不能使用超过周期的数据 抽样时不要只挑正常页面，至少应覆盖多 SKU 商品、无促销商品、促销商品、缺货商品、价格区间商品和页面字段缺失商品。
我的经验是，正常样本往往只能证明解析器在理想场景下工作，异常样本才决定这套数据能不能长期运行。验收结果还应该保留任务编号、解析规则版本、采集时间和异常日志。这样当运营质疑某个价格时，可以追溯到具体页面和规则，而不是重新抓一次后争论哪个结果才是真的。
读者评论
文章把“抓得到”和“抓得对”区分得很清楚，尤其是价格、SKU和采集时间绑定的例子，对竞品监控需求很有参考价值。
对销量字段的处理比较客观，保留原始展示值、标准化值和统计周期，能避免把“10万+”误当成精确数据。
将商品、SKU、店铺和活动拆分为不同层级很实用，很多项目返工确实源于对象粒度没有提前确定。
空值状态的分类值得关注。把未展示、无权限、解析失败和业务为零区分开，能减少后续分析中的误判。
文章更偏产品需求和数据治理，技术实现讨论较少，但对于明确验收标准、异常规则和合规边界已经覆盖得比较完整。