数据仓库埋点治理

1、什么是埋点

埋点：又称为事件追踪（Event Tracking），指的是针对特定用户行为或事件进行捕获，处理和发送的相关技术及其实施过程。

功能方面，埋点是用来收集用户行为数据。比如想要了解一个用户在APP里面点击了哪些按钮，看了哪些页面，做了哪些事情等，就可以通过埋点来实现。

实现方式方面，埋点就是通过植入一段代码到某个页面或某个按钮，从而监听用户行为并进行收集上报。

2、埋点的作用

开始之前我们先看一下我们为什么要收集埋点数据，埋点都可以做什么，埋点主要用于记录用户行为,几乎是应用必不可少的功能.埋点的作用包括但不限于

分析用户转化以及存留：例如下载的用户数量,注册的用户数量,一段时间之后的存留用户数量;

分析用户偏好：例如通过用户行为的分析,可以对用户的偏好做一定的概括,便于投其所好针对特性的用户推送特定的服务,甚至开发不同的用户体验;

收集市场反馈：例如针对新功能的用户行为进行统计,就可以分析出功能的市场反馈,为是否保留功能或者改良方向提供依据;

保障用户数据安全：例如用户的地理位置数据在短时间内突然发生了异常变更,这一秒在南京,下一秒突然就在东京登陆了,那就说明账号发生了异常,需要对账号身份进行验证,以确保用户数据的安全.

定位异常：例如特定的数据(比如注册)在某一段时间内数据突然无缘由发生持续性异常,说明该功能可能存在异常,需要及时做排查.

其他作用：例如当某一个较早机型占比降低到某一个阀值时,就可以在下一个版本中去掉对该设备的支持.

3、埋点数仓设计

数据进入数仓之前我们就需要设计好数仓表，埋点的表的数据有几个特点，所以我们在设计的时候需要考虑到

1. 数据量非常大，可能是所有数据集成渠道里面，流量最大的了
2. 数据不存在更新，这是埋点表的数据特点

面对这两个特点，我们需要做一些设计，当然还有一些其他设计方面的点需要注意一下，首先因为量大，而且我们往往关注的是昨天的数据，所以我们的表肯定是分区表，其次因为我们使用的特点，例如关注的是页面浏览或者是按钮点击，所以我们在时间分区的基础上按照事件进行分区。这样我们可以在数据查询的时候过滤掉大量的数据从而提高查询的性能。

其次就是埋点表的作为数据报表的数据来源的时候，可能会大概率遇到计算延迟，或者是一些其他问题，所以在宽表的设计或者是报表展示中，请尽量地将集成进行后延，从而更好的保证稳定性和可用性。关于这一点，请参考数仓建模—宽表的设计

这里是我们公司小程序端的埋点表

下面是web 端的埋点表

4、埋点的类型

埋点：在期望的点位，埋设一个记录的标记。这个点位，一般多是指用户与产品进行一次次交互的接触点，从而可以在用户和产品交互的时候，将用户的数据进行上报。

通过收集这些标记点的数据，可以帮助产品运营及开发同学了解功能的整体使用、运行情况，并通过数据基础上做出下一步调整或优化的方向。遇事不拍脑袋，而是用数据说话，这是数据埋点最大的价值。

在AB测试的场景下，数据埋点为实验组的效果提供数据支持，其本质也是数据决策的基础。

根据目前常见的数据埋点形式，可以将数据埋点分为全埋点、代码埋点(自定义埋点)，当然我们也可以按照产品的类型划分为，APP埋点、web 埋点、小程序埋点

全埋点

全埋点的逻辑，是指数据采集sdk无区别的对待所有事件的，将所有事件(页面的加载成功事件、控件的浏览和点击事件)全部获取后先存下来，到使用的时候，再根据具体的页面路径和控件名称，去捞取相应的数据。

可视化埋点

基于此，可视化埋点是指，在全埋点部署成功、已经可以获得全量数据的基础上，以可视化的方式，然后进行数据选择。

