首页 ꄲ 原创文章 ꄲ 企业如何做好埋点管理

企业如何做好埋点管理

　　如果你是一名数据分析师，是否有过这样的经历，当你需要查询APP产品埋点数据的时候，你不得不经常找数据产品经理去确认是否已有埋点，埋了哪些字段，是否已有上报数据等，常常这些埋点事件元信息分散在多个产品经理手上，信息散乱，分析师使用埋点数据之前沟通成本极高，影响数据使用的效率……

　　不仅如此，我们还会遇到埋点数据异常，追溯埋点历史问题过程也是非常的漫长，需要数据产品经理去跟业务产品经理确认埋点需求的版本，然后数据产品经理确认埋点设计需求的批次，然后给到开发，开发同事再去查找问题……

　　以上种种问题场景相信大家都经历过，且一直是困扰着我们的痛点。对类似埋点管理场景中的痛点，我们总结后包括如下五点：

　　► 埋点需求及埋点设计文档管理散乱，产品，开发，测试协同沟通效率低下，严重影响工作效率

　　► 埋点事件元信息管理散乱，常是分布在多个产品经理手上，分析师使用埋点数据时需要查询埋点需求及埋点事件的元信息这个过程链路长，沟通成本非常高，埋点元信息使用查询极其不便利

　　► 若出现埋点数据异常问题，若开发同事需要追溯埋点历史数据，则更是需要有当时的埋点需求批次和埋点设计文档作为辅助，这时候的埋单需求文档和埋点元信息的统一管理，对于历史问题追溯问题的效率有极其大的帮助。

　　► 非可视化测试，验收埋点难度太大。每次都要跑去数据库了查询，对于没有写SQL基础的业务经理来说，验收埋点数据的效率就会比较低下。

　　► 数据校验流程混乱，版本管理难度大，开发同学常常要自己开发一个后台管理功能来管理埋点发布或下线的版本。

　　1. 埋点管理最佳实践

　　为了解决这些痛点问题，网舟根据多年企业埋点管理的实施经验，从埋点规范化、流程化、自动化和监控四个方面，提供一些来自实际工作中的方法和经验，以供大家参考。

　　1.1. 埋点规范化

　　埋点工作通常是多个人、多个团队甚至多个部门来同时参与，良好的规范可以有效降低沟通成本，提升互操作性。网舟在多年的数据采集工作中总结经验，从两个方面对埋点进行了规范化：

　　► 命名规范

　　对于埋点位置和名称，要遵循一定的命名规范，让使用者能够仅仅通过名字就了解埋点的基本含义。例如：

　　应用下的原生或Web页面，其下面可以包含区块、展位和埋点;每一个位置有一个唯一的位置标识，其格式定义如下：a<业务码>.b<页面ID>.c<区块ID >.d<展位ID>。其对应的位置全称格式为：业务名称-页面名称-区块名称-展位名称。

　　实际开发的埋点定义，包括事件类型和其他各类属性字段。每一个埋点有一个唯一的埋点标识ID区分，埋点标识ID的格式定义如下：a<业务码>.b<页面ID>.c<区块ID >.d<展位ID>_<埋点ID>.<事件类型>，其对应的埋点全称格式为：业务名称-页面名称-区块名称-展位名称_埋点名称-事件类型。

　　► 口径定义规范

　　对于同一个含义的字段，可能在多个应用和部门中的名称不一样，这样会造成字段定义重复和混乱，不利于后续的数据规整。因此，所有的事件、事件属性、用户属性应该统一维护，不能有各个部门和团队自己随意定义，只能从已有的事件和属性中选择合适的。

　　如果需要定义新的事件和属性，可以走申请流程进行申请，由数据中心管理员进行统一审批和管理。

　　1.2. 埋点流程化

　　埋点工作会涉及到业务团队、产品团队、开发及测试团队以及数据分析团队等多个角色的人员，通常情况下，埋点场景的业务流程如下：

　　► 需求阶段

　　业务团队跟数据产品团队提出埋点需求，数据产品团队会根据用户的当期及未来的统计需求，确认增加哪些埋点，并通过拆解埋点需求指标，输出埋点设计文档;而后，产品团队跟大数据开发团队进行埋带设计需求的评审，评审通过之后再上线开发。

　　► 埋点开发阶段

　　开发团队同事按照数据产品经理提供的已评审过的埋点设计文档进行开发;开发自测完成后会提测给测试同事，测试同事按照埋点设计文档进行功能和数据的测试;测试通过后，数据产品经理将进行埋点验收，产品经理不但要按照埋点设计文档验收事件及事件参数的完整性，也要去数据库验收埋点数据的准确性。

