用户行为数据采集──埋点，是用户行为分析中非常重要的环节，直接决定数据广度、深度、质量，影响后续所有的环节。就埋点本身来说，技术实现的难度并不高，但是整个埋点的过程可以说十分的复杂繁琐，有非常多细节和流程需要考虑，不同类型客户端如何采集，数据如何统一，哪些信息需要在客户端采集，哪些信息需要在后端采集，如何减少数据上报的延时和漏报，如何对成千上万个埋点进行统一的管理？
这一系列文章基于用户行为分析数据平台一年的工作经验，会对埋点的全过程进行思考和讨论，涉及对埋点基础知识的介绍，讨论如何从 0 到 1 开始用户行为数据采集工作，分享负责项目的埋点方案，介绍埋点管理系统，梳理整个埋点协作流程等方面。
上篇文章讨论了为何、以及如何建立用户行为数据采集规范，点击查看。本文是系列文章的第三篇，介绍如何将采集规范线上化──埋点管理系统。
为什么要做埋点管理系统？
就埋点本身而言，并没有什么技术挑战，但涉及的环节特别多，包括埋点需求提交、埋点设计（定义采集字段、格式、采集时机、上报策略）、埋点开发上线、无用埋点下线等等，这些环节都需要一个有效的流程串联起来，在上一篇文章中建立了采集规范，已经有了这样的流程。但这还不够，因为整个流程需要多个团队协作，如业务团队、数据团队、埋点研发团队（又包括后端埋点，不同端的前端埋点，如 iOS 端、Android 端、Web 端、微信小程序端等），各团队按照规范各司其职、相互配合，如果这些都要靠人「自觉」的协作，那要付出巨大的沟通成本。在实际的工作中，人的「自觉」几乎是不可能的，因为每个角色处在不同的环节上，只会去寻找「局部最优」。所以，我们希望让「系统」来做协调的工作，通过将流程线上化到系统中去，各个团队都到系统中去处理自己负责的事项，使得各环节的输入输出更加的标准化、自动化，以此减少不必要的沟通，提高效率。这就是为什么要做埋点管理系统。
埋点生命周期管理
完善的埋点管理应该覆盖埋点的整个生命周期，包括埋点需求阶段、埋点实施阶段、埋点使用阶段（数据分析），以及埋点下线回收。
使用埋点管理系统上线埋点应该经历如下流程：
埋点管理系统参与了埋点的所有环节，各个团队/角色通过埋点管理系统完成以下工作：
- 业务团队（有埋点需求的团队）：
- 注册埋点：埋点方案评审之后，满⾜业务需求的埋点信息被确认，包括埋点名称、属性名称、属性数据类型、属性含义、采集时机等。业务团队埋点负责人需要登录埋点管理系统注册埋点，完善相关信息，后续将以此为依据进行研发工作；
- 埋点属性管理-自定义属性：自定义属性相对于通用属性，是某个事件下特有的属性，由业务方根据埋点方案在系统中维护；
- 埋点信息查看/编辑：埋点上线之后，需要查看埋点信息来进行数据分析，另外，埋点信息有变化时还需要进行编辑更新；
- 埋点回数状态查询：埋点上线之后，业务团队需要验证最初需求计划埋点以及属性是否都已上报了数据；
- 埋点回收：过期的无用埋点需要进行下线操作。
- 数据团队：
- 埋点属性管理-通用属性：通用属性是指产品/业务层面的公共属性，为避免相同属性出现不同定义，数据团队需要进行统一的定义和管理；
- 监控埋点数据上报：在埋点上报之后，数据团队需要时时了解数据上报的情况，监控异常。
- 埋点研发测试团队：
- 埋点信息查询：查询埋点信息，按照需求方录入埋点信息进行开发测试；
- 监控埋点数据上报：在埋点上报之后，研发团队需要时时了解数据上报的情况，如出现异常情况，需要及时介入解决。
埋点管理功能设计
通过整理上述的埋点管理流程，以及各种角色的诉求和职责，我们梳理出了埋点管理系统应该覆盖的功能，分别是：埋点管理、埋点属性管理、上报埋点数据监控。
埋点管理
埋点列表
埋点注册之后将会进入埋点列表，埋点列表提供比较完善的埋点信息，同时也是编辑埋点、查看埋点数据上报统计的入口。
注册/编辑埋点信息
埋点需求确认之后，将新的埋点录入埋点管理模块，需要完善的信息包括：
- 埋点基本信息，包括埋点名称、显示名、在线周期、可见性（设置为不可见的埋点会自动被设置为隐藏，所有分析功能都不能使用）、业务负责人、开发负责人、覆盖客户端（产品可能涉及多种客户端，如iOS、Android，需要说明哪些端会上报这个埋点），以及额外的备注信息。
- 通用属性：数据团队维护了产品/业务层面的公共属性，注册埋点时，需要选择埋点要包括哪些通用属性。
- 自定义属性：埋点下特有的属性，有需求方按照评审内容进行添加，需要填写埋点名称、显示名、字符类型、可见性、覆盖端等信息。
埋点回数状态
查看需求计划中的埋点以及属性在各端是否都已触发（上报数据）。
埋点回收
完整的埋点生命周期应该包括下线无用埋点，埋点回收功能将不再使用的埋点移到回收站中。埋点被回收后，历史数据依然可查询，但后续将不在接收该埋点的上报数据。用户可以通过移出回收站，恢复接收上报数据。
需要特别说明，这样的设计是出于业务特点的考虑。在用户行为分析系统的初期，我们定义了埋点的规范，但并未将整个规范流程线上化，只做了简单「埋点启用/禁用」功能，来控制埋点是否可以查询到。随着业务的发展，埋点个数在短短的时间内激增到了上万个，其中非常多的埋点上报后从来没有被查询过，有的埋点被禁用了很长时间，但一直在上报数据。后来经过盘点，实际上只有 15% 左右的埋点有过查询记录，而这些无用的埋点占用了大量的计算资源，也增加了埋点数据查询的难度（毕竟要从上万个埋点里找出关注的埋点不是一件容易的事）。基于这样的背景，我们添加了僵尸埋点过滤的功能，将首次上报后 3 个月未启用的埋点、禁用后的埋点过滤掉，即这些数据不会进入用户行为分析平台的计算引擎。功能上线后，做了简单的统计，大概能够节约 30% 的计算资源。
后来，我们做了埋点管理功能，将整个规范流程线上化。埋点管理中仍然保留了僵尸埋点的过滤策略，并做了进一步的优化。比如用户在注册埋点的时候，可以选择埋点的在线周期是长期在线还是到某一天就自动下线回收。并且，我们要将埋点可查询和埋点可接收做了分离：通过操作埋点及属性的可见性，控制数据是否可查询；通过将埋点移入/移出回收站，控制是否接收数据上报。
埋点属性管理
在埋点元数据中维护产品/业务层面的通用属性，由数据团队统一维护，所有可见的属性，都可以在注册/编辑埋点是添加属性时搜索到。自定义属性相对于通用属性，是某个事件下特有的属性，由业务方根据埋点方案维护。
上报埋点数据监控
我们可以在埋点管理中看到具体埋点的数据上报情况，监控异常。
