面向“交管12123”App的客户端数据采集关键技术研究

文图｜胡杰 朱明 殷磊

“交管12123”App2016 年上线，截至2023 年6 月底，已累计注册个人用户5.1 亿个，提供各类服务达51.3 亿次，社会经济效益显著。在为广大用户提供稳定服务的同时，“交管12123”App 自身版本迭代、优化工作也一直在持续进行，且多为被动式的问题“上报－修改”、建议“反馈－优化”，缺乏主动、有效、准确地分析C 端用户的真实使用情况的能力，而且对C 端产品质量也缺乏量化的分析数据，为此12123 需要研究客户端数据采集技术。数据采集作为数字化运营中最重要的一环，通过采集、分析客户端数据，可以实时跟踪C 端产品质量，主动发现问题并预警，及时进行修复和优化，提高App 的稳定性和可靠性。本文就基于“交管12123”App 的客户端数据采集的总体思路、关键技术进行研究探讨，便于通过分析用户行为数据和反馈信息，增强对用户需求和行为的了解，从而更好地进行产品设计和优化，提高用户体验感和满意度。

一、总体思路

以App 前端视角观察整个系统，通过埋点方式搜集 App 用户终端的行为信息，通过海量数据的统计分析，及时发现问题及优化方向。一是在不影响现有业务逻辑的情况下，以旁路监控数据埋点的方式，采集客户端数据，数据采集尽量与业务逻辑解耦。二是由于终端使用场景复杂且不可控，所以需要使用多种策略尽量提高数据的准确性、完整性和及时性。三是采集的数据要尽可能有效、符合数据分析的需求，同时为了降低传输及存储的资源消耗，单条数据内容要尽可能精简。如图1 所示，由“交管12123”手机终端记录数据，然后通过访问部平台APM 服务提供的接口上传日志数据，最终部平台通过日志采集分析组件Flume 将采集的日志数据聚合、分析后存储至大数据平台HBase、MPPDB等数据库中。

图1 总体构架

二、关键技术

（一）数据埋点

现在业界主流的埋点方式包括代码埋点、全埋点、可视化埋点三种。三种埋点方式各有优缺点，本文采用的是混合方式，即全埋点为主、部分代码埋点为辅。针对“交管12123”App 框架层面的埋点，通常采用全埋点的方式，如网络层http 监控埋点。如图2 所示，针对http 网络层的数据采集，本文采用AOP（面向切面编程）的方式，通过记录http 请求各个阶段的切面时间，以此计算分析每个http 请求各阶段耗时情况、状态结果（该部分计算由手机终端完成，并不占用服务端资源），最终生成标准格式的数据，可用于后端直接分析处理。而针对上层的业务数据埋点需求，本文采用代码埋点的方式记录数据，这种方式工作量较大，但自定义程度高，可以更精准控制埋点的位置、更方便更灵活地自定义事件和属性，满足更精细化的业务分析需求。

图2 网络层http切面

（二）数据格式/事件模型

在数据分析中，一般都是采用“事件模型”来描述用户在产品上的各种行为。它通过who、when、where、how、what 记录了谁在某个时间点、某个地方、用某种方式、做了某一件事情（某个行为）。who、when、where、how、what 即是事件模型的五个要素。因此，本文数据格式的定义也是围绕这五个方面来展开，每一条数据都代表了一个事件，都需要包含这五个最基本的要素。其中，Who- 事件参与者（用户id，设备指纹）；When- 事件发生的时间（时间戳）；Where- 事件发生的地点（页面id，功能id）；How- 事件发生时的状态（用户使用的设备信息、应用程序版本号、操作系统版本号、渠道信息等）；What- 事件的具体内容（事件id，事件名称）。

如图3、图4 所示，本文记录的事件都包含info和data 两部分，其中，info 是数据的基础部分，里面包含事件模型的五个要素；data 是数据的内容部分，里面携带了具体事件的详细信息，根据不同的埋点数据类型，data 部分可以自定义实现。同时为了降低数据冗余提高传输效率，info 和data 是一对多关系，即多个data 可以共用一个info。

图3 info部分

图4 data部分

（三）数据同步

因为手机终端的使用场景比较复杂且不可控制，所以为了保证单个设备采集数据的准确性、完整性和及时性，需要针对不同的场景，使用多种数据上传同步策略。一是启动同步，分为冷启动、热启动两种情况。冷启动的情况下，先检查本地磁盘上是否有缓存未同步的数据，如果有就立即上传；热启动也是同样的同步策略，但是检查的是内存中未同步的数据。二是定时同步，即手机终端每隔一定的时间间隔同步一次（比如每隔30 秒）。三是定量同步，即客户端本地已缓存的数据超过一定条数时同步数据（比如100 条）。四是即时同步，适用于对数据及时性要求比较高的数据类型，也用于防止特殊场景造成的数据丢失等，比如应用程序进入后台时尝试同步本地已缓存的所有数据，最大限度地保证数据的完整性。除了以上四种策略外，还有其他保障机制保证数据的完整性，比如失败重传，即对于偶发单次同步上传的数据失败情况，需要增加重传机制，把数据重新加入到待传队列之中。同时，为了节约服务端资源，避免同步大量无效数据到服务端，每个终端默认不传数据，由服务端下发指令控制终端设备的数据采集是否开启，同时服务端也可以控制采集数据阈值，对于某些类型的数据，触发阈值才会被记录。

