先说结论
按"用户播放时长"结算的激励体系，工程难点不在播放器本身，而在两件事：统计口径是否可信、账能不能对上。播放器是现成的，统计链路是自己写的——口径定义错、去重缺失、上报丢重、对账不可下钻，任何一环出问题，结算金额都会偏差，而偏差无法举证。
一条可用的原则是：把"统计"当成一条独立的数据管线来做，而不是在业务代码里顺手累加。 下面按有效播放判定、去重、上报幂等、对账下钻、数据留存五段拆实现要点。
一、有效播放判定：把口径做成配置，不要硬编码
"有效播放"通常是"单次播放达到某时长阈值才计入"这类规则。实现上要避免三种写法：
- 把阈值写死在客户端。规则调整要求发版，且各端版本不一致会导致口径分裂。
- 只统计次数不统计时长。按次数结算与按时长结算的结果差异会随内容长度放大，对账时无法解释。
- 播放事件与内容、广告位不关联。缺少维度就无法下钻，出差异时只能整体怀疑。
推荐做法：服务端下发统计规则（阈值、心跳周期、判定字段），客户端按规则上报原始事件，服务端按规则判定。规则版本号随事件一起入库，这样"同一批数据用不同规则算出的结果不同"是可解释、可复算的。
一个容易被忽略的细节是心跳事件。长内容需要周期性上报播放进度，否则中途退出、切后台、熄屏都无法区分。心跳周期越短精度越高、流量越大，需要一个明确取舍并写进规则。
图 5：统计规则由服务端下发，客户端只上报原始事件，规则版本随数据入库
二、去重：设备与账号双维度，且要能申诉
同一用户反复刷新、同一设备切换账号、同一账号多设备登录，都会污染统计。只按账号去重会漏掉"多账号刷量"，只按设备去重会误伤"换机用户"。稳妥的是设备 + 账号双维度分别计数，再按业务规则取交集或并集，并把两套计数都留存。
去重键的设计要点：
- 设备标识要稳定但不唯一依赖。客户端可获取的设备标识存在重置与缺失的情况，需要一个"本地生成 + 服务端补偿"的稳定标识。
- 时间窗口要显式。去重通常按"自然日"或"滚动窗口"进行，窗口定义要写清楚，否则跨天行为无法解释。
- 保留原始事件。去重后只留存聚合值，等于放弃了申诉能力。原始事件至少保留到结算周期结束后的一段时间。
三、上报链路：幂等、重传与乱序
客户端上报有三类不可避免的问题：网络失败导致丢事件、重试导致重复事件、多端并发导致乱序。
处理方式：
- 每条事件带全局事件 ID，服务端以该 ID 做唯一约束，重复入库直接忽略。这是幂等的基础。
- 客户端本地队列 + 失败重传，重传时沿用原事件 ID，不生成新 ID。
- 服务端按事件时间而非到达时间排序。到达时间只用于监控链路健康度，不参与业务判定。
- 批量上报。逐条上报在弱网下失败率高，批量上报要把"批内单条失败"与"整批失败"区分开，避免整批重传放大重复。
监控上至少要盯三个指标：上报量突降、重复率突升、乱序延迟中位数。 这三个指标异常通常对应"客户端版本回归""重传逻辑出错""服务端时间处理有 bug"。
图 6：事件 ID 全局唯一 + 服务端唯一约束，是幂等入库的前提
四、结算与对账：日粒度对齐、差异下钻
外部结算数据通常按天给出。系统要能回答三个问题：某天的总数差多少、差在哪个维度、差异是否可解释。
实现要点：
- 日粒度落库：自有统计与外部结算数据都按"自然日 + 内容 + 广告位（或权益位）"落一张对账表，避免只存总数。
- 差异下钻两级：先按维度（内容 / 广告位）定位到差异块，再按明细（设备 / 账号）定位到具体记录。只有两级都能下钻，差异才有解释能力。
- 差异分类：把差异归为"口径差、时间差、去重差、链路丢失"四类，每类有对应的排查路径。把差异直接记为"外部算错了"是危险的做法——一旦形成习惯，真实链路问题会被长期掩盖。
- 对账结果可回溯：每次对账的输入快照与结论要留存，便于后续复核。
五、数据留存与权限
- 留存量级要与结算周期匹配。原始事件体量通常远大于聚合数据，需要冷热分离：近端查询走聚合表，原始事件落冷存储。
- 金额一律以分为单位的整数存储，全程不做浮点运算，避免累加误差。
- 对账数据要按角色隔离。渠道方只应看到自己的数据，多租户隔离要在查询层强制生效，而不是靠调用方自觉。
- 关键操作用事件日志留痕：口径调整、去重规则变更、对账结论修正，都要有操作记录。这类系统的审计要求通常比业务系统更高。
| 环节 | 核心职责 | 关键约束 |
|---|---|---|
| 采集 | 上报播放与心跳原始事件 | 事件 ID 全局唯一、带规则版本 |
| 判定 | 按服务端下发规则判定有效播放 | 规则可配置、判定可复算 |
| 去重 | 设备与账号双维度去重 | 双套计数留存、窗口显式定义 |
| 对账 | 自有数据与外部结算按日对齐 | 两级下钻、差异分类留存 |
| 留存 | 原始事件冷存、聚合热查 | 留存期覆盖结算与申诉窗口 |
六、常见问题
Q1：为什么不能直接在客户端累加播放时长？
客户端累加无法防篡改、无法去重、无法审计。客户端只应上报原始事件与心跳，判定与统计全部在服务端完成。
Q2：去重按账号还是按设备？
两者都要，且分别计数。只按一种都会留下盲区：只按账号漏多账号刷量，只按设备误伤换机用户。口径按业务规则取交集或并集，并把两套数据都留存。
Q3：对账差 0.5% 需要处理吗？
需要，但要分类处理。先确认差异属于口径差、时间差、去重差还是链路丢失，再决定是否调整。不分类直接归因于"外部误差"，会掩盖真实的链路问题。
Q4：原始事件要留多久？
至少覆盖一个完整结算周期加上申诉窗口。仅留存聚合值等于放弃举证能力。
Q5：多端同时在线怎么处理？
按账号 + 设备维度分别统计，多端并发不合并为一次播放，也不重复计入两次，具体规则由业务口径定义并在规则版本中固化。
