竞品监控里最容易误判的一句话是：“任务显示成功，但数据为什么是空的？”我在处理电商数据抓取问题时，遇到过一个典型场景：某店铺监控任务连续执行 23 次，任务日志全部显示完成，结果表却只有商品标题，价格、SKU、评论和销量字段几乎全部为空。团队第一反应是修改解析规则，后来才发现，真正的问题不是一个，而是“入口页被重定向、部分字段需要后续加载、清洗规则又过滤了空值”三个环节叠加。
竞品监控中数据拿不到，不能从结果表倒推原因，而要沿着目标、请求、响应、解析、清洗、存储六层链路逐层定位。
这篇《电商数据抓取：数据新手实战复盘：竞品监控中数据拿不到的定位步骤》不讨论如何绕过平台限制，也不把所有异常简单归因于反爬，而是专门解决一个更实际的问题：当数据为空、字段缺失、部分成功或突然中断时，数据新手应该先检查什么、暂时不要做什么，以及如何判断这批数据是否真的能用于竞品分析。
很多新手把“结果为空”当成一个统一故障，实际上它可能对应完全不同的处理方式。任务可能根本没有启动，也可能已经拿到响应但解析失败，还可能是解析成功后被清洗逻辑删掉，或者数据已经入库但查询条件写错。
| 最终现象 | 更准确的描述 | 第一检查位置 | 不应立即做的事 |
|---|---|---|---|
| 任务没有记录 | 调度、运行环境或权限未生效 | 任务日志、调度日志 | 修改字段解析规则 |
| 任务完成但结果为空 | 请求、响应、解析或清洗任一层可能为空 | 原始响应与分层计数 | 直接判定为平台限制 |
| 标题有、价格无 | 字段来源不同或价格加载失败 | 字段来源、后续请求 | 批量重试整个任务 |
| 部分商品成功 | 页面模板、商品状态或数据口径存在差异 | 成功样本与失败样本对比 | 只拿成功样本当作全量结果 |
| 昨天有、今天无 | 入口、结构、权限、频率或环境发生变化 | 时间点前后的响应差异 | 回滚全部代码并重新开发 |
我通常把这六层称为“竞品数据链路”：目标层、入口层、请求层、页面或接口层、解析层、清洗存储层。只要能确定数据在哪一层消失，排查范围就会从“整个采集系统”缩小到一个可验证的问题。
例如，原始响应中已经没有价格字段，那么继续修改选择器没有意义；如果原始响应有价格、解析结果也有价格，但入库表为空，就应该去查清洗规则、字段类型、主键冲突或查询条件，而不是回头研究页面结构。
系统里的成功状态通常只代表程序没有抛出未处理异常，或者调度器已经执行完任务。它不一定代表目标商品正确、核心字段完整、数据口径一致，也不代表最终结果可以支持选品和价格判断。
我建议把任务状态至少拆成三种：执行状态、字段状态、业务质量状态。执行状态回答“程序有没有运行”；字段状态回答“目标字段有没有拿到”；业务质量状态回答“这些字段是否足以支撑分析”。
| 状态层 | 示例判断 | 适合谁查看 |
|---|---|---|
| 执行状态 | 任务已启动、请求完成、无系统异常 | 技术人员、运维人员 |
| 字段状态 | 标题完整率 98%，价格完整率 71%，SKU 完整率 64% | 数据人员、开发人员 |
| 业务质量状态 | 价格是否对应正确规格，时间口径是否一致 | 运营、选品、管理人员 |
如果一个任务执行状态为成功，但价格完整率从 96% 降到 58%，这应该被标记为业务异常，而不是继续显示绿色的“成功”。这也是竞品监控与普通一次性数据导出的差别：竞品监控关注的不是某一次是否跑完，而是长期趋势是否可信。
数据新手最常见的错误，是发现结果为空后马上改选择器、换请求参数、增加重试次数，甚至同时修改多个模块。这样做可能暂时恢复数据，却会让后续无法判断真正的根因。
更稳妥的顺序是：先固定一个失败样本，保存执行时间、目标链接、返回状态、响应摘要、解析结果、清洗结果和写库结果，再只改一个变量进行复测。没有问题现场，所谓“修复”往往只是碰巧重新拿到了数据。
一次性抓取通常只需要回答“现在页面上有什么”。竞品监控则要回答“这个商品相对于昨天、上周或上一个活动节点发生了什么变化”。因此，除了当前值，还要关心历史快照、采集时间、字段口径、商品标识和异常缺失。
例如，价格从 99 元变成 79 元，可能是真实降价，也可能只是抓到了另一个 SKU 的价格；销量从 1000 变成 0，可能是字段缺失，也可能是平台展示口径变化。如果没有规格、时间和数据来源，数字看起来精确，结论却可能完全错误。
竞品监控至少要建立一条稳定的记录主键，通常由平台、店铺、商品、规格和采集时间构成。没有稳定主键时，商品改链接、变体拆分或页面跳转都会造成重复记录和假变化。
标题、价格、SKU、评论、库存、销量和上下架状态，往往并不来自同一个页面位置，也不一定由同一种数据机制提供。标题可能直接出现在页面内容中，价格可能由规格选择触发，评论可能需要分页，销量可能受登录状态、地区或展示口径影响。
| 监控字段 | 常见数据来源 | 容易出现的误判 | 建议校验方式 |
|---|---|---|---|
| 商品标题 | 页面正文、结构化信息或接口字段 | 标题有变化就认为商品定位变化 | 保存历史版本并区分活动词、规格词 |
| 价格 | 页面展示、规格价格或促销信息 | 低价被误认为商品统一售价 | 绑定 SKU、规格、币种和优惠条件 |
| SKU | 规格模块、商品接口或页面交互结果 | 缺少 SKU 被认为商品没有规格 | 比较页面模板和规格状态 |
| 评论 | 评论区、分页响应或导出数据 | 评论数量少被认为用户反馈差 | 记录分页深度、时间范围和去重规则 |
| 销量 | 公开展示字段或平台统计口径 | 把累计值当成日销量 | 记录字段名称、采集时间和口径说明 |
在实际项目中，我会把原始采集结果接入数据分析工具，例如九数云，用于建立字段完整率、商品覆盖率、异常趋势和分店铺对比。它的价值不在于替代采集程序，而在于把“感觉数据少了”变成可观察的指标。
比如，把每天的商品数、价格完整率、SKU 完整率和异常响应数做成趋势图后，通常能看出异常是突然发生，还是逐步恶化。突然下降更像页面结构、入口或访问环境变化；逐步下降则可能与商品下架、规则老化或清洗条件累积有关。
需要强调的是，九数云这类分析平台展示的是已经进入分析链路的数据。若源端没有保留原始响应、失败原因和任务日志，仪表板只能告诉你“结果变差了”，不能单独证明“为什么变差”。
访问限制当然可能导致数据拿不到，但它只是候选原因之一。错误链接、登录页、验证页、地区差异、商品下架、页面模板变化、动态加载和清洗误删，都可能产生相同的“空结果”现象。
判断是否存在访问限制，至少要同时观察返回状态、最终页面类型、跳转链路、失败比例和失败时间段。若所有商品都在同一时间突然返回相同的验证页面，访问策略是重要嫌疑；若只有某一类商品的价格字段缺失，则更应该先查字段来源和页面模板。
把所有问题都归因于反爬，会导致两个后果：一是技术人员在不必要的方向上增加复杂度，二是业务人员忽略了本来可以通过修复口径和清洗规则解决的问题。
浏览器最终展示的页面，是多个请求、脚本和交互共同完成的结果。数据新手经常看到页面上有价格或 SKU，便认为初始响应中也必然存在这些字段，然后不断修改页面选择器。
正确的判断是：先确认目标字段出现在什么层级，是初始内容、结构化数据、后续请求，还是用户选择规格后才产生。字段来源没确认之前，改解析规则通常只是无效劳动。
这类问题还容易造成“标题可以抓，价格抓不到”的假象。标题是静态字段，价格却可能随规格、地区、促销或登录状态变化，两者本来就不一定共享同一条数据路径。
重试适合处理短暂超时、网络抖动和偶发服务错误，不适合解决错误入口、失效登录态、错误字段规则或持续性页面变化。对一个确定返回错误页面的请求重复 20 次，只会增加等待时间和访问压力。
| 异常类型 | 增加重试是否有价值 | 更合理的动作 |
|---|---|---|
| 偶发超时 | 有一定价值 | 设置有限次数、退避时间和失败告警 |
| 域名或链接失效 | 价值很低 | 核对入口、重定向和商品状态 |
| 登录状态失效 | 基本无效 | 按合规流程重新确认授权状态 |
| 字段结构变化 | 无效 | 保留响应并更新解析规则 |
| 清洗规则误删 | 无效 | 比较清洗前后记录数和字段值 |
一个商品能成功，不代表全店都能成功。商品可能使用不同页面模板，存在不同规格状态，处于不同上下架阶段，或者由不同的商品类型承载。
我更建议使用“最小但有差异的样本集”：一个普通商品、一个多规格商品、一个促销商品、一个评论较多的商品和一个近期新上的商品。这样比只测试一个页面更容易发现模板差异和字段边界。
在报表里把空值填成零，看起来更整齐，却可能把“未知”伪装成“确实为零”。价格缺失不等于零元，销量缺失不等于没有销量，评论抓不到也不等于评论数量为零。
建议至少区分三类状态：源数据明确为零、源数据为空、采集过程失败。只有第一类才适合进入数值统计中的零值，否则趋势图会产生非常严重的误导。
任何抓取任务开始前，都要先写清楚监控对象和字段口径。不要只写“监控竞品店铺”，而应明确店铺标识、商品范围、规格范围、采集频率、历史保存方式和成功标准。
例如，“监控价格”至少要进一步说明：监控商品展示价、起售价、指定规格价格，还是优惠后的到手价；“监控销量”要说明是页面展示值、累计销量、月销量还是某个时间窗口内的估算值。
目标定义不清时，后续很容易发生“抓到了数据但业务认为不对”的情况。数据新手常把这个问题误认为解析失败，实际上是监控口径没有被定义。
入口层是最容易被忽略、却最容易造成全链路误判的一层。店铺名称可能重复，商品链接可能重定向，商品可能已下架，规格链接也可能被归并到另一个对象。
我通常会在原始记录中同时保存目标 URL、最终 URL、店铺标识、商品标识、页面标题和采集时间。这样即使页面内容异常，也能知道程序最终访问的到底是什么对象。
如果失败样本全部被跳转到登录页或验证页，说明入口之后的响应已经不是目标页面；如果只有个别商品跳转到失效页，则更可能是商品状态或链接维护问题。
不要只看一个状态码。一个请求即使返回正常状态，也可能返回登录页面、提示页面、降级页面或不完整内容。真正要确认的是：返回内容是否属于预期页面，是否包含能识别目标对象的特征，是否发生了重定向，响应是否被截断。
建议为每次任务保留最小化日志，而不是永久保存所有敏感内容。日志至少包括请求时间、目标标识、响应状态、最终地址、响应类型、耗时、失败原因和字段计数。对于涉及账号、个人信息或商业敏感数据的场景，还应遵守数据最小化和授权要求。
这一层要回答的不是“选择器怎么写”，而是“字段真实存在于哪里”。价格可能来自商品详情，SKU 可能来自规格数据，评论可能来自分页数据，销量可能由平台以不同口径展示。
如果页面初始内容中没有字段，却在浏览器完成加载后出现，应该先确认是否存在后续合法数据来源。不能因为看得到，就默认可以从初始页面直接解析，也不能在未经授权的情况下把隐藏接口当作任意可用来源。
对数据新手来说，一个简单方法是选择一个已知字段做对照：如果标题在原始内容中、价格不在，那么两者数据来源大概率不同。继续用标题的解析方法处理价格，成功率通常不会高。
当原始响应完整、目标字段也确实存在时，才进入解析规则排查。此时要比较成功样本和失败样本，而不是只看失败样本。
重点检查字段名称、层级、页面模板、编码、类型转换和空值处理。尤其要防止一个规则覆盖多个页面模板，因为规则看起来简洁，实际可能只适用于最早测试过的商品。
为了降低修改风险，我建议每次只调整一项解析逻辑，并保留旧版本解析结果。这样可以回答“新规则到底修复了哪些样本、又误伤了哪些样本”。
很多空结果并不是采集阶段造成的，而是清洗阶段把“不符合预期”的记录全部删掉。例如价格为空就整行过滤、SKU 数量异常就删除商品、日期格式转换失败就丢弃记录。
清洗规则应尽量从“删除”改为“标记”。一条记录即使价格缺失，也可以保留商品标识、标题、采集时间和缺失原因。这样运营人员知道商品还存在，只是价格暂时不可用，而不是误以为商品没有被采集。
存储层还要检查主键冲突、字段长度、数据类型、写入环境和查询条件。曾经遇到过一次“采集结果为空”的问题，最后发现数据已经写入临时表，但报表仍然查询旧表；这个问题与页面、请求和解析完全无关。
下面这个案例经过匿名化处理，数字为项目复盘中的情景模拟，用于说明定位过程，不代表任何平台的公开统计。某电商团队需要监控 12 个竞品店铺，每个店铺先选取约 80 个商品，关注商品标题、当前价格、规格组合、评论数量、商品状态和采集时间。
团队使用采集程序获取源数据，再将结构化结果汇总到九数云，制作店铺覆盖率、字段完整率和价格变化看板。初始目标不是追求全量，而是先保证重点商品能够稳定形成历史快照。
前两周看板表现正常：商品标题完整率约 97%，价格完整率约 93%，SKU 完整率约 88%。第三周开始，标题完整率仍保持在 96%左右，但价格完整率下降到 68%，SKU 完整率下降到 61%，评论字段没有明显变化。
这个现象非常关键。若是整个请求链路失效，标题、价格、SKU、评论通常会一起下降；现在只有价格和 SKU 同步下降，说明更可能是某个共同数据来源或页面模板发生变化。
团队没有立即批量重跑，而是从同一店铺中各选 3 个样本：一个价格正常的商品、一个没有价格但有标题的商品、一个多规格且价格缺失的商品。同时记录三类样本的目标地址、最终地址、执行时间和任务编号。
对比后发现，三个商品都能返回可识别的商品页面，标题和商品标识一致，说明目标层和入口层暂时没有明显问题。失败样本的响应时间也没有异常，不像单纯的网络超时。
在原始响应摘要中，正常商品包含价格字段，失败商品只包含标题和商品基础信息。失败商品的价格并不是空字符串，而是根本没有出现在初始响应中；规格信息也没有完整出现。
这一步把问题从“解析规则可能坏了”缩小为“目标字段没有在当前响应中返回”。如果此时继续修改选择器，只是在对不存在的字段做匹配。
团队进一步对比浏览器完成加载后的页面和初始响应，发现失败商品在完成规格交互后才展示价格和 SKU 组合。标题在初始内容中就存在，而价格和规格由后续页面逻辑呈现。
这里的结论不是“必须使用某种复杂技术”，而是先确认数据来源和使用边界。对公开、授权或平台允许的数据，应优先选择合法接口、官方导出或合规的数据接入方式；对于不允许自动化获取的内容，不应通过规避限制的方式强行采集。
源端只有价格和 SKU 缺失，理论上仍应保留商品标题和商品标识。但原有清洗规则要求“价格不能为空”，于是整条商品记录被删除。最终看板里不仅没有价格，连这个商品本身也消失了。
修复后，团队将记录状态拆成“字段可用”“字段缺失”“源端异常”“清洗异常”四类。价格缺失的商品继续进入主表，但价格字段为空，另增加 price_status 字段记录原因。这样运营人员可以区分“商品没有被采集”和“商品被采集但价格暂不可用”。
修复后的看板不再只展示商品数量，而是增加了商品覆盖率、价格完整率、SKU 完整率、原始响应异常数、清洗丢弃数和入库失败数。九数云适合将这些分层结果汇总成趋势和分组分析，帮助业务人员观察异常集中在哪些店铺、商品类型和时间段。
在本案例的情景模拟中，修复前 960 个计划商品中有 742 条记录进入分析表，表面覆盖率为 77.3%；修复清洗规则并保留缺失状态后，进入分析表的商品记录恢复到 925 条，覆盖率为 96.4%。但价格完整率并没有立即恢复到 93%，而是维持在 69%左右。
这说明修复成功了一半：商品记录不再被错误删除，但价格数据源的问题仍然存在。看板覆盖率提升，不代表核心字段已经恢复；不同指标必须独立验收。
这个案例最终确认了三个不同层面的原因：第一，部分商品的价格和 SKU 不在初始响应中；第二，页面展示状态与源数据状态并不相同；第三，清洗规则把字段缺失误判成整条记录无效。
如果只修复解析规则，问题不会解决；如果只修复清洗规则，商品记录会回来，但价格仍然缺失；只有把源数据、字段状态和业务看板分开，才能准确判断每一项修复带来了什么结果。
先查看调度记录、运行环境、任务权限、时间配置和资源状态。不要从页面字段开始查，因为没有请求就不会有响应，也不会有解析结果。
如果任务偶发失败，应增加明确的失败状态和有限重试；如果任务持续不执行，应优先解决调度和环境问题，而不是调整抓取字段。
先确认数据来源是否被授权、访问方式是否符合平台规则，以及当前登录或授权状态是否有效。不要把验证页面当成商品页面交给解析器，否则最终可能生成大量空值或错误标题。
在合规前提下，可以记录最终地址、页面类型、响应时间和错误分类。若平台提供官方接口、数据导出或合作数据服务，应优先使用稳定且被允许的来源。对于不适合自动化访问的数据，应调整监控目标或采用人工导入，而不是无限增加访问压力。
先拿一个成功样本和一个失败样本比较原始响应。若字段只在成功样本中存在，应检查页面模板、商品类型、规格状态、地区和时间差异；若两个样本原始内容都没有字段，应重新确认字段来源。
这类问题的修复路径通常有三种：
不要把失败商品直接从任务中排除。先按照商品类型、页面模板、规格数量、上下架状态、店铺和采集时间分组，观察失败是否集中在某一类。
如果多规格商品失败率明显高于单规格商品，优先查规格数据来源；如果新上架商品失败率更高，优先查新旧页面模板；如果某个店铺全部失败，优先查店铺入口或授权状态。
先做时间点前后的响应对比，而不是直接回滚。保留昨天的成功响应摘要，与今天的失败响应摘要比较，重点看最终地址、内容类型、字段名称、页面结构和错误信息。
如果变化发生在某个固定时间点，通常应重点排查平台页面更新、授权状态过期、任务环境变化、访问频率调整和规则版本变更。可以暂时降低批量范围，使用最小样本确认原因，避免错误任务继续扩大影响。
全量监控看起来最完整，但维护成本、异常数量和字段差异也最高。对于刚开始做竞品分析的团队，我更建议先建立重点商品池，再逐步扩展。重点商品可以按销售影响、价格敏感度、活动频率和新品程度筛选。
| 方案 | 优点 | 短板 | 适用场景 |
|---|---|---|---|
| 重点商品监控 | 样本少、定位快、质量易控制 | 可能漏掉长尾变化 | 数据新手、初期验证、资源有限 |
| 店铺级全量监控 | 覆盖面广、适合发现新品和下架 | 页面差异大、维护成本高 | 成熟团队、明确业务价值 |
| 分层监控 | 核心商品高频，长尾商品低频 | 需要制定分层规则 | 长期竞品运营和预算管理 |
分层监控通常更实用：核心商品每天监控价格和状态，普通商品每周监控，长尾商品只监控上下架和标题变化。这样既保留业务价值，又不会让所有字段都承担相同的采集成本。
实时并不等于更有价值。若业务只是判断竞品价格趋势，每天固定时间保存快照可能已经足够；若业务关注活动期间价格变化，则需要缩短频率，但同时必须提高异常告警和数据校验能力。
频率越高，越要关注重复数据、访问压力、失败重试和历史存储成本。不要为了“看起来实时”而采集大量无法解释的噪声数据。
自动化适合字段稳定、来源合法、频率明确的场景；人工导入适合偶发分析、字段不稳定或数据来源需要人工确认的场景。两者不是非此即彼，很多团队会采用“自动化监控趋势，人工核验关键异常”的混合方式。
例如，价格突然下降 40%时，系统只负责发现异常并标记相关商品，运营人员再通过合规渠道确认是否为活动价、特定规格价或展示误差。这比让系统直接把异常值当成真实策略变化更可靠。
为了追求完整率，系统可能把不确定数据填补成默认值；为了追求可信度，系统可能保留更多空值和异常标记。对竞品监控来说，我更重视可解释性，而不是表面上的 100% 非空。
一个价格完整率 85%、但每条记录都有来源和状态的数据集，往往比价格完整率 100%、却混入默认值和错误规格的数据集更有用。业务人员至少应该知道哪些数值是真实观测、哪些数值是缺失、哪些数值需要人工确认。
至少要持续观察商品覆盖率、价格完整率、SKU 完整率、评论完整率、原始响应异常率、清洗丢弃率和入库失败率。不同字段要有不同阈值，不能用一个“任务成功”指标代替所有质量判断。
阈值不必一开始就追求精确。可以先用过去两到四周的稳定数据建立基线，再根据业务重要性设置告警。例如价格完整率低于过去均值 15 个百分点，或者某店铺连续两次低于 70%，就进入人工核验。
建议每次任务记录以下数量：计划对象数、有效入口数、有效响应数、解析成功数、字段完整数、清洗保留数、入库成功数和报表刷新数。
如果只保留最终表，就无法判断 1000 个目标是请求阶段少了、解析阶段少了，还是清洗阶段少了。分层数量不需要复杂，但必须稳定、可比较、可按店铺和日期追踪。
推荐给商品记录增加状态字段，例如 normal、field_missing、source_error、parse_error、clean_error、storage_error。实际命名可以按团队规范调整，但状态含义必须清晰。
这样一来，运营人员看到价格为空时，不会误以为商品没有价格，而是可以进一步查看缺失原因。技术人员也能按照状态聚合异常，而不是人工翻阅所有空值。
页面结构、字段规则或数据来源发生变化时，必须保留一组稳定样本做回归测试。每次规则更新后，至少比较标题、价格、SKU 和评论四类字段的完整率，以及成功样本和失败样本的差异。
不要只看新版本成功数量上升了多少，还要检查是否误伤原本正常的商品。对竞品监控来说，修复一个页面模板不应以破坏另一个模板为代价。
在九数云或其他数据分析平台中，建议把看板分成两层。第一层面向业务，展示商品覆盖、价格趋势、SKU 变化和异常商品；第二层面向数据维护，展示字段完整率、响应分类、解析失败、清洗丢弃和入库状态。
业务看板回答“竞品发生了什么”；质量看板回答“我们为什么看到这些数据”。两者混在一起，业务人员会被技术异常淹没，技术人员也难以快速判断哪些问题真正影响决策。
| 检查项 | 需要记录的内容 | 判断结果 |
|---|---|---|
| 目标 | 店铺、商品、规格、字段、时间范围 | 是否采对对象 |
| 请求 | 执行时间、响应状态、最终地址、耗时 | 是否获得有效响应 |
| 原始数据 | 字段是否出现、页面类型、内容摘要 | 字段是否真实返回 |
| 解析 | 成功字段数、规则版本、失败原因 | 规则是否命中 |
| 清洗 | 过滤数、格式错误数、去重数 | 是否被业务规则误删 |
| 存储 | 写入数、冲突数、表名、刷新时间 | 是否正确进入分析链路 |
更稳妥的做法是先让一个小样本恢复到可解释状态，再扩展到一个店铺，最后才考虑全量。每次扩展都要比较字段完整率、异常类型和人工核验结果。
如果某个字段长期无法稳定、合法地获取，就应该重新评估它是否是必要指标，或者改用可获得的替代指标。竞品监控的价值不在于字段越多越好，而在于核心字段长期可比、来源清楚、异常可解释。
数据抓取失败不是单纯的技术问题，而是数据链路和业务口径共同产生的问题。页面没有返回字段、解析没有命中字段、清洗删除字段、报表没有刷新字段，这四种情况在最终表里都可能表现为“没有数据”，但修复方式完全不同。
如果只能记住一条经验，请记住：先看原始响应，再看解析结果；先看分层数量，再改规则；先确认数据来源，再讨论工具；先判断业务是否需要，再决定是否追求全量。
下一步可以从一个竞品店铺和十个重点商品开始，建立字段字典、最小测试样本和分层质量表。将商品覆盖率、价格完整率、SKU 完整率、异常响应数和清洗丢弃数接入九数云等分析平台，连续观察两周。两周之后，你通常就能判断：问题是偶发网络波动、特定页面模板、字段来源变化，还是整个监控口径本身需要重新设计。
真正成熟的竞品监控系统，不是永远不出错，而是出错时能告诉你错在哪里、影响多少、是否影响业务判断，以及下一步应该修复还是调整目标。这比一张看起来字段齐全、实际上无法解释的数据表更有价值。
我刚开始做竞品监控时，最困惑的是任务日志明明显示成功，但导出的结果却是空表。我第一反应是解析规则失效，后来才发现“任务执行成功”和“业务数据采集成功”根本不是一回事。
我复盘过一次类似问题：任务状态显示成功，运行耗时 18 秒，但最终写入数据为 0 条。起初我连续改了几次字段规则，结果没有任何变化。后来把链路拆开，才发现程序只是完成了请求和流程退出，并没有证明目标页面、字段解析和数据入库都正常。
我现在会把“成功”拆成 6 个计数点，而不是只看一个任务状态： 检查层需要记录的数量典型异常 目标层计划采集的商品数商品链接失效或对象选错 请求层实际发出的请求数任务启动了，但请求没有发出 响应层获得有效页面的数量返回登录页、错误页或验证页 解析层成功提取字段的数量页面有内容，但规则没有命中 清洗层通过校验的数据量空值或格式异常被全部过滤 存储层最终写入的数据量主键冲突、字段类型错误或写入了错误环境 定位时最重要的一步，是先保存一份原始响应，再看解析结果。
如果原始响应本身就是空内容或非目标页面，就不该继续改解析规则；如果原始响应完整、解析结果为空，才应该检查字段路径；如果解析结果有数据但数据库为空，则问题已经进入清洗或存储环节。我的判断标准也从“程序有没有报错”改成了“核心字段是否满足业务要求”。
例如，商品标题、价格和商品标识是必填字段，任一字段缺失就不能把这条记录标记为成功。这样做虽然会增加告警数量，但能避免把空数据误当成正常数据。
我用浏览器打开竞品详情页时，价格、销量和 SKU 都能正常显示，所以一直以为这些内容就在页面源码里。可是实际采集时只能拿到标题和链接，我想知道到底是页面结构变了，还是这些数据根本来自其他地方。
这个现象我踩过坑。第一次遇到时，我把选择器从一个版本改成了三个版本，仍然只能拿到标题。后来对比页面初始响应和浏览器加载完成后的内容，发现标题出现在初始页面中，而价格、SKU 和部分销量是在后续加载阶段才出现的。因此，“浏览器看得到”只能证明最终页面展示了数据，不能证明第一次请求就返回了这些数据。
电商页面通常至少要区分三种情况： 现象更可能的原因优先检查什么 标题和链接有，价格没有价格动态加载或展示条件不同初始响应中是否存在价格字段 商品信息有，SKU 没有SKU 在规格选择或后续请求中返回不同规格状态下的数据来源 详情页有销量，列表页没有两个页面的字段口径不同页面类型和统计口径 有时有数据，有时没有登录态、地区、设备或响应内容变化同一 URL 的原始响应对比 我现在不会一上来修改解析代码，而是先做一个“字段来源表”，记录每个字段在哪个页面、哪个响应或哪个合法数据出口中出现。
只有确认字段确实返回，并且位置发生变化，才调整解析规则；如果初始响应根本没有该字段，就不能把问题简单归结为选择器写错。还要注意，销量、库存和评论数量可能存在展示口径差异。采集到一个数字，不代表它一定是实时销量或累计销量。
做竞品分析前，我会给字段标注“当前展示值”“累计值”“估算值”或“未确认”，否则后续趋势图看起来很精确，实际比较的却不是同一种数据。
我的监控任务运行了几周都很稳定，最近却从每天几百条变成只剩几十条。程序没有明显报错，我担心是平台页面改版，也担心是访问频率、登录状态或运行环境发生了变化，不知道应该从哪一层开始排查。
我遇到过一次“昨天正常、今天骤降”的情况，当时第一反应也是重写解析规则。后来对比同一批商品的原始响应，发现有些请求返回的不是商品页，而是登录页面；另一些请求虽然返回了页面，但关键字段被省略。这个案例说明，数据量突然下降时，不能默认是页面结构变化。
我会先用同一组 10 个固定商品做小样本对照，而不是立即扩大重试次数。对照表通常包含昨天成功的响应、今天的响应、状态码、重定向地址、页面标题和核心字段数量。通过这个小样本，可以快速判断是全部失败、部分失败，还是只有某类页面失败。
对比结果优先怀疑方向下一步 所有商品都返回非目标页面登录态、权限、访问策略或环境异常核对运行账号、合法访问条件和请求日志 只有新商品缺失页面模板或商品类型变化比较新旧商品的页面结构 只有价格、销量缺失字段来源或展示条件变化检查原始响应和字段来源 解析有结果但入库减少清洗、去重或写库问题比较解析数量与入库数量 我不建议用无限重试来验证问题。
重试只能增加请求次数，却不能告诉你返回内容是不是目标页面，还可能让故障更难判断。更稳妥的做法是保留失败样本、降低无效请求、设置合理退避，并按照平台规则和授权范围检查访问方式。我的经验是，突然缺失通常要同时看“时间”和“范围”。如果在某个时间点后所有字段一起消失，更像访问或响应问题；
如果只缺一个字段，更像数据来源或解析问题；如果只有写入结果下降，则应优先检查清洗和数据库。先按范围切分，比盲目改代码更省时间。
我做竞品分析时经常遇到 SKU 数量变少、评论数量为空或某些商品没有价格。我不知道这些数据是真的不存在，还是在请求、解析、清洗过程中被丢掉了，如果把缺失值直接当成零，可能会影响选品和运营判断。
这是竞品监控里最容易被忽略、但影响决策最大的问题。以前我看到某商品 SKU 从 8 个变成 3 个，差点把它判断为商家收缩规格。后来回看原始记录，发现那次只采到了默认规格，其他规格并不是商品真的消失，而是没有完成后续加载。
现在我会把缺失分成三类，而不是统一写成 0： 缺失类型含义能否直接参与比较 源数据缺失目标页面或合法数据源本身没有该字段不能当作零，需要标记为“未展示” 采集失败请求、权限、加载或解析环节未获得数据不能参与比较，应进入补采或告警 业务上的空值该字段对当前商品确实不适用可以保留为空，但要记录字段规则 最有效的判断方法，是同时保留原始响应、解析结果和清洗结果，并给每个字段增加状态值。
例如价格字段不要只有一个 price，还可以配合 price_status：success、source_missing、parse_failed、not_applicable。这样业务人员看到空值时，知道它代表什么，而不是把所有空值都解释成“价格为零”。我还会用交叉验证避免误判。
SKU 可以和规格选项数量、价格梯度和商品展示状态对比；评论数据可以和页面分页状态、评论总数展示对比；价格则要确认是否对应当前 SKU，而不是默认规格或促销前价格。单个字段孤立变化，通常不足以支持竞品策略判断。最后，缺失值要进入数据质量指标。
比如固定样本中价格缺失率从 4% 升到 28%，就应触发告警；但如果某类商品从一开始就没有 SKU 字段，则应作为源数据特征记录。只有把“没有数据”和“没有采到数据”分开，监控结果才真正能支持选品、定价和运营决策。
读者评论
文章把“任务成功”和“数据可用”区分开，这一点很实用。尤其是先看原始响应、再查解析和清洗，能避免新手一上来就反复改规则。
六层链路的排查思路比较清晰，分层记录目标数、响应数、解析数和入库数，对定位数据在哪一步丢失很有帮助。
文中对价格、SKU、销量等字段来源不同的说明比较客观。实际做竞品监控时，确实不能因为标题抓到了，就默认其他字段也应存在。
把空值、明确为零和采集失败区分开很重要。这个细节容易被报表忽略，但如果直接补零，可能会让价格和销量趋势产生误判。