在 B站，产品的迭代少不了数据指标的监测，公司内各业务线的产品经理、运营、分析师会关注产品内部的各个指标，从数据采集到分析一整套的流程都需要有高效的工具支持，大家日常会使用各种分析模型进行获客、活跃、留存、转化等数据指标分析。

北极星埋点分析平台是内部统一的埋点定义管理、录入、分析平台，目前已经接入B站内数十项业务，管理12W+ 埋点事件信息，日增量上报埋点数据过千亿。通过埋点分析平台提升营销、产品、运营的数据驱动能力。

如图所示，B站的埋点分析平台实现了埋点从设计管理-采集-测试-入库存储-查询分析-埋点下线的全过程管理

过去几年B站的埋点分析平台经历了不断的填坑成长，整体可以分为 2 个阶段

阶段一 ：Excel+info 文档管理埋点设计信息，埋点日志单点上报至不同 Hive 表，下游使用通用型 BI 工具进行可视化分析+离线表 SQL 自定义查询数据指标

阶段二：统一埋点数据上报模型及上报通道，规范埋点采集 SDK，设计迭代埋点分析专用可视化平台，引入 Clickhouse 查询引擎提升查询速度

基于埋点数据流在各个环节流转及管理，抽象为埋点分析平台的主要结构如下

各个环节中相互配合，相互协作，接下来我们简单介绍一下中间的关键模块

埋点设计规范及管理：引入 Spmid 埋点设计命名规范，同时通过埋点管理模块对埋点事件名称、公共属性、类型公共属性、私有属性进行结构化管理，从 Excel/ Info 文档各自管理升级到平台统一录入

埋点测试：通过扫码连接测试设备，并关联埋点管理元数据信息，对上报埋点进行直观的可视化校验

埋点分析：抽象日常埋点数据分析中会高频使用场景，形成了事件分析、漏斗分析、留存分析、路径分析、单用户行为细查、用户分群、自定义 SQL 查询等分析模块，形成低门槛的分析

数据看板：通过存储埋点分析模块的结果，沉淀业务分析指标，提升整体分析结果的复用性，通过数据看板的分享、复制等功能进一步降低普通用户查看埋点数据指标的门槛

运维监控：通过对埋点 event采集时对用户侧触发、上报、服务器接收、数仓归档等几个时间均增加时间戳字段，在下游准确监控埋点上报及延迟情况，另外对埋点新建、使用、存储成本等T+1 同步至数仓补充相关效率指标监控

在业内通常通过 Event track 记录Event（埋点事件）、Session（会话）、User（用户） 三方面的信息，然后在下游数仓中进行梳理清洗使用，形成基于Event-User 为主要结构的埋点数据模型。基于此我们定义了新的事件模型和数据传输协议，序列化及反序列化协议（protocol buffer协议）

为什么事件（Event）和用户（User）两个核心实体结合在一起就可以清晰地描述清楚用户行为，实际上，我们在描述用户行为时，往往只需要描述清楚几个要点，即可将整个行为描述清楚，要点包括：是谁、什么时间、什么地点、以什么方式、干了什么。

对于埋点的命名，我们采用了业内比较通用的 Spmid (Super Position Model)全称超级位置模型命名规范，一个埋点名称由 5 段组成，分别是业务.页面.模块.位置.类型。对于各段信息进行标准化定义管理，例如埋点类型，我们枚举了点击、曝光、浏览、播放、系统全局、性能 几种类别，在设计埋点时便严格按照这些类型进行枚举选择。

同时在埋点属性的基础命名上我们做了一些限制，能有效的提升规范性

• 事件和属性命名统一采用下标命名法或驼峰命名

• 事件和属性的命名单词全部为名词 属性命名时，使用单词为通用名词

• 方便复用通用的字段属性复用已有字段，如 topic_id 、order_id

• 服务避开默认字段属性名避开使用 / | * 空格等特殊字符

基于 Spmid 的埋点命名规范，在我们进行数仓建模时可以根据关键字段信息进行业务域DWD 中间表划分，并进行相关分区字段添加，优化查询速度。

埋点的上报协议侧，我们采取了公共参数、类型公共参数、私有参数的结构。其中类型公共参数、私有参数我们均放在独立扩展字段中使用 JSON 嵌套方式上报，在下游查询中解析。

在没有产品化管理之前，采用文档或表格的方式对埋点信息进行维护

^{图：文档录入埋点参数用例}

在产品功能上线后我们通过标准化的操作完成埋点的定义和录入管理

^{图：埋点管理产品}

在埋点的元数据信息中，我们增加抽样比例、核心埋点标记、自定义分流标记，通过埋点管理平台推送至埋点采集 SDK，针对抽样埋点，实现不发版上报量就能动态控制埋点上报抽样比例，从全量上报到远程下线采集的自助配置，在业务高峰期能降低下游传输、存储压力；对标记为核心埋点数据传输链路上单独分流至高优队列，提升 SLA 保障等级。