这种方案的弊端之一是耗流量和存储空间，全埋点采集的数据一般会根据情况设定一个销毁时限，比如7天。即：全采集过来的数据，如果7天之内没有被使用，则会删除。而一旦对圈选数据做了圈选定义之后，则被定义的页面数据、控件数据，则会一直采集，且不会删除。

全埋点，其优势和特点是功能上线时，不需要开发做额外的埋点定义工作，用的时候再根据需求去获取对应的数据，因此也叫无埋点。

全埋点的缺点：

1. 耗用户流量、占存储空间；
2. 一旦版本迭代，对页面的路径做修改，或者控件位置、文案有修改，原来的圈选数据可能就会出错，需要重新圈选，之前利用圈选指标设定的分析模型都要替换；
3. 圈选指标无法区分细部参数，比如：商品详情页，无法通过圈选数据来区分是哪一个商品或哪一个类目；
4. 对web的页面数据处理一直不好，尤其是涉及到APP的内嵌H5页时，非常痛苦。

因此，全埋点适用于业务多变、经常调整，且分析诉求比较轻量的场景。对于通用的功能，形态相对比较固定，且对数据分析颗粒度、下钻深度、聚合程度要求比较高，那就需要用到代码埋点

代码埋点

代码埋点也叫自定义埋点，从字面上即可理解：是针对想要的点位单独定义，并可以通过变量丰富埋点的信息，以支持上下游分析。

代码埋点分为前端埋点和后端埋点。

前端埋点，包括但不限于APP客户端、H5、微信小程序、PC网页，是指对具体的功能场景（如加载成功、浏览、点击等）进行明确的定义，由前端触发，采集上来的数据相比于全埋点，更准确、稳定，且通过变量字段，能够实现更细颗粒度数据的拆分、聚合和下钻。

后端埋点，指触发了服务端接口调用（如：接口回调成功触发）的事件埋点，如最典型的注册成功事件、付费成功事件。后端埋点对数据的准确度要求更高，同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻。需要强调的是，后端事件一般采集的是已登录状态下的用户行为，如果想使用后端埋点事件作为流程分析的其中一环（如漏斗分析），则可能出现未登录的用户会漏掉的情况。

综合以上，几种埋点类型的比较

5、埋点上报方式

对于一个埋点方案来说，数据上报有两个点需要着重考虑：

1. 对跨域做特殊处理。
2. 页面销毁后，如何还能够将未上传的埋点数据成功上报

参考 https://juejin.cn/post/6844904153739706375

图片请求

有下面几点优势：

1. 没有跨域问题，一般这种上报数据，代码要写通用的，img 天然支持跨域；（排除 ajax）
2. 不会阻塞页面加载，影响用户的体验，只要 new Image 对象就好了, 通过它的onerror和onload事件来检测发送状态；（排 除 JS/CSS 文件资源方式上报）
3. 在所有图片中，简单、安全、相比PNG/JPG体积最小；（比较 PNG/JPG）（tip:最小的BMP文件需要74个字节，PNG需要67个字节，而合法的GIF，只需要43个字

这种使用方式也存在缺陷。首先对于src 中的URL内容是有大小限制的，太大的数据量不适用。详细看这里。其次，在页面卸载的时候，若存在数据未发送的情况，会先将对应的数据发送完，再执行页面卸载。这种情况下，会在体验上给使用者带来不方便。

GET 请求

GET把参数包含在URL中，也就是说我们的上报的数据是在一个url 参数中或者是几个参数中，例如 ?data=XXXX
 这里的data 就是我们上报的数据

GET 请求 最大的特点就是简单，但是同时也带来了很多其他的问题，首先是安全问题因为GET 请求参数被暴露在IURL 中，GET请求只能进行url编码，而POST支持多种编码方式，其次GET请求在URL中传送的参数是有长度限制的，也就是如果你上报的数据内容比较多，可能会被截断。

POST 请求

POST 请求 相比GET 请求首先就是更加安全，其次是支持多种编码，而且所能发送的数据量也更大，看起来是个不错的选择，但是还是不如图片请求好

