发布时间：2022-12-17 11:50:01源自：https://www.it-th.com作者 ：it谈话网阅读(287)
备注：如果您已经知道为什么要做埋点管理系统了，可以直接跳去第三节看埋点管理系统的建设过程。如果还没有很好的了解过埋点管理系统，建议从头开始读起，本文章小长，但是一定有干货哦，建议好好读完！
如果你是一名数据分析师，是否有过这样的经历，当你需要查询APP产品埋点数据的时候，你不得不经常找数据产品经理去确认是否已有埋点，埋了哪些字段，是否已有上报数据等，常常这些埋点事件元信息分散在多个产品经理手上，信息散乱，分析师使用埋点数据之前沟通成本极高，影响数据使用的效率……
不仅如此，我们还会遇到埋点数据异常，追溯埋点历史问题过程也是非常的漫长，需要数据产品经理去跟业务产品经理确认埋点需求的版本，然后数据产品经理确认埋点设计需求的批次，然后给到开发，开发同事再去查找问题……
以上种种问题场景相信大家都经历过，且一直是困扰着我们的痛点。
1、埋点需求及埋点设计文档管理散乱，产品，开发，测试协同沟通效率低下，严重影响工作效率。
2、埋点事件元信息管理散乱，常是分布在多个产品经理手上，分析师使用埋点数据时需要查询埋点需求及埋点事件的元信息这个过程链路长，沟通成本非常高，埋点元信息使用查询极其不便利。
3、若出现埋点数据异常问题，若开发同事需要追溯埋点历史数据，则更是需要有当时的埋点需求批次和埋点设计文档作为辅助，这时候的埋单需求文档和埋点元信息的统一管理，对于历史问题追溯问题的效率有极其大的帮助。
4、非可视化测试，验收埋点难度太大。每次都要跑去数据库了查询，对于没有写SQL基础的业务经理来说，验收埋点数据的效率就会比埃及地下。
5、数据校验流程混乱，版本管理难度大，开发同学常常要自己开发一个后台管理功能来管理埋点发布或下线的版本。
有没有比较好的方法解决以上问题呢，答案是有的！就是我们下面要介绍的埋点管理系统。埋点管理系统是做什么用的？埋点管理系统为啥在数据产品体系中相对少听到，为什么业内也没有非常出名和成熟的产品？
埋点管理系统本质是解决数据采集及数据使用场景问题的业务系统，业务方则是数据产品、数据开发工程师、数据分析师等数据团队的人员。
在业务尚处于快速发展的阶段，数据团队的领导更多关注的是为业务团队提供数据产品，而通过给数据团队提供数据工具来提升数据服务的效率，这个问题一般是在数据团队的服务能力相对稳定和成熟之后才会去落地。也就是当大家的KPI都是在满足业务的数据需求的时候，只要有可替代的方案，领导会更愿意暂时用着替代方案去解决这个问痛。
比较常见的例子，数据分析师在业务处于快速发展的阶段就大概率只让你取数，未必让你真正的去做业务数据分析的活儿。等数据取数这类需求达到一定的数量，老板才会想着去开发可视化类的取数工具，帮助数据分析师从大量的数据查询和报表开发的工作解脱出来，去做更加有价值的业务专题分析的工作。
回到主题，埋点管理系统也常常会等到埋点需求非常多，从埋点需求产出端到埋点需求使用方都感觉到这个合作流程已经影响了整体的工作效率的时候，埋点管理系统才会被老板想到，这个工具是否可以替代原本的零散和低效的协同模式来提高大家的工作效率。所以，埋点管理系统本身是一个提升数据同事工作效率的工具。
埋点管理系统能解决问题主要有以下5点：
1、通过统一管理应用产品及埋点设计，解决了埋点需求及埋点设计管理散乱，产品团队、开发团及测试团队，数据应用团队的协同沟通效率低下问题。
2、通过统一管理埋点事件的元信息，解决了数据应用场景中需要高频及便利的查询查询埋点事件元信息问题。
3、通过统一的埋点需求管理及事件元信息管理，解决了开发同事在遇到埋点数据异常需要追溯历史埋点。
4、通过可视化抓包，解决了埋点数据验收的重度依赖数据库查询的相对低效的方法。
5、通过可视化对比校验和发布／下线能力，解决了开发同事单独管理埋点需求的版本及发布场景问题，并有明确的数据校验流程，从而间接提升数据质量的管理。
说了埋点管理系统能解决的问题，接下来聊聊埋点管理系统长啥样，如何才能设计出解决我们以上问题的埋点管理系统。在此之前，我们先了解埋点场景的业务流程：
图一：埋点业务流程图1
在需求阶段：业务团队跟数据产品团队提出埋点需求，数据产品团队会根据用户的当期及未来的统计需求，确认增加哪些埋点，并通过拆解埋点需求指标，输出埋点设计文档而后，产品团队跟大数据开发团队进行埋带设计需求的评审，评审通过之后再上线开发。
埋点开发阶段：开发团队同事按照数据产品经理提供的已评审过的埋点设计文档进行开发开发自测完成后会提测给测试同事，测试同事按照埋点设计文档进行功能和数据的测试测试通过后，数据产品经理将进行埋点验收，产品经理不但要按照埋点设计文档验收事件及事件参数的完整性，也要去数据哭验收埋点数据的准确性。
埋点应用阶段：埋点上线后，数据分析团队就可以直接去按照埋点设计文档去数据库查询提取埋点数据进行分析应用了。这个过程，分析师一般需要先跟产品经理先过一遍新上的埋点设计文档后再开始使用数据。
埋点回收阶段：埋点也是有生命周期的，有开始时间也会有结束时间。若产品已经下线，且后期将长期不再需要使用这些用户行为数据了，基于海量数据存储成本和资源浪费力的角度考量，企业会愿意将这类埋点下线。一般并不会直接下线，标识上可以下线的标识后，一般过3-6个月依然不再被范围调用，则执行下线。
业务流程确认了，我们就在对应的业务流程上增加产品功能模块去承载每个业务流程节点的需求，如下图：
图二：埋点业务流程图2
通过埋点业务流程的梳理，得出了多个系统功能模块，拆解出来的埋点系统功能结构如下图：
图三：埋点管理系统功能结构图
在功能结构图中提到了应用、埋点需求、事件、属性等对象，在展开阐述每个功能模块之前，我们先了解一下埋点管理系统里涉及到的全部管理对象及对象之间的关系。
图四：埋点事件模型图
埋点管理系统一共涉及到四个对象，分别是应用、埋点需求批次、埋点事件、事件属性。他们之间的关系是自上而下的逻辑关系。比如在系统的埋点需求管理模块，筛选出一个应用名称，则对应展示的是选中的应用下面的所有埋点需求清单，选中单个埋点需求批次的时候，对应展现的就是这个批次下面的所有埋点事件。了解到此，下面我将分别展开介绍每个模块的功能：
应用管理功能主要是承载业务团队新增一个APP/小程序／H5／web端等业务产品对象，我们需要在系统里先创建一个新的埋点产品对象，然后才有后续增加的埋点需求及事件元信息等。这个模块包含应用新增、删除、编辑等基础功能。产品团队需要负责的埋点产品都可以放在这里统一管理。
图五：应用管理列表图
埋点需求管理功能主要承载集中管理业务团队提过来给产品团队的埋点需求文档，这里可以创建需求、编辑需求、下钻需求、下线需求等。在这里，需求按照批次来进行管理，每一个埋点需求都有一个唯一的批次号，挂载到对应的应用及版本上，并且点击单个埋点需求批次号，可以直接下钻到该埋点需求下的全部事件列表。
图六：埋点需求管理列表图
事件管理功能则承载来所有埋点需求拆解出来需要开发的埋点事件元信息，这里可以创建事件、编辑事件、下钻事件、搜索事件、下线事件等。事件是埋点拆解的最小对象单元，在这里每个事件都要挂载在对应的埋点需求批次上，系统里没有独立自自己游荡的事件。这样所有的应用、埋点需求批次和事件都有了映射关系。当需要使用埋点数据时，先来埋点管理系统查找埋点需求批次，这种清晰的映射关系在查询埋点元信息时提供了高效的途径。
图七：埋点需求管理列表图
属性管理功能模块承载的是常用的有共性的属性。一个个独立的属性常用属性，比如用用户ID、用户客户端系统、在线时长等属性，可以在属性管理这里完成注册。在用户新建事件时，可以直接引用已注册完成的属性绑定到事件上，减少用户填写事件属性信息时的大量重复填写工作。
走到这里，埋点已经开发完成了，到了测试、验收、上线的环节。这里的埋点校验包含两部分，可视化抓包测试及开发环境和测试环境的信息对比。完成这两个环节之后，开发同事才可以把埋点发布到正式环境。
可视化抓包功能页主要提供给产品经理和测试同学可以现场抽样测试事件数据，检查上报的属性是否已经完整，属性值是否准确。
图八：埋点数据实时抓包图
在线对比和发布功能页则是承载了开发童鞋对比生产环境和测试环境埋点元信息的差异之处，帮助快速确认已经进行了变更处理之处。及支持开发童鞋在线可视化发布埋点事件，便捷高效。
图九：埋点需求对比及同步功能图
埋点监控功能承载的则是埋点管理系统全部埋点事件的及任务运行的结果监控。包括展示全部埋点应用统计数、埋点需求统计数、事件统计数、有效在线事件统计数、异常的埋点事件数、未处理的埋点需求／事件数等，是统计和展示整个系统管理对象及对象运行情况的监控功能模块。方便参与埋点工作的同事了解整体产品的埋点任务运行情况，和及时发现埋点上报数据的异常情况。也是埋点管理系统的一个必不可少的模块。
以上从埋点管理系统的定位和解决的痛点问题，及系统的建设过程给大家阐述一遍，希望能帮助大家在对埋点管理系统及建设有个相对完整的认识。
1、埋点管理系统是一个服务于数据团队但涉及合作团队较多的系统。在不同公司，可能埋点业务流程不一样，而我这里分享的是我经历过的埋点工作场景中协同效率比较高效的埋点业务流程，希望能提供参考借鉴。
2、埋点需求批次跟应用版本号不完全保持一致，不要当作是形同对象而相互替代。因为很可能在后期版本增加早期发版的产品功能的埋点。如果当作同一个问题处理，将导致埋点需求管理能力可扩展性太弱，很快整个系统都陷入了管理瓶颈。
3、埋点管理系统真实可以提升业务、产品、开发、数据分析多个团队的协同效率，用起来非常爽，能早建设尽早建设。
此处完结。
-END-
欢迎分享转载→ 如何设计出一个高效的埋点管理系统？
