旅游行业大多数竞争性价格监控都建立在沙地上。团队抓取供应商网站，存下 HTML 或一张 PNG，然后称之为证据。当客户问”你怎么知道下午两点价格更低？”时，答案是一张由定时任务打上时间戳的截图。这不是智能，这是剪贴簿。

HotelByte 的价格智能白皮书提出了一个更严格的主张：价格智能必须是一个可追溯的事实系统。每一次观察都必须携带请求和响应的加密指纹、结构化的错误分类，以及一条可被独立查询的时序记录。没有这些，你只有轶事；有了这些，你才有证据。

行业盲区：把抓取当作真相

传统的价格监控方法把网页当作真相来源。工程师编写爬虫解析 HTML、提取价格展示、对 DOM 做快照。这在短期内有效，直到失效为止。供应商网站改了页面结构，A/B 测试对不同访客展示不同价格，动态定价注入了不反映市场状况的个性化费率。而当争议发生时，唯一的证据是一张截图——它无法证明爬虫实际请求了什么，也无法证明供应商实际返回了什么。

更深层的问题是认识论层面的。截图捕捉的是浏览器渲染的内容，而不是 API 说了什么、用了什么凭证、发送了什么参数，以及响应是否被限流、超时或返回了错误。旅游业运行在 B2B API 合约之上，而不是零售网页之上。监控页面而不是 API，就像通过看一幅天空的画来确认天气。

HotelByte 的取舍：事实优先于渲染

HotelByte 通过认证 API 调用而非网页抓取来监控供应商价格。每次调用都被记录为时序数据库中的不可变事实，请求和响应的 SHA-256 哈希值构成了加密可验证的证据。系统在每个分析周期内评估多达 90 万次供应商价格调用，覆盖酒店-市场-供应商-提前期-入住时长-入住人数的全组合。

这种方法带来的收益：

  • 可验证的来源。每一条价格观察都可以通过重新计算存储的请求和响应的 SHA-256 哈希来独立验证。
  • 结构化错误分类。失败被分类为限流、超时、取消或供应商错误，支持透明的 SLA 报告，而不是静默的数据缺口。
  • 纵向趋势分析。费率事实被不可变地存储，支持历史价格走势分析和供应商覆盖度追踪。
  • 尊重式交互。按来源市场的信号量和限流熔断器保护供应商 API 容量，维护长期的数据访问关系。

代价：

  • API 依赖。系统只能监控提供认证 API 访问的供应商，纯网页供应商不在范围内。
  • 凭证管理。每次爬取任务在分发前都要针对已认证的供应商凭证进行验证。这增加了运维复杂度，但确保了查询可追溯。
  • 计算规模。每周期 90 万次调用成本不菲。HotelByte 通过动态查询频率集中资源：距入住 7 天内的日期每 2 小时查询一次，远期日期每 24 小时查询一次。

证据优先原则

白皮书的中心论断很精确：”价格智能是一个可追溯的事实系统，而不是截图对比。” 这把竞争性基准测试从一个营销特性重新定义为治理能力。当企业客户问”你能证明这个价格曾经可用吗？”时，答案必须是一条带有加密完整性的可查询事实记录——而不是一张可能来自任意浏览器会话的截图。

HotelByte 通过以下具体机制实现这一点：

  • 供应商调用事实（Supplier Call Facts）记录每次爬取任务的完整生命周期：标识符、酒店和供应商元数据、来源市场、凭证、请求和响应的 SHA-256 哈希、HTTP 状态、延迟、错误分类和限流命中标记。
  • 费率事实（Rate Facts）记录成功响应的结构化内容：酒店、供应商、市场、入住参数、房型、费率套餐、餐食、可退模式、净价和货币。
  • 阈值触发告警配合 24 小时冷却期，确保客户仅在观察到的节省达到可配置百分比阈值时才收到通知，防止告警疲劳。
  • HMAC 签名报告下载带有 90 天有效期和访问日志，保护竞争数据不被未授权共享。

白皮书阅读路径

如果你正在构建或评估价格智能系统，重点关注以下章节：

  • 设计原则（”数据驱动决策”与”尊重式爬取”）：了解结构化错误分类和限流熔断器设计。
  • 爬虫层：并发控制、按来源市场信号量和凭证验证管道。
  • 事实存储层：时序数据模型，以及供应商调用事实与费率事实的区别。
  • 对比层：统一多供应商查询方法和基准价格对比逻辑。
  • 可审计性：外部评审者可用来验证爬取完整性和历史趋势的机制。

延伸阅读