用户行为数据采集──埋点,是用户行为分析中非常重要的环节,直接决定数据广度、深度、质量,影响后续所有的环节。就埋点本身来说,技术实现的难度并不高,但是整个埋点的过程可以说十分的复杂繁琐,有非常多细节和流程需要考虑,不同类型客户端如何采集,数据如何统一,哪些信息需要在客户端采集,哪些信息需要在后端采集,如何减少数据上报的延时和漏报,如何对成千上万个埋点进行统一的管理?
这一系列文章基于用户行为分析数据平台一年的工作经验,会对埋点的全过程进行思考和讨论,涉及对埋点基础知识的介绍,讨论如何从 0 到 1 开始用户行为数据采集工作,分享负责项目的埋点方案,介绍埋点管理系统,梳理整个埋点协作流程等方面。
上篇文章讨论了为何、以及如何建立用户行为数据采集规范,点击查看。本文是系列文章的第三篇,介绍如何将采集规范线上化──埋点管理系统。

为什么要做埋点管理系统?

就埋点本身而言,并没有什么技术挑战,但涉及的环节特别多,包括埋点需求提交、埋点设计(定义采集字段、格式、采集时机、上报策略)、埋点开发上线、无用埋点下线等等,这些环节都需要一个有效的流程串联起来,在上一篇文章中建立了采集规范,已经有了这样的流程。但这还不够,因为整个流程需要多个团队协作,如业务团队、数据团队、埋点研发团队(又包括后端埋点,不同端的前端埋点,如 iOS 端、Android 端、Web 端、微信小程序端等),各团队按照规范各司其职、相互配合,如果这些都要靠人「自觉」的协作,那要付出巨大的沟通成本。在实际的工作中,人的「自觉」几乎是不可能的,因为每个角色处在不同的环节上,只会去寻找「局部最优」。所以,我们希望让「系统」来做协调的工作,通过将流程线上化到系统中去,各个团队都到系统中去处理自己负责的事项,使得各环节的输入输出更加的标准化、自动化,以此减少不必要的沟通,提高效率。这就是为什么要做埋点管理系统。

埋点生命周期管理

完善的埋点管理应该覆盖埋点的整个生命周期,包括埋点需求阶段、埋点实施阶段、埋点使用阶段(数据分析),以及埋点下线回收。
使用埋点管理系统上线埋点应该经历如下流程:

埋点管理流程

埋点管理系统参与了埋点的所有环节,各个团队/角色通过埋点管理系统完成以下工作:

  • 业务团队(有埋点需求的团队):
    • 注册埋点:埋点方案评审之后,满⾜业务需求的埋点信息被确认,包括埋点名称、属性名称、属性数据类型、属性含义、采集时机等。业务团队埋点负责人需要登录埋点管理系统注册埋点,完善相关信息,后续将以此为依据进行研发工作;
    • 埋点属性管理-自定义属性:自定义属性相对于通用属性,是某个事件下特有的属性,由业务方根据埋点方案在系统中维护;
    • 埋点信息查看/编辑:埋点上线之后,需要查看埋点信息来进行数据分析,另外,埋点信息有变化时还需要进行编辑更新;
    • 埋点回数状态查询:埋点上线之后,业务团队需要验证最初需求计划埋点以及属性是否都已上报了数据;
    • 埋点回收:过期的无用埋点需要进行下线操作。
  • 数据团队:
    • 埋点属性管理-通用属性:通用属性是指产品/业务层面的公共属性,为避免相同属性出现不同定义,数据团队需要进行统一的定义和管理;
    • 监控埋点数据上报:在埋点上报之后,数据团队需要时时了解数据上报的情况,监控异常。
  • 埋点研发测试团队:
    • 埋点信息查询:查询埋点信息,按照需求方录入埋点信息进行开发测试;
    • 监控埋点数据上报:在埋点上报之后,研发团队需要时时了解数据上报的情况,如出现异常情况,需要及时介入解决。

埋点管理功能设计

通过整理上述的埋点管理流程,以及各种角色的诉求和职责,我们梳理出了埋点管理系统应该覆盖的功能,分别是:埋点管理、埋点属性管理、上报埋点数据监控。

埋点管理

埋点列表
埋点注册之后将会进入埋点列表,埋点列表提供比较完善的埋点信息,同时也是编辑埋点、查看埋点数据上报统计的入口。

埋点列表

注册/编辑埋点信息

注册/编辑埋点信息

埋点需求确认之后,将新的埋点录入埋点管理模块,需要完善的信息包括:

  • 埋点基本信息,包括埋点名称、显示名、在线周期、可见性(设置为不可见的埋点会自动被设置为隐藏,所有分析功能都不能使用)、业务负责人、开发负责人、覆盖客户端(产品可能涉及多种客户端,如iOS、Android,需要说明哪些端会上报这个埋点),以及额外的备注信息。
  • 通用属性:数据团队维护了产品/业务层面的公共属性,注册埋点时,需要选择埋点要包括哪些通用属性。
  • 自定义属性:埋点下特有的属性,有需求方按照评审内容进行添加,需要填写埋点名称、显示名、字符类型、可见性、覆盖端等信息。

埋点回数状态
查看需求计划中的埋点以及属性在各端是否都已触发(上报数据)。

埋点回数状态

埋点回收
完整的埋点生命周期应该包括下线无用埋点,埋点回收功能将不再使用的埋点移到回收站中。埋点被回收后,历史数据依然可查询,但后续将不在接收该埋点的上报数据。用户可以通过移出回收站,恢复接收上报数据。

需要特别说明,这样的设计是出于业务特点的考虑。在用户行为分析系统的初期,我们定义了埋点的规范,但并未将整个规范流程线上化,只做了简单「埋点启用/禁用」功能,来控制埋点是否可以查询到。随着业务的发展,埋点个数在短短的时间内激增到了上万个,其中非常多的埋点上报后从来没有被查询过,有的埋点被禁用了很长时间,但一直在上报数据。后来经过盘点,实际上只有 15% 左右的埋点有过查询记录,而这些无用的埋点占用了大量的计算资源,也增加了埋点数据查询的难度(毕竟要从上万个埋点里找出关注的埋点不是一件容易的事)。基于这样的背景,我们添加了僵尸埋点过滤的功能,将首次上报后 3 个月未启用的埋点、禁用后的埋点过滤掉,即这些数据不会进入用户行为分析平台的计算引擎。功能上线后,做了简单的统计,大概能够节约 30% 的计算资源。

后来,我们做了埋点管理功能,将整个规范流程线上化。埋点管理中仍然保留了僵尸埋点的过滤策略,并做了进一步的优化。比如用户在注册埋点的时候,可以选择埋点的在线周期是长期在线还是到某一天就自动下线回收。并且,我们要将埋点可查询和埋点可接收做了分离:通过操作埋点及属性的可见性,控制数据是否可查询;通过将埋点移入/移出回收站,控制是否接收数据上报。

埋点属性管理

在埋点元数据中维护产品/业务层面的通用属性,由数据团队统一维护,所有可见的属性,都可以在注册/编辑埋点是添加属性时搜索到。自定义属性相对于通用属性,是某个事件下特有的属性,由业务方根据埋点方案维护。

埋点属性管理

上报埋点数据监控

我们可以在埋点管理中看到具体埋点的数据上报情况,监控异常。

上报埋点数据监控

文章来源于互联网,如有雷同请联系站长删除:【用户行为采集】(三)埋点管理系统

发表评论