埋点元数据产品化管理中我们实现了对属性、属性枚举资产化管理，引入埋点属性组（模板）概念，一次设计，多处引用，降低埋点设计中重复录入，属性命名不统一的问题，长期看来实现埋点设计逐步沉淀为业务资产。

从设计到埋点应用的过程中，各团队在各环节各司其职相互配合，实现从需求->埋点->数据->指标的流转。

为了提升埋点数据准确性，我们设计了埋点测试模块，移动端（iOS端、Android端、iPad端等） 扫码连接后，所有测试设备上报数据通过Nginx转发到Lancer的gateway组件，并直接写入到Kafka集群（用于缓冲），lancer-Collector组件将数据从kafka提取，然后在下游实现可视化的直观展示。在测试模块中关联埋点元数据信息进行直观展示，用于判断埋点是否正常上报。

^{图：数据测试流程图}

^{图：数据测试操作示意图}

业务分析中比较高频的场景是对查询埋点的UV、PV 等基础指标，这类场景我们经过拆解后，发现主要包含以下诉求，基于以下的需求场景我们重新设计了埋点分析产品模块。

• 进行埋点私有参数的过滤

• 进行不同参数的分组聚合

• 对多个埋点事件的结果再进行二次的计算，CTR 指标等

• 查询结果能查看明细和汇总指标

• 查询结果能快速分享并支持二次编辑

^{图：埋点数据分析产品设计}

用户在前端页面发起查询后，会将event_id、 filter param、group param 等参数传递给服务端，在后端的 query engine 中拼接完整的查询 SQL，提交查询任务。在服务端首次接到查询任务后，会将任务提交查询队列，并同时返回任务ID。异步执行查询任务，在获取到结果后存入缓存。前端应用在获取到任务ID后，会根据任务ID定时获取任务结果，直到查询到结果展示。

在计算引擎的选择上 ，早期使用 Hive 作为计算引擎，单个事件分析查询通常耗时超过 10min，后续采用 clickhouse 做为查询引擎后，相同的查询分析控制在 亚秒级就能得到结果，85%+查询分析控制在 30s 内完成。

^{图：埋点数据分析流程示意图}

服务端在前端传参后的分析 SQL 基于最简单的单个事件分析逐步叠加，完善为单事件、多事件、关联用户标签、用户人群等复杂场景，以下为事件分析发起查询时拼接的查询样例。

对于用户关键业务流程中的转化，这类我们一般使用漏斗模块进行分析。通过拆解 BI 分析师及访谈业务产品和运营，对漏斗分析需要包含以下几项能力

• 转化步骤间能设置不同事件转化的先后触发

• 每个步骤过滤不同的埋点私有参数

• 能查看每个转化步骤过去一段时间变化趋势

• 单独设置漏斗转化窗口期

^{图：埋点漏斗分析产品设计}

针对产品页面上简化后的漏斗分析

除了事件分析、漏斗分析，我们不断抽象业务分析的模型，实现了一系列的基础查询模块，让业务运营、产品和分析师能对埋点数据的基础查询直接通过产品页面拖拽点选完成分析。

数据分析结果沉淀上遇到的坑，在分析结果的保存上，我们集合到了数据看板中。

这个部分在随着业务分析的增加，到后期已经达到了过千个业务分析数据看板，用户第一次打开时并发的查询导致加载缓慢。

1. 初期用户打开即刷新看板内的分析卡片，结果做缓存，避免重复查询

2. 随着卡片越来越多，为了提升看数效率，我们在每日凌晨刷新一遍 T+1 动态更新类型的看板卡片

3. 随着刷新的卡片增加，以及公司降本增效的要求，我们优化了查询更新机制。对所有看板进行访问日志记录，根据看板过去7 日访问情况针对新的刷新。在不降低业务查看体验前提下，大大降低了服务器压力

^{图：埋点数据看板设计}

埋点分析平台致力于提升B站对埋点数据的采集、管理、分析提效，目前已经接入B站数十个业务端产品，周新增数百个埋点，我们也在思考如何进一步提升埋点管理和分析应用的效率，以发挥数据价值。

• 埋点动态 TTL 生命周期管理，能自动化的精细到每个 event_id，降本增效

• 基于埋点管理平台配置化的中间表生成机制，高效划分业务 DWD 表

• 与公司内 AB 系统、用户标签等系统更深度的融合，让数据在各系统间流转

References

[1] https://mp.weixin.qq.com/s/dUs7WUKUDOf9lLG6tzdk0g

[2]  https://blog.naaln.com/2017/08/alibaba-data-track-1/

以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，欢迎点个“在看”吧！