如何从公共产品页面构建补货提醒
Scrapeless Agent Browser 提供一个浏览器会话，用于在店面脚本和选项控件加载完成后检查公共产品可用性。
摘要
- 补货提醒需要一个精确的被关注商品。 尺码、颜色、卖家、地区和履约方式都会改变可用性。
- 未知不同于缺货。 无法读取的页面不能支撑库存状态转换。
- 在被接受的状态转换上触发提醒。 首次观测或重复的可用状态需要单独的策略。
- 投递需要事件身份。 在不改变商业观测的前提下防止重复通知。
管线一览：观测、决策、投递
补货提醒是从可比较的公共可用性观测推导出的事件。该管线识别被关注的变体，建立购物者上下文，收集可用性证据，校验状态，将其与上次被接受的观测进行比较，并投递去重后的事件。
产品页面描述的是公共可购买性而不是仓库台账。启用的购买按钮可以是有用信号，但并不保证订单一定成功，也不会透露实体库存数量。预售商品和可立即购买的商品也需要不同处理。
该 价格变动提醒工作流 提供了相关的“观测并比较”架构。对于补货监控，核心决策是状态转换而不是数值阈值。通知应标明精确选项和上下文，以便收件人在采取行动前核实该报价。
前提条件：明确监控契约
创建一条监控记录，其中包含来源店铺、产品 URL、产品和变体身份、已选选项、国家/地区、配送或自提方式以及任何公共门店位置。决定该监控涵盖普通可用性、预售接受，还是其他明确定义的条件。
你需要一个公共页面采集器、调度器、持久状态存储，以及由订阅者授权的通知目的地。将采集许可和通知同意纳入运营设计。本文解释的是服务逻辑，其示例不涉及真实订阅者消息或购买行为。
为首次观测、过期历史和不确定性分别制定策略。订阅者可能希望收到首次可用通知，但那与确认补货是不同的事件。如果这一区别重要，请编码为不同事件类型，以免报表夸大库存变更次数。
阶段 1：读取正确的可用性界面
可用性采集应在被监控上下文下检查所选变体的购买区域。整个产品级别的徽标可能概括的是不同尺码，而分类卡片可能在产品页面已变化时仍然是缓存内容。保留来源界面及其新鲜度限制。
“ ItemAvailability 词汇表 区分了有库存、缺货和预售等状态。使用一个内部状态模型，同时容纳未知、上下文不匹配和采集失败。附加状态描述的是你的证据质量，而不是商家的库存。
在可用时，结合明确的库存标签、所选变体身份和按钮状态。如果这些信号不一致，请保留原始证据并暂缓商业决策。未解决尺码选择器旁边的启用按钮不足以证明被关注尺码可以购买。
阶段 2：将采集结果与库存状态分离
采集结果应描述是否获得了可信的可用性观测。仅成功导航是不够的。在接受库存状态之前，检查预期产品身份、相关购买区域、已选选项和可识别的可用性证据。
“ HTTP 语义标准 在协议层定义了响应状态的含义。成功的 HTTP 响应并不保证页面正文的业务含义。挑战页、同意页或无关产品都应仍然视为采集结果，而不是库存观测。
使用 Agent Browser时，你的采集器可以检查渲染后的状态并与公共选项控件交互。将这些交互限制在有边界的工作流中。如果无法确认国家或位置，标记为上下文不匹配，并保持上次被接受的商业状态不变。
阶段 3：定义状态转换规则
已确认的补货事件通常需要同一监控键下，一个被接受的不可用状态后跟一个被接受的可用状态。保留先前被接受状态及其时间。中间出现的未知观测不应仅因采集器缺乏证据而被当作不可用。
当较长观测间隔会导致事件具有误导性时，在策略中添加最大证据时效。经过过期区间后，你可以选择发送带有间隔标签的可用性观测，而不是断言确切补货时刻。该策略属于你的服务契约。
对于噪声较大的来源，在发出事件前要求声明确认规则。确认可以采用重复的有效读数，或独立公共信号之间的一致性。明确选择延迟与置信度的权衡。监控总是在离散时刻进行观测，无法保证捕捉到每一个短暂的库存窗口。
| 先前被接受状态 | 当前结果 | 结果 |
|---|---|---|
| 不可用 | 可用，相同上下文 | 候选补货事件 |
| 可用 | 可用 | 没有新的补货事件 |
| 未知或没有基线 | 可用 | 初始可用性策略 |
| 不可用 | 有人机验证或缺失产品标记 | 保持先前状态；标记采集缺口 |
| 预购 | 有现货 | 如果已配置，则使用单独的履约转换 |
阶段 4：在本地运行决策逻辑
下面的 Python 示例使用一个示意性的状态序列，不进行任何网络采集或消息投递。它在一次未知读取中保持已接受的状态，并发出单个补货决策。这样可以在不依赖特定店面提取器的情况下独立测试服务规则。
在生产环境中，事件键还应包含一个稳定的观测或转换标识符。仅凭监控键无法区分未来的第二次补货。以原子方式存储事件创建和状态推进，或使用 outbox 模式，以避免进程中断导致通知历史不一致。
# Illustrative observations; no live inventory is represented.
sequence = ["unavailable", "unknown", "available", "available"]
accepted = None
events = []
for observation_number, state in enumerate(sequence):
if state == "unknown":
continue
if accepted == "unavailable" and state == "available":
events.append(("restock", observation_number))
accepted = state
print(events)阶段 5：让通知具体且可审计
有用的补货通知应包含产品名称、精确选项、公开可用性状态、市场或地点、来源 URL 和观测时间。在服务在采集缺口之后观测到可用性时附上简短说明。避免使用暗示预留或在结账时保证库存的措辞。
将投递状态与观测状态分开存储。即使目标拒收消息，也可以正确创建事件。保留事件标识和投递结果，便于运营人员在不人为制造新的库存转换的情况下进行调查。订阅者偏好应控制路由和安静时段。
当来源提供稳定的公开 URL 时，提醒应链接到被监控的产品或变体状态。保留影响选择的变体参数。通用的父级 URL 可能会打开错误尺码，从而让本来准确的事件在收件人看来是错误的。
阶段 6：在不隐藏缺口的情况下运营监控列表
可用性监控除了事件流之外还需要健康视图。为每个监控记录最近一次被接受的观测、最近一次采集尝试、上下文验证状态以及当前证据时效。静默的采集器不应让监控看起来一直处于不可用状态。
使用按主机有界的工作队列，以及与来源允许使用和订阅者预期相匹配的频率。公共流量限制与可用云会话数量相互独立。查看 Scrapeless 定价 并结合被接受的检查次数和证据要求进行评估，包括选项选择和位置设置。
在扩展之前，请手动检查具有代表性的监控。包括一个缺失变体、一个预购、一个依赖位置的报价，以及一个暂时缺少可识别产品内容的页面。最有价值的接受结果是：在存在不确定性时不会产生错误的补货事件。
负责任地处理提醒订阅
即使被监控的页面只包含产品信息，提醒订阅中也可能包含个人联系数据。仅收集所需的最少目标信息，强制实施租户隔离，并履行退订或删除请求。将通知凭据与店面采集设置分开。
“ 机器人排除协议 ”描述的是爬虫指令，并不能替代对特定来源权限的审查。遵守已批准的来源范围，避免访问私人库存或购买流程。可用性观察者无需将产品加入购物车或自动化结账。
结论：在提醒服务中保留不确定性
当被监控的变体是明确的、未知结果可以保留商业状态、并且通知与被接受的转换相绑定时，到货提醒才是可靠的。在扩展监控列表之前先构建状态机和投递历史。服务应解释其观测及任何缺口，同时将购买决策留给收件人。
构建你的到货提醒工作流
将上述采集和验证决策应用到你已获批准的电商来源，并结合 Scrapeless 使用。
立即注册即可获得 $5 免费额度 — 无需信用卡.
领取你的 $5 额度 →常见问题
问：缺少“加入购物车”按钮能否说明已售罄？
单凭按钮缺失无法确认已售罄。所选选项可能尚未解析，页面可能不完整，或布局可能已更改。在接受“不可用”状态之前，需要可识别的产品与可用性证据。
问：未知观测是否应该重置之前的库存状态？
未知观测不应重置上一次被接受的商业状态。应单独标记采集缺口。如果缺口超过策略规定的新鲜度窗口，应将下一次读取归类到“陈旧基线策略”下，而不是断言一个精确的补货时间。
问：提醒是否保证能成功购买？
提醒并不保证能成功购买。在观测与结账之间，可用性可能发生变化，公开的库存标签也不会预留库存。在提醒中包含被监控的选项和观测时间，以便收件人查看当前店面状态。
问：如果出现人机验证或选择器发生变化怎么办？
挑战或选择器变更应暂停受影响的商业决策。在接受更多库存状态之前，检查产品标记并修复采集器。将诊断失败保持在库存转换历史之外。
问：这可以在没有 AI 代理或使用多个工作进程的情况下运行吗？
确定性的计划服务可以在没有 AI 代理的情况下运行。使用有界的每主机并行度和一致的市场上下文。在合适的情况下，地理路由可能有助于重现该上下文，但应核实显示的位置和货币，而不是假定路由本身就能证明它们。
问：需要哪些来源和订阅方权限？
使用经批准的公共来源或授权 API 以及授权的通知目标。审查适用条款并尽量减少订阅方联系数据。监控产品可用性并不授权访问私有库存系统或进行自动化购买。