Skip to main content
我们在延迟与新鲜度中公布各博彩商的延迟数字，并在 GET /bookmakers 上提供实时上界。本页是这些数字背后的方法 —— 究竟测量什么、数字从何而来、以及如何自行复现。没有方法支撑的数字只是营销；有方法约束的数字才是承诺。

​
测量的量

每条赔率更新一个指标：
  • bookmakerChangedAt —— 博彩商自己发布的变更时间戳。
  • changedAt —— OddsPapi 在博彩商处观察到变更的时间。
这是我们负责的延迟：从价格在源头变动，到我们拿到它。它刻意排除了观察之后的一切环节 —— 见数字不包含什么。 延迟按博彩商聚合，并按交付模式拆分 —— 滚球、赛前、赛前主盘 —— 因为各模式走不同的采集路径，延迟各不相同。一个混合数字恰恰会掩盖最重要的差异。

​
实测与估计

每个公布的数字都标注两种模式之一： 模式与每个数字并列公布。如果某行标注为估计，请将其视为我们诚实的上界推测，而非测量结果 —— 另请注意 bookmakerChangedAt 是博彩商的时钟而非我们的，因此即便是实测值也继承了数据源的时间戳质量。

​
数字在哪里

两个载体，职责不同：
  • GET /bookmakers —— 实时权威来源。maxDelayLiveInSec、maxDelayPregameInSec 与 maxDelayPregameMainInSec 按博彩商、按交付模式给出最大预期刷新延迟，以滚动值维护。这些上界就是承诺；请据此要求我们。
  • 文档表格 —— 试用者最常问到的博彩商的滚动 p50 代表性快照。它用于说明；端点才是准绳。
两者不一致时，以端点为准 —— 它随数据流更新，文档页面随编辑更新。

​
数字不包含什么

观察延迟止于 changedAt。其后的环节：
  • 内部管道 —— 从观察到网关发送约增加 20 毫秒（p50）。
  • 合并 —— 更新在固定约 6 毫秒的窗口内批处理，最新值胜出；没有任何状态丢失，见传输语义。
  • 传输跳 —— 从网关 ts 到您的接收取决于您的部署位置；同区部署可低至约 5 毫秒（见服务器位置）。
刻意排除这些是有原因的：传输跳主要由您的部署决定，把它折进公布数字会让数字无法核验。每条更新携带完整的时间戳链（bookmakerChangedAt、changedAt、ts），每一段都可以单独测量。

​
自行复现

这套方法没有任何特权成分 —— 我们聚合的时间戳就在您收到的每条更新上。在试用期按博彩商记录 changedAt − bookmakerChangedAt，分滚球与赛前，取 p50，与公布的行并排对比。完整方案（含恢复演练与 CLV 对账）见评估数据源；与现有数据源在同一批盘口变动上竞速见作为第二数据源运行。 如果您的测量与我们不符，请将受影响的博彩商与 UTC 时间戳发送至 contact@55-tech.com —— 可复现的分歧就是一份缺陷报告，我们也会如此对待。