6、六个步骤实现数据埋点设计

数据埋点设计是埋点的重中之重，埋点设计得好能够极大地方便后续的数据应用。对于数据埋点设计，我们也总结了六个关键步骤。

1.确认事件与变量

这里的事件指产品中的功能或者用户的操作，而变量是指描述事件的属性或者关键指标。确认事件与变量可以通过AARRR模型或者UJM模型进行逐步拆解，理清用户生命周期和行为路径，抽象出每一个步骤的关键指标。

Tips：AARRR模型和UJM模型会在之前的文章中有讲过，点击阅读原文即可跳转。

2.明确事件的触发时机

 不同的触发时机代表不同的计算口径，因此触发时机是影响数据准确的重要因素。以用户付款为例，是以用户点击付款界面作为触发条件，还是以付款成功作为触发条件进行埋点呢？二者口径不同，数据肯定会有一定差异，因此明确事件触发条件非常重要。

而在用户付款这个例子中，我们建议使用两个字段记录用户付款行为，一个字段记录点击付款界面这个行为，另一个字段记录是否付款成功。

3.明确事件的上报机制

不同的上报机制也是数据准确性的重要影响因素之一，客户端上报数据可能会由于网络原因出现丢包的情况，前面章节已经详细介绍过，这里就不在赘述上报机制之间的异同。而作为数据分析师，在完成埋点工作的时候也需要确定数据是实时上报还是异步上报，以确定埋点是否合理，并及时调整数据埋点方案。

4.设计数据表结构

统一的数据表结构，方便团队内部进行数据的管理和复用，建议团队内部形成一套统一的数据结构规范。例如，将表分为不同的层级，第一层记录用户的基础信息，包括id,地区,昵称等；第二层记录玩家行为信息。

5.统一字段命名规范

有了统一的数据表结构档案还是不够的，统一数据命名规范数据埋点工作的重要一环。确保同一变量在所有的数据表当中都用统一的字段，比如消费金额这个字段，我们希望所有的表只要出现消费金额都用Amount字段，不要出现money,pay等其他字段。

建立公司内部或者团队内部的命名规范是非常必要的，可以采用「动词+名词」或者「名词+动词」的规则来命名，比如「加入购物车」事件，就可以命名为：addToCart。

6.明确优先级

数据埋点都是为数据应用做铺排，埋点之后分析师可能面临着搭建指标体系和数据报表体系的工作，可以根据报表的优先级、埋点的技术实现成本以及资源有限性为数据埋点确定优先级。

（1）通过UJM模型拆分用户购买商品的路径：将用户购买路径拆解为注册-登录-商品曝光-商品点击-浏览页面详情-加入购物车-生成订单-订单支付步骤，根据产品或策划提的数据需求，确定每一个步骤学要看哪些字段才能实现数据需求。

（2）确认触发机制：明确是在点击按钮时记录行为还是在用户完成该步骤时记录行为。

（3）确认上报机制：明确数据上报机制，是实时上报还是异步上报，不同的上报机制采集到的字段可能不一样，或者说需要将字段拆分到不同表进行记录。

（4）统一字段名：业务内同一变量在所有的数据表当中都用统一的字段，例如，用户编号用account_id,用户所属国家用region,用户所属地区用ip_region等等。

（5）统一表层级结构：我们这里采用两层数据表结构，第一层存放用户基信息，第二层存放用户行为信息。这个根据团队内部的数据接入规范进行调整，只要是统一的结构，对于数据分析师的分析都是有利的。

（6）明确数据优先级：根据埋点需求的紧急程度，给每一个买埋点任务标上优先级。

根据上面的六个步骤，将每一个步骤需要记录的字段按照标准格式汇总到文档，即可完成初步的埋点设计。当然完成初版埋点设计之后，还需要与产品、策划、程序一遍一遍过文档内容，不断修改完善，直至三方会谈达成统一意见。

7、埋点的事件分类

1. 页面事件：用户访问页面的信息，比如可以通过页面埋点统计页面浏览量（PV）；

