⽹站流量分析项⽬（三）--⽹页埋点
简介
很早之前，也就是当年的PC时代，由于受限于存储和计算能⼒， ⼤家⼀般很少⽤⽇志来分析业务。 ⽽是在业务逻辑⾥，将业务需要分析的数据事先写⼊到库⾥， 针对库的数据进⾏统计分析。 所以之前做OLAP， 需要很⾼级的硬件⽀持， ⼤家都去IOE等买昂贵的服务器来做数据仓库以及进⾏数据分析。 由于成本的问题， 我们拿到的数据是很少的， 所以进⾏统计分析和挖掘所得到的收益微乎其微。
随着Hadoop的兴起， 分布式⽂件系统和分布式计算⼤⼤降低了存储成本和计算成本， 使得我们现在⽤⽇志分析业务成为了可能。
2数据
对于移动端的App来说， 分析的数据⼤致上都可以分为俩种， ⼀种是在线数据，⼀种是离线数据。 在线数据， 即App后端服务所产⽣的⽇志数据，例如服务接⼝的性能数据， 服务接⼝的调⽤及其参数等， 通过服务端的⽇志数据， 我们不但可以统计服务接⼝的性能指标，还可以针对具体的业务逻辑，做相关的分析，⼀些常见的App分析指标如新增，活跃，累计，留存等，也都可以通过服务⽇志来统计出来。
对应的离线数据即是App客户端本⾝产⽣的数据， 这种情况⼀般是发⽣在客户端不调⽤底层服务的情况
下，需要了解⽤户在客户端的⾏为，就需要⽤到离线数据。 离线⽇志⼀般记录⽤户在客户端的具体⾏为，如⽤户在客户端的拖动，上下滚动，翻页等不涉及到后端服务的操作，以及App本⾝的崩溃⾏为产⽣的数据， 都可以被记录， ⼀般的，记录的内容包括事件类型，控件编号，控件属性及相关参数，事件时间等。
3在线⽇志
在线⽇志，⼀般来讲，有两种：
web服务器的配置化log(如Nginx, apache等web服务器的access.log)
这⼀类⽇志不需要⽤户⾃⼰做实现， 只需要开启web服务器的相关⽇志功能，即可完成⽇志记录。
应⽤服务器的log
⼀般包括应⽤服务器的配置化log 以及 ⽤户⾃定义的log。 ⽤户⾃定义log包括⽤户通过相关⽇志组件⾃⼰的debug, waring ,error, info等级别的⽇志。 这⼀类⽇志没有固定的格式，完全有⽤户⾃⾏控制。
在线⽇志⼀般会伴随业务直接产⽣在相关的业务服务器上(web服务器⽇志产⽣在web服务器上)，但是有的时候，为了将相关服务的监控⽇志与业务分析⽇志分离，会将业务⽇志直接记录在⼀台独⽴的⽇志服务器上。
4离线⽇志
离线⽇志，⼀般也有两种：
客户端的⾏为⽇志：⽤户在操作App的时候，产⽣的⾏为，都可以记录下来。 ⾏为⽇志⼀般是⽤来研究⽤户使⽤习惯， 分析应⽤的使⽤热度的。 同时可以结合客户端异常⽇志来分析异常原因。
客户端的异常⽇志：⽤来监控客户端异常原因， 帮助解决相关问题。
5埋点及上传
不管是在线⽇志，还是离线⽇志，我们⾸先都要确认在什么地⽅记录⽇志， 于是我们就引⼊了埋点的概念。 通俗的讲，在正常业务代码逻辑上， 添加记录⽇志的代码， 都叫做埋点。 但是⼀般的，埋点只⽤来描述客户端⽇志记录。
网站流量统计分析工具由于在线⽇志是直接产⽣在服务器端， ⽇志采集⼯具可以直接从含有⽇志的服务器上采集⽇志数据到
相应的⽂件系统， 所以不存在⽇志上传的问题。但是对于离线⽇志来说， 数据是产⽣在客户端的， 所以上传机制必须考虑。
6离线⽇志上传机制
业界采⽤的离线⽇志上传机制如下:
1. 服务端提供⽇志记录接⼝，当客户端有事件时，直接调⽤⽇志记录接⼝将⽇志记录在服务器端。
2. 服务端提供⽇志上传接⼝， 客户端先将⽇志暂存客户端本地，当达到⼀定的⼤⼩，⽹络环境允许的情况下， 通过上传接⼝，将⽇志⽂
件打包压缩后上传。
第⼀种上传⽅式，时效性⽅⾯有⼀定的保障， 在⽹络环境允许的情况下，能及时的将信息记录到服务器，但是当埋点较多时，记录⽇志产⽣的流量会很⼤，占据很⼤的带宽，给⽤户带来损失。 同时， 前端的某些⾏为，如在某个activity停留时间等也⽆法通过这种在线的⽅式捕获。 还有⼀个重要的问题是， 由于客户端数据没有暂存机制， 当⽹络暂时⽆法使⽤时， ⽇志记录接⼝⽆法正常调⽤， 所有的⽇志也就随之丢失。 第⼆种⽅式，在时效性上较差，因为它需要等待数据累计到⼀定程度，或者⽹络允许的情况下，如在wifi情况下，才发送，但是占⽤的带宽相对较⼩， 对客户端动作的捕获较为灵活。
7埋点的三种⽅案
1、传统埋点：开发者直接在客户端埋点。
优点： 开发者可以随意的在任何地⽅添加埋点。
缺点： 成本⾼，每次埋点的增删改都需要发版，很难控制。启明星现在采⽤的就是传统的埋点⽅式，
由于之前没有统⼀的规划， 相关页⾯的同⼀个按钮，不同的版本功能不同， 但却埋了同⼀个点， 造成统计⽐较混乱。之后我们引⼊了埋点下发平台，虽然⼀定程度上缓解了这种问题，但是由于其灵活性以及主观性， 问题依然⽆法避免。
2、可视化埋点：由于传统埋点的⼀系列问题， ⾃然⽽然的就产⽣了可视化埋点的⽅案， ⽤可视化交互的⼿段来代替写代码，将核⼼代码和配置，资源分开， 在App启动是通过⽹络更新配置和资源来实现埋点功能。
可视化埋点的⼤体流程如下：
⾸先埋点服务平台与埋点客户机做关联， 包括客户机包含的埋点模块扫描当前整个客户端页⾯的控件，形成控件树，并将当前页⾯截图，发送给埋点服务端平台；
埋点服务端平台接收到截图和控件树数据后，在服务端重新绘制App界⾯，通过可视化交互的⽅式，给当前页⾯需要埋点的控件上添加事件，添加完毕后，形成配置⽂件， 并发布上线；
装有埋点模块的所有客户端，接收到配置⽂件并解析， 根据配置为页⾯中相关的控件添加监听事件， 当这些控件出发事件时记录⽇志。
其中有很多细节的地⽅需要注意：
可视化埋点也需要考虑不同版本之间埋点的差异；
可视化埋点在分发埋点配置⽂件的时候，会有延迟或者丢失的情况， 有的客户端有可能收不到或者很久才能收到配置⽂件，这样埋点的时效性会⼤打折扣。
3、⽆埋点：所谓的⽆埋点，其实也就是全埋点， 它和可视化埋点很像， 可视化埋点是根据埋点配置来收集数据，⽽⽆埋点⽅案则是尽可能的收集所有控件的操作数据。 实现原理也很简单， 客户端添加扫描代码， 为每个扫描到的控件添加监听事件。 当事件被触发后，记录⽇志。
其实我想，⼤家对此也不陌⽣，⽐如很早之前，对PC站点的统计， 各⼤分析平台，都需要在⽹页
之间添加⼀段js代码。 其实那段js代码， 就是我们现在提到的⽆埋点的扫描代码。
这⾥强调⼀下， 由于可视化埋点是在需要的时候才埋点， 所以它并不能回溯事件，也就是说，我们只能统计需求提出后，埋点开始的所有的数据，埋点之前的数据我们是拿不到的。 ⽽⽆埋点⽅案， 在开始埋点的时候，所有的数据已经都被记录了， 所以它可以查看之前的数据(这⾥的之前也是相对与提统计需求的时间，⽽不是相对于埋点的时间)， 也就是说它可以做回溯。 ⽽这种回溯是建⽴在⼤量存储要求的基础上的。
8总结
不管是哪种解决⽅案，我们的⽬的只有⼀条，就是尽可能多的收集需要的数据， 所以在实际操作过程中， 我们可以根据具体情况，多种⽅案相结合使⽤。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。