金融支付行业埋点治理实践

一、背景

笔者在国内某金融支付平台大数据部门做埋点管理工作，主要对App产品以及集成的众多业务线应用做埋点需求对接、埋点方案设计以及测试验证等工作。在工作期间中，经历了埋点粗放式管理到标准化治理的全过程，今天和大家做一下分享，希望对奋战在埋点工作一线的同学们有帮助。

二、现行埋点系统

公司内部使用神策分析系统进行埋点管理和数据分析。神策分析系统的系统架构图如下所示：

神策分析系统的埋点管理功能，主要采用“事件”模型，主要管理事件、事件属性、用户属性等元数据，这种方式无法满足我们的埋点工作要求，主要体现在三个方面：

首先是元信息追溯能力，即业务方无法回溯埋点元数据的变更，只能查询当前最新的埋点元数据信息。

其次是需求管控的能力，即当业务部门进行版本迭代时，可以设计和管控当前版本需要的埋点元信息，由此可以了解到不同版本下新增、修改、删除了哪些埋点。这样对于增量埋点，就可以做元数据层面的管控。

最后是埋点的验收与保障，由于初期以功能开发为主，埋点比较混乱，很多情况都是端上开发自行埋点，并且由于历史原因埋点已没有归属，存在僵尸埋点，而增量埋点质量也没有良好的测试。

三、埋点工作面临的问题

随着业务和应用越来越多，埋点规模越来越大，原有的埋点管理功能，渐渐不能适应多产品多业务的规范化集中管理，开始出现一些问题：

1、采集数据不规范，各业务部门自由定义，不利于统一分析。

自定义的埋点事件、事件属性和用户属性，是各产品部门自己维护的，但由于缺乏通用的埋点规范，各部门定义的字段规则不一致，同名不同义、同意不同名等问题频繁发生，导致数据质量很差，尤其是做联合分析时，计算口径经常对不上。

2、缺乏模板和规范，开发埋点容易出错

开发的同学往往对采集SDK的学习和使用不太上心，导致经常出现埋点错误、触发时机不对等问题，有时需要反复修改，开发效率很低。

3、对埋点进行测试比较麻烦，缺乏相关工具

神策分析系统虽然提供了埋点调试工具，但主要是给开发人员自测用的。产品进入到测试阶段时，通常对埋点的测试采用抓包和查数据库两种方式，但无论哪种方式，需要人工去核对校验埋点数据的错埋、漏埋、重埋等问题，效率极低且容易出错。

4、埋点从定义、开发、验证到上线的流程缺乏

通常完整的埋点工作流程包括：埋点需求对接、埋点方案设计、插码开发、埋点验证以及上线。但整个过程目前是通过产品侧同学发起，大数据部门、研发部、测试部配合，期间需要反复开会沟通，成本很高。缺乏一套标准规范化的流程来约束和简化沟通协作。

5、埋点上线后，数据出现异常发现不及时

埋点上线后，也经常会出现数据异常波动以及数据字段不合法的情况，这些问题往往在使用时才能发现，缺乏一种监控预警机制，能够尽快发现问题，通知相关人员解决。

6、埋点方案文档维护，不利于统一管理和追溯

埋点工作的核心产出“埋点设计方案”，之前是各部门用文档的形式进行维护。随着产品版本的迭代升级，同一个业务产品往往会有很多埋点设计方案，从这些文档中查询历史埋点的定义会非常麻烦。

7、埋点方案文档维护，不利于统一管理和追溯

四、埋点治理实践

为了解决上述问题，我们从两个方面进行改进：制定埋点规范和借助平台工具。

（一）制定埋点规范

1、埋点命名规范

之前埋点管理采用神策的“事件”模型，就是用户+物品+事件的集合体，这也是神策分析底层的数据模型：user+item+event模型。

具体来讲，what代表的是event，where代表位置，在app的初始阶段，我们可能只需要关注到页面粒度，即event发生在某个page，但是随着业务的发展以及对精细化分析能力的要求，where的关注粒度可能需要进一步下沉，在app上，体现的就是不仅仅要知道event发生的page，还要细化到改page下具体的楼层和具体的点位，也就是具体的评估指标从页面级精细化到楼层和坑位级别。

因此，我们在事件模型的基础上，采用了类似阿里的SPM模型（Super Position Model），从站点、业务、页面、区块、展位多个层级定位埋点。

• 站点：对应神策分析系统中的一个项目；
• 业务：对应不同的业务应用；
• 页面：指应用下的原生或Web页面，其下面可以包含区块、展位和埋点
• 区块（全局区块）：一个页面上的区域或多个页面的全局区域，其下可以包含展位和埋点；
• 展位：区块下面的具体的埋点位置，比如一个区块下的某个按钮，其下可以包含埋点；
• 埋点：对应实际开发的埋点定义，包括事件类型和其他各类属性字段。每一个埋点有一个唯一的埋点标识ID区分，埋点标识ID的格式定义如下：a<业务码>.b<页面ID>.c<区块ID >.d<展位ID>_<埋点ID>.<事件类型>，其对应的埋点全称格式为：业务名称-页面名称-区块名称-展位名称_埋点名称-事件类型

