一、为什么要做埋点治理
用户行为数据管理和对应的行为数据分析的关系十分紧密,如何在产品层面上应用好,前置条件是埋点数据需要做到标准化、规范化的管理和应用,这是很多行业内公司及团队都会碰到的课题。
然而随着业务的迭代变更,部分埋点数据失去效用。为了确保数据的质量、效率、安全、标准及易用性,需要对埋点数据进行治理。不仅是存量数据的治理,新增数据更是要保证从源头开始就是正确的。在埋点数据的生命周期内,每个环节制定原则性的管理方法和具体的落地措施。一个稳定的治理链路是埋点治理的基石。
埋点数据从生产到消费使用会有一个比较长的链路,可以从生产环节和消费环节两个方向来看。
从生产环节来看,业内都会将埋点采集抽象为可复用的埋点数据模型并集成到SDK内,避免每次业务开发都要重新定义采集的格式规范。这个SDK通常会划分为iOS、安卓、Web、服务端等等,还有以backload的方式批量导入的离线数据,这是数据的生产侧。在数据流转侧,通过抽取转换加载(ETL)的方式进入到传输流,这里有两条链路,一部分业务需要消费数据实时流,另一部分业务是消费离线数据。实时流的消费可能会用于算法推荐,或者实时的数据分析,实时的监控看板。离线的数据,就是关于数仓的ODS到DWD,再到ADS的这个部分。在离线存储的部分,数据的存储会采用不同的介质,比如常见的HDFS、Parquet等等。查询引擎包含了ClickHouse、Presto、Hive等行业内主流引擎,通常也提供了一个可视化的Web,给产品经理、分析师、运营等同学去操作分析。
从消费环节来看,业务的同学通过点选的操作去查看埋点常见的PV、UV数据,前端把操作拼接的参数传给查询引擎,作为查询SQL的拼写。业内关于查询引擎的采纳,根据每个公司的数据量会有多种不同的方案。常见的情况是:如果数据量比较小,那就直接用Hive查询,如果数据量多一些,那可能会用Presto。目前对于日增千亿的数据量级,可能采用的是ClickHouse、Doris等作为查询引擎。为支撑整个数据链路,还会采用埋点测试、埋点监控去保障埋点数据质量。
在业务服务、业务支持过程中,面对非常多的业务痛点,主要可以归纳为两大方面:生产设计和消费使用。
- 生产设计方面
首先,最常见的问题就是属性命名,不同的业务和开发团队有着不同的命名偏好,有的人喜欢驼峰命名,有的人喜欢用下划线做分割,有的人喜欢用中划线去做分割,这会导致埋点非常混乱,需要统一命名的规范。
第二个问题是在埋点上报的时候,有记录业务属性的参数,在业务实际的管理过程中,可能会出现参数枚举的映射值找不到了,比如原本是小写的abc,另一个业务用的是大写ABC,业务值的映射方向混乱会导致埋点管理的混乱。
第三个问题是在埋点生产的过程中,会涉及到数据产品、开发人员、测试人员以及线上的应用方,参与方越多,各方的埋点信息越可能对不齐。
最后一个问题是,用Excel或文档来管理埋点,数据量少的时候是可以操作的,但是数据量多、交接的人员多的情况下,信息失真就会比较严重。
2、消费使用方面
第一个问题是,运营常常会向产品发起拷问,页面上对应的埋点是哪个ID?在数据里面找不到。
第二个问题,查询埋点数据的时候,应该查询哪一张表,过滤哪一个埋点的参数,私有参数是什么。
二、埋点治理最佳实践
针对上述问题,我们提出了从埋点生产到消费下线全生命周期的埋点治理方案,包括埋点设计、埋点审核、埋点开发、埋点测试、埋点监控等核心环节,保障埋点治理工作有序有效开展。
1、埋点设计
在埋点标准化设计的过程当中,有三个重要的部分:埋点命名规范,埋点属性管理和工具化支持。
- 埋点命名规范
首先来看一下埋点的命名,很多业务会各自命名埋点的eventID,需要一个低门槛的工具管理埋点的eventID,不需要思考怎么样命名,也不要去做随机的编码,而是要有一个高业务可读性的ID信息。另外,几个版本需要有可延续性,不要过几个版本就混乱了。要求可交接或者可读性,在版本之间的迁移度是较高的。最后,还需要有一个工具保证不同维护人之间可以顺畅交接。
这里建议引入了阿里的SPM模型(超级位置模型)。在埋点的eventID中包含业务的实际信息,将各业务含义抽象在埋点ID当中,然后将这个ID进行维表化的管理。整体分成五个部分,包括业务ID、页面ID、区块ID、展位ID和事件类型。通过规范的命名可以提升整个业务的可读性,在做埋点数据治理时,可以合理的定位问题,降低埋点的成本。相同的命名,不同的埋点类型可以做到复用。
对于 使用者来说,拿到这个eventID以后能快速地定位到这个埋点所处的页面模块、位置模块,以及在哪一个页面homepage,所属的业务线是哪一条,能够精确地定位它所处的业务线对应的信息。
这个业务埋点ID,对于做一个定位或者类型的划分,能够做到业务的可读性非常高,分摊业务埋点的成本,并且复用性非常高。点击的埋点命名为click,那同样一个模块,曝光的埋点,命名为show就可以了。
在做埋点的时候,上报的时候会划分为客户端SDK上报以及服务端上报。客户端通过埋点的类型划分,包括启动、浏览、曝光、点击、播放、系统以及其它事件。服务端包括这个API的请求记录,以及业务端业务表的日志变更信息。
(2)埋点属性管理
在埋点上报的时候,有一个很重要的部分是记录埋点的属性参数。埋点属性在业务含义当中是对用户有一些定制采集的信息。会做三个层级的划分:
首先是全局公共字段,包括埋点事件ID、APP信息、触发的时间戳、触发时间的网络、运营商、操作系统的版本等等。
第二个是针对不同的埋点类型,包括页面浏览PV、播放,或者业务特色的业务内容埋点,抽象出这个类型通用字段去做一个具体的预填充。这两个部分都是预设在SDK当中,业务开发无需二次处理。
第三个部分就是业务定制化的私有参数,比如做海报轮播的时候,需要这个海报轮播的bannerID,或者这个海报对应跳转up主的mid等参数,就是业务它自定义去使用的参数信息。
在业内有另外两种主流的方案,一种是采集参数,平铺预留10-20个param的私有参数,另外一种就是只区分公共属性跟私有字段的属性。这两类方案的问题是扩展性会有一些欠缺,虽然在早期的时候可以快速地去辅助业务的数据采集,但是后期的治理成本比较高。经过长期的实践发现,采用公共字段+类型通用字段+私有字段这种方式,是一个比较通用,而且扩展性比较强的埋点属性规范方式,保证了灵活性和扩展性。
(3)工具化支持
我们希望应用工具去做SPM模型支持,而避免让业务同学人工选择。我们内部使用一款叫做网舟埋点管理平台的工具。
上图中可以看到,这是一个埋点事件创建模块,将埋点的业务、页面、区块、展位、类型都抽象为了可视化位置层级和维表化的选择。创建埋点的运营和产品只需要去做下拉点击的筛选,而不需要去从头去做一个埋点设计。如果有历史的埋点,做一个快速地复制,修改一些参数信息即可。第一部分是埋点的命名。第二部分是去做埋点属性的标准化,包括属性ID、属性显示名,属性的枚举类型等等。第三个部分是业务比较关注的上报时机,埋点是否需要做抽样上报,以及配置远程是否停止采集。上述的几个部分都做了维表化抽象,每个环节、每个模块都有一个对应的管理列表,结构化存储在业务表中,方便下游的使用。
2、埋点审核
通常情况下,埋点需求评审由数据团队主导,埋点研发测试团队参与,业务方确认。在需求评审会上,埋点研发测试团队确认需求可行性,业务方确认事件设计方案符合业务需求、数据团队确认埋点数据是否符合数据规范。如一次评审没有达成一致,将多次组织需求 review,直到三个团队达成一致。评审通过后,才可进入埋点开发阶段。
通常评审过程需要几次开会才能达成一致,为了提升沟通的效率,我们使用网舟埋点管理平台,将评审流程线上化,有问题直接反馈给指定责任人。
3、埋点开发
埋点开发过去需要开发同学非常了解埋点时机和采集SDK的使用,才能做好埋点插码工作。为了减轻这个工作负担,提高效率,我们通过使用网舟埋点管理平台,根据埋点设计和采集SDK代码模版,自动生成开发指南,开发同学参照指南,在合适的配置将代码块拷贝到相应的位置即可。
4、埋点测试
过去验证上报数据是否准确,通常由两种方式:要么通过网络抓包,要么需要测试人员申请数据库表权限,然后手写 SQL 查询数据。这两种方式都很低效且容易出错。
埋点测试比 QA 要难很多,看的是一串数字、类型的值等。怎么去做好测试这件事的呢?重点还是前面提到的做好埋点设计。只有设计周全,才能积攒足够的规则进行自动化测试,因此埋点设计方案非常重要。埋点设计者会在方案设计时制定一系列的约束规则,我们会依托这些约束规则生成一系列相匹配的测试用例,并在测试过程中进行自动匹配、测试。埋点测试时,我们使用的网舟埋点管理平台提供了埋点测试工具,测试者手机扫码即可将服务器和浏览器建立连接,在 App 上操作后,流量平台可以实时接收到对应的埋点数据。因为已经有测试用例,规则执行引擎便可以自动匹配执行并得到结果,再通过验证结果推送服务实时推送至浏览器。埋点测试后,用户可以通过报告生成器可以一键生成报告,发送给 RD 进行修改或者 DA 进行验收。这样就完成了整个测试流程。
![](https://i-blog.csdnimg.cn/direct/b6fe35f770f5403a822eac28a7bb202e.png)
5、埋点监控
通过增量埋点和存量埋点的监控能力,可以了解埋点的情况和趋势,以及 PV/UV 等指标。通过质量监控系统和实时监控,可以对埋点的数据质量进行可视化呈现。同时,对埋点进行分级治理,梳理出治理措施和层面。根据埋点类型进行过滤和抽样,缓解资源问题。
首先是埋点的监控能力,会有相关卡片即每天会监控一些核心埋点事件,这些核心埋点事件的趋势以及 PV/UV 指标会被展现出来,接下来会对所有核心埋点做质量保证。
通过这两种方式就可以知道埋点的大致情况,此外还有一些实时的埋点质量监控,对于某条业务线的所有埋点做一个简单汇总,例如有哪些事件版本,以及相关的校验数量和错误数量。当这些监控完善之后,就会对之前处于混沌状态的埋点,有更加清晰的认识。
三、未来展望
埋点治理是一个持续不断优化的长期工作,未来我们将着力于埋点血缘建设。
数仓这边存在一大痛点是有时根本不知道埋点在哪些表中,是如何抽取出来的。因此会加强血缘方面的能力建设,通过埋入新的埋点事件后,分析出这些埋点的下游链路,使得埋点在整个数据链路上有可追溯的能力。
埋点血缘和离线血缘抽取不太一样。离线血缘是点与点之间的血缘,但埋点血缘关注的是内容与点的血缘,它需要知道一张表的哪些行的信息有用。这是完全不同的一个领域,没有任何前人的经验可以借鉴,我们后续将在这方面做更多的探索。