B站内各业务产品迭代离不开各种数据决策，而依托于埋点的用户行为数据在其中起到了 关键作用。埋点也是算法推荐、渠道投放、业务决策的重要数据来源，鉴于此，如何规范埋点设计，高效采集，让业务团队快速直观分析成为了推进业务发展的重要一环。本文主要分享B站过去在埋点规范设计、埋点分析应用的经验，我们相信数据只有流动起来，才能发挥它的价值，The data must flow！

在 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 段组成，分别是业务.页面.模块.位置.类型。对于各段信息进行标准化定义管理，例如埋点类型，我们枚举了点击、曝光、浏览、播放、系统全局、性能 几种类别，在设计埋点时便严格按照这些类型进行枚举选择。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

References

[1] 

[2]  

    以上就是本篇文章【B站埋点分析平台的构建之路】的全部内容了，欢迎阅览 ！ 文章地址：http://dfvalve.xrbh.cn/news/478.html 
     资讯      企业新闻      行情      企业黄页      同类资讯      首页      网站地图      返回首页 迅博思语资讯移动站 http://keant.xrbh.cn/ , 查看更多