　　► 埋点应用阶段

　　埋点上线后，数据分析团队就可以直接去按照埋点设计文档去数据库查询提取埋点数据进行分析应用了。这个过程，分析师一般需要先跟产品经理先过一遍新上的埋点设计文档后再开始使用数据。

　　► 埋点回收阶段

　　埋点也是有生命周期的，有开始时间也会有结束时间。若产品已经下线，且后期将长期不再需要使用这些用户行为数据了，基于海量数据存储成本和资源浪费力的角度考量，企业会愿意将这类埋点下线。一般并不会直接下线，标识上可以下线的标识后，一般过3-6个月依然不再被范围调用，则执行下线。

　　网舟多年专注于数据埋点采集方向，对埋点管理的业务流程进行梳理和总结，发现埋点管理流程各阶段的任务，都可以通过埋点管控平台等工具来IT化这些工作，能够有效降低各类角色团队成员之间的沟通成本，提升工作效率。下面以网舟的“埋点管理平台”为例进行介绍。

　　1) 埋点需求

　　埋点设计通过埋点需求来管理埋点采集方案，每次应用的迭代升级，可能会有对应的埋点采集方案，在埋点管理平台上体现为一个埋点需求。埋点需求中可以定义很多埋点，同一个业务下的埋点需求，新的埋点需求基于上一个埋点需求的基础上进行迭代增加。埋点需求一般由产品团队的同学来创建。

　　在埋点需求下可以添加、修改、删除和查看位置和埋点。位置包括页面、区块和展位三级，页面下可以包含区块和展位，区块下可以包含展位。埋点可以属于某个位置，也可以是与位置无关的全局埋点。

　　添加或修改埋点时，可以设置埋点名称、事件、动作效果、埋点时机和已选属性。其中，动作效果是指触发埋点后的后续行为，比如：跳转、弹窗等;埋点时机是对任何触发埋点的说明;已选属性是和埋点事件相关的其他属性信息，比如：订单事件可以添加订单号、订单金额等属性。

　　当前埋点需求下的埋点支持删除。如果是已上线的需求下的埋点，则只能下线，不能删除，下线的埋点不再采集数据。

　　埋点需求创建完成后，可以提交给产品团队领导或大数据团队进行审核。

　　2) 埋点审核

　　以前埋点部署方案提交给研发人员后，经常会出现埋点定义不合理或技术无法实现的情况，这导致业务人员和研发人员进行反复沟通，浪费时间。

　　因此，埋点管理平台在业务人员和研发人员之间，提供部门审核和大数据审核流程，提前发现埋点定义不合理的情况，降低沟通成本。

　　埋点需求提交审核后，指定的审核用户可以看到待审核的需求，并查看埋点需求的详细信息，包含位置定义和埋点定义。

　　埋点需求审核没问题的话，可以提交给开发团队的同学。如果有问题，可以驳回到埋点需求设计阶段。

　　3) 埋点开发

　　埋点需求提交到开发后，开发人员可以查看待处理的埋点需求。埋点开发模块会将埋点需求转化成插码说明和代码模板，让开发人员可以直接拷贝使用。

开发人员根据埋点需求完成插码后，可以提交给测试人员进行埋点测试。如果需求中有的埋点定义不合理导致无法插码，则可以驳回到埋点审核和埋点需求设计阶段。

　　4) 埋点测试

　　埋点需求提交到测试后，测试人员可以对需求下的埋点进行测试，验证插码是否正确。

　　埋点测试时，可以接收到当前测试的埋点需求下埋点采集测试数据，并通过数据验证服务对测试数据进行验证，及时发现重埋、漏埋、错埋的问题。

　　埋点测试支持手动测试和扫码测试两种方式。手动测试需要手动输入测试设备的id，而扫码测试需要扫码二维码自动获取测试设备id。

　　埋点需求测试通过后，测试人员可以将埋点需求提交上线。如果测试有问题，可以驳回到开发阶段，由开发人员进行修改。

　　1.3. 埋点自动化

　　埋点工作中一些任务通过人工完成比较耗时耗力，可以通过IT工具实现自动化，提升工作效率。网舟在承接中国电信和中国人保等公司的埋点插码项目时，埋点实施工作最耗时费力的是在于开发人员插码和埋点测试两个环节。因此，网舟“埋点管理平台”通过提供自动生成插码代码和指南和自动测试功能，将这两个环节自动化，大大提升了埋点工作的效率。

　　► 插码代码自动生成

　　通过在管理后台上传插码样例代码，并通过变量替换的方式，自动生成Android、IOS、JS、小程序等采集SDK样例代码。