背景

云积分是一家深耕在电商行业的互联网公司，所做的业务就包含电商的一些数据报表、数据分析，埋点就成为了其业务中必不可少的一环。而且由于电商行业的复杂性，针对埋点这一块，也有它独特的复杂性。

比如，某个客户，针对自己举办的某一场互动活动，需要这一场互动活动的PV、UV、拉新人数、入会人数、消费金额、订单转化率等数据。

同传统的埋点提供商相比，云积分的埋点有通用的地方，比如PV、UV、拉新人数等指标，是比较好统计的。但是如果涉及到消费金额、订单转化等维度的数据，基本很难做到具体的指标分析。而且每一个商家、每一场活动，关注的数据指标也不同。哪怕针对同一个指标，比如入会人数，有些人理解是点击了入会的按钮，就算入会，有些人理解是通过入会的接口，返回成功后才算入会人数。这些gap，就需要有一个非常实用的工具，来帮助大家解决这些问题。

痛点分析

从云积分业务发展历史，才能客观的看待业务的现状以及未来。

数据报表是一个强需求，是每一个商家非常关注的点，起初为了满足客户的诉求。我们定义了一套规则，大数据根据上报的这些数据，提供接口查询能力。这套规则其实就是采集用户的行为数据，把每一种行为定义为一类事件，每个事件都上报了一些通用的字段，比如项目名称、页面url、用户openid等等。

这样的设计，看起来还凑合，但是在实际执行中，引发了一系列的开发灾难。

1、大数据和前台业务的耦合、上层业务和底层大数据无法形成统一的规范认知

每一个互动的需求进来之后，前端按照规范进行埋点，埋点之后大数据进行数据加工。但是业务的需求，是经常调整的，从客户那边得到的诉求通常会有理解上的差异，并且开发之间，也有理解上的差异，前端觉得我把核心的数据给到大数据了，大数据就能计算出来，大数据觉得，前端的数据字段传递的不完整，有些事脏数据。回馈到客户那边，就是云积分的数据统计经常不准确。

2、人力资源内耗严重，每次关于报表的功能，都需要重新理解数据需求进行开发

数据埋点，应该是有一套标准的，可量化的解决方案。但是随着客户不同的诉求的增加，前端、大数据都深度参与了业务的理解上面，一个细小的改动，链路从用户、到产品、到前端、到大数据，每个人都需要理解一遍。而且为了这么一个小的诉求，人力的耗费非常大。

方案设想

我们应该有新的方案，来面对这些业务的痛点。

1、大数据和前台业务完全解耦。

从原则上说，大数据本身应该不需要关注具体的业务，就算参与一些业务理解，也要尽量的在可控范围内，尽量把精力聚焦在具体某一项能力和服务上。

初步的设想是，大数据不关注具体的业务，它本身只是对数据的聚合、统计、加工处理。对上层提供通用的接口能力。

前台业务，需要对具体的数据负责，埋什么点位，大数据就给吐什么数据，大数据只对服务的准确性负责，前台对业务的准确性负责。

2、需要抽象业务的模型

根据上面的诉求，大数据和前台分离，需要有比较好的概念抽象能力。

我们的埋点设计，抽象了四层概念，确保了大数据和前台业务的分离，也定义了各自关注的标准格式。这四层概念分别是：应用、指标、事件、属性。

1、应用，每一个新的项目，就是一个应用，每一个应用，会关联相关的指标，这些指标，就是客户所关心的数据。

2、指标，指标是客户关注的核心数据，每一个指标，都会关联相关的事件。

3、事件，事件就是用户的一次行为，用户每做出一个行为，就会产生一条数据，由大数据进行统计。

4、属性，属性定义了每一个事件，传递的参数是什么，每个参数代表了什么意义。

分为四层模型，大数据只需要关注具体的事件，相关的数据统计。它本身只向上层提供事件的数据统计结果的查询。而上次业务，关注的是指标，指标需要关联事件，具体指标是由什么事件计算得来，由上层业务自行决定。

3、报表应该是自定义的

报表不需要每次重新开发，我们应该有这样的一个平台，能够通过应用，自定义创建报表，因为每一个应用都关联了指标，我们对这些指标做可视化的展示就行。至于大数据，还是提供底层的基础事件查询能力。我们需要什么样的数据，我们自行决定。

方案详情

关于方案，具体实施起来的细节，太多了。我们不会纠结于某一个小点，给大家说明方案是什么，我们提供的是我们的一个解决思路，技术框架。

整个架构图如下所示

埋点管理平台

它包含三部分内容：埋点规范定义约束、自定义报表、数据大盘分析。

其中，埋点规范定义约束，是要定义SDK进行数据上报的字段标准。比如应用名称、code、事件名称、事件code等等。

自定义报表，自行配置应用的相关报表，从大数据的标准接口中读取事件的统计数据，进行数据聚合展示。

数据大盘分析，也就是用户行为分析。

在技术方面，我们的埋点管理平台，是由一个node服务当server端，前端使用react进行页面展示。

sdk部分

云积分的项目，主要由两部分构成：1、不通平台的各种小程序。（京东、淘宝、抖音等等）。2、Web端的PC后台管理系统和H5页面。

所以在设计SDK的时候，有两个重点：小程序和H5的兼容问题、数据字段校验问题。

数据接收服务

这是一个Java服务，是SDK内部调用的上报接口，它仅仅有一个功能，就是把上报的数据推送到Kafka。

大数据

大数据的功能主要有这么几部分：

1、大数据从Kafka消费上报的数据，把具体的的事件落到数仓。

2、大数据每天定时跑任务，对事件数据进行聚合统计计算。

3、对外提供标准的事件查询服务。

对外开放能力

埋点平台从始至终的目标有两个：

1、提供自定义报表能力。解决业务中每次需要重新开发报表的痛点。

2、对外开放api。我们对事件进行统一管理、产生数据之后，就能对用户的行为进行统一的行为数据分析。赋能商业价值。

以埋点平台为基础，向上能够做各种数据分析。并且在我们的系统中，本身就有指标能力的抽象，这些指标能力，是具有巨大的商业价值，能够辅助我们的业务发展和决策。