2、埋点事件类型管理

由大数据部门统一管理维护所有的埋点事件类型，不再由各部门自己维护。各部门设计埋点时，尽量从已有的事件类型中选择。如果确实需要自定义事件类型，则需要申请创建新的事件类型，由大数据部门审批通过后上线。

3、埋点属性管理

由大数据部门统一管理维护所有的埋点属性，不再由各部门自己维护。埋点属性可以设置严格的验证规则，比如：长度验证、数值范围验证、枚举值验证等，对埋点属性值进行规范。

埋点属性分为SDK内置属性、平台内置属性、全局属性和事件关联属性四类。其中，SDK内置属性是神策采集SDK内置的事件属性和用户属性；平台内置属性是埋点标识、页面、区块、展位等SPM信息相关的属性；全局属性是所有的事件类型都可以使用的属性；事件关联属性是只有特定事件才能使用的属性。

各部门设计埋点时，尽量从已有的属性中选择。如果确实需要自定义属性，则需要申请创建新的属性，由大数据部门审批通过后上线。

（二）埋点管理平台建设

我们希望应用工具去做SPM模型支持、规范化业务流程以及提升开发测试的效率，内部开发了一款埋点管理工具，从规范埋点工作流程、埋点设计版本管理、埋点方案自动生成、埋点测试和埋点监控等方面，帮助提升埋点工作的质量和效率。

1、规范埋点工作流程

我们制定了一套埋点工作流程，并固化在埋点管理平台上。工作流程图如下：

• 埋点需求pm

负责提出并且设计埋点需求、并且测试验收要求:具备基本的数据分析思维，了解埋点设计，了解埋点数据如何应用。

•    业务需求对接人

负责该业务板块的埋点审核统筹工作要求:原则上由事业群数据人员担任。具备完整的埋点设计、分析思维，了解埋点开发原理，了解业务需求。

•  大数据审核

大数据部门从数据规范角度审核埋点需求是否合规，此步骤非必需。

• 开发人员

负责实施埋点采集工作要求:了解埋点采集开发原理、了解数据上报机制、能够自查埋点数据上报

• 测试人员

负责测试埋点数据是否符合需求要求:了解埋点需求、了解埋点数据流程。

除此之外，维护埋点管理平台还有两个角色：

• 大数据管理员

负责埋点管理平台和行为分析平台的运营配置；负责埋点指导文档的更新和宣讲；负责业务、站点的划分规则，属性、事件类型、事业群、用户角色等管理工作；负责指导事业群埋点全流程工作

• 技术部SDK管理员

负责更新维护sdk使用文档；负责对接开发人员的使用咨询及排障；负责采集相关规则的优化等工作

2、埋点设计版本管理

通过在埋点管理平台上创建埋点需求来进行埋点设计。埋点需求通常对应埋点设计方案，每个埋点需求对应一个埋点版本。新的埋点需求在历史埋点需求基础上，进行具体的埋点设计和定义。

埋点设计过程中，支持设置公共属性、从其他需求复制埋点等方式，来提升埋点设计工作的效率。

对于上线的埋点需求，可以通过埋点管理平台追溯任意历史埋点需求的埋点，查找非常方便。

3、埋点方案自动生成

根据产品同学设计的埋点需求，可以通过平台自动生成埋点开发方案，即针对埋点需求中每个埋点生成开发指导文档，包括：埋点位置、埋点时机、示例代码、注意事项等。开发的同学不用了解SDK，按照说明拷贝代码，做一些简单修改就可以了。

4、埋点测试工具

为了让上报变得更准确，平台提供埋点测试工具，埋点测试的时候能够快速精准、半自动甚至是全自动能够发现业务上报的问题点在什么地方。

在埋点设计的时候，根据业务的需求抽象为埋点定义，这部分会录入到结构化的埋点管理工具当中，埋点管理工具去生成测试校验的规则，比如枚举空值、默认值以及值范围等等。

除了对当前埋点需求做测试，也支持对以前的重要埋点做回归测试，确保本次埋点工作不影响之前的埋点。

5、埋点监控

通过增量埋点和存量埋点的监控能力，可以了解埋点的情况和趋势，及时发现数据异常。通过实时监控，可以对埋点的数据质量进行可视化呈现。

现在的埋点依赖于神策服务，对于梳理出来的一些无效埋点，通常可以直接在最前端拒绝掉，或是反馈给业务，让业务做处理。

五、未来展望

通过制定埋点规范和推行埋点管理平台，让我们的埋点工作相比以前更加有序和高效，数据质量也有了很大的提升。后续我们计划推进如下两方面的工作：

• 存量埋点改造

由于历史问题，还有很多存量埋点需要使用旧的管理方式，后续将通过对埋点分级，分阶段完成存量埋点的改造。

• 采集SDK能力升级

目前神策采集SDK虽然能满足我们大部分场景的采集需求，但还是有一些特定事件和属性的采集，是各部门开发同学自行实现的，我们计划将具有普遍性的采集需求，封装到采集SDK中，便于在各部门之间规范和重用。比如：页面前向三级来源、页面停留事件、App压后台事件、App返前台事件等。

本文由网舟科技提供发布支持，转载请注明出处