Markout、Insights 与 Logs¶
第二阶段调查进阶
第一阶段新人不需要使用 Insights、Markout 或复杂分析。先学会在 Orders 中找到正确订单并核对成交事实；只有在 Senior 指导下需要扩大调查范围时，才使用本页内容。
这三块分别承担三个层次：逐笔成交后的价格变化、聚合模式分析、系统与操作证据。正确顺序通常是先发现问题，再缩小范围，最后回到单笔订单与日志证明。
分析与取证路径¶
发现聚合模式→MARKOUT REPORT
定位具体 Decision/Ticket→ORDER / DECISION / EXECUTION
还原订单→LOGS
补充系统或操作证据
Insights 中的异常柱形或热力格只是调查线索，不是客户投诉成立的证明。
Markout report：逐笔观察成交前后¶
Markout report 可以按日期、Broker、Symbol、Tag、Tier、Taker、Group、Order type、Bucket、Account 筛选，并支持 Arrival / Filled / Executable 基准及 bps / pts / $ 单位切换。
表格把订单身份和客户背景与多个时间窗放在一起。当前可见窗口包括 -1s、-100ms、0ms、100ms、1s、5s、30s、5m，导出可包含完整 18-window markout。
新人阅读顺序¶
- 用 Decision ID、Ticket、Order ID 固定订单；
- 核对 Broker、Account、Client、Group、Tag、Tier；
- 核对 Symbol、Side、Lots、Type、Mode、Bucket；
- 明确当前选择的是 Arrival、Filled 还是 Executable；
- 明确单位是 bps、pts 还是
$； - 从负时间窗读到正时间窗，观察变化方向和持续性；
- 回到 Decision/Execution/Ticks 验证，而不是只凭 markout 定性。
空白窗口表示该记录没有显示相应 markout 数据，不应自动解释为零。
Insights：聚合数据用来找模式¶
Insights 实际包含 Slippage、Markup、Markout、Tag value、Overview。已核实的 Slippage 页面支持日期、Broker、Symbol、Mode、Action、Taker、Group、Account 筛选，并提供 Captured $、Summary final slip、Decisions、Lots。
页面还提供按日、小时×品种、Symbol、Mode、Safe-formula dimension、Tier、Lot band、Bucket、BFC bypass 等视角。
必须遵守的口径¶
- Captured $ 与 final slip 的平均值以 lot 为分母，缩小筛选范围时要同时观察样本量；
- Action = Close 同时包含自愿平仓和 SL/TP/SO 等强制退出，页面没有 order-type breakdown，因此差异只是调查信号；
- Direct/Market 没有 slippage 的 fill 不进入小时热力图相应统计；
Base VMD / M / C / B / Manual / Delay是公式拆分，页面明确说明不是因果；- Bucket 行会重叠，因为同一订单可以命中多个 Bucket，不能把各行相加；
- Bucket 表属于 B-book universe，最终 STP 或 rejected 的命中记录要回 Reports → Decision 查；
- Shadow bucket 仍可能显示为真实分析行，不能当作不存在。
因此新人写分析结论时必须同时带上：筛选范围、指标单位、Decisions、Lots、对比维度以及已知限制。
Logs：三类证据不要混用¶
Audit events¶
Audit events 按时间、Resource、Action、Actor 和关键词查询，适合调查“谁对什么资源做了什么操作”。进入页面后需要选择筛选条件并点击 Search。
Alarm log¶
Alarm log 用于查看 Rule、Severity、Scope、Triggered、Recovered 与 Status。Firing 和 Recovered 是告警引擎状态，不等于订单 Status。
System log¶
System log 包含 API activity 与 Runtime log 标签。API activity 可以按时间、Method、Status 和关键词搜索，并提供可选列与 CSV 导出。Runtime log 用于另一类运行时记录；不要因为导航名称叫 System log 就把所有系统问题都归入同一张表。
问题类型对应入口¶
| 问题 | 第一入口 | 下一步证据 |
|---|---|---|
| 某张订单成交后市场怎样变化 | Markout report | Decision、Ticks |
| 某品种/时段整体滑点偏高 | Insights → Slippage | Markout report 定位 Ticket，再查订单证据 |
| 某标签客户群是否存在特殊表现 | Insights → Tag value / Slippage | Clients、Markout、Decision |
| 谁修改了配置 | Audit events | 对应 Controls 当前配置与变更记录 |
| 是否发生系统告警及恢复 | Alarm log | System summary、System log |
| API 或运行时异常 | System log | Alarm、Execution、受影响订单 |
案例：XAUUSD 某小时滑点偏高¶
任务：在 Insights 发现 XAUUSD 某小时 final slip/lot 偏高后，说明如何验证它是不是系统性问题。
展开参考答案
先记录 Insights 的日期范围、Broker/Mode/Action 等筛选器、时区、Decisions 和 Lots，确认不是极小样本。再切换 Symbol、Mode、Tier、Lot band、Bucket 视角寻找共同范围。进入 Markout report 用相同条件定位具体 Decision ID/Ticket，检查各时间窗；随后在 Decision 核对 Rule/Route/Mode/M/C/B/Final，在 Execution 查 LP/Pool/Latency/Reason，在 Ticks 查报价背景。若多张订单集中于同一系统窗口，再查 Alarm/System log；若怀疑配置变更，查 Audit events。只有这些证据一致后，才能称为系统性问题。禁止的捷径¶
- 用一个 Insights 图表直接判断单笔投诉；
- 忽略筛选条件、时区、单位和样本量；
- 将 Bucket 行相加或把维度拆分解释为因果；
- 把 markout 空白值当成零；
- 用 Alarm 的 Recovered 代替订单恢复证明；
- 只看当前 Controls，不查 Audit events 与历史订单记录。