整体设计：
日志采集的过程基本是：用户输入网址请求，浏览器返回已经处理好埋点的html页面，用户浏览产生响应，将数据上报到日志采集服务器。
前端日志采集的方式
本质来说，前端日志采集就是执行一段能和日志系统交互的js脚本，通过传递不同的参数，传递不同的用户行为信息。至于如何执行和载入此脚本，大致分为两种形式：
1.提供api，由开发者手动植入到具体的页面加载或者响应事件生命周期中。这些代码在前端编译时就已经生成，存放在后端服务器中，包含在具体的每个Html页面中。
2.在前端获取对应相关页面时，后端服务器响应时自动植入到对应的Html具体位置中。当然，由于每个页面内容的千差万别，想要自动植入其实并不容易，这需要一套完整的植入体系和管理，达到定点关联。
假设存在一个管理端，能够让开发者（业务方）定制化的为每个页面中的各个元素指定对应的采集响应事件，如通过id分配具体某个元素，然后为此id绑上相应的采集事件，如按钮点击，鼠标轨迹跟踪，或者区域位置停留时长。然后在浏览器请求此页面时，后端服务会根据预先配置好的具体元信息，为此页面定制生成对应的采集脚本。
埋点分类
1.页面级浏览数据，这个级别的数据，相对而言，简单很多，因为每个页面都有相应的create和destory生命周期，具备一致性，在这两个生命周期中，很容易就能埋点得到相应的pv，uv数据，做相应的页面流量分析。
2.控件级别跟踪数据，这是较页面而言，精细化的数据分析，比如一个用户在此页面中的具体的某个区域位置停留多久，以及在此页面上，鼠标轨迹是由哪个区域转向哪个区域。这些信息的采集能够有效的分析出一些用户特征，比如用户关注点，以及内容关联性等等。
3.页面与页面轨迹数据，对于一个页面的来源和去向其实包含宝贵的用户特征信息和营销策略分析。毕竟在数据时代，一个用户的线上轨迹，其实已经是裸奔的状态了。如果能拿到对应的页面轨迹信息，比如一个用户从哪个页面进入，到哪个页面离开，其间浏览了哪个页面，我们就能对其做更多的关注点推荐，关联商品推荐等。
移动端日志采集方式
目前市面上的app基本上都保持着混合开发模式，如native+html，原生+html等。这种为内容扩展提供了很好的基础，能够很灵活的为每个模块，每个区域不同时间，不同阶段提供定制化内容。但是对于日志采集数据的统一和分析来说，具有一定的难度。如果单纯是给一个语言模式做链路分析，是简单的。但如果登录页是原生app页面，跳到主页后是原生框架，每个ViewPage又是一个个html页面，此时就会存在一些数据壁垒问题了。想要打通，就需要实现统一，如html页面native格式化，或者native页面html格式化。一般来说，前端和移动端数据对比，移动端需要采集的数据是包含前端的，两者都需要上述的埋点分类信息，以及一些基础设备信息，如ip，分辨率等，而移动端还需要更多的设备信息，比如移动端设备配置，定位信息等等，这些信息对于用户分析是至关重要的，并且移动端的数据上报较前端而言，更加灵活，可以选择不同的时机上传，这是由移动端天生需要考虑网络不加，甚至是网络异常的情况决定的，前端所有的请求一般来说是短连接，都是即时的，而移动端则可以先检查自身的网络环境，如果网络异常，则可以先做缓存，择机再传，保证了数据的完整和稳定。所以更加倾向选择前端页面数据native格式化。
