价格监控：定时任务、字段变更通知、Dataset 与 API

价格监控要的不是一次表格，而是可持续的闭环

业务口中的“盯一下竞品价格”，落到工程上通常包含四件事：稳定地生成或维护商品 URL；定期抓取列表与详情；把价格等字段存成可查询历史；价格变动时通知人，并允许下游系统用 API 拉取。只导出一次 Excel 无法满足第二周的复盘，也无法满足凌晨自动巡检。

HuluFlow 用工作流把这四件事收束到同一条资产上。文档场景见 价格监控指南 与用例 价格监控。本文把调度、notify、Dataset 与 API 串成一条可落地的操作说明，并标明积分与合规边界。

如果你同时做线索列表或内容情报，节点组合会相似，只是监视字段与通知条件不同。先把价格监控跑通，再复制工作流改字段，通常比从零设计三条互不相关的脚本更省事。产品化的复利，就来自这种可复制的图结构。同一套心智模型也能降低新人上手成本。

推荐节点图：从 URL 到可告警的表

一条经典价格监控流水线是：

url_gen → list scrape → detail scrape → store → notify

url_gen

若你已有固定 SKU/商品链接清单，用 list 模式粘贴 URL。若监控的是分页目录，用 range 模板生成页码 URL，并遵守数量上限，先小范围验证。分页专题见 分页指南。

list scrape 与 detail scrape

列表页负责发现商品卡片：标题、列表价、详情链接。详情页再抓更准的成交价、库存文案、规格字段。是否需要两段 scrape，取决于列表页是否已含你要监视的全部字段。很多站点列表价与详情价不一致——监视“业务认定的那一个价格字段”，并在字段命名上写清楚。

store

选择 Dataset，配置 key_fields（通常包含 url 或 link）。upsert 让同一商品行在多次运行中更新，而不是无限追加重复行。没有稳定键，后续的 field_change 通知会失真。

notify

对价格监控，优先 when=field_change，监视价格相关列；若你也关心新品上架，可另建或兼用 when=new。收件人使用真实会处理告警的邮箱，避免测试阶段打爆收件箱。上线前先用手动 run 触发一封测试信，确认模板可读、链接可点，再打开自动调度。

定时运行与积分预算

在工作流上设置 interval_minutes 与下次运行时间。worker 到期执行；你也可以在控制台或 API 手动 run 做补跑。频率要匹配业务：日级竞品巡检与小时级闪购监控的积分消耗差一个数量级。

积分按成功的 scrape 页面请求计。列表扇出到大量详情时，详情倍率会放大账单。上线前用小 URL 集估算：每次运行大约多少列表页 + 多少详情页，再乘以每日次数，对照计划额度。Free 档适合验证图是否正确；生产监控请选足额计划，避免半夜里额度耗尽导致空洞数据。

云端调度与扩展手动跑可以并存：白天用扩展验证改版后的字段，夜间仍走调度。权威结果以 Dataset 与 runs 记录为准。

字段变更通知：让人只处理例外

notify 的价值是减少“每天打开表格盯一眼”。当监视字段相对上次入库发生变化时发信，人处理的是例外而不是全量。为了让变更有意义，请保证：键稳定、字段语义稳定、不要把每次爬取都抖动的噪声列（如精确到秒的时间戳）放进监视集合。

邮件应写清是哪个工作流、哪个键、哪些字段从何值变为何值（以产品实际邮件模板为准）。收到告警后的标准动作是：打开 Dataset 核对样本 → 必要时在目标站人工确认 → 决定是否调整业务价或忽略。把告警当工单入口，而不是再开一个聊天群传截图。

Dataset：浏览、导出与作为系统源

控制台 Dataset 视图用于抽查行列、确认 upsert 是否按预期合并。导出 CSV/JSON 适合给不使用 API 的同事做周报。对工程下游，Dataset 更适合作为“当前快照表”：通过 API 分页拉取，写入数仓或内部 DB，由你们自己保留更长历史若需要。

注意 Dataset 不是无限廉价对象存储；它服务于工作流产出的结构化行。字段变更时，及时在 scrape 配置与文档中同步列名，避免下游报表 silently 读空列。

用 API 把监控结果接到内部系统

在控制台创建 API Key，请求头使用 Authorization: Bearer hulu_…。典型集成：

• POST /api/v1/workflows/{id}/run — 外部系统触发补跑（例如发布会前强制刷新）。
• GET /api/v1/workflows/{id}/runs — 检查最近运行状态。
• GET /api/v1/datasets/{id}/rows 与 …/export — 拉取或导出当前行。

更完整的管道思路见 API 优先指南 与 API 参考。密钥按环境拆分，泄漏后立即轮换。不要把 Key 写进前端公开仓库。

一种稳健架构是：HuluFlow 负责“按计划把公开页变成表 + 邮件例外”，你们的数仓负责“长期历史与复杂分析”。两边用 Dataset API 或定时导出衔接，职责清晰。

上线后的运维清单

• 每周抽查若干商品页，确认字段未因改版漂移。
• 关注失败 runs：连续失败应暂停调度，避免空耗积分。
• 回顾通知噪声：过于频繁说明监视字段选错或页面本身波动大。
• 核对计划额度与实际月消耗，提前升级而不是事后救火。
• 合规：仅监控你有权采集的公开页，控制频率，遵守目标站条款与法律。

建议在团队日历里放一个轻量“监控健康”例会：十分钟看失败率、告警量、额度消耗曲线。价格监控一旦变成无人照看的定时任务，最常见的结局是静默失败两周，直到业务问“怎么没人发现竞品降价”。工作流资产需要主人，就像生产服务需要 on-call——不必沉重，但必须有人认领。

常见失误与纠正

把列表价和详情价混在同一个监视字段里。 先选定业务口径，必要时分两列，只监视其中一列。

url_gen 一次铺开上千链接再“看看积分还够不够”。 先用 5–20 条校准字段与单次成本，再放大。

notify 接到个人邮箱且周末无人值守。 改用共享别名或值班列表，并接受“非工作时段延迟处理”的业务约定。

只用 CSV 邮件附件当长期档案。 CSV 适合分享；系统源应是 Dataset + API 或你们数仓中的同步表。

忽略合规与频率。 监控不等于高频压测。把间隔设到业务真正需要的粒度，既省积分也更可持续。

纠正这些失误之后，你得到的不是“更炫的爬虫”，而是一条可解释的数据供应链：输入是公开 URL，输出是表、邮件与 API，中间每一步都能在控制台指给人看。

下一步

从 价格监控指南 搭好最小图，用手动 run 验证 store 与一封测试通知，再打开调度。需要从页面冷启动时，配合 扩展。若你还停留在“我们到底为什么不自己写脚本”的问题上，可回到本 Blog 第一篇对产品定位的说明。

价格监控做成工作流资产之后，团队讨论的将是阈值、字段与频率，而不是“脚本在谁笔记本上”。这正是 HuluFlow 希望交付的工作方式：公开页进 Dataset，变化进收件箱，快照进 API——三条线同一条工作流。当你第一次在竞品降价的早晨收到字段变更邮件，而不是靠偶然点开网页才发现，你会清楚这条闭环为什么值得产品化。