"我希望每天早上 8 点，只收到昨天新上架的竞品新品和售罄商品的整理报告。"
需求就这一句话。但一旦开始询价，对话总会不断跑偏到“那个网站能采集吗”。
这个需求的难点不在采集。
竞品商品列表现在也都完整显示在页面上。打开页面就能看到。
唯一看不见的是，其中哪些昨天还不存在。
价格写在今天的页面上。新品和售罄，只有在拥有昨天的列表时才会存在。
而这个差异会直接影响营收。哪怕提前一天知道竞品新品，也能获得应对的提前量；抓住竞品主力商品售罄的瞬间，就有机会争取需求转移到我们这边的溢出收益。反过来，如果错过了与我们畅销品正面竞争商品的补货时机，这个窗口就会悄然关闭。新品·售罄监控不是“了解现状”，而是争取应对时机。
3 行摘要 (TL;DR)
- 新品和售罄不是从页面读取的数值，而是昨天列表与今天列表之间的差异(diff)。因此，首要设计对象不是爬虫，而是每天以相同标准留存的基准快照。
- 第二个难点是售罄标识并不统一。售罄、暂时售罄、到货提醒、选项级售罄在各网站的表达各不相同。如果不定义什么算作售罄，每天积累的就是用不同尺子衡量的数字。
- “每天早上”不是采集时间，而是送达时间。如果希望 8 点送达，就必须倒推出验证与重试的时间；没有阈值、什么都发送的话，从第三周起就没人会打开了。
目录
- 什么是新品监控和售罄监控
- 丢掉昨天的列表，今天的新品就永远看不见
- 售罄在每个网站都有不同说法
- 每天早上不是采集时间，而是送达时间
- 每天出现 200 条的报告，从第三周起就没人看了
- 按方式对比：人工确认 vs 无代码工具 vs 托管服务
- 开始前自检 5 问
- 实施 5 步骤
- 常见问题
- 结论
什么是新品监控和售罄监控
新品监控是指，按固定周期采集竞品·销售渠道的商品列表，自动识别基准时间点不存在的商品是否新出现的活动。
售罄监控是指，定期采集同一商品的可售状态，捕捉在售 → 售罄、售罄 → 补货等状态发生变化的瞬间的活动。
两个定义中都有相同的词：原本没有，以及发生变化。
这正是它与价格监控分道扬镳的地方。
价格只需看今天的一页页面就能得到答案。因为页面上写着数字。
新品和售罄仅凭今天的页面无法得出答案。必须有可对比的昨天。
因此，这项工作与其说是采集，不如说是比对。价格侧的设计标准已在如何选择用于电商价格比较·监控的数据采集服务中另行整理。
丢掉昨天的列表，今天的新品就永远看不见
基准快照是指，将某一时点的商品列表和状态完整保存，并作为与下一次结果进行比较基准的数据。
要让比对正常运行，必须固定三件事。
- 标识符 — 将什么视为同一商品（商品 ID·URL·商品名+选项）
- 范围 — 昨天和今天的采集范围是否相同
- 时间 — 是否每天在相同时间采集
最常发生问题的是第二项。
如果昨天采集了列表的 3 页，今天采集了 5 页，报告中就会出现数十个新品。即使其中一个都不是真正的新品。
还有一个更棘手的问题。第一次见到的商品，不等于新品。
商品第一次出现在列表中的情况至少有四种。
- 真正的新品 — 新上市的商品
- 改版重新登记 — 容量·包装改变后，重新建立商品页面
- 新增选项 — 原有商品增加颜色·尺寸，看起来像独立商品
- 补货回归 — 因售罄从列表下架后又重新出现
第四种尤其是隐蔽的误报。很多网站会将售罄商品直接从列表中移除，因此补货商品每次都会被识别为新品。
区分依靠的不是技术，而是规则。是否新发放了商品 ID、商品名相似度超过阈值时是否列为改版候选、最近 30 天内曾出现在列表中时是否视为再次出现。
在为 500 多家企业提供采集支持的过程中，看到的新品报告第一次失败，通常不是因为被拦截，而是因为没有保留昨天的列表。
由谁制定这些规则，又由谁在网站改版后继续维护它们。这实际上就是该项目唯一的问题。
售罄在每个网站都有不同说法
售罄也不是一个单一数值。相同的“现在无法购买”，各网站会以不同方式显示。
- 售罄 / 暂时售罄 / 预计补货 / 停止销售
- 购买按钮消失，只剩下“申请到货提醒”的状态
- 按钮仍在，但打开选项后发现全部无法选择
- 12 个选项中仅 3 个售罄（商品本身仍在销售）
- 从搜索结果中彻底消失的状态
这里需要做出一个业务决策。
“12 个选项中有 3 个售罄的商品，算售罄吗，还是不算？”
如果团队无法用一句话回答这个问题，每天收到的售罄数量就是每天按照不同标准统计出来的数字。
较稳妥的做法是分两层记录。
- 商品级别 — 现在是否可购买（可 / 不可）
- 选项级别 — 全部选项中有多少不可购买
同时保留页面中显示的原始文本。因为即便网站修改文案，也可以追溯重新分类历史数据。
部分网站会展示“剩余 3 件”之类的库存数量。这个数字与新品·售罄不同，是可以直接从当天页面读取的“值”，但它是预示售罄的领先信号，因此值得一并记录。因为一旦捕捉到库存跌破阈值的瞬间，就能在售罄“发生后”之前，而是在“发生前”进行应对。不过，库存数量的准确度和展示方式同样因网站而异，因此更安全的做法是：仅将展示库存的网站作为附加信号使用，未展示库存的网站则只判断可售/不可售状态。
最后一种，即从搜索结果中消失的状态，需要单独处理。究竟是售罄、停止销售，还是我们的采集范围发生波动——这三种情况在页面上看起来完全一样。
售罄不是状态，而是定义。如果不写下定义，每天积累的就是用不同尺子衡量的数字。
每天早上不是采集时间，而是送达时间
需求是“早上 8 点邮件”，但设计通常停留在“凌晨运行爬虫”。必须把顺序颠倒过来。
从送达时间开始倒推。虽然会因目标规模和网站难度而异，但框架大致如下。
| 时间 | 工作内容 |
|---|---|
| 08:00 | 报告送达负责人邮箱·Slack（这才是需求） |
| 07:40 | 生成·发送报告 |
| 07:00 | 完整性验证 + 与昨天快照比对 |
| 05:30 | 开始采集 — 包含失败部分的重试余量 |
| 前一日 05:30 | 作为对比基准的快照 |
常被留空的环节有两个：验证和重试。
如果按采集一次就会成功的前提制定时间表，失败当天的报告就会为空或延迟。没有余量的管道，在失败当天是沉默的。
每天保持相同的快照时间也是同样的原因。昨天凌晨 3 点采集、今天早上 9 点采集，那么期间上架的商品可能被拆分到两天中识别，或者完全漏掉。
困难的不是“早上”，而是“每天”。做一次一天就够了，但要每天在相同时间、按相同标准送达，这才是运营。
每天出现 200 条的报告，从第三周起就没人看了
监控三家竞品的全品类，每天的新品·售罄变动会达到数百条。
第一周会全部阅读。第二周只会浏览。第三周就不会再打开。
因此，阈值占据了报告设计的一半。
- 范围 — 不要从全品类开始，而是从我们实际能够应对的品类·价格区间·品牌开始
- 重要性 — 将主力品类的新品、与我们畅销品竞争商品的售罄固定在顶部
- 汇总 — 不要逐条发送，而是每天汇总一次。顶部 10 条 + 全部内容作为附件
- 收件人 — 新品发送给商品企划，售罄发送给销售·MD。不要让任何人收到与自己无关的提醒
报告的目的不是展示全部信息，而是只留下今天需要看的内容。
从检测到应对的闭环设计已在监控不是采集，而是通知——构建应对闭环中整理。
按方式对比：人工确认 vs 无代码工具 vs 托管服务
托管采集服务是指，由服务商代为运营爬虫开发、反爬应对、网站变更时修复、异常检测和准时交付，企业仅接收结果报告的订阅型服务。
将三种方式放在相同维度上比较，差异如下。
| 分类 | 人工每日确认 | 无代码工具调度器 | 托管采集服务 |
|---|---|---|---|
| 代表工具 | 浏览器收藏夹 | Octoparse（八爪鱼）、Thunderbit 等 | Hashscraper 等 |
| 新品识别（与昨天的差异） | 依靠记忆和目测 | 可获得每次结果 — 比对通常由用户负责 | 将快照保存 + 识别规则作为需求进行设计 |
| 售罄标识应对 | 人工查看判断 | 原样采集指定元素 | 建立并维护各网站标识词典 |
| 每日准时交付 | 取决于负责人上班时间 | 云端定时执行（以官方网站为准） | 从送达时间倒推进行设计·运营 |
| 异常检测（空值·数量骤变） | 感到异常时 | 用户自行确认 | 包含数量趋势·必填值验证（99.7% 准确率） |
| 网站改版时 | 需要更多人工操作 | 用户修复规则 | 服务商检测·修复（包含在订阅中） |
| 适用场景 | 目标不超过 10 个·每周 1 次 | 目标较少·结构稳定·可自行运营 | 每天早上报告关联实际业务 |
表中需要看的行是上面两项：新品识别与售罄标识应对。其余都是这两项决策的结果。
并不是无代码工具能力不足。因为这两项都不是工具功能的问题，而是定义的问题。Octoparse（八爪鱼）和 Thunderbit 在设定规则后，都能认真地执行到定时运行（以各官方网站为准）。但“与昨天的内容相比，只保留新出现的行”这一判断，仍然留给人来完成。
如果有开发团队，还存在第四种选择。购买 Zyte·Firecrawl 等面向开发者的抓取 API 作为采集层，自行构建快照保存、比对和报告生成的组合（以各官方网站为准）。自由度最高。
不过，本文讨论的三项——快照管理、售罄标识词典、准时交付——任何 API 都不会替你定义。它们会原封不动地留在构建方手中。
Hashscraper 基于采集韩国国内 5,000 多个网站的经验和覆盖 195 个国家的代理网络，提供这种托管方式，已有 500 多家企业在使用。
开始前自检 5 问
检查一下。这五行比三份报价单更快。
- [ ] 昨天采集的商品列表现在还保留着吗 — 是否以能与今天内容逐行比对的形式保存？
- [ ] 对“第一次见到的商品”区分为新品·改版·新增选项·补货的规则，是否已有文档？
- [ ] 对于“仅部分选项售罄”的商品是否算售罄，团队能否用一句话回答？
- [ ] 采集失败当天，收件人能否区分报告是空内容送达了，还是根本没有送达？
- [ ] 查看上周报告后，是否有实际采取的行动？
如果第 1 项是“否”，还没到比较工具的阶段。首先应该从今天开始保存列表。
如果第 5 项是“否”，问题不在采集，而在阈值。缩小目标范围会更快见效。
实施 5 步骤
第 1 步。缩小监控对象 — 不要从“所有竞品”开始，而是从“我们所应对品类中的竞品商品”开始。目标越广，误报也会同步扩大。
第 2 步。用一页纸写下识别规则与售罄定义 — 标识符是什么、如何区分改版与新品、如何统计选项售罄。这一页就是需求定义书。
第 3 步。从送达时间倒推制定时间表 — 逆向安排采集·重试·验证·发送。关键是不留空验证和重试环节。
第 4 步。确定交付形式与阈值 — 在 Excel·邮件·Slack·API 中，发送到负责人已经在工作的地方。不同形式的判断标准请参考接收 Excel 数据 vs 查看仪表盘数据。
第 5 步。通过 2 周试点排除误报后再扩大 — 前两周人工比对报告中出现的新品。将改版误算为新品，或将补货误算为新品的误报出在哪里，此时都会完全显现。
今天要做的不是选择服务商。而是第 2 步——用一句话写下我们团队的“新品”和“售罄”分别是什么。
常见问题
Q. 我想每天早上自动收到竞品新品和售罄现状数据，应该怎么做？
A. 顺序有三步。① 缩小目标列表（哪个网站的哪个品类）② 定义识别规则（什么算新品、什么算售罄）③ 从送达时间倒推制定采集·验证·发送时间表。然后再选择方式。如果目标较少，且公司内部有人能在规则失效时进行修复，可以从 Octoparse（八爪鱼）·Thunderbit 等无代码工具的定时执行开始（以官方网站为准）。如果目标增加，或者每天早上的报告关联实际业务，托管采集服务会更现实。Hashscraper 可将快照保存、识别规则和准时交付均作为需求进行设计并运营。
Q. 如何区分是新品还是改版？
A. 无法自动做到 100% 区分。需要通过规则缩小范围——商品 ID 是否新生成、商品名相似度是否超过阈值、最近 N 天内是否曾出现在列表中。结合这三个信号，将商品划分为“新品 / 改版候选 / 再次出现”，再仅由人工确认候选集，这是业务实践中较稳定的方式。
Q. 每个网站的售罄标识不同，可以统一吗？
A. 可以建立各网站的标识词典，并将其标准化为一个状态值。此时，保留页面显示的原始文本标识很重要。因为即使网站修改文案，也可以重新分类历史数据。
Q. 除了 Excel，还可以通过 Slack 或 API 接收吗？
A. 可以。以 Hashscraper 为例，支持 Excel 文件、邮件自动发送、API 对接和直接写入 DB。原则只有一个——发送到负责人已经在工作的地方。必须主动去查看才知道的结构，和信息主动送达后才知道的结构，应对速度不同。
Q. 售罄数据应该多久采集一次？
A. 应与应对周期相匹配。如果是在每天早会中进行判断，每天 1 次就足够。对于库存消耗会在一天内决定胜负的商品群，可以设计更短周期，但缩短周期会同时增加被拦截风险和成本。标准不是技术极限，而是应对速度。
结论
将“每天早上新品·售罄报告”的设计压缩后，就是以下四点。
- 保留昨天的列表 — 没有基准快照，就无法计算新品和售罄
- 定义什么算新品·售罄 — 区分改版·新增选项·补货的规则
- 从送达时间倒推 — 不留空验证和重试环节
- 只留下今天要看的内容 — 200 条报告和 0 条报告没有区别
价格是读取，新品和售罄是统计。
统计需要尺子。与昨天相同的尺子。
你需要的不是今天的商品列表，而是昨天与今天之间的差异。
不保存昨天的采集，会永远错过今天的新品。
立即开始
请告诉我们需要监控的竞品·品类以及希望的送达时间，我们将免费诊断采集可行性，以及应如何制定新品·售罄识别规则。新注册用户可获得 5 万积分，先行确认结果质量。
.jpg?locale=zh)
