埋点管理系统与埋点地图

在介绍埋点管理系统之前，我们来回顾下，之前的埋点工作是怎么做的。

从开发协作演化反思埋点管理

协作流程0.1版本：

上图是刚成立之初，在人员紧缺，数据开发的工程环境几乎为0的情况下，整个团队的协作流程：

1. 产品经理输出功能需求和数据需求
2. 业务开发和数据开发分别承接对应的功能需求和数据需求的开发
3. 数据需求和业务开发的需求是没法同步进行的，需要等待业务开发完，确认了最终的数据格式和数据标准，并且已经正常生产数据时，才开始介入开发。所以需要频繁去确认业务开发功能是否开发完毕，已经上线。
4. 如果开发完毕，数据开发正式介入开发

我们可以看到能否把5出现的问题，尽可能的提前，这样可以避免走完所有的开发流程后，才发现问题，导致弥补成本很高。于是我们改进下

协作流程0.2版本：

我们引入了评审数据需求这个环节，将所有数据需求，所用到的数据，提前进行评审，确保数据需求，所需的基础数据，都能在业务开发完成后。一切看起来又向高效美好的工作方向靠近。但是随着公司团队规模的扩大，新的问题又来了。

从上图我们可以看到，随着产品人员的增多，需求的增多，各个团队都会遇到一些问题，总结起来，有如下三个主要问题：

1. 回溯困难：想回溯之前的埋点，查阅埋点说明信息，但是埋点信息散落在各个产品梳理的文档，文档类型包括Word、Excel或者项目需求管理系统里面。而且不同产品经理不同时期梳理的文档风格多样，想回溯具体的埋点信息，几乎不可能。渐渐的，这些无法回溯的埋点成为，系统里面不可丢弃的“垃圾”。
2. 重复埋点：不同的产品梳理了不同的数据需求，涉及到相同的功能点，重复梳理了，只是命名不同，造成业务开发重复埋点。
3. 埋点缺漏：特别是在产品需求存在交集的情况下，可能因为团队内部互相扯皮或者沟通问题导致都忘记梳理相关的埋点。

除了上面三个共性问题外。对于非业务开发人员，例如数据研发，还都会关注数据质量，这方面主要会包括下面的俩点：

1. 所需的埋点数据是否都已经上报。
2. 所需的埋点数据是否都按照既定的格式上报。

当前的埋管管理与工作协作

基于上面的所罗列的问题，我们也整理了一套的解决方案。

首先统一了埋点文档的标准，解决回溯困难，如下图：

1. 业务UI的前端图片和点位标识
2. 针对点位的信息描述，以表格形式展现。里面包含几个列：点位，业务含义，事件类型，补充扩展字段，客户端埋点还是服务端埋点。其中事件类型的起名由页面、功能、操作元素类型、操作元素的动作、该点初始上线的版本，这几部分构成。每个点位都有一些特定的描述信息，这些信息在各个点位都不太一样，所以我们新增了补充扩展字段这一列。

• 埋点梳理我们统一交给一个接收口人，并将这些埋点统一放到云文档中进行共享，方便相关埋点梳理人员进行通盘梳理，尽可能避免因找不到相关文档，或者不同人员的梳理导致的重复埋和漏埋。
• 定义了统一的客户端、服务端上报的埋点格式，如下：

{

    "app_id": "xxx",  // 产品id

    "app_version": "4.5.8",   //软件版本号

    "app_platform": "ANDROID",  // 软件平台 （微信小程序，H5，IPHONE，ANDROID）

    "event_id": "bd0ebac0-e04e-49a5-b984-899cc23593f7",  //事件id

    "event_ts": 1587435557503,  //事件发生的时间戳

    "event_type": "learning_report_bottom_feedback",  //事件标签名称

    "sink_ts": 1587435557503,  //记录该日志的时间戳

    "user_id": 1,  //用户的id

    "side": "server",  //对应埋点来源（客户端，服务端）

    "session_id": “xxxxx”,  //session_id, 服务端需要客户端回传下session_id,

    “live_session_id”:”xxxxx”,//服务端需要客户端回传下这个ID，标

    “first_login_time”:””,//注册日期

    "params": {

        "question_level": "A1",     //A1，A2......，题目对应的等级

        "question_type": "词汇题",     //词汇题，语法题......，题目对应的题型

    }  

}

通过定义统一个埋点上报规范，我们有做数据校验的基础，在数据采集的时候，我们可以根据上面的JSON-Schema,去检查整个JSON是否符合规范，JSON的字段是否都按照既定的格式进行上报，不同埋点的JSON是否都已经上报，来保证数据质量。

整个的埋点工作的协作流程变为：

流程看起还不错，产品经理只输出功能需求和最终的数据需求，数据产品或者分析梳理基础业务数据或者埋点需求，埋点需求放到一个统一目录下，业务开发拿到功能开发需求和埋点需求各自开发，数据开发拿到数据产品进行评审和开发。

每个岗位各司其职，一切好像都运行得很流畅，但是在实际的操作中，当埋点的需求变多，埋点的文档将会快速膨胀，后续在查找相关的埋点也会很困难，如果埋点梳理的统一接收口人，也出现多个的情况，极大概率可能因为梳理的需求工作有重叠，也会导致，错漏埋。 如何根本上解决埋点的问题？我们认为要是需要有一个类似地图一样的工具用于替换目前的输出的word/excel/原型文档，来标识产品上各个功能页面的埋点信息，既有埋点信息的说明，又有类似axure原型的直观展现效果。通过这个地图工具，我们可以快速查看各个功能页面上缺漏的埋点。数据产品/分析在梳理埋点的时候，可以快速浏览相关功能下的埋点，防止错埋、漏埋。所有数据产品/分析人员的操作都是基于这个地图来梳理埋点，也可以从根本上解决重复埋的问题。业务在开发的时候拿到埋点需求的时候，也可以根据这个地图，开发相关的埋点，防止埋点埋错位置。后续数据在开发和分析的时候，也可以根据这个地图快速拿到各个埋点的信息和业务含义，进行快速开发和分析以及复盘。基于这样的一个地图我们将所有的埋点进行统一管理，也从根本上避免埋点“垃圾”的产生。

