无线端客户的日志采集
1. 页面事件
1）日志采集内容
2）日志采集时间
3）特别的，UT还有一个透传参数功能
UserTrack的透传参数功能允许将当前页面的某些信息传递到下一个或后续多个页面的日志记录中。例如，如果一个用户在电商网站上搜索了"连衣裙"，进入有很多商品的页面后，点击某个商品A进入商品详情页，那么这个搜索词’'连衣裙’的信息可以被透传至用户接下来访问的所有页面的日志中，包括商品A详情页，这样即使用户浏览多个页面，系统也能持续跟踪最初的搜索意图。
2. 控件点击及其他事件
- 控件点击事件的逻辑比较简单，就是操作页面上的某个控件，因此只需要把相关基础信息告诉采集SDK就可以了
- 其他事件：用户可以根据业务场景需求，自定义采集相关信息。UT提供了一个自定义埋点类，包含（1）事件名称（2）事件时长（3）事件所携带的属性（4）事件对应的页面
3. 特殊场景
一次浏览，一个点击就会产生一条日志，用来处理普通业务是足够的，但阿里业务体量巨大，为了平衡日志大小，减少流量消耗、采集服务器压力、网络传输压力等，采集SDK提供了聚合功能。
例如曝光日志。如果一个商品的一次曝光就对应一条日志的话，在搜索结果页的一次滚屏浏览过程中将产生几十条甚至上百条日志。从下游使用及分析的角度来说，其实只是想知道哪些内容被曝光。此时为了平衡业务需求及减少全链路资源消耗，采集SDK提供了本地聚合功能。在客户端端对这类日志进行聚合，上传聚合后的日志到采集服务器即可。同时对于一些只需要计数，而不需要知道具体内容的场景，如需要分析某些接口的调用次数，此功能就更加凸显出其作用了。
又例如，在无线客户端用户的访问行为路径存在明显的回退行为（如点击回退按钮、各种滑屏等）
“双11”主会场页>女装分会场>女装店铺A>回退到女装分会场>女装店铺B，在这个访问路径中，若只是按照普通的路径来处理，则认为第二次浏览的女装分会场来源为店铺A，就会把女装分会场的一次浏览效果记为女装店铺A带来的。倘若这样处理，就会发现类似的活动承接页其来源有一大部分均为各类详情页（店辅详情页/商品详情页），这必然干扰到分析。所以针对这种场景，阿里开发人员利用页面的生命周期，识别页面的复用，配合栈的深度来识别是否是回退行为。
上述举了两个特殊场景下日志采集的处理，实际生产中会面临更多具体问题，在这里不再赘述。
4. H5(HTML5)&Native 日志统一
是统一到native里还是h5里呢？
阿里选择统一到native当中，原因有二：
- 这样采集SDK可以采集到更多设备相关的数据，这在移动端的分析尤为重要
- 采集SDK处理日志，会先在本地缓存，然后借机上传，然后在网络状况不佳时延迟上报，保证数据不丢失
5. 设备标识
- 需要设备标识的原因：很多日志行为不要求登录，这就导致采集日志没有用户ID，PC端可以用cookie信息作为唯一标识，但是app我们就要另想办法。
- 单app公司对设备唯一标识的需求不那么紧迫
- 苹果之前使用UDID作为设备唯一识别，但现在因为涉及数据隐私等问题已被禁用，阿里用的是UTDID。
6. 日志传输
先储存在客户端本地，然后再伺机上传。考虑日志大小及合理性（如单条日志太大可能是错误日志），同时还要考虑上传时网络耗时。
