大数据相关技术架构理财&产品

日志埋点系统的架构与实现

2019-04-25  本文已影响24人  oneape15

1. 埋点的意义

1.1 什么是埋点?

所谓“埋点”,是数据采集领域(尤其是用户行为数据采集领域)的术语。指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。
埋点的技术实质,是先监听软件应用运行过程中的事件,当需要关注的事件发生时进行判断和捕获。

1.2 意义何在?

2. 埋点的技术难点

现在的业务技术架构都不仅仅是单独的一种技术方案能解决的。现在只要是做互联网的公司,其业务系统都会包含如下系统模块:

关于Hybrid 类型埋点

客户端内的 H5 生成埋点使用的是 JavaScript SDK,如果直接发送到日志收集服务,会丢失客户端的一些重要属性(用户设备信息、当前网络状态、所在地区等)。一般的处理方式为H5的日志通过JSBridge调用Native,由Native统一向后端发送日志信息。

Hybrid模式下日志收集

3. 埋点的方式

埋点方式多种多样,按照埋点位置不同,可以分为前端(客户端)埋点与后端(服务器端)埋点,其中前端埋点包括:代码埋点、全埋点、可视化埋点。
这些埋点方式的比较如下:

代码埋点 全埋点 可视化埋点 服务端埋点
采集说明 嵌入SDK,定义事件并添加好事件代码 嵌入SDK 嵌入SDK,可视化圈选定义事件 接口调用、数据结构化
场景 以业务价值为出发点的行为分析 无需采集事件,适用于活动页、着陆页、关键页;需设计体验衡量 用户在页面的行为与业务信息关联较少,页面量较多且页面元素较少对行为数据的应用较为浅 前后端数据整合,如订单数据
优势 按需采集;业务信息更完善;对数据的分析更聚焦 简单、快捷;与代码埋点相比开发人员工作量较少 与代码埋点相比、开发人员工作量较少 更灵活、更准确、无需要发版,数据上传更加及时
劣势 与后两种采集方式相比,开发人中工作量较多 数据准确性不高,上传数据多,消耗流量高数据维度单一(仅点击、加载、刷新) 业务人中工作量较大、改版后需要重新定义事件,缺乏基于业务的解读 仅服务端采集缺少前端的环境信息,前端交互数据缺失
典型案例 友盟、百度统计 google analytics Mixpanel神策数据

埋点准确性顺序
代码埋点 > 可视化埋点 > 全埋点

4. 最理想的埋点方式?

任何单一的埋点方式都存在优点与缺点,希望通过简单粗暴的几行代码、一次部署、甚至牺牲用户体验的埋点方式,都不是我们所期望的。

要满足精细化、精准化的数据分析需求,可根据实际需要的分析场景,选择一种或多种组合的采集方式,毕竟采集全量数据不是目的,实现有效的数据分析,从数据中找到关键决策信息实现增长才是重中之重。

因此,数据采集只是数据分析的第一步,数据分析的目的是洞察用户行为,挖掘用户价值,进而促进业务增长,故最理想的埋点方案是根据根据不同的业务和场景以及行业特性和自身实际需求,将埋点通过优劣互补方式进行组合,比如:

5. 日志采集规范

日志采集的规范越早统一,对于数据分析、利用越有帮助。这里借用大厂阿里的规范说一下。

5.1 SPM(Super Position Model)全称超级位置模型。

SPM是Web端Aplus日志体系和APP端UserTrack日志体系下,共同使用的的重要规范。

阿里的SPM位置编码由A.B.C.D四段构成, 各分段分别代表 A:站点/业务, B:页面, C:页面区块, D:区块内点位. 如下图所示:

5.2 SCM(Super Content Model)全称超级内容模型。

与业务内容一起下发的埋点数据,用来唯一标识一块内容。 客户端打点时,将 SCM 编码作为埋点的参数上传给 UT 服务器。

SCM编码也采用a.b.c.d的格式,其中,一般来说,

5.3 黄金令箭

用户在页面上某个行为触发一个异步请求,按照约定的格式向日志服务器发送请求,展现、点击、等待、报错等等都可以作为交互行为。

6. 系统架构设计

日志埋点系统整体框架图

具体日志发送流程如下图:


日志采集端发送日志流程图

7. 系统能力

  1. 系统能力支持动态横向扩容;
  2. 日志可以设置优先级、分业务处理(通过设置不同的topic);
  3. 为数据分析、挖掘提供可用性数据支持;

8. 指标收集概括

具体收集指标
上一篇下一篇

猜你喜欢

热点阅读