埋点进阶（二）：埋点治理最佳实践

一、为什么要做埋点治理

        用户行为数据管理和对应的行为数据分析的关系十分紧密，如何在产品层面上应用好，前置条件是埋点数据需要做到标准化、规范化的管理和应用，这是很多行业内公司及团队都会碰到的课题。

        然而随着业务的迭代变更，部分埋点数据失去效用。为了确保数据的质量、效率、安全、标准及易用性，需要对埋点数据进行治理。不仅是存量数据的治理，新增数据更是要保证从源头开始就是正确的。在埋点数据的生命周期内，每个环节制定原则性的管理方法和具体的落地措施。一个稳定的治理链路是埋点治理的基石。

        埋点数据从生产到消费使用会有一个比较长的链路，可以从生产环节和消费环节两个方向来看。

        从生产环节来看，业内都会将埋点采集抽象为可复用的埋点数据模型并集成到SDK内，避免每次业务开发都要重新定义采集的格式规范。这个SDK通常会划分为iOS、安卓、Web、服务端等等，还有以backload的方式批量导入的离线数据，这是数据的生产侧。在数据流转侧，通过抽取转换加载（ETL）的方式进入到传输流，这里有两条链路，一部分业务需要消费数据实时流，另一部分业务是消费离线数据。实时流的消费可能会用于算法推荐，或者实时的数据分析，实时的监控看板。离线的数据，就是关于数仓的ODS到DWD，再到ADS的这个部分。在离线存储的部分，数据的存储会采用不同的介质，比如常见的HDFS、Parquet等等。查询引擎包含了ClickHouse、Presto、Hive等行业内主流引擎，通常也提供了一个可视化的Web，给产品经理、分析师、运营等同学去操作分析。

        从消费环节来看，业务的同学通过点选的操作去查看埋点常见的PV、UV数据，前端把操作拼接的参数传给查询引擎，作为查询SQL的拼写。业内关于查询引擎的采纳，根据每个公司的数据量会有多种不同的方案。常见的情况是：如果数据量比较小，那就直接用Hive查询，如果数据量多一些，那可能会用Presto。目前对于日增千亿的数据量级，可能采用的是ClickHouse、Doris等作为查询引擎。为支撑整个数据链路，还会采用埋点测试、埋点监控去保障埋点数据质量。

        在业务服务、业务支持过程中，面对非常多的业务痛点，主要可以归纳为两大方面：生产设计和消费使用。

1. 生产设计方面

        首先，最常见的问题就是属性命名，不同的业务和开发团队有着不同的命名偏好，有的人喜欢驼峰命名，有的人喜欢用下划线做分割，有的人喜欢用中划线去做分割，这会导致埋点非常混乱，需要统一命名的规范。

        第二个问题是在埋点上报的时候，有记录业务属性的参数，在业务实际的管理过程中，可能会出现参数枚举的映射值找不到了，比如原本是小写的abc，另一个业务用的是大写ABC，业务值的映射方向混乱会导致埋点管理的混乱。

        第三个问题是在埋点生产的过程中，会涉及到数据产品、开发人员、测试人员以及线上的应用方，参与方越多，各方的埋点信息越可能对不齐。

        最后一个问题是，用Excel或文档来管理埋点，数据量少的时候是可以操作的，但是数据量多、交接的人员多的情况下，信息失真就会比较严重。

2、消费使用方面

        第一个问题是，运营常常会向产品发起拷问，页面上对应的埋点是哪个ID？在数据里面找不到。

        第二个问题，查询埋点数据的时候，应该查询哪一张表，过滤哪一个埋点的参数，私有参数是什么。

二、埋点治理最佳实践

        针对上述问题，我们提出了从埋点生产到消费下线全生命周期的埋点治理方案，包括埋点设计、埋点审核、埋点开发、埋点测试、埋点监控等核心环节，保障埋点治理工作有序有效开展。

1、埋点设计

        在埋点标准化设计的过程当中，有三个重要的部分：埋点命名规范，埋点属性管理和工具化支持。

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 进行验收。这样就完成了整个测试流程。

5、埋点监控

        通过增量埋点和存量埋点的监控能力，可以了解埋点的情况和趋势，以及 PV/UV 等指标。通过质量监控系统和实时监控，可以对埋点的数据质量进行可视化呈现。同时，对埋点进行分级治理，梳理出治理措施和层面。根据埋点类型进行过滤和抽样，缓解资源问题。

        首先是埋点的监控能力，会有相关卡片即每天会监控一些核心埋点事件，这些核心埋点事件的趋势以及 PV/UV 指标会被展现出来，接下来会对所有核心埋点做质量保证。

        通过这两种方式就可以知道埋点的大致情况，此外还有一些实时的埋点质量监控，对于某条业务线的所有埋点做一个简单汇总，例如有哪些事件版本，以及相关的校验数量和错误数量。当这些监控完善之后，就会对之前处于混沌状态的埋点，有更加清晰的认识。

三、未来展望

        埋点治理是一个持续不断优化的长期工作，未来我们将着力于埋点血缘建设。

        数仓这边存在一大痛点是有时根本不知道埋点在哪些表中，是如何抽取出来的。因此会加强血缘方面的能力建设，通过埋入新的埋点事件后，分析出这些埋点的下游链路，使得埋点在整个数据链路上有可追溯的能力。

        埋点血缘和离线血缘抽取不太一样。离线血缘是点与点之间的血缘，但埋点血缘关注的是内容与点的血缘，它需要知道一张表的哪些行的信息有用。这是完全不同的一个领域，没有任何前人的经验可以借鉴，我们后续将在这方面做更多的探索。