网舟科技|金融支付行业埋点治理实践
一、背景
笔者在国内某金融支付平台大数据部门做埋点管理工作,主要对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),从站点、业务、页面、区块、展位多个层级定位埋点。
- l站点:对应神策分析系统中的一个项目;
- 业务:对应不同的业务应用;
- 页面:指应用下的原生或Web页面,其下面可以包含区块、展位和埋点
- 区块(全局区块):一个页面上的区域或多个页面的全局区域,其下可以包含展位和埋点;
- 展位:区块下面的具体的埋点位置,比如一个区块下的某个按钮,其下可以包含埋点;
埋点:对应实际开发的埋点定义,包括事件类型和其他各类属性字段。每一个埋点有一个唯一的埋点标识ID区分,埋点标识ID的格式定义如下:a<业务码>.b<页面ID>.c<区块ID >.d<展位ID>_<埋点ID>.<事件类型>,其对应的埋点全称格式为:业务名称-页面名称-区块名称-展位名称_埋点名称-事件类型
2、埋点事件类型管理
由大数据部门统一管理维护所有的埋点事件类型,不再由各部门自己维护。各部门设计埋点时,尽量从已有的事件类型中选择。如果确实需要自定义事件类型,则需要申请创建新的事件类型,由大数据部门审批通过后上线。
3、埋点属性管理
由大数据部门统一管理维护所有的埋点属性,不再由各部门自己维护。埋点属性可以设置严格的验证规则,比如:长度验证、数值范围验证、枚举值验证等,对埋点属性值进行规范。
埋点属性分为SDK内置属性、平台内置属性、全局属性和事件关联属性四类。其中,SDK内置属性是神策采集SDK内置的事件属性和用户属性;平台内置属性是埋点标识、页面、区块、展位等SPM信息相关的属性;全局属性是所有的事件类型都可以使用的属性;事件关联属性是只有特定事件才能使用的属性。
各部门设计埋点时,尽量从已有的属性中选择。如果确实需要自定义属性,则需要申请创建新的属性,由大数据部门审批通过后上线。
(二)埋点管理平台建设
我们希望应用工具去做SPM模型支持、规范化业务流程以及提升开发测试的效率,内部开发了一款埋点管理工具,从规范埋点工作流程、埋点设计版本管理、埋点方案自动生成、埋点测试和埋点监控等方面,帮助提升埋点工作的质量和效率。
1、规范埋点工作流程
我们制定了一套埋点工作流程,并固化在埋点管理平台上。工作流程图如下:
l埋点需求pm
负责提出并且设计埋点需求、并且测试验收要求:具备基本的数据分析思维,了解埋点设计,了解埋点数据如何应用。
业务需求对接人
负责该业务板块的埋点审核统筹工作要求:原则上由事业群数据人员担任。具备完整的埋点设计、分析思维,了解埋点开发原理,了解业务需求。
大数据审核
大数据部门从数据规范角度审核埋点需求是否合规,此步骤非必需。
开发人员
负责实施埋点采集工作要求:了解埋点采集开发原理、了解数据上报机制、能够自查埋点数据上报
测试人员
负责测试埋点数据是否符合需求要求:了解埋点需求、了解埋点数据流程。
除此之外,维护埋点管理平台还有两个角色:
大数据管理员
负责埋点管理平台和行为分析平台的运营配置;负责埋点指导文档的更新和宣讲;负责业务、站点的划分规则,属性、事件类型、事业群、用户角色等管理工作;负责指导事业群埋点全流程工作
技术部SDK管理员
负责更新维护sdk使用文档;负责对接开发人员的使用咨询及排障;负责采集相关规则的优化等工作
2、埋点设计版本管理
通过在埋点管理平台上创建埋点需求来进行埋点设计。埋点需求通常对应埋点设计方案,每个埋点需求对应一个埋点版本。新的埋点需求在历史埋点需求基础上,进行具体的埋点设计和定义。
埋点设计过程中,支持设置公共属性、从其他需求复制埋点等方式,来提升埋点设计工作的效率。
对于上线的埋点需求,可以通过埋点管理平台追溯任意历史埋点需求的埋点,查找非常方便。
根据产品同学设计的埋点需求,可以通过平台自动生成埋点开发方案,即针对埋点需求中每个埋点生成开发指导文档,包括:埋点位置、埋点时机、示例代码、注意事项等。开发的同学不用了解SDK,按照说明拷贝代码,做一些简单修改就可以了。
4、埋点测试工具
为了让上报变得更准确,平台提供埋点测试工具,埋点测试的时候能够快速精准、半自动甚至是全自动能够发现业务上报的问题点在什么地方。
在埋点设计的时候,根据业务的需求抽象为埋点定义,这部分会录入到结构化的埋点管理工具当中,埋点管理工具去生成测试校验的规则,比如枚举空值、默认值以及值范围等等。
除了对当前埋点需求做测试,也支持对以前的重要埋点做回归测试,确保本次埋点工作不影响之前的埋点。
5、埋点监控
通过增量埋点和存量埋点的监控能力,可以了解埋点的情况和趋势,及时发现数据异常。通过实时监控,可以对埋点的数据质量进行可视化呈现。
现在的埋点依赖于神策服务,对于梳理出来的一些无效埋点,通常可以直接在最前端拒绝掉,或是反馈给业务,让业务做处理。
五、未来展望
通过制定埋点规范和推行埋点管理平台,让我们的埋点工作相比以前更加有序和高效,数据质量也有了很大的提升。后续我们计划推进如下两方面的工作:
存量埋点改造
由于历史问题,还有很多存量埋点需要使用旧的管理方式,后续将通过对埋点分级,分阶段完成存量埋点的改造。
采集SDK能力升级
目前神策采集SDK虽然能满足我们大部分场景的采集需求,但还是有一些特定事件和属性的采集,是各部门开发同学自行实现的,我们计划将具有普遍性的采集需求,封装到采集SDK中,便于在各部门之间规范和重用。比如:页面前向三级来源、页面停留事件、App压后台事件、App返前台事件等。
- 2024-09-05
- 2024-09-02
- 2024-07-15
- 2024-02-02
- 2023-04-28
- 2023-03-02
- 2023-02-10