回顾：Day 2 总结了浏览器日志采集的过程 回看点击：大数据之路 读书笔记 Day 2
无线端客户的日志采集
无线端客户日志采集名为UserTrack （UT）的SDK来采集，UT将采集称为事件，常用的包括页面事件 （即页面浏览）、控件点击事件（即页面交互），下面会给大家讲到。
SDK、UK是什么？
- SDK 是 "Software Development Kit" 的缩写，中文意译为"软件开发工具包"。它是由软件、硬件、操作系统或编程语言的制造商提供的一套开发工具，旨在帮助软件开发者为特定的平台、系统或语言创建应用程序。
- 在阿里巴巴的大数据实践中，UT通常指的是UserTrack， UserTrack主要用于收集用户行为数据，包括页面浏览、页面交互、控件点击等事件，这些数据对于后续的数据分析、用户行为理解、产品优化和个性化推荐等都至关重要。UT就是阿里巴巴内部用于日志采集的一种软件开发工具包，也就是SDK。
1. 页面事件
1）日志采集内容
页面事件日志 1.设备及用户的基本信息 2.被访问页面的信息,如商品详情页的商品ID、所属店铺 3.访问基本路径，如页面来源、来源的来源
2）日志采集时间
接口方法调用 页面展现接口,记录进入页面时的状态,但不发送日志 页面退出接口,可以是退出淘宝,也可以是返回上一页,发送日志 添加页面扩展信息接口,离开前给页面添加相关参数,比如添加店铺ID,店铺类别等
思考：为什么要在调用退出接口时才发送日志？
- 确保日志完整性：在用户离开页面时发送日志，可以确保所有相关的用户行为和页面状态信息都被完整记录下来。如果在页面加载时立即发送日志，可能会遗漏后续发生的用户互动或其他重要事件。
- 减少无效或部分日志：如果在页面刚加载时就发送日志，可能会产生很多无效的日志条目，特别是对于那些用户快速浏览后离开的页面。在退出时发送日志可以避免这种情况，确保每条日志都代表了完整的用户会话。
- 方便分析师计算用户停留时间
- 处理异常和错误：在用户离开页面时发送日志，还可以捕捉到可能发生的异常或错误，这些信息对诊断问题和改进系统至关重要
3）特别的，UT还有一个透传参数功能
UserTrack的透传参数功能允许将当前页面的某些信息传递到下一个或后续多个页面的日志记录中。例如，如果一个用户在电商网站上搜索了"连衣裙"，进入有很多商品的页面后，点击某个商品A进入商品详情页，那么这个搜索词''连衣裙'的信息可以被透传至用户接下来访问的所有页面的日志中，包括商品A详情页，这样即使用户浏览多个页面，系统也能持续跟踪最初的搜索意图。
2. 控件点击及其他事件
- 控件点击事件的逻辑比较简单，就是操作页面上的某个控件，因此只需要把相关基础信息告诉采集SDK就可以了
- 其他事件：用户可以根据业务场景需求，自定义采集相关信息。UT提供了一个自定义埋点类，包含（1）事件名称（2）事件时长（3）事件所携带的属性（4）事件对应的页面
埋点是什么意思
"埋点"是指在应用程序或网站中设定的特定位置，用于收集用户行为或系统状态数据的技术。埋点可以捕捉用户的各种操作，如点击、滑动、购买等，以及页面加载、错误报告等事件。
自定义埋点是什么意思允许开发者根据自身需求定义新的事件或指标，比如特定的用户操作、业务流程中的特定步骤等。自定义埋点类就是指开发者自己定义的一系列数据采集点，用于收集特定业务场景下的数据。
自定义埋点类的使用，意味着开发者可以更灵活地监控和分析特定的业务逻辑或用户行为，而不仅仅是通用的预设事件。
3. 特殊场景
一次浏览，一个点击就会产生一条日志，用来处理普通业务是足够的，但阿里业务体量巨大，为了平衡日志大小，减少流量消耗、采集服务器压力、网络传输压力等，采集SDK提供了聚合功能。
例如曝光日志。如果一个商品的一次曝光就对应一条日志的话，在搜索结果页的一次滚屏浏览过程中将产生几十条甚至上百条日志。从下游使用及分析的角度来说，其实只是想知道哪些内容被曝光。此时为了平衡业务需求及减少全链路资源消耗，采集SDK提供了本地聚合功能。在客户端端对这类日志进行聚合，上传聚合后的日志到采集服务器即可。同时对于一些只需要计数，而不需要知道具体内容的场景，如需要分析某些接口的调用次数，此功能就更加凸显出其作用了。
又例如，在无线客户端用户的访问行为路径存在明显的回退行为（如点击回退按钮、各种滑屏等）
"双11"主会场页>女装分会场>女装店铺A>回退到女装分会场>女装店铺B，在这个访问路径中，若只是按照普通的路径来处理，则认为第二次浏览的女装分会场来源为店铺A，就会把女装分会场的一次浏览效果记为女装店铺A带来的。倘若这样处理，就会发现类似的活动承接页其来源有一大部分均为各类详情页（店辅详情页/商品详情页），这必然干扰到分析。所以针对这种场景，阿里开发人员利用页面的生命周期，识别页面的复用，配合栈的深度来识别是否是回退行为。
上述举了两个特殊场景下日志采集的处理，实际生产中会面临更多具体问题，在这里不再赘述。
4. H5(HTML5)&Native 日志统一
H5和Native的区别是什么？
Native应用和H5（Web应用）的主要区别在于它们的开发方式、运行环境和性能表现：
- 开发方式：
- Native：使用特定平台的编程语言和工具开发，如iOS上的Swift或Objective-C，Android上的Java或Kotlin。
- H5 (Web)：使用Web技术栈开发，主要包括HTML5、CSS和JavaScript。
- 运行环境：
- Native：直接运行在设备的操作系统上，充分利用硬件资源。
- H5 (Web)：运行在设备的浏览器内，依赖于浏览器引擎的渲染和执行能力。
- 性能：
- Native：通常提供更流畅的用户体验和更高的性能，因为它们可以直接访问设备的硬件和系统资源。
- H5 (Web)：性能可能略逊于Native应用，尤其是在复杂的交互和图形处理方面，但随着Web技术的发展，差距正在逐渐缩小。
- 跨平台性：
- Native：需要为每个平台单独开发和维护。
- H5 (Web)：可以一次开发，多平台部署，具有良好的跨平台特性。
- 功能访问：
- Native：可以访问设备的所有功能，如相机、GPS、文件系统等。
- H5 (Web)：受限于浏览器的安全策略，访问设备功能可能需要额外的权限或通过插件/桥接实现。
- 更新和分发：
- Native：需要通过应用商店审核，更新可能需要用户手动下载新版本。
- H5 (Web) ：可以即时更新，用户访问时自动获取最新版本，无需额外的安装步骤。
简而言之，Native应用更适合追求高性能和深度集成的场景，而H5应用则在跨平台和快速迭代方面更有优势。
是统一到native里还是h5里呢？
阿里选择统一到native当中，原因有二：
- 这样采集SDK可以采集到更多设备相关的数据，这在移动端的分析尤为重要
- 采集SDK处理日志，会先在本地缓存，然后借机上传，然后在网络状况不佳时延迟上报，保证数据不丢失
5. 设备标识
- 需要设备标识的原因：很多日志行为不要求登录，这就导致采集日志没有用户ID，PC端可以用cookie信息作为唯一标识，但是app我们就要另想办法。
- 单app公司对设备唯一标识的需求不那么紧迫
单APP公司较少考虑设备唯一标识，因为：
- 用户群体区分：
单一APP公司主要关注的是其APP的用户群，而不是跨多个APP的用户识别。设备唯一标识在单一APP环境下主要用于统计和分析目的，如用户活跃度、留存率、转化率等，而不涉及跨APP用户身份的统一识别。- 营销和广告定位：
多APP公司可能需要在不同APP间共享用户数据，以便进行更精准的营销和广告投放。单一APP公司则主要在其自身平台上进行这些活动，因此对跨平台用户标识的需求较低。- 数据孤岛：
对于单一APP公司，数据通常集中在单一的数据库或分析系统中，不需要特别处理跨平台数据融合的问题。这减少了数据管理的复杂性和成本。
- 苹果之前使用UDID作为设备唯一识别，但现在因为涉及数据隐私等问题已被禁用，阿里用的是UTDID。
UTDID 是一种用于移动设备的唯一标识符，它在阿里云的移动推送服务和其他场景中扮演着重要角色。UTDID 全称是 Unique Terminal Device IDentifier，它是一种软件级别的设备ID，由应用在首次调用时根据特定算法生成，并持久化存储在移动设备的存储组件中。这意味着每当同一应用再次使用 UTDID 时，它将从系统存储组件中获取先前生成的值，以保持标识符的唯一性和一致性。
UTDID 的主要用途包括：
- 推送消息识别：在推送通知服务中，UTDID 被用来区分不同的终端设备，确保消息能够准确地推送到指定的设备上。
- 数据统计与分析：UTDID 可用于收集和分析设备的使用情况，帮助开发者和运营者更好地理解用户行为。
- 个性化服务：通过 UTDID，服务提供商可以提供更加个性化的体验，比如推送定制化的内容或广告。
- 设备绑定与认证：在一些安全敏感的应用场景中，UTDID 可用于设备的绑定和认证过程。
6. 日志传输
先储存在客户端本地，然后再伺机上传。考虑日志大小及合理性（如单条日志太大可能是错误日志），同时还要考虑上传时网络耗时。