（四）时间修正

在事件模型里，时间的准确性尤为重要，因为后续的数据分析和问题回溯都依赖于时间的准确性。最简单的方案就是把用户手机设备的时间戳作为事件发生时间，但有些用户手机设备是不准确的，从而导致系统采集到的时间不准确。另一种方案是使用服务端的时间戳作为事件发生的时间，但这个方案也不准确，因为事件信息记录后，并不会立即同步给服务端（比如每隔30 秒定时同步），从而导致无法及时获取服务端的时间戳。经过一段时间的探索和测试，本文最终采用的是“时间修正”策略。如图5 所示，用户在手机时间戳T1时触发了一个事件，本地缓存记录该事件数据。在用户手机时间戳T2 时开始同步数据，然后服务端获取到数据时间戳T2。如果T2 与当前服务端的时间戳T3 的误差在一定的可接受范围之内（比如30 秒以内，http 网络请求也需要时间），就可以认为当前用户手机的时间戳是准确的，同时也认为事件发生的时间戳T1 也是准确的，服务端在接收到事件信息时直接记录事件时间为T1，无需额外处理。但如果T2 与T3相差比较大（比如图4 中的T2 为13:00:00，T3 为14:00:00），则认定当前用户手机的时间戳T2 是不准确的，即比服务端的时间戳晚了一个小时，从而就可以推断事件发生时的时间戳T1 也比服务端晚了一个小时，即12:00:00 变为13:00:00。因此，服务端在接收到事件信息时会将T1 修正为13:00:00，从而就达到了“时间修正”的效果。

图5 时间纠正示意

（五）设备指纹

针对事件分析来说，首先需要标识事件，即事件模型里的Who，选取合适的标识，对于提高数据分析的准确性有很大的影响，本文是使用设备指纹作为事件标识。设备指纹在事件模型中的作用是标识设备的唯一性，通过采集设备各项信息，如硬件、网络、系统等，并将这些信息组合起来，形成一个唯一的设备标识，并通过多种关联和相似查找算法来保障这个标识的稳定不变。

设备指纹的研究主要包括两个部分：设备指纹如何生成以及如何保持稳定。一是关于设备指纹的生成，受隐私政策法规的影响，目前业内没有一种完美的方案，所以只能在现有的条件和限制之下，寻找一种相对比较完美的方案。本文采用的是渐进式获取方式IDFA（广告标识符）→IDFV（应用开发商标识符）→UUID（通用唯一标识符），获取到系统提供的标识后，再附加额外的设备信息（网络、系统等），通过自研算法生成一个长度、格式固定的标识字符串，以此作为设备指纹。二是对于设备指纹如何保持稳定，不管是使用IDFA 还是IDFV，用户限制广告追踪或App 卸载重装，都有可能导致发生变化，为了保证用户卸载App 后设备指纹不变，本文采用的方式是将其保存在Keychain（系统密码管理系统）中，如果应用程序被卸载了，下次安装启动时优先会从Keychain 中寻找而不是重新生成，以此保证设备指纹的稳定性。

（六）崩溃信息

崩溃属于一种特殊的事件且数据的优先级比较高，所以数据的采集、存储、同步也比较特殊，目前比较成熟的做法是在崩溃发生时，将崩溃的错误栈信息保存到磁盘，下次启动时同步到服务端。用这种做法搜集到的崩溃信息，大部分可以顺利定位到问题代码并即时修复，但本文面对亿级体量的手机设备群体，线上的崩溃问题五花八门，始终有小比例的疑难崩溃无法解决。经过长期探索，本文目前采用了“现场恢复”的策略，在检测到崩溃发生的同时，记录崩溃发生前一段时间的事件信息，同步上传到服务端，服务端根据时间顺序还原用户崩溃前的操作情况，为分析具体崩溃原因提供了额外的数据支撑，目前这个策略效果显著。

三、结语

综上所述，本文以App 前端视角观察整个系统，通过埋点方式搜集前端数据，在手机终端使用场景复杂且不可控的情况下，尽可能提高数据的准确性、完整性和及时性，同时为了降低传输及存储的资源消耗，在不影响现有业务逻辑的情况下，以旁路监控方式采集数据，从而在更好地了解产品内在性能和用户使用情况同时，为整个系统优化提供了数据支撑，进一步提升了“交管12123”App 的用户体验，为提高12123 平台服务水平和服务质量创造有利条件。