> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oddspapi.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 评估 OddsPapi —— 亲自测量延迟、覆盖与恢复

> OddsPapi 试用方案：按博彩商记录观测延迟并对照公布数值、演练恢复路径、用 API 实测核对覆盖范围，并用 CLV 为速度之争给出定论。

我们公布按博彩商实测的延迟数值，且每条更新都携带可供核验的时间戳。所以不必凭信任接受这些数字 —— 本页给出一套试用方案，让评估以您自己的分布数据收尾，而不是一个印象。

***

## 每条更新能让您测量什么

两个指标，分开评判 —— 因为它们的归属方不同：

| 指标   | 计算方式                             | 归属方                       |
| ---- | -------------------------------- | ------------------------- |
| 观测延迟 | `changedAt − bookmakerChangedAt` | **我们**，按博彩商 —— 这就是我们公布的数字 |
| 交付跳程 | `您的接收时间 − ts`                    | **您** —— 取决于部署位置          |

第二个指标读数偏慢，对第一个指标不构成任何结论；先测清两者再归因。两者都在比较您的时钟与我们的时钟，因此在相信 100 毫秒以内的读数之前，请先跑好 NTP。完整时间戳链见[延迟与新鲜度](/zh/api-reference/reliability#延迟与新鲜度)，部署位置见[服务器位置](/zh/api-reference/concepts#服务器位置很重要)。

***

## 试用方案

<Steps>
  <Step title="限定在您真正交易的范围">
    用 `sportIds`、`tournamentIds` 和 `bookmakers` 过滤条件登录，只订阅将来真正承载您交易量的博彩商与运动。在订阅 `odds` 的同时订阅 [`bookmakers`](/zh/websocket/channels/bookmakers) —— 您会希望采集的数据里带有陈旧度信号。
  </Step>

  <Step title="记录原始数据，事后聚合">
    每条更新记录博彩商、`oddsId`、两个差值，以及赛事当时是否为滚球。聚合为按博彩商的分位数（p50 / p95），并区分滚球与赛前 —— 公布的数值是按交付模式区分的，您的对照也应如此。
  </Step>

  <Step title="对照我们公布的数值">
    按博彩商：您实测的 p50 对照[延迟与新鲜度](/zh/api-reference/reliability#延迟与新鲜度)中的代表性 p50，尾部对照 `GET /bookmakers` 上的 `maxDelayLiveInSec` / `maxDelayPregameInSec` 上界。这些上界就是我们的承诺；请以此要求我们。
  </Step>

  <Step title="演练故障路径">
    数据源之间的速度差异更多体现在故障中而非稳态 —— 见下文演练。
  </Step>

  <Step title="与现有数据源同场竞速">
    通过 `externalProviders` 一次性完成赛事映射，在选项键上对齐，并对同一次改线为两个数据源分别计时 —— 映射与方法见[并行第二数据源](/zh/guides/second-feed#测量哪一路更快)。
  </Step>
</Steps>

***

## 演练故障路径

稳态延迟是容易的部分；生产环境中真正拉开数据源差距的是恢复行为。三项演练，试用期内均可安全进行：

* **恢复（resume）** —— 断开连接几秒，携带 `serverEpoch` 与每频道 `lastSeenId` 重连，验证遗漏的更新被无缝重放。这是短暂中断的既定路径。
* **重新快照** —— 保持断开超过重放窗口（`resumeWindowMs`），让网关发出 `snapshot_required`，然后为完整恢复计时：一次 REST 快照，按键以较新的 `changedAt` 合并。该耗时就是您的最坏情况上界 —— 请确认它是您可以接受的。
* **陈旧度统计** —— 在试用期内按博彩商统计 `staleOdds` 事件的次数与持续时间。上游失联会被显式上报而非隐藏；一个从不显示陈旧的数据源未必更新鲜，它可能只是没有告诉您。

前两项的机制见[恢复和重放](/zh/websocket/resume-replay)；标志位见[状态信号](/zh/coverage/bookmakers#状态信号)。

***

## 覆盖范围，以 API 为准

请用实时响应而不是宣传材料核对您的需求清单：

* **您的密钥能看到的博彩商** —— 枚举 `GET /bookmakers`；访问权限按密钥授权，这才是*您的*合同对应的权威清单。
* **各运动的盘口** —— `GET /markets?sportId=…` 逐线值返回您可能收到报价的每个盘口与选项。
* **赛程深度** —— 拉取您所需赛事的一个代表性星期的 `GET /fixtures`，与您自己的赛程需求做差异对比。

目录结构见[覆盖范围](/zh/coverage)、[博彩商覆盖](/zh/coverage/bookmakers)与[盘口覆盖](/zh/coverage/markets)。

***

## 结果层面的定论

逐条更新的秒表竞速回答「谁先看到」；收盘线价值回答这份速度是否变现。试用结束时，把您本会交易的价格与收盘线做关联：

```json theme={null}
"id1400003160574219:pinnacle:14198:0": {
  "olv": { "price": 1.952, "changedAt": 1765975761422 },
  "clv": { "price": 1.952, "changedAt": 1766361894121 }
}
```

`GET /fixtures/odds/clv` 按 `oddsId` 返回开盘与收盘价格 —— 与实时数据流同键，因此与您试用日志的关联零成本。在试用期标记的线路上跑赢收盘线，才是经得起生产检验的评估结论。方法见 [sharp 线路交易与 CLV](/zh/guides/sharp-line-trading)。

***

## 一份完成的评估长什么样

* 按博彩商的观测延迟分布，滚球与赛前分开，与公布的 p50 及上界并列 —— 相符与否一目了然。
* 实测的 resume 与重新快照耗时，让最坏情况恢复成为一个数字，而不是一个指望。
* 基于实时 API 响应、对照您需求清单的覆盖差异。
* 您本会交易线路上的 CLV 关联。

如果您的测量与公布数值不符，我们希望知道：把受影响的博彩商、UTC 时间戳以及您的 `serverEpoch` / `entryId` 发到 [contact@55-tech.com](mailto:contact@55-tech.com)，我们可以快速定位会话。试用权限也通过同一邮箱安排。