1.1 数据采集

在移动App产品发布或版本升级上线之前，提前在工程中插入统计代码做关键页面或关键动作的采集，可以方便产品上线后进行数据分析和优化迭代。例如，对于视频产品，可能最值得关注的点是视频播放次数，更进一步会涉及流量、转化率、人均视频播放次数和留存率等核心数据指标，可以针对这些指标进行数据采集。

通常，随着App的扩张和功能升级，工程会越来越庞大和复杂，数据埋点的瓶颈很容易会因前期缺少规范而出现，比如，埋点出现偏差、数据采集不准确、需要对新老埋点做大量的兼容操作，以及埋点遗漏或文档不规范等。综上所述，在数据采集前期，进行定义设计时，制定数据采集规范至关重要，一套良好的数据采集系统可以给产品带来效率和规范化方面的提升。

1.1.1 数据格式

定义数据格式是数据采集的第一步，暂时没有统一的定义规范，但其实并不复杂，在实践中制定内部规范还是非常有必要的。往往越简单的事情，越能体现设计的意义和价值。目前，移动互联网比较通用的数据格式是流式格式。

以下是一个流式格式表达结构的例子。

流式格式表达结构如下：

version || client_ip || imei || imsi || brand || cpu || device_id || device_model || resolution || carrier ||access || access_subtype || channel || app_key || app_version || usernick || phone_number || language ||os || os_version || sdk_type || sdk_version ||reserve || local_time || server_time || page || eventid || arg1 ||arg2 || arg3 || args

具体字段及含义如下：

1. version：协议封装版本。

2. client_ip：采集的客户端IP地址。

3. imei：国际手机唯一标识。

4. imsi：国际移动用户唯一标识。

5. brand：手机品牌。

6. cpu：处理器。

7. device_id：设备ID。

8. device_model：设备型号。

9. resolution：分辨率（如800×480）。

10. carrier：运营商。

11. access：连接的网络，如2G、3G、Wi-Fi等。

12. access_subtype：网络子类型，如WCDMA、Unknown等。如果access不为Wi-Fi，那么需要在该字段中列出具体的类型，如该字段是WCDMA；如果access为Wi-Fi，那么该字段必须是Unknown。

13. channel：业务方自定义的渠道ID。

14. app_key:App标识。

15. app_version:App版本。

16. usernick：用户昵称。

17. phone_number：电话号码。

18. language：语言。

19. os：操作系统。

20. os_version：操作系统版本。

21. sdk_type :SDK类型。

22. sdk_version:SDK版本。

23. reserve：预留字段。

24. local_time：行为发生时的本地记录时间。

25. server_time：服务器的时间戳值。

26. page：页面。

27. eventid：行为ID。

28. arg1：行为的扩展参数1。

29. arg2：行为的扩展参数2。

30. arg3：行为的扩展参数3。

31. args：行为的扩展参数（其他）。

上述字段也可以结合具体业务自行定义。

1.1.2 多端协同技巧

对客户端而言，若使用本地原生技术开发的功能埋点存在问题，则需要等下一个版本发布时才能修复，并且还存在版本覆盖度的问题。修复埋点一般都会存在一个时间窗口，会对业务产品的快速迭代产生负面影响。其中良好的协同技巧往往可以显著地提升工程效率。一般的客户端埋点数据质量保证流程如图1-1所示，在质量保障过程中，产品经理、开发人员、测试人员及数据分析师都需要参与。

在如图1-1所示的流程中，沟通和协作会花费一些时间，下面将详细阐述在流程执行过程中如何沟通，以及如何提高效率。

1．如何沟通

有几个工作需要提前确定：产品的埋点需求文档、各时间节点（数据开始进入埋点设计的时间节点、收集产品需求的起止时间、与产品经理核对埋点需求的时间节点、与开发人员核对埋点需求的时间节点、与测试人员核对质量验收的时间节点）。

（1）与产品经理核对埋点需求

一般每个版本在交互稿完成后，数据分析师就需要开始了解交互情况并设计埋点文档，之后会与产品经理就产品设计和埋点需求进行确认，整理埋点需求列表和文档，并与产品经理进行最终确认，在进入开发前停止收集埋点需求。

（2）与开发人员核对埋点需求

数据分析师需要联合产品经理，与真正实现功能落地的开发人员一起进行埋点需求的再次确认。

（3）与测试人员核对质量验收

数据分析师需要联合产品经理，与最后进行质量验收的测试人员一起确认相关标准及交付时间。

2．如何提高效率

（1）优化流程

埋点时间主要花在沟通上，主要的原因在于埋点需求文档写得不清楚，需要与产品经理多次进行沟通、确认。基于这个原因，建议产品经理在写埋点需求时，清楚地写明需要哪个页面、哪个控件的何种事件并附上维度，最好标明需要的数据格式与报表形式，以避免遗漏需求；在埋点时尽量设计简单的规则，以便于理解，减少出错；如果有可能，在与开发人员核对需求时也可以让数据分析师、测试人员参与，以降低沟通成本。

（2）建立常用埋点模板

