作者：weberli 李少鹏
编辑：lynnewei 魏琳
埋点上报作为数据统计分析的基础，随着业务的发展，对其准确性与稳定性的要求越来越高。本文主要介绍了微保在埋点设计规范中遇到的一些痛点与解决思路。
1
前言
随着用户增长在微保业务中的大规模落地，以数据指导业务精细化运营的模式正在成为日常工作中的标配。在具体实践中，又以A/B实验作为核心的决策依据。（关于A/B实验，可以阅读历史文章《面向数据开发之A/B实验平台概述》） 万丈高楼平地起，作为A/B实验数据统计基石的前端埋点上报必然要做到精准无误，微保的全埋点上报SDK为A/B实验的埋点上报做了不少前期的工作。然而在埋点上报方案重新梳理之前，前端在接入A/B实验时，业务开发常常根据自己的理解，对埋点的字段，触发事件等内容进行上报。随之产生了以下几个问题：
上报字段不规范，数据分析无法做到通用化。
埋点的准确性难以得到保证，如是否漏报，字段是否上报准确。
埋点的管理查询缺乏工具，需要通过基础日志来查询。
埋点定义不一致，比如提交表单的动作，有的是点击提交按钮，有的是表单提交完成后触发上报。
针对上面的痛点，我们做了下面三件事，旨在解决上面的痛点，做好A/B实验数据统计基石：
埋点业务流程整理
埋点规范设计
埋点管理设计
2
埋点业务流程整理
在对埋点业务做整理之前，埋点通常是常规需求的附加需求，产品在提需求时不重视，开发按照自己的理解来添加埋点。特性上线后，产品在业务数据分析时才想起埋点的重要性，往往会导致统计逻辑要适配不同风格的埋点，或者埋点优化返工。
在A/B实验中，埋点字段中附带实验信息，上报到日志服务之后，再进行数据分析。因此埋点处于重要的中间环节。
为了解决这个痛点，同时配合A/B实验复杂埋点的需要，我们对埋点业务流程进行了梳理，新增“方案设计评审”这个环节。整体流程如下：
图表1 埋点业务流程图
那方案设计怎么做呢？
在全埋点的基础上，结合A/B实验逻辑，对页面、模块、组件和特性进行拆解，并设计好埋点上报的事件与时机，输出设计方案文档，与上下游对齐。
如“微保首页”的埋点方案，我们将首页拆成N个组件，每个组件都对应有“埋点定义”，“上报例子”等内容。
图表2 埋点方案设计文档示例
3
规范设计
埋点规范设计
除了实验的信息，还需要识别用户的身份、设备、客户端版本等信息来帮助实验做好染色分流、数据分析。
上文已经提到，微保采用的是全埋点的上报方案，那么如何把数据转换成运营的角度来分析问题呢？
借鉴业内的方法，我们将用户的行为拆成5个事件，遵从“4W1H”的原则，即用户在什么时间做了什么事情，当时他做的这个事情的位置和场景是什么。
可以通过下图案例来理解这个原则：
图表3“4W1H”案例
假如我们需要对上图标红的模块做不同样式的点击效果实验。“4W1H”可以描述为：用户A（WHO）在June 5th 2020, 17:02:37.032（WHEN）在个人中心页（WHERE）点击（HOW）了保单入口（WHAT）。
其中红色的“WHAT”和“HOW”是需要单独开发上报的，它属于配置或自定义数据。蓝色的事件则交由微保的全埋点SDK上报。
通过这样的设计，我们就能很清晰地分析出用户在小程序内各个变量下做出的实验效果。
具体5个事件的枚举值可以参考下表：
图表 4“4W1H”字段枚举表
红色的“WHAT”和“HOW”，非全埋点规范的内容，那要上报什么字段呢？我们对此也是进行了充分的讨论，充分照顾到了A/B实验与其他统计场景所需要的字段，最终形成下面的规范。
上报事件的枚举值有：
| event | 描述 |
| click | 点击 |
| dataExposure | 数据曝光 |
| visualExposure | 视觉曝光 |
每个事件附带规范字段：
| key | 描述 |
| elemId | 元素的唯一标识，根据pageId+elemId确定元素的唯一性 |
| desc | 埋点的中文描述字段 |
| itemId | 类目Id |
| link | 小程序/H5链接 |
| isHighlight | 元素是否做强势展现（比如：红点，角标等） |
| elemPos | 元素在组件中的位置 |
| modulePos | 模块在页面的位置 |
| componentPos | 组件在模块的位置 |
| componentId | 实验组件Id |
| testTag | 实验标签 |
| testId | 实验Id |
| moduleId | 模块Id |
| featureId | 特性Id |
| extraInfo | 用于承载智能推荐或其他场景的埋点上报 |
埋点SDK设计
看到上面比较多的字段，所需埋点之处都要重复添加，这显然会降低前端埋点的开发效率。举一个点击埋点上报的例子：
图表5 点击埋点上报示例
因此，我们封装了一个埋点上报SDK，逻辑如下图：
图表6 埋点SDK 逻辑图
核心逻辑是提供一个获取实验信息的接口获得实验字段，再合并传入字段、默认字段，最终形成上报所需的规范字段。这样做的好处是入参少，规范了上报字段，提高开发效率。改进后的点击上报例子如下：
图表7 点击埋点SDK上报示例
4
埋点管理
开发侧的埋点设计规范我们已经制定好了，埋点上报到了后台，如何来管理这些埋点又是一个新的难题。
要解决好这个问题，我们围绕埋点收集、埋点查询、埋点测试三部分展开阐述。
埋点收集
收集前端在交互过程中产生的信息，保存为规范化的日志落地，这是日志上报服务的工作。
在此基础上，我们又增加了埋点收集管理服务，便于业务分析、异常监控。具体架构如下：
图表8 日志收集与使用
埋点查询
在日常开发的工程中，常常会被数据使用方问询问埋点的上报格式内容。早期，如果想查看一个埋点的信息，需要去日志系统(ELK)查询。但原始的日志数据，查看起来很费劲。如下图：
图表9 日志数据示例
为了解决这个痛点，在埋点收集管理服务中我们提供了更丰富的查询能力。具体包含下面的功能：
图表10 埋点管理的功能模块
通过对上报字段的筛选，展示关键字段，呈现出清晰的埋点列表。并且提供更加便捷的搜索功能，可以对自定义字段进行搜索。
图表11 埋点管理系统中的埋点查询界面
同时我们可以对每个埋点进行管理，如进行备注，获取上报的详细信息等。
图表12 埋点管理系统中的埋点字段结构图
通过这样的管理设计，只要在这里搜一下，复制一下埋点的详细内容，就可以给到对应的数据使用方做参考。
埋点测试
怎样保证上报的埋点的准确性，一直是困扰测试、开发的问题。一是如何确保有上报，二是要确保上报得准确。
前期我们只能通过人工来检测每个埋点，费时费力，容易出错。而且当埋点被改变发布的时候，测试、开发如果没有回归测试，这时很容易出现上报错误。
为了解决上面的问题，我们给出了下面的方案：
当需求提测时，测试、开发可以通过搜索来确定埋点是否上报，对必须上报的字段做强校验，并且保存第一次上报的埋点镜像。
当下次提测时，点击扫描埋点，如果出现埋点变动，则发出告警通知，如果埋点没有变化则显示为“正常”状态。
5
总结
作为支持A/B实验的基础，为保证埋点的规范性和稳定性，我们提高对前端埋点的重视，重新梳理了埋点业务流程。在全埋点的基础上，对埋点的规范设计使用了“4W1H”的原则，便于定义分析埋点。另外，我们开发了埋点管理系统，方便使用者查询埋点，确保埋点的稳定可靠。希望这些思考与实践，能够为读者带来帮助。
