“我想每天早上 8 点，只收到昨天新上架的竞品新品和售罄商品整理。”
需求到这一句就结束了。但一旦询价，对话总会不断转向“那个网站能采集吗”。
这个请求里困难的部分并不是采集。
竞品商品列表现在也都完整显示在页面上。打开页面就能看到。
唯一看不到的是，其中哪些昨天还不存在。
价格写在今天的页面上。新品和售罄，只有在拥有昨天的列表时才会存在。
3 行摘要（TL;DR）
- 新品和售罄不是从页面读取的值，而是昨天列表与今天列表的差异(diff)。因此，首要设计对象不是爬虫，而是每天按照相同标准保留的基准快照。
- 第二个难点是售罄标记并没有统一标准。售罄、暂时缺货、到货提醒、选项级售罄在各网站的表达都不同。如果不定义什么算作售罄，每天累积的就是用不同尺子测量的数字。
- “每天早上”不是采集时间，而是送达时间。如果希望 8 点送达，就必须倒推验证和重试时间；如果没有阈值就全部发送，从第三周开始就没人会打开了。
目录
- 什么是新品监控与售罄监控
- 丢掉昨天的列表，今天的新品就永远看不见
- 每个网站对售罄的说法都不同
- 每天早上不是采集时间，而是送达时间
- 每天出现 200 条的报告，从第三周开始就没人看了
- 各方式对比表：人工确认 vs 无代码工具 vs 托管型服务
- 开始前自检 5 问
- 导入 5 步骤
- 常见问题
- 结论
什么是新品监控与售罄监控
新品监控，是指按照固定周期采集竞争对手与销售渠道的商品列表，自动识别基准时点不存在的商品是否新出现的活动。
售罄监控，是指定期采集同一商品的可售状态，捕捉从在售 → 售罄、售罄 → 补货等状态发生变化的时刻的活动。
两个定义中都包含相同的词：不存在，以及变化。
这正是它与价格监控的分界点。
价格只需看今天的一张页面就能得到答案，因为页面上写着数字。
新品和售罄仅靠今天的页面无法得出答案。必须有可供比较的昨天。
因此，这项工作比起采集，更接近于比对。价格相关的设计标准已另行整理在如何选择用于电商价格比较与监控的数据采集服务——一切取决于问题：能否覆盖 Coupang。
丢掉昨天的列表，今天的新品就永远看不见
基准快照，是指完整保存某一时点的商品列表和状态，并将其作为与下一次数据进行比较基准的数据。
要让比对正常运行，必须固定三项内容。
- 标识符 — 将什么视为同一商品（商品 ID、URL、商品名+选项）
- 范围 — 昨天与今天的采集范围是否相同
- 时间 — 是否每天在相同时间采集
第二项最容易出问题。
如果昨天采集了列表的 3 页，今天采集了 5 页，报告中就会出现数十个新品。即使其中一个也不是真正的新品。
还有一个更棘手的问题。第一次看到的商品，并不等于新品。
商品首次出现在列表中的情况至少有四种。
- 真正的新品 — 新上市的商品
- 改版重新上架 — 容量或包装改变后重新建立商品页面的商品
- 新增选项 — 既有商品增加颜色、尺寸后，看起来像独立商品的情况
- 补货回归 — 因售罄从列表中下架后又重新出现的商品
第四种尤其是隐蔽的误报。许多网站会直接将售罄商品从列表中移除，因此补货会每次都被识别为新品。
区分依靠的不是技术，而是规则。是否新发放了商品 ID、商品名相似度超过阈值时是否排除为改版候选、最近 30 天内曾出现在列表中时是否视为再次出现。
在支持超过 500 家企业采集的过程中，我们看到新品报告的首次失败通常不是因为拦截，而是昨天的列表没有被保留下来。
谁来制定这些规则，又是谁在网站改版后继续维护它们。这个项目实际上就是在回答这一个问题。
每个网站对售罄的说法都不同
售罄也不是单一的值。各网站对同一种“现在无法购买”的情况有不同标识。
- 售罄 / 暂时缺货 / 预计补货 / 停止销售
- 购买按钮消失，只留下“申请到货提醒”的状态
- 按钮仍在，但打开选项后发现全部无法选择
- 12 个选项中仅 3 个售罄（商品本身仍在销售）
- 从搜索结果中完全消失的状态
这里需要做出一个业务决策。
“12 个选项中有 3 个售罄的商品，算不算售罄？”
如果团队无法用一句话回答这个问题，每天收到的售罄数量，就是每天按不同标准统计的数字。
比较稳妥的方式是分两层记录。
- 商品级 — 现在能否购买（可 / 不可）
- 选项级 — 所有选项中有多少个不可购买
同时保留页面上显示的原始文案。这样即使网站修改了措辞，也能对历史数据进行追溯并重新分类。
最后一种情况，即从搜索结果中消失的状态，需要单独看待。是售罄、停止销售，还是我们的采集范围发生了变化——这三种在页面上的表现完全一样。
售罄不是状态，而是定义。若不写下定义，每天累积的就是用不同尺子测量的数字。
每天早上不是采集时间，而是送达时间
需求是“早上 8 点收到邮件”，但设计往往停留在“凌晨运行爬虫”。必须颠倒顺序。
从送达时间开始逆向计算。具体时间会因目标规模和网站难度而异，但基本结构如下。
| 时间 | 工作内容 |
|---|---|
| 08:00 | 报告送达负责人邮箱·Slack（这才是需求） |
| 07:40 | 生成并发送报告 |
| 07:00 | 一致性验证 + 与昨天快照比对 |
| 05:30 | 开始采集 — 包含失败部分的重试余量 |
| 前一日 05:30 | 作为比较基准的快照 |
最常被留空的环节有两个：验证与重试。
如果按采集一次就能成功的前提安排时间表，那么失败当天的报告要么为空，要么迟到。没有余量的管道，在失败那天会悄无声息。
每天保持相同的快照时间，也是出于同样的原因。昨天凌晨 3 点采集、今天早上 9 点采集，那么在这期间上架的商品，要么会被分到两天中识别，要么会完全漏掉。
困难的不是“早上”，而是“每天”。搭建一次一天就够了，但每天在同一时间、按同一标准送达，才是运营。
每天出现 200 条的报告，从第三周开始就没人看了
如果对三家竞争对手覆盖全品类，新品与售罄变动每天会有数百条。
第一周大家会全看。第二周只会扫一眼。第三周就不会打开了。
因此，阈值占报告设计的一半。
- 范围 — 不从全品类开始，而是从我们实际会应对的品类、价格带、品牌开始
- 重要性 — 将核心品类的新品、与我方畅销品直接竞争商品的售罄固定在顶部
- 汇总 — 不逐条发送，而是每天 1 次摘要。顶部 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)
