数仓建模【埋点设计与管理】

埋点设计与管理

埋点的作用

1. 分析用户转化以及留存：
2. 分析用户偏好
3. 收集市场反馈
4. 保障用户数据安全
5. 定位异常
6. 其他作用

埋点数仓设计

 数据进入数仓之前我们就需要设计好数仓表，埋点表的数据有几个特点：

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

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

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

小程序端的埋点表

web端的埋点表

 

埋点的类型

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

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

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

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

1. 全埋点：全埋点的逻辑，实质数据采集sdk无区别的对待所有事件的，将所有事件（页面加载成功实践、控件的浏览和点击事件）全部获取后先存下来，到使用的时候，再根据具体的页面路径和控件名称，去捞取相应的数据。
   1. 优点：其优点和特点是功能上线时，不需要开发做额外的埋点定义工作，用的时候再根据需求去获取对应的数据，因此也叫无埋点。
   2. 缺点：耗费用户流量、占存储空间；一旦版本迭代，对页面的路径做了修改，或者空间位置、文案有修改，原来的圈选数据可能就会出错，需要重新圈选，之前利用圈选指标谁当的分析模型都要替换；圈选指标无法区分细部参数，比如：商品详情页，无法通过圈选数据来区分是哪一个商品或哪一个类目；对web的页面数据处理一直不好，尤其是设计到app的内嵌H5页时，非常痛苦。
   3. 因此，全埋点适用于业务多变、经常调整，且分析诉求比较轻量级的场景。对于通用的功能，形态相对比较固定，且对数据分析颗粒度、下钻深度、聚合程度要求较高，那就需要用到代码埋点。
2. 可视化埋点：基于此，可视化埋点是指在全埋点部署成功、已经可以获得全量数据的基础上，以可视化的方式，然后进行数据选择。这种方案的弊端之一是耗流量和存储空间，全埋点采集的数据一般会根据情况设定一个销毁时限，比如7天。即：全采集过来的数据，如果7天之内没有被使用，则会被销毁。而一旦对圈选数据做了圈选定义之后，则被定义的页面数据、控件数据，则会一直采集，且不会删除。
3. 代码埋点：代码埋点也叫自定义埋点 ，从字面上是针对想要的点位单独定义，并可以通过变量丰富埋点的信息，以支持上下游分析。代码埋点分为前端埋点和后端埋点：
   1. 前端埋点：包括但不限于APP客户端、H5、微信小程序、PC网页，是指对具体的功能场景（如加载成功、浏览、点击等）进行明确的定义，由前端触发，采集上来的数据相比于全埋点，更准确、稳定，且通过变量字段，能够实现更细粒度的数据拆分、聚合和下钻。
   2. 后端埋点：指触发了服务端接口调用（如：接口回调成功触发）的事件埋点，如最典型的注册成功事件、付款成功事件。后端埋点对数据的准确度要求更高，同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻。需要强调的是，后端事件一般采集的是一登陆状态下的用户行为，如果像使用后端事件作为流程分析的其中一环（如漏斗分析），则可能出现未登录的用户会漏掉的情况。

埋点上报方式

1. 图片请求 ：优势没有跨域问题；不会阻塞页面加载；在所有图片中，简单、安全；

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

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

埋点管理设计

整个埋点的事件我们可以使用4W1H进行表示

 

 下面是APP端的一个例子

事件模型

我们使用”事件模型（Event模型）“来面熟用户的各种行为，事件模型包括事件和用户两个核心实体。整个埋点的属性，我们可以分为两个大类，第一类是事件属性，第二类是用户属性。

为什么这两个实体结合在一起就可以清晰的描述清除用户行为？实际上，我们在描述用户行为时，往往只需要描述清除几个要点，即可将整个行为描述清除，要点包括：是谁、什么时间、什么地点、以什么方式、干了什么。而事件和用户这两个实体结合在一起就可以达到目的。下面介绍以下这两个实体。

 

 事件的设计

基本规范

 

预置属性

 

设计原则

整个埋点的设计我们应该遵循以下几个原则，从而可以更好的维护和管理整个埋点系统。

• 通用基础事件：埋点事件能通用则不单独埋点，不是说单独埋点越多越好，我们应该尽可能地从上层设计比较通用地事件，这样方便复用。
• 重要事件：重要事件要单独处理，统一上报，保证采集的可用性
• 业务主流程：对于主要的业务流程，我们可以设计独立的事件，从而方便更好的分析； 

数据从生产到应用的流程 

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

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

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

 

埋点系统的设计

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

埋点列表

 

埋点注册

 

埋点详情

 

属性管理

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

 

表设计

 

字段名称	备注
埋点ID	表的自增ID即可
埋点域	是APP埋点还是web埋点还是都是
埋点中文名称
埋点英文名称
埋点位置	这个位置我们要求使用图片进行展示+文字说明 这里的图片展示很重要，因为这样很形象
埋点开发负责人	谁负责开发，很多时候会涉及到APP和WEB同时开发
埋点业务负责人	谁提的需求
埋点数据负责人	谁负责该埋点对应数据需求的处理，完成最终的埋点的验收
埋点业务含义	为什么埋点，关于埋点的具体数据计算逻辑是什么
埋点所属事件	买单所属的事件，一般情况下我们都可以将一个买单归到我们已经定义的埋点事件中去，如果没有合适的埋点事件，需要先定义事件，再定义该埋点
埋点通用属性	一旦归类到某个埋点事件下面，我们要求上报该事件的全部属性
自定义属性	该埋点的自定义属性
埋点代码git的PR	是一个url。方便追踪埋点代码
埋点的jira	埋点需求的jira跟踪
埋点的状态	上线、测试、开发、下线、不可见等状态
埋点的创建时间
埋点的上线时间
埋点的更新时间

数据丢失如何处理

总结

1. 埋点是数据平台很重要的一部分，如果只有业务数据没有埋点数据，那么用户在我们平台上的一切行为对我们来说都是黑盒，所以我们想要做到精细化运维埋点是必须的；
2. 优于埋点的数据从产生使用链路很长，而且很复杂，这就需要我们做好设计和管理工作。