2. 点击事件：用户在页面的点击行为，比如想要收集用户点击搜索按钮时，填入了哪些关键字，就可以在搜索按钮上埋一个点击事件，通过字段keywords上报的值实现分析关键字的目的；

3. 曝光事件：用户浏览页面的区域，比如统计某个区域是否被浏览过，需要进行曝光埋点；

4. 停留事件：用户访问页面的停留时长的信息，比如某APP定义用户在文章页面停留为一个埋点，获取除返回后台的停留时长，重新切入页面累计时长，用来分析喜好情况。

8、埋点事件的组成

1. 用户基本信息：描述用户的基本属性信息，包括用户ID，性别，运营商，设备类型等

2. 时间信息：事件发生的时间

3. 行为信息：用户做了哪些行为，比如点击行为，浏览行为等

4. 行为对象信息：用户的行为作用在哪些对象上，比如点击按钮A，浏览页面B，那么A，B就是用户行为作用对象

5. 另外，也可以从4w1h（who,when,where,what,how）五个维度来划分埋点属性

9、埋点技术的选择

我们已经知道了有埋点技术和无埋点技术的优缺点，那么如何选择埋点技术呢？接下来针对不同的场景，进行埋点技术的推荐。

• 公司刚启动，技术人员少，人员流动大，公司初步扩张中，尚未进入精细化运营阶段。只要符合其中一点，就可以选择无埋点技术。

• 项目在天使阶段之后的融资阶段，业务复杂度高，App应用的技术多样。符合这些点中的一点，就不要用无埋点技术了。当然，在融资阶段，使用私有化部署的无埋点技术也还是可以的。

• 公司流量巨大，业务复杂度高。当公司进入这个阶段的时候，就需要有埋点和无埋点技术联合使用。对无埋点技术也要进行一定的修改，上报阶段要通过后台配置项进行配置上报。这个阶段就需要建设自己的埋点管理平台了。

有埋点和无埋点技术都是为了数据采集而存在的，而且各有优劣，企业在不同阶段，产品在复杂度不同的情况下，根据自身的需要进行选择。效用最大化是组织的目的，所以不要在某一点上进行过度开发，避免产生不必要的浪费

10、埋点管理

2.1 新增埋点设计

2.1.1 埋点指标定义-事件表

2.1.2 埋点指标定义-用户表

2.1.3 埋点指标定义-默认属性

2.2 通用埋点设计

2.3 数据指标地图

2.4 版本迭代功能埋点管理

11、数据从 生产到应用的全流程

业务流程

确定场景或目标

确定一个场景，或者一个目标。比如，我们发现很多用户访问了注册页面，但是最终完成注册的很少。那么我们的目标就是提高注册转化率，了解为什么用户没有完成注册，是哪一个步骤挡住用户了。

数据采集规划

思考哪些数据我们需要了解，以帮助我们实现这个目标。比如对于之前的目标，我们需要拆解从进入注册页面到完成注册的每一个步骤的数据，每一次输入的数据，同时，还有完成或者未完成这些步骤的人的特征数据。

埋点采集数据

我们需要确定谁来负责收集数据，一般是工程师，有些企业有专门的数据工

程师，负责埋点采集数据。

数据评估和数据分析

给出优化方案

发现问题后，怎么给出解决方案。比如，是否需要在设计上改进，或者是否是工程上的 bug。

实施优化方案

谁负责实现解决方案，需要确定方案的实施责任人。

评估解决方案的效果

进行下一轮数据采集和分析，回到第一步继续迭代。

知易行难。这整个流程里，第 2 步到第 4 步是关键。目前传统的服务商

比如 Google Analytics、百度统计、友盟所采用的方式称作 Capture 模

式。通过在客户端埋下确定的点，采集相关数据到云端，最终在云端做呈

现。

开发流程

首先是基于一定的需求出发，然后产品/业务/分析师 对需求进行评审，主要就是需求同步，信息对齐，接下来就是埋点的开发与测试，埋点上线之后，数据同学开始进行数据需求开发在此过程中对埋点进行验收，最后对数据需求进行交付

