4. 数据来源与采集

要统计成交率与撤单率，第一步不是写公式，而是把“数据从哪来、每个字段代表什么、时间戳以谁为准”这三件事定清楚。成交率与撤单率本质上是订单生命周期事件的比率，分子分母必须来自同一套可对齐的订单集合，否则统计结果会系统性失真。本节围绕三个数据来源——交易系统（含策略端与订单管理模块）、柜台（券商交易柜台/极速柜台）、交易所回报（成交回报、订单确认、撤单确认）——说明各自能提供什么、字段如何映射、时间戳如何选取与对齐。

三个数据源的分工与可信度差异

交易系统侧记录的是“我方意图与动作”：订单在何时由哪个策略、哪个账户、以什么价格数量生成，何时发出委托，何时主动发起撤单。它的优势是字段完整、含策略标签与内部订单号，劣势是“发出”不等于“被接受”，网络延迟、柜台拒单都会让系统侧记录与市场事实不一致。柜台侧记录的是“通道视角的事实”：委托是否被柜台接受、是否被交易所拒绝、报单编号、通道耗时、席位信息。交易所回报则是“最终事实”：订单是否成交、成交价量、成交编号、撤单是否成功。三者构成一条从意图到结果的证据链，统计时应以交易所回报为成交与撤单的最终判据，以柜台数据判断委托是否有效进入市场，以交易系统数据做策略归因。

关键字段识别与映射

采集时最容易出问题的是“订单主键不统一”。交易系统用内部订单号，柜台用柜台委托号，交易所用报单编号，三者必须建立映射表，否则成交回报无法回挂到策略订单上。建议在委托发出时即落一条映射记录：order_id ↔ cl_ord_id ↔ order_ref，并保留账户与市场标识，因为同一 order_ref 在不同市场可能重复。成交侧需要 trade_id、成交价、成交量、成交时间、买卖方向、手续费；撤单侧需要撤单发起时间、撤单确认时间、撤单结果（成功/部分成交后撤单/失败）以及撤单时的剩余未成交量。统计撤单率时，“部分成交后撤单”应单独归类，不能简单计入“完全撤单”，否则会高估撤单率、低估成交率。

字段口径还要明确“数量单位”和“价格类型”。股票以股为单位、期货以手为单位，若混用会导致成交率计算错误；限价单与市价单的成交概率差异极大，统计时应按价格类型分层。对于批量撤单场景，还需记录撤单请求是逐笔还是批量，批量撤单的确认回报可能合并返回，需按订单号拆分。

时间戳要求：选谁的时间、怎么对齐

时间戳是成交率与撤单率统计中最隐蔽的误差来源。三个来源的时钟并不一致：交易系统用本机时钟，柜台用柜台服务器时钟，交易所回报带交易所时间戳，而本地接收时间又受网络与行情通道影响。实践中的原则是：判定事件先后用交易所时间，评估系统与通道性能用本地接收时间。例如判断“撤单是否在成交前到达”，应以交易所侧的订单确认与撤单确认时间比较，而不是用我方发起撤单的时间，因为发起撤单到交易所收到之间存在延迟，用发起时间会误判为“撤单在先”。

时间精度要求取决于策略频率。日内中低频策略，毫秒级时间戳通常足够；高频或做市策略，需要微秒级甚至纳秒级时间戳，并统一时区与时钟源（如统一使用交易所时区、通过 NTP/PTP 校时）。采集时应同时保留原始时间戳与标准化后的时间戳，标准化只做时区转换与格式统一，不做“修正”，以免破坏可追溯性。对于跨日统计，要明确交易日切分点（如期货夜盘归属下一交易日），否则订单会被切到错误日期。

采集实现要点与校验

落地时建议采用“回报驱动 + 定时对账”的方式：实时订阅柜台与交易所回报，按订单号更新订单状态机（已报、部成、全成、已撤、废单），同时每日收盘后与柜台对账单、交易所成交明细做一次全量对账，核对订单数、成交笔数、成交量与撤单笔数。对账差异常见于废单未回写、部分成交后撤单状态未更新、回报重复推送。采集程序需做幂等处理，以 trade_id 或“订单号+成交序号”去重，避免重复回报导致成交量虚增。

最后，采集字段与时间戳规范应固化为数据字典，明确每个字段的来源系统、类型、单位、是否可空、时间基准。只有字段口径与时间基准统一，后续的成交率、撤单率以及分策略、分时段、分价格类型的下钻统计才具备可比性。