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