这个过程，需要专门投入专人去做这个事情，企业需要定制顶层的业务规范，上面的流程中有一个环节是没有的，那就是埋点的下线。

数据产品和数据分析师不仅要考虑到业务需求和数据分析的工作，还要站在业务线数据体系和数据应用负责人的角度，对埋点实施、管理、迭代、文档、交付、支持进行掌控和维护

埋点管理系统设计

其实很多公司针对埋点会维护单独的一个系统，这个系统主要维护了公司的全部埋点，其实你可以将其理解为和jira 类似的一套系统。下面我们看系统的核心

埋点列表

埋点注册

埋点详情

主要提供关于埋点的基本信息和统计信息

属性管理

在埋点元数据中维护产品/业务层面的通用属性，由数据团队统一维护，所有可见的属性，都可以在注册/编辑埋点是添加属性时搜索到。自定义属性相对于通用属性，是某个事件下特有的属性，由业务方根据埋点方案维护

表设计/展示设计

主要的就是上面这些，我们需要做的就是将这些进行前端展示和前端录入。

数据解析在哪里做

首先我们还是先看一下一个架构图，从而理解一下数据流转，下面就是数据流转的一个大致方向

最后面的maxcompute 是我们的计算引擎，你可以将其当作是hive/spark ,具体是啥不重要，我们的数据通过前端(APP/web)前端上报，但是我们需要一个后端服务用来接收数据，然后后端获取到数据之后进入消息队列，最后我们再通过数据同步工具/数据消工具 把数据同步到大数据平台，从而开始数据计算和建模。

这里有一个问题就是我们上报上来的数据可能是加密的，或者是我们的消息队列是支持schema的(kafka 不支持)，这种情况下我们的数据要不要解析呢？直接说结论吧，最好不要解析，将解析的工作放在计算引擎中做，原因很多，下面陈述两点：

1. 后端服务在这里扮演的角色其实和消息队列差不多，如果这个过程有逻辑越多，耦合就越高，可扩展性就差，例如前端上报的数据格式变了，或者是有其他的一些升级，这个时候后端也要做对应的操作，然后重新发布。
2. 后端服务如果在这里有大量的逻辑的话，对性能也不好，因为埋点的数据量很大，如果这里出现瓶颈的话，就会出现服务不稳定，从而导致数据丢失

其实我看到有的人可能将IP 解析放在这里做，其实这也是不合理的，因为做IP 解析之前你需要先做数据解密、JSON 解析，然后数据推送到消息队列之前还要做数据加密，可以看出这里的加解密想当于白做了。

但是凡事也有例外，你也可以在后端这里做一些数据过滤，这样可以减少后面数据处理的压力，毕竟相比CPU ,网络才是最慢的。

数据丢失如何处理

这里我们主要关注前端—>后端—> 消息队列的这个环节的消息丢失，我们认为消息只要成功投递就不会发生消息丢失，关于这一点很多消息队列都可以保证，我们不做过多讨论，可以参考: https://blog.csdn.net/king14bhhb/article/details/114624437

所以我们的消息丢失主要在后端这一块，当然这里丢失的原因，我们可以分为两类

1. 后端服务不稳定，前端请求得不到影响，数据丢失，我们可以认为是前端数据丢失
2. 消息队列服务不稳定，后端消息不能成功投递，导致消息丢失，我们可以认为是后端数据丢失

可以看出来，这里后端是关键，所以我们采取的措施是日志补偿的方式，也就是对于投递失败的消息，我们可以将其追加到特定的日志文件，然后再将抽取到大数据计算平台，这里有一个问题就是最好监控，如果有大量的消息投递失败，我们一定要及时修复，防止日志文件过大。

对于后端服务的不稳定导致前端数据投递失败，我们需要做的就是做好监控和高可用，以及自动扩容，因为很多时候是因为流量急剧增加导致后端服务压力太大，从而导致不稳定。

12、总结

埋点业务流程图和埋点系统功能结构图：