无线客户端的日志采集

0 概述

1. 无线客户端的数据采集，一是为了协助开发者分析各类设备信息，二是为了帮助各APP更好地了解用户在APP上的各类行为，从而优化APP；
2. 无线客户端的日志采集使用采集SDK来完成，在阿里，使用名为UserTrack（UT）的SDK来完成无线客户端的日志采集；
3. 日志采集根据不同的用户行为分成不同的事件，“事件”是无线客户端日志行为的最小单位；
4. 事件一般分为页面事件和控件点击事件等；

1 页面事件

1. 每条页面事件日志记录三类信息：（1）设备及用户的基本信息（2）被访问页面的信息（如商品详情页的商品ID、所属店铺等）（3）访问基本路径（如页面来源、来源的来源等），用于还原用户完整的访问行为；
2. UT提供了页面事件的无痕埋点，提供了三个接口：页面展现、页面退出及添加页面扩展信息的接口；
3. 以进入手机淘宝的某店铺详情页举例：（1）当进入店铺详情页时，调用页面展现接口，该接口记录页面进入时的一些状态信息，但此时不发送日志；（2）当从该店铺详情页离开时（点击某商品到了对应商品详情页/退出手机淘宝/点击返回），调用页面退出的接口，该接口会发送日志；（3）除此之外，UT还提供了添加页面扩展信息的接口，在页面离开前，使用该接口提供的方法给页面添加相关参数，如商铺ID，商铺类别（淘宝/天猫）等；
4. 为了平衡采集、计算和分析的成本，在部分场景下我们将选择采集更多的信息来减少计算及分析的成本，比如UT提供了透传参数功能；
5. 所谓透传参数，即把当前页面的某些信息，传递到下一个页面甚至下下一个页面的日志中；
6. 比如在手机淘宝首页搜索“连衣裙”，进入搜索list页面，然后点击A商品进入商品A详情页。如果需要分析“连衣裙”这个关键词或商品A的来源搜索词，就需要把”连衣裙“这个关键词带入到搜索list页面日志、商品A详情页日志中。这样以来，分析搜索词的效果就显而易见了；
7. 在阿里，使用SPM（super position model，超级位置模型）进行来源去向的追踪，在无线客户端使用SPM，SPM信息就可以通过透传机制带入到下一步甚至下下一步的浏览页面，这样整个用户行为路径还原就可以实现了；

2 控件点击及其他事件

1. 同浏览器的日志采集一样，无线客户端交互日志的采集也无法规定统一的采集内容，呈现出高度自定义的业务特征；在阿里，将无线客户端的交互日志采集从页面事件采集中剥离出来，即控件点击事件和其他事件；
2. 控件点击事件比页面事件简单得多：（1）记录基本的设备信息、用户信息（2）记录空间所在的页面名称、控件名称、控件的业务参数等；
3. 其他事件的采集，即用户根据业务场景需求，使用自定义事件来采集相关信息；UT提供了一个自定义埋点类，包括事件名称、事件时长、事件携带的属性、事件对应的页面等；具体实现什么功能，需要采集哪些内容，各个采集SDK可以自行决定；

3 特殊场景

1. 为了降低流量消耗、减小采集服务器压力和网络传输压力等，采集SDK提供了聚合功能，对某些场景如曝光或一些性能技术类日志，提倡在客户端对这类日志进行适当聚合，以减少日志大小、减少对日志采集服务器端的请求；
2. 以曝光日志举例：若一个商品等一次曝光就对应一条日志，那么在搜索结果页的一次滚屏浏览过程中将产生几十甚至上百条日志，而从下游使用及分析的角度来说，其实只是想知道哪些内容被曝光。因此使用SDK提供的本地聚合功能，在客户端对这类日志进行聚合，并上传聚合后的日志到采集服务器；
3. 而对于一些只需计数，而不需要知道具体内容的场景，如需要分析某些接口的调用次数，聚合功能就更体现其价值了；
4. 不同于浏览器的页面访问，无线客户端用户的访问行为路径存在明显的回退行为（如点击回退按钮、滑屏等），在进行业务分析时，回退也要作为特殊场景对待；
5. 例如在“双11”主会场页——>女装分会场——>女装店铺A——>女装分会场——>女装店铺B，在这个访问路径中，如果按照普通路径处理，则会认为第二次浏览的女装分会场来源于店铺A，这必然干扰到分析；
6. 因此，针对回退的场景，SDK做了特殊的设计，利用页面的生命周期、识别页面的复用、配合栈的深度来识别是否有回退行为；

