优惠监测：追踪优惠券、组合装和促销横幅
Scrapeless Agent Browser 让你在渲染后的店面环境中检查公开的促销横幅和交互式商品优惠。
摘要
- 横幅是已宣传优惠活动的证据。 它不代表特定购物篮一定会获得折扣。
- 优惠条件是第一类数据。 保留可享资格、数量、门槛、排除项和可见时间限制。
- 组合装需要自己的比较基准。 在计算单位金额之前，先记录所含商品和数量。
- “检测”和“验证”是不同状态。 区分观察到的文案与经授权测试确认的优惠金额。
流程一览：捕获宣传声明和优惠条件
优惠监测将公开的活动信息和优惠变更转化为具有明示证据的结构化观测数据。该流水线会发现活动展示位置，抓取其文案，抽取条件，关联商品，并对变更进行分类。其输出应说明观测到了什么、以及哪些仍未被验证。
针对活动、促销机制、商品优惠和集合观测分别使用独立记录。站点级横幅可以描述一个活动；优惠码描述一种可能的机制；商品页面提供一个可见的优惠。将这些记录关联起来，需要证据表明该活动适用于该商品和该购物场景。
此处的 retail pricing pipeline 提供更广泛的采集模式。优惠监测增加了对条件和宣传声明的解释。一个更低的可见价格是一种信号，而新增组合装、仅会员可用的优惠码或免运门槛则是不同的商业事件。
前置条件：定义展示面与验证范围
从经批准的公共首页横幅、活动落地页、集合卡片、商品购买区域和优惠条款页面开始。为每个展示面记录市场和设备视口。移动端横幅和桌面端主视觉可能以不同文案或链接描述同一活动。
定义监测是仅捕获广告，还是也执行经授权的购物篮测试。本指南的采集流程是公共页面观测；它不会提交订单，也不会声称优惠券已被兑换。任何结账或购物车验证都需要独立授权、受控测试条件以及记录结果。
在编写抽取规则之前，先创建优惠分类体系。常用类别包括直接降价、优惠券、数量优惠、固定组合装、赠品和运费激励。当信息缺乏细节时，允许“未知机制”。模型或解析器不应用最常见的优惠模式来填补空白。
阶段 1：在各展示面发现活动
活动发现应保留消息出现的位置以及其链接到的条款页面。检查公告栏、主视觉区域、促销集合、商品徽标和链接条款。有轮播横幅时需要制定观测策略：要么捕获初始可见消息，要么捕获一个有记录的、有限的公共状态集合。
当文案出现在图片中时，保留原始文本以及允许的截图或证据引用。图片文件名或替代文本有助于发现，但不应被视为完整的优惠条款。 text-alternative requirements 区分非文本内容与其无障碍替代内容；你的证据应记录实际被读取的是哪一种表现形式。
使用内容签名对重复消息进行分组，同时不丢弃其投放位置历史。同一优惠券在首页和商品页展示时，可以视为一个机制的多次观测。有不同排除项或市场条件时，即便活动名称相同，也应创建不同版本。
阶段 2：在不猜测的前提下标准化条件
优惠标准化应在每个抽取出的条件旁保留原始宣传声明。捕获优惠码、利益类型、门槛金额和货币、适用品类或商品、排除项、会员要求、数量规则以及声明的有效期窗口。当公开证据未提及时，将字段留空。
将含糊的日期以原始文本形式保留，并附带观测时的市场上下文。没有本地化信息时，简写日期可能不清楚；倒计时描述的是相对展示，而非永久可靠的结束时间。不要把不断变化的倒计时在每次采集中都当成一个新优惠。
此处的 Shopify discount-combination rules 说明了为什么不能简单地把分别宣传的优惠直接相加。监测系统应记录优惠组合是被明示、未知，还是在受控场景下已验证。仅凭可见的优惠券文案，无法确定运费优惠与商品折扣可以叠加。
阶段 3：将优惠与商品进行关联
优惠与商品的匹配应遵循明确的适用证据。促销落地页、商品徽标或条款列表都可以支持这种关联；与通用站点级横幅的空间邻近则未必可以。保留匹配原因和范围，而不是把每个活动分配给全部目录商品。
将普通报价和促销报价保存在不同字段中。 Offer data model 对表示商业条款很有用，但你的应用仍需要可享资格和验证字段。对比价格应保持为商家展示的参考金额，而不是被改写成声称的历史售价。
对于组合装，要记录每个组成部分及其所需数量。仅在所含商品等价且分摊规则已明示时，才比较有效单位金额。免费配件可能有价值，但为其虚构现金价值会造成误导性的折扣百分比。
| Mechanic | Capture | 请勿推断 |
|---|---|---|
| 优惠券 | 代码、声明的优惠、排除项、门槛 | 仅凭横幅成功兑换 |
| 组合包 | 组件 ID、数量、组合包总价 | 不同商品的等值优惠 |
| 降价 | 当前金额和对比金额、变体 | 从删除线文本中得到的历史价格 |
| 运费优惠 | 目的地范围和门槛 | 向每个地址免费配送 |
| 会员优惠 | 公开的适用对象表述 | 匿名购物者是否可享受 |
第 4 步：在本地测试适用性规则
一条适用性规则应在预设场景下返回一个明确的决策。下面的 Python 示例使用示意数值来说明固定组合包的最低数量要求。它展示的是一次内部规则评估；并不验证真实促销，也不确认商家会接受某个购物篮。
将规则版本和输入数量与推导出的决策一并保存。如果证据没有说明最低数量，那么正确状态应为未知，而不是符合条件。真实组合包还可能要求特定组件组合，因此仅检查总数量只适用于这个刻意收窄的示例。
# Illustrative policy check, not merchant checkout validation.
observed_offer = {"mechanic": "quantity_bundle", "minimum_quantity": 3}
scenario = {"eligible_item_quantity": 2}
minimum = observed_offer.get("minimum_quantity")
if minimum is None:
decision = "unknown"
else:
decision = "eligible" if scenario["eligible_item_quantity"] >= minimum else "ineligible"
print(decision)第 5 步：为营销活动变更分类
营销活动的变更应区分外观变化、文案修改、条件修改、优惠变更以及确认下线。与已过期的条款页面相比，在轮播位中不再显示的横幅只能算较弱的活动结束证据。保持观测策略一致，避免把投放位置变化当成商业主张。
一条告警应包含营销活动标识、市场、变更前后条款、来源界面、受影响的商品范围以及核实状态。将修改后的优惠券限制与价格降价分开路由。分析师由此可以评估促销策略，而不必研究充满无关内容的原始页面差异。
将最近一次确认的营销活动版本与最新观测结果一并存储。如果采集失败，将该活动的新鲜度标记为过期，而不是结束该活动。使用 Scrapeless pricing 在你需要的各类界面之间，为采集和证据留存做预算规划；横幅监控与完整变体检查的工作量是不同的。
第 6 步：审视标示节省金额的边界
标示的节省金额在比较基准尚未明确前，应始终视为一种主张。保留原始措辞、参考价格类型以及任何限定条件。监控系统可以报告某零售商宣称折扣百分比，而无需认可其计算方法，或断言该折扣适用于每件商品。
为了形成负责任的审核流程，应将观测到的广告、内部分析估算以及经授权的核实结果分开。为分析师翻译条件时要保留源语言。简明的翻译摘要固然有用，但在排除条款或截止日期引发争议时，原文措辞是必须的。
先从一个小型营销活动样本开始，并手动检查其中的疑难案例。包括一个会员代码、一个混合商品组合包以及一个运费门槛。在这些条件都能被表达而不被简化为普通商品价格之后，再扩大自动化范围。
结论：追踪优惠及其条件
促销监控应保留商业主张、其可见条件，以及支撑每种解读的证据。将营销活动历史与价格历史分开构建，保留组合包构成，并如实标注兑换状态。一条有用的告警应告诉分析师发生了什么变化，以及该变化可能影响哪种购物者情境。
构建你的促销监控工作流
将上述采集与校验决策应用到你经批准的电商来源上，并结合 Scrapeless 使用。
立即注册即可获得 $5 免费额度 — 无需信用卡.
领取你的 $5 额度 →常见问题
问：检测到优惠券是否能证明它可用？
检测到优惠券只能证明其代码或信息在被观测的界面上是可见的。兑换结果可能取决于购物篮内容、账户资格、地理位置及其他条件。需明确区分“已宣传”和“已验证”的状态。
问：组合包价格应该如何比较？
仅在保留组件、数量和分摊策略之后再比较组合包价格。对于等量单位，有效单位价格可能有用。不要给赠品虚构价格，也不要将混合组合包直接与单个不相关商品相比。
问：横幅的消失能否用来确认促销已经结束？
仅凭横幅消失可能不足以确认促销结束。该位置可能轮播，或因视口不同而变化。应进行多次一致性观察，并在可用时检查明确的结束条款，同时在公共证据不完整时保留不确定性。
问：当 DOM 发生变化或加载挑战（challenge）时应该发生什么？
DOM 变化或加载挑战时，应产生一次收集状态。更新促销历史前，要确认活动展示位置及其条款。缺失的抽取文本不能自动撤销优惠券或将活动标记为已结束。
问：收集是否可以在没有 AI 的情况下运行？是否需要代理（proxies）？
收集和确定性促销规则可以在没有 AI 的情况下运行。适当时，地理路由可用于支持在公共市场中的一致观察。对每个主机保持并行工作有界，并核实实际国家和货币，而不是仅依赖路由设置。
问：促销监测适用哪些访问边界？
促销监测应遵循已批准的公共来源范围和适用条款。仅限账号的折扣、购物车变更和结账实验需要单独授权。当这些附加操作不在范围内时，应让公共观察者专注于活动证据。