于是我们开发了自己的埋点地图和埋点需求管理工具。

产品功能目录树

如果要梳理一个埋点地图出来，就需要有一个能够完整刻画产品功能之前的关系。我们认为一个产品功能目录树是最为直观的表达方式。下面是我们产品功能目录的整体界面图

整个产品分为四个功能：

1. 产品功能目录树的展现：客户整个目录的层级关系
2. 产品功能的目录筛选框：快速定位产品功能。如我们定位首页

1. 产品功能录入：这里我们提供了一个录入页面，如下图：

其中：

上级目录：表示能跳转到该页面的前置功能。

页面类型：分为主页和跳转页。有些页面具有多个前置功能，即有多个入口都能到达该页，在我们录入一个页面后，后续还遇到相同的页面，只是前置功能不同的话，为了防止信息的重复录入，就可以将后续的相同页面定义为跳转页，每个跳转都会被映射到最初的定义那个唯一主页。这里跳转页里面不能录入后续的一些埋点信息，所有信息只能在主页类型页面进行录入。例如2中的，重点词汇下的词汇学习（跳转页）对应的就是主页就是视屏结束后练习的词汇练习。

1. 修改产品功能的信息描述。

有埋点事件地图管理

浏览地图中的埋点

下面是有埋点事件地图的功能界面

点击图上左边的功能，在右边的列表信息框会列出该功能下所有埋点信息信息。图左边功能名称旁边的数字表示该功能有多少个埋点。

图右边的列表有如下字段：

1. 产品：表示该埋点所在的产品，在公司有多个产品的情况下，有用
2. 平台：表示该埋点是在ANDROID还是IPHONE
3. 初始上线版本：表示该埋点在哪个版本上线
4. 事件类型：开发埋点所用埋点英文名
5. 事件名：埋点对应的中文名
6. 埋点端：有三个枚举值
   1. 客户端：表示该点位为客户端负责埋点。
   2. 服务端：表示该点位为服务端负责埋点
   3. H5：表示该点位为H5前端负责埋点
7. 埋点需求原型图：表示该点位对应的Axure原型图，如

1. 点位：表示埋点需求原型图里面的具体表示的红点。例如上图中1,2,3就是表示具体需要埋的点位
2. 需要task：表示项目管理工具分配到需求名称
3. 关联pb的task的URL：pb是我们的项目管理工具，这里的URL会指向具体的需求任务。这一栏主要是为方便使用该埋点的相关人员能够快速了解到需求的上下文信息。
4. 埋点所属页面：表示该埋点在那个页面下
5. 启用状态：表示该埋点是否还在使用中
6. 事件params参数：每个点位都可以附带一些该点位才有的特殊信息，这里我们用params来存储这些具体信息，这里面定义的就是params里面的字段参数
7. 是否监控：表示是否已经纳入到监控系统中，自动监控该点位的上报是否正常。

 

新增/修改埋点

点击新增按钮，我们会弹出相关埋点录入功能，如下图

其中埋点需求原型图，我们支持保存在内存中的图片直接黏贴上去。换句话说用户可以直接Ctrl+C和Ctrl+V直接上传图片。

埋点事件，这里我们支持一个原型图，录入多个埋点，点击图最下面的新增，即可实现新增。

有埋点事件全量管理

在实际工作中，一个需求往往涉及多个页面，为了快速查看、管理多个页面的埋点，我们提供了一个扁平化的管理功能，即“有埋点事件全量管理”

从上图我们可以看到，这里集成了很多功能

1. 支持多种查询条件，如：产品，平台，版本，事件类型，事件名称等等。
2. 支持新增/修改埋点，同有埋点事件地图管理里面的新增/修改
3. 支持生成需求URL。在数据产品/分析人员录入相关的埋点信息，一般会提供一个文档给到相应的开发人员开发，一般常规的做法就是导出文档，但是文档可能存在信息不同同步的问题，频繁修改频繁导出也稍显麻烦。所以这里我们提供一个生成需求URL，这个会保存这个页面的查询条件，数据产品只要将该链接给到开发人员，开发人员就可以快速看到自己需要做的埋点。并且在这上面可以做到实时同步需要修改的埋点。
4. 保存需求。保存需求本质上也是生成需求URL然后保存在系统。新增了这个功能，可以方便后续需求人员快速查看跟踪具体的需求下面所有埋点的点位信息。
5. 批量删除。可以批量删除无用的埋点
6. 批量修改。上图6标识批量修改只是批量修改需求信息，而不是埋点信息，如下图

如果要批量修改埋点信息，直接操作表格，如图上标识13。

1. 批量更改埋点事件状态。批量上下线埋点。
2. 批量修改埋点监控。将事件批量纳入到监控系统中进行监控。
3. 查看当前埋点的数据趋势。点击上图标识11，可以看到如下界面

用户可以根据时间，自由查看不同时间点的上报情况

埋点的统计信息

埋点的统计信息，可以快速获取

1. 埋点总数据量
2. 各个产品的埋点数量
3. 监控的埋点信息
4. 下线的埋点数量
5. 异常告警的埋点数量