一场渠道大会直播结束的第二天早上,客户市场部把三张截图发到群里,配了一句"到底信哪个"。
平台后台显示峰值同时在线 8642,CDN 厂商控制台给的是 11208,他们自己埋点的数据看板显示 7391。三个数字,最大的比最小的多出 51%。市场总监要拿这个数字写复盘 PPT 给老板看,写哪个都心虚。
于是下午我们把三方拉到一间会议室,对了两个多小时的口径。这篇就是那次对账的记录。直播并发统计这件事,表面是技术问题,实际是定义问题——三方没有一个算错了,他们只是在算不同的东西。
第一处差异:去重的单位不一样
先问最基础的:一个人算一个,还是一个连接算一个?
CDN 那边算的是活跃连接数。同一个观众,如果他手机看着、电脑上又开了一个,就是两个连接。更麻烦的是,HLS 协议下播放器会持续拉取分片,某些播放器实现会同时开两到三个 TCP 连接做预取,一个观众能贡献三个连接。
平台后台算的是登录态用户数,按 user_id 去重。同一个人两个设备只算一个。
自建埋点算的是心跳会话数,按前端生成的 session_id 去重。同一个人两个设备是两个 session,但同一设备刷新页面会生成新 session——如果旧 session 还没超时,就会重复计数一小段时间。
三个口径:连接、人、会话。数字对不上是必然的。
摄行科技做直播并发统计方案时,现在会强制客户先在合同附件里写死一句话:"本项目所称同时在线,指按 user_id 去重后的登录态用户数。"就这一句,后面能省掉无数扯皮。
第二处差异:采样周期决定峰值高低
第二个大头是采样。
CDN 的控制台是 1 分钟采样一次,取该分钟内的最大值。平台后台是 5 分钟采样,取采样瞬间的快照。自建埋点是 30 秒心跳,按 30 秒窗口聚合。
这个差异在峰值上体现得最狠。他们那场直播,主讲人在第 47 分钟放了一个抽奖二维码,两分钟内涌进来一大批人,然后迅速走掉一半。
1 分钟采样抓到了这个尖峰。5 分钟采样的快照恰好落在尖峰之后,完美错过。30 秒窗口聚合抓到了,但因为是窗口内平均而不是最大值,尖峰被抹平了三成。
所以峰值这个指标,不说明采样周期就没有意义。我们后来给他们定的规则是:所有对外披露的峰值,统一使用 1 分钟窗口内的最大值,并且在数字后面标注口径。PPT 里那行小字看着不起眼,但半年后有人翻旧账时能救命。
第三处差异:心跳超时,尾巴有多长
第三处是最隐蔽的。观众关掉浏览器的那一刻,系统怎么知道他走了?
答案是不知道,只能靠超时判断。心跳间隔 30 秒的话,超时通常设 90 秒——连续三次心跳没来就认为离线。
这意味着每个离开的观众,都会在在线人数里多挂 60 到 90 秒。直播过程中人来人往,这个"尾巴"是持续存在的。人流越大,尾巴贡献的虚高越明显。
我们粗算了一下他们那场:平均每分钟离开约 180 人,尾巴按 75 秒算,任意时刻大概有 225 个已经走了但还在计数里的幽灵。占八千的比例接近 3%。
CDN 那边的超时更长,某些厂商是 5 分钟。这就是为什么 CDN 的数字总是三方里最大的——除了连接口径的重复,还有一条更长的尾巴。
把超时改短行不行?可以,但会带来另一个问题:网络抖动时正常观看的用户会被误判离线,人数曲线出现锯齿。我们试过把超时压到 45 秒,曲线抖得没法看。90 秒是我们现在的推荐值,配 30 秒心跳。
关于大并发下播放端的连接行为,WebRTC企业直播的万人并发实测那篇里讲了调度层怎么看待这些连接。
对完口径,数字最后落在哪
三处差异拆清楚以后,我们做了一次回算。
拿自建埋点的原始日志,按 user_id 重新去重(把同一账号多设备合并),采样窗口统一到 1 分钟取最大值,心跳超时按 90 秒截断并扣除幽灵尾巴。算出来的峰值是 7860。
CDN 的 11208 里,扣掉播放器多连接(实测系数约 1.28)和更长的超时尾巴,折算回来是 8100 左右。平台的 8642 因为 5 分钟采样错过尖峰,反而偏低,把采样补齐后是 8390。
三个数字从 7391/8642/11208 收敛到 7860/8390/8100。剩下的 6.7% 差异来自各家对"有效播放"的判定不同——有的要求播放器真的在解码,有的只要请求了分片就算。这部分我们没继续深挖,对业务决策已经没有影响了。
摄行科技的经验是,直播并发统计的对账做到 10% 以内就可以收手了。要做到完全一致,成本高得不合算,而且没有意义——业务上关心的是量级和趋势,不是个位数。
那这个数字到底该写多少
会议最后市场总监还是要一个数。我们给的建议是写 7860,并在脚注里注明"按登录用户去重、1 分钟窗口峰值"。
理由是这个数字最保守,而且口径最清楚。如果明年同期做对比,只要口径一致,趋势就是可信的。用 CDN 那个 11208 当然更好看,但明年万一换了 CDN 厂商,基准就断了。
顺带说一句,我们劝住了他们另一个想法——把"累计观看人次"当成"观看人数"来写。那场的累计人次是 23000 多,是所有进入过直播间的去重用户数。这个数字本身没问题,但跟同时在线是两回事,放在一起容易误导。复盘 PPT 里两个指标都列,各自标清楚定义,是最稳妥的做法。项目验收环节该怎么写这些指标,直播项目验收标准该写哪几条里有具体条款示例。
埋点侧的几个实操建议
心跳里带上播放状态。这是摄行科技做埋点方案时的头一条建议。只发心跳不带状态,就区分不了"页面开着但暂停了"和"正在看"。加一个 playing 布尔值,成本几乎为零,但能算出真实观看时长。
session_id 要跨刷新保持。存在 sessionStorage 里而不是内存变量里,页面刷新不重新生成。这一条能消掉刷新造成的重复计数。
多设备登录要不要合并,提前定。有些企业培训场景故意允许多设备,合并了反而不符合业务预期。这个没有标准答案,但必须提前定,不能算完了再讨论。
峰值和曲线一起存。只存峰值,事后想换口径重算就没数据了。原始的分钟级曲线数据量很小,存三年也没多少空间。
关于用户数据的采集与留存边界,可以参考国家网信部门公开的相关管理规定(samr.gov.cn)以及广电主管部门对网络视听服务的规范要求(nrta.gov.cn)。培训类场景的到课统计逻辑,银行网点培训的千点位同步直播那篇里有实际落地的表结构设计。
需要有人帮你对一次账
如果你也在被三个数字困扰,或者更常见的情况——只有一个数字但没人知道它是怎么算出来的,可以把三样东西发给摄行科技:平台后台的统计说明文档、CDN 厂商的指标定义页面、你们自己埋点的字段设计。我们免费帮你出一份口径差异对照表,标出哪几处会造成偏差、各自贡献多少。
直播并发统计做扎实了,后面的转化分析、内容复盘才有地基。要做完整的数据方案或者整场直播技术保障,把场次规模和现有系统情况告诉摄行科技,我们按实际情况给方案和报价,不套模板。
#摄行科技