可以根据事件类型和功能属性，提前制作一些埋点模板，在设计具体埋点需求时根据事件复制相应的模板填到埋点文档中。

1.1.3 数据分级方案

根据常规的业务需求，一般可以将数据进行分级：基础常规事件、业务核心事件和特殊自定义事件。

1．基础常规事件

下面将从页面访问事件、控件点击事件和控件曝光事件来介绍基础、常规的通用事件。

（1）页面访问事件

下面是页面访问事件的常用数据采集参数定义说明。

● 事件ID：如2001表示此页面访问事件的信息标识。

● 页面：当前页面的名称。

● 参数1：当前页面的上一个页面的名称。

● 参数（其他）：扩展参数，如可以是页面访问次数。

● 其他统计点：如统计页面的独立访客数和停留时长等。

说明：

上报时机为页面离开（离开的定义是物理消失）时，包括正常页面跳转、前台切换到后台等。

（2）控件点击事件

下面是控件点击事件的常用数据采集参数定义说明。

● 事件ID：如2101表示此控件点击事件的信息标识。

● 参数1：控件名称，在控件名称前自动拼接当前页面名称。

● 参数（其他）：扩展参数。

● 其他统计点：如统计页面上具体控件和功能的使用次数等。

说明：

控件点击事件的埋点依赖于页面访问事件，必须先埋好页面访问事件再埋控件点击事件。

（3）控件曝光事件

下面是控件曝光事件的常用数据采集参数定义说明。

● 事件ID：如2201表示此控件曝光事件的信息标识。

● 参数1：控件名称。

● 参数（其他）：扩展参数。

● 其他统计点：如统计页面上具体控件曝光的次数。

说明：

当指定的页面元素曝光时长超过一定的时长（如500ms），并且页面元素曝光面积占总面积的百分比大于一定的值（如50%）时，认为此指定的页面元素曝光。

2．业务核心事件

不同类型的产品有各自关注的核心业务，比如，作为一个应用下载平台，业务的核心事件就是下载事件，具体包括下载开始事件和下载完成事件，下面就以下载事件为例来做介绍。

（1）下载开始事件

下面是下载开始事件的常用数据采集参数定义说明。

● 事件ID。

● 页面：当前下载的页面名称。

● 参数1：下载应用ID。

● 参数（其他）：扩展参数，包括下载链接等。

● 其他统计点：如统计应用的下载触发量。

（2）下载完成事件

下面是下载完成事件的常用数据采集参数定义说明。

● 事件ID。

● 页面：当前下载的页面名称。

● 参数1：下载应用ID。

● 参数（其他）：扩展参数，包括下载链接等。

● 其他统计点：如统计应用的下载时长、下载完成度。

上面是两种核心下载事件的数据采集参数介绍，接下来阐述下载事件日志上报的两套逻辑。

（1）下载器通用上报日志

● 优点：减轻前端工作量，开发人员只需要嵌入下载器SDK（Software Development Kit，软件开发工具包），相关日志采集工作会自动完成。

● 缺点：下载上报的只是通用参数，不会采集与页面强相关的业务参数，只能通过业务开发传参给下载器再上报。链路长，若出现问题，修改会滞后。

（2）业务端上报日志

● 优点：参数上传由业务端开发控制，方便根据业务及时进行调整、修改。

● 缺点：新增下载业务需要开发人员手动增加、上报，有一定的工作量。

3．特殊自定义事件

特殊自定义事件主要指除基础常规事件和业务核心事件外的所有自定义事件。

下面是自定义事件的常用数据采集参数定义说明。

● 事件ID。

● 页面：当前页面名称。

● 参数1：事件类型标识。

● 参数（其他）：扩展参数，根据具体事件类型设置。

某些功能或某块业务有一定的重要性，但又不是全局核心事件，不需要单独申请事件ID，可以全都放在某一自定义事件下，用“参数1”进行区分，如登录事件和分享事件等。

1.1.4 多进程解决方案

在多进程解决方案中，数据采集需要获得数据的读/写性能，以及数据的同步和数据的准确性等基本特性，下面会从数据采集SDK独立子进程和SDK多进程实例化来进行分析。

1．数据采集SDK独立子进程

在子进程中只存在事件采集和事件处理两个模块，为了保证事件的连续性，数据的存储和上报统一放到独立子进程中处理，这样避免了数据读/写的同步问题，保证了数据的准确，同时还提升了系统的性能。

因为事件采集是触发式的，所以在进程间通信上可以选用跨进程通信方案，比较推荐的是使用广播和接口定义语言机制，由统一的进程专门处理数据采集的存储和上报，这样更有利于同步管理。

2.SDK多进程实例化

数据采集SDK支持多个进程间实例化（进程间实例化是为各个进程对象分配内存空间的过程），为了更方便业务方接入，SDK内部将不同进程的采集数据进行了隔离，为每个进程分配不同的内存和存储实例。保证数据操作读/写分离的优点是，通过消耗一定的内存降低接入的成本，同时保证了数据埋点的高效性和准确性。

综上所述，数据采集SDK在设计原则上需要在内部同时支持上述两点，以更好地将数据埋点能力输出给业务方。