如何设计出一个实用高效的埋点管理系统？
一、为什么要做埋点管理系统？
如果你是一名数据分析师，是否有过这样的经历：
当你需要查询APP产品埋点数据的时候，你不得不经常找数据产品经理去确认是否已有埋点，埋了哪些字段，是否已有上报数据等。常常这些埋点事件元信息分散在多个产品经理手上，信息散乱，分析师使用埋点数据之前沟通成本极高，影响数据使用的效率……
不仅如此，如果遇到埋点数据异常，追溯埋点历史问题过程也是非常的漫长，需要数据产品经理去跟业务产品经理确认埋点需求的版本，然后数据产品经理确认埋点设计需求的批次，然后给到开发，开发同事再去查找问题……
以上种种问题一直是困扰着我们埋点工作的痛点。埋点场景的痛点我总结为以下5点：
- 埋点需求及埋点设计文档管理散乱，产品、开发、测试协同沟通效率低下，严重影响工作效率。
- 埋点事件元信息管理散乱，常是分布在多个产品经理手上，分析师使用埋点数据时需要查询埋点需求及埋点事件的元信息这个过程链路长，沟通成本非常高，埋点元信息使用查询极其不便利。
- 若出现埋点数据异常问题，若开发同事需要追溯埋点历史数据，则更是需要有当时的埋点需求批次和埋点设计文档作为辅助，元信息管理散乱，极其影响debug的效率。
- 非可视化测试，验收埋点难度太大。每次都要跑去数据库了查询，对于没有写SQL基础的业务经理来说，验收埋点数据的效率就会比埃及地下。
- 数据校验流程混乱，版本管理难度大，开发同学常常要自己开发一个后台管理功能来管理埋点发布或下线的版本。
二、埋点管理系统是什么？
埋点管理系统本质是解决数据采集及数据使用场景问题的业务系统，业务方则是数据产品、数据开发工程师、数据分析师等数据团队的人员。
比较常见的例子，数据分析师在业务处于快速发展的阶段大概率只让你取数，未必让你真正去做业务数据分析的活儿。
等数据取数这类需求达到一定的数量，老板才会想着去开发可视化类的取数工具，帮助数据分析师从大量的数据查询和报表开发的工作解脱出来，去做更加有价值的业务专题分析的工作。
回到我们的主题，埋点管理系统也常常会等到埋点需求非常多，从埋点需求产出端、到埋点需求使用方都感觉到这个合作流程已经影响了整体的工作效率的时候，埋点管理系统才会被老板想到，这个工具是否可以替代原本的零散和低效的协同模式来提高大家的工作效率。所以，埋点管理系统本身是一个提升数据同事工作效率的工具。
埋点管理系统能解决问题主要有以下5点：
- 解决了埋点需求及埋点设计管理散乱，产品团队、开发团及测试团队，数据应用团队的协同沟通效率低下问题。
- 解决了数据应用场景中需要高频及便利地查询查询埋点事件元信息问题。
- 解决了开发同事在遇到埋点数据异常需要追溯历史埋点的历史文档寻找的版本管理问题。
- 通过可视化抓包，解决了埋点数据验收的重度依赖数据库查询的相对低效的方法。
- 通过可视化对比校验和发布／下线能力，解决了开发同事单独管理埋点需求的版本及发布场景问题，并有明确的数据校验流程，从而间接提升数据质量的管理。
三、如何设计埋点管理系统？
1. 业务流程确认
说了埋点管理系统能解决的问题，接下来聊聊埋点管理系统长啥样，如何才能设计出解决我们以上问题的埋点管理系统。在此之前，我们先了解埋点场景的业务流程：
图一：埋点业务流程图1
2. 系统功能确认
业务流程确认了，我们就在对应的业务流程上增加产品功能模块去承载每个业务流程节点的需求，如下图：
图二：埋点业务流程图2
3. 事件模型确认
在了解系统功能设计之前，我们先了解一下埋点管理系统里涉及到的全部管理对象及对象之间的关系。
埋点管理系统一共涉及到四个对象，分别是应用、埋点需求批次、埋点事件、事件属性。他们之间的关系是自上而下的逻辑关系。
图三：埋点事件模型图
4. 系统功能架构设计
通过埋点业务流程及事件模型的梳理，我们得出了多个系统功能模块，拆解出来的埋点系统功能结构如下图：
图四：埋点管理系统功能结构图
下面我们将对系统的每个功能模块展开阐述：
1）应用管理
应用管理功能主要是承载业务团队新增一个APP/小程序／H5／web端等业务产品对象，我们需要在系统里先创建一个新的埋点产品对象，然后才有后续增加的埋点需求及事件元信息等。
这个模块包含应用新增、删除、编辑等基础功能。产品团队需要负责的埋点产品都可以放在这里统一管理。
图五：应用管理列表图
2）埋点需求管理
埋点需求管理功能主要承载集中管理业务团队提过来给产品团队的埋点需求文档，这里可以创建需求、编辑需求、下钻需求、下线需求等。
在这里，需求按照批次来进行管理，每一个埋点需求都有一个唯一的批次号，挂载到对应的应用及版本上，并且点击单个埋点需求批次号，可以直接下钻到该埋点需求下的全部事件列表。
图六：埋点需求管理列表图
3）事件管理
管理功能则承载来所有埋点需求拆解出来需要开发的埋点事件元信息，这里可以创建事件、编辑事件、下钻事件、搜索事件、下线事件等。
事件是埋点拆解的最小对象单元，在这里每个事件都要挂载在对应的埋点需求批次上，系统里没有独立自自己游荡的事件。这样所有的应用、埋点需求批次和事件都有了映射关系。当需要使用埋点数据时，先来埋点管理系统查找埋点需求批次，这种清晰的映射关系在查询埋点元信息时提供了高效的途径。
图七：事件管理列表图
4）属性管理
属性管理功能模块承载的是常用的有共性的属性。一个个独立的属性常用属性，比如用用户ID、用户客户端系统、在线时长等属性，可以在属性管理这里完成注册。
在用户新建事件时，可以直接引用已注册完成的属性绑定到事件上，减少用户填写事件属性信息时的大量重复填写工作。
5）埋点校验
走到这里，埋点已经开发完成了，到了测试、验收、上线的环节。这里的埋点校验包含两部分，可视化抓包测试及开发环境和测试环境的信息对比。完成这两个环节之后，开发同事才可以把埋点发布到正式环境。
可视化抓包测试：
可视化抓包功能页主要提供给产品经理和测试同学可以现场抽样测试事件数据，检查上报的属性是否已经完整，属性值是否准确。
图八：埋点数据实时抓包图
对比与同步：
在线对比和发布功能页则是承载了开发童鞋对比生产环境和测试环境埋点元信息的差异之处，帮助快速确认已经进行了变更处理之处。及支持开发童鞋在线可视化发布埋点事件，便捷高效。
图九：埋点需求对比及同步功能图
6）埋点监控
埋点监控功能承载的则是埋点管理系统全部埋点事件的及任务运行的结果监控。包括展示全部埋点应用统计数、埋点需求统计数、事件统计数、有效在线事件统计数、异常的埋点事件数、未处理的埋点需求／事件数等，是统计和展示整个系统管理对象及对象运行情况的监控功能模块。
方便参与埋点工作的同事了解整体产品的埋点任务运行情况，和及时发现埋点上报数据的异常情况。也是埋点管理系统的一个必不可少的模块。
四、写在最后
以上从埋点管理系统的定位和解决的痛点问题，及系统的建设过程给大家阐述一遍，希望能帮助大家在对埋点管理系统及建设有个相对完整的认识。
最后，总结几点系统建设过程中的思考分享给大家：
1）埋点管理系统是一个服务于数据团队但涉及合作团队较多的系统。在不同公司，可能埋点业务流程不一样，而我这里分享的是我经历过的埋点工作场景中协同效率比较高效的埋点业务流程，希望能提供参考借鉴。
2）埋点需求批次跟应用版本号不完全保持一致，不要当作是形同对象而相互替代。因为很可能在后期版本增加早期发版的产品功能的埋点。如果当作同一个问题处理，将导致埋点需求管理能力可扩展性太弱，很快整个系统都陷入了管理瓶颈。
3）埋点管理系统真实可以提升业务、产品、开发、数据分析多个团队的协同效率，用起来非常爽，能早建设尽早建设。
此处完结。
本文作者 @九果女孩Maky
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
