埋点系统之可信数据采集持续集成实践

引言

埋点数据,必须是准确的、完备的,否则无法为上层BI产品提供可信数据。端数据采集方案可简单归类为手动埋点、可视化埋点以及无痕埋点三大类。在高DAU APP中,要完全脱离手动埋点,实行无痕埋点方案,在网络带宽、数据存储等方面会带来一定的压力。我司目前停留在手动埋点阶段,在实践过程,我们发现,由于手动埋点依赖上层业务开发人员,也较容易出现漏埋和错埋,并且错误数据的发现存在滞后性,往往在BI输出产品阶段才被发现。
为保证数据的可靠性,以及尽量减少开发人员对埋点的工作投入,我们做了以下几方面工作:

  1. 在浏览器端,提供埋点管理平台,为BI、测试、开发等角色提供事件定义、埋点版本追踪、数据验收、数据回归测试等持续集成功能;
  2. 在手持端,在APP中嵌入可视化埋点工具,为开发与测试同学提供实时数据校验功能;
  3. 简化开发同学编码:控件点击、页面曝光只需一行代码;页面等事件无需开发同学关注,埋点SDK自动上报并补全设备和用户信息;

部分术语

埋点协议:规范一条埋点数据格式,数据对象中各字段含义以及取值来源;协议要尽量涵盖Android和iOS设备纬度信息、用户信息、以及业务自身数据;
埋点事件:标识一个原子操作,比如一次控件点击、一次网络请求;
业务埋点事件:BI或业务关心的数据,比如用户注册、控件点击,页面路径;
技术埋点事件:大部分是开发人员关注的数据,可用于各性能指标的统计,比如网络事件、CDN健康状态事件;

埋点管理平台

埋点管理平台承载以下基础功能:
1、规范和约束事件定义;
2、业务埋点持续集成,BI编辑埋点、开发查看变更埋点和测试人工/自动化测试埋点;
3、业务埋点测试辅助,如埋点回归验证;
4、基于规范化埋点管理,输出数据相关服务,如 kibana自动化查询业务数据需求;

本文我们只关注,如果让数据开发与验收成为持续集成中不可或缺的一环。

埋点流程

在APP版本研发前,产品同学会提出需求,以及他们所关心的数据。BI同学会与产品同学沟通,输出必要的业务埋点事件,同时录入埋点管理平台,如下图:

埋点管理平台,提供埋点查询与过滤功能。例如,我们提供APP版本、开发同学归属的埋点、埋点所处页面,区块等过滤条件;我们用颜色区分埋点事件的状态,如红色标识为变更埋点,黄色标识为新增埋点等。通过各维度查询,尽量让开发和测试同学快速找到关心的埋点数据。

开发同学收到埋点通知后,进行埋点开发,自测通过后在埋点管理平台进行开发状态确认。测试同学收到埋点开发完成通知,进行埋点测试与校验。

通过埋点录入、埋点开发和校验,能极大减少漏埋和错埋的案例发生。

手持端数据校验

通过埋点管理平台,也无法完全杜绝漏埋和错埋,比如特殊场景下,es数据消费阻塞,开发和测试同学无法在浏览器端进行校验,这时就要在手持端进行校验工作了。

手持端可视化埋点工具,要做到不能阻塞APP操作,以及要能实时显示埋点数据和数据汇总查询。借助hyperion以及埋点SDK提供的功能,我们实现了最初的想法。部分截图如下:


结束语

埋点这块,有很多可以和大家讨论的点,比如埋点SDK上报流程设计、前端与后台数据存储、实时和离线数据分析与利用。本文只是一个起点,后续会陆续分享出来我们现在的一些玩法,都是我们的一些实践。