日志埋点系统的架构与实现
1. 埋点的意义
1.1 什么是埋点?
所谓“埋点”,是数据采集领域(尤其是用户行为数据采集领域)的术语。指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。
埋点的技术实质,是先监听软件应用运行过程中的事件,当需要关注的事件发生时进行判断和捕获。
1.2 意义何在?
- 流量监测(在线情况分析、按时段分析、按来源分析);
- 构建行为路径, 通过对处理后的信息进行关联,获取用户的整条行为链路;
- 通过对埋点数据的处理、分析、建模,可以挖掘用户的喜好、需求,判断产品的效果和未来走向;
- 监控应用运行状态,提供问题跟踪定位的数据支持;
- 为营销策略提供数据支持;
- 实施 AB Testing;
- 作为数据平台中,数据采集的一个不可缺少的环节;
2. 埋点的技术难点
现在的业务技术架构都不仅仅是单独的一种技术方案能解决的。现在只要是做互联网的公司,其业务系统都会包含如下系统模块:
- 大前端。这里包含 WEB、HTML5, App(IOS、Android、Hybrid形式)
- 后端应用系统
- 服务器系统
关于Hybrid 类型埋点
客户端内的 H5 生成埋点使用的是 JavaScript SDK,如果直接发送到日志收集服务,会丢失客户端的一些重要属性(用户设备信息、当前网络状态、所在地区等)。一般的处理方式为H5的日志通过JSBridge
调用Native,由Native统一向后端发送日志信息。
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的格式,其中,一般来说,
- a标识投放系统ID,用来标识不同的内容投放方,比如商城的阿拉丁系统,对应的投放系统ID为1003。
- b标识投放算法ID,用来标识投放系统产生不同内容的投放算法。
- c标识投放算法版本ID,用来标识投放算法的不同版本。
- d标识投放人群ID,用来标识不同的投放人群,或者对接profile。
5.3 黄金令箭
用户在页面上某个行为触发一个异步请求,按照约定的格式向日志服务器发送请求,展现、点击、等待、报错等等都可以作为交互行为。
6. 系统架构设计
日志埋点系统整体框架图具体日志发送流程如下图:
日志采集端发送日志流程图
7. 系统能力
- 系统能力支持动态横向扩容;
- 日志可以设置优先级、分业务处理(通过设置不同的topic);
- 为数据分析、挖掘提供可用性数据支持;