4 H5 & Native 日志统一

1. APP分两种：一种是纯Native APP；一种是既有Native，又有H5页面嵌入的APP，即Hybrid APP。一般都是Hybrid APP；
2. Native页面采用采集SDK进行日志采集，H5页面采用浏览器的页面日志采集方式进行采集；
3. 在当前实践中，由于采集方式不同，采集到的内容及采集服务器均分离开。如果要进行完整的数据分析，需要将两类日志在数据处理时进行关联。即使不考虑处理成本，在很多情况下，Native和H5互跳，即使关联也无法还原用户路径，数据丢失严重；
4. 因此考虑到后续日志数据处理的便捷性、计算成本、数据的合理性及准确性，有必要对Native和H5日志进行统一处理；
   
5. 要实现Native和H5日志的统一处理，需要对Hybrid日志有统一的方案，一个可行的思路是将两类日志进行归一；
6. 阿里选择将H5日志归到Native日志，即采用采集SDK进行日志采集；
7. 原因有二：（1）采集SDK可以采集到更多的设备相关数据；（2）采集SDK处理日志，会先在本地缓存，而后借机上传，在网络状况不佳时延迟上报，保证数据不丢失；
8. 具体流程如下：（1）对于H5页面，通过加载日志采集的JS脚本，采集当前页面信息；（2）在日志采集的JS脚本中实现将所采集的数据打包到一个对象中，调用WebView框架的JSBridge接口，调用移动客户端对应的接口方法，将埋点数据对象当作参数传入；（3）移动客户端日志采集SDK，封装提供接口，实现将传入的内容转换成移动客户端日志格式：采集SDK会根据日志类别来识别是页面浏览事件，还是控件点击事件，然后调用内部相应的接口进行处理，将埋点数据转换成移动客户端日志的统一格式；（4）而后同移动客户端的日志处理一样，先记录到本地日志缓存中，择机上传；

5 设备标识

1. 关于UV（Unique Visitors，访客数），可以使用用户ID来进行唯一标识，但很多日志行为并不要求用户登录，这就导致很多情况下采集上来的日志都没有用户ID；
2. PC端一般使用Cookie信息作为设备的唯一信息，对于APP来说，要想办法获取到能够唯一标识设备的信息；
3. 然而随着用户的自我保护意识加强以及各系统升级，很多基本的设备信息获取不再那么容易；
4. 阿里集团的无线设备唯一标识使用UTDID，每台设备一个ID作为唯一标识。就目前来说，UTDID还未完全实现其使命；

6 日志传输

1. 无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生日志后，先存储在客户端本地，然后再伺机上传；
2. 伺机上传需要有数据分析的支持，例如在启动后、使用过程中、切换到后台时这些场景下分别多久触发一次上传动作。而单纯地靠时间间隔来决定上传动作是不够的，还需要考虑日志的大小及合理性（如单条日志超大，很可能就是错误日志），考虑上传时网络的耗时，来决定是否要调整上传机制；
3. 客户端数据上传时是向服务器发送POST请求，服务器端处理上传请求，对请求进行相关校验，将数据追加到本地文件中进行存储；
4. 存储方式使用Nginx的access_log, access_log的切分维度为天，即当天接收的日志存储到当天的日志文件中；
5. 考虑到后续的数据处理，及特殊时期不同日志的保障级别，对日志进行了分流。例如阿里的Adash（无线日志服务器端处理程序），根据应用及事件类型对每日高达数千亿的日志进行了分流；
6. 分流的价值很明显，如在“双11”时，日常数千亿的日志可能冲高到万亿，此时服务器及后续的数据计算压力就非常大了，而对于重要的数据计算来说，很可能只需要页面事件及控件点击事件，此时就可以适当释放其他类型日志的资源来处理更重要的页面事件及控件点击事件；
7. 至于日志采集服务器的日志如何给到下游，阿里使用消息队列（TimeTunnel，TT）来实现日志采集服务器到数据计算的MaxCompute；
8. TT将消息收集功能部署到日志采集服务器上进行消息的收集，而后续的应用可以是实时的应用实时来订阅TT收集到的消息进行实时计算，也可以是离线的应用定时获取消息进行离线的计算；