前言
随着移动互联网市场快速发展，以往“跑马圈地”式的粗犷运营时代已成为过去时。大环境的改变，也导致移动端的数据统计分析在产品的研发、决策、运营等方面起着越来越重要的作用，“精细化运营”一时间成为热点词——从大厂到创业团队，无论是自建数据统计系统还是借助于第三方，市场对于简单易用、稳定可靠数据统计方案的需求从未衰减过。
挑战
产品运营人员目前迫切地需要更加详尽、多维的移动端数据，同时期望数据能够以直观清晰的方式展现。若是自建应用数据统计系统，则少不了多方的配合与协助：开发人员需要在数据获取方面下一定功夫，尤其是针对无埋点的统计需求；数据人员则需要承担海量数据分析的艰巨任务，部分小型团队缺乏数据相关的岗位，只能将这项工作交给服务器端同学来完成，但后者相对缺乏大数据分析经验与能力，难以保证分析质量。
因此个人认为，当团队的资源有限时，可以考虑寻求专业的第三方解决方案，既能够让研发同学不必为了不断变更的数据统计需求而绞尽脑汁，也能够让产品运营同事在更专业的数据结果中抽丝剥茧。
数据统计分析
从前，移动端的数据主要来自于两个主流系统的应用：iOS应用和Android应用；而最近，十大厂商在大力推广基于Android平台的[快应用](https://www.quickapp.cn/)，快应用也在急速发展中，有望成为应用市场的第三极。因此，现阶段的数据统计工作应涵盖三种应用统计对象，即：iOS应用、Android应用和快应用。
目前市场上主流的移动端统计类SDK，只有个推出品的[个数·应用统计](http://docs.getui.com/geshu/start/ios/)支持这三种应用统计。虽然不同平台接入个数SDK的方式也有所差异，但数据分析的对象是一致的，本文以个数iOS SDK的接入和使用为例，分享移动端数据统计分析的最佳实践，以及自己的一些思考。
移动端的数据统计分析，主要分为两部分，即数据归纳与可视化展示。
数据统计
个数iOS SDK的集成教程可以查看：[iOS SDK集成文档](http://docs.getui.com/geshu/start/ios/)，本文不再赘述具体集成过程。
移动端的数据可以分为两部分：
一部分是应用的基础数据，如：应用的新增用户、活跃用户、启动次数、活跃时长等。通常基础数据也是一款应用整体活跃质量最为直观的表现，因而精准度至关重要。这部分数据可以在集成并启动个数SDK后，由SDK自动化记录和汇报。
#import 'GTCountSDK.h'
#define kGcAppId @"xxxxxxx"
@implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// 启动个数 SDK，即可自动采集应用基础数据
[GTCountSDK startSDKWithAppId:kGcAppId withChannelId:@"appstore"];
return YES;
}x
另一部分是精细化的页面数据、事件数据和计数统计事件。
在个数SDK中，基于无埋点的方案可实现对页面的精确统计。针对集成了个数SDK的应用，个数会统计相关页面的启动次数、活跃时长等，有效解决了传统手动埋点的痛点，实现了流程的自动化。
而事件统计和计数统计可以计算某些用户自定义埋点的发生时间以及次数，例如广告点击、短信数量等，具有很高的自主性：
（1）次数统计：统计指定行为被触发的次数。
（2）时长统计：统计指定行为消耗的时间，单位为秒；需要eventBegin和eventEnd接口成对使用才可生效。
通过调用SDK的API接口，开发者可以方便地进行统计工作，如在某段ID为`music001` 的音乐播放开始和结束位置埋点：
-(void) musicStart{
// 为了正确统计，要确保开始和结束接口的参数 self.eventProperty 内存地址是一致的。
self.eventProperty = @{@"key":@"value1"};
[GTCountSDK trackCustomKeyValueEventBegin:@"music001" withArgs:self.eventProperty];
}
- (void) musicStop{
[GTCountSDK trackCustomKeyValueEventEnd:@"music001" withArgs:self.eventProperty];
}
或者统计某个ID为 `goods001` 商品的购买按钮的点击次数：
- (IBAction) buyButtonClick:(id)sender {
[GTCountSDK trackCountEvent:@"goods001" withArgs:@{@"cKey1":@"cValue1"}];
}
有了相应的数据以后，为了应对不同的网络环境所产生的各类问题，完善的数据缓存和汇报机制也是非常重要的，因此我们需要设置一个符合当前网络环境和最优化用户体验的数据上报策略。个数SDK使用了丰富的上报策略，能够适合各类网络环境：
个数SDK的数据上报策略包括以下5种（默认为`GESHU_STRATEGY_PERIOD`，周期为60分钟）：
|编号|策略名称|策略说明|
|:------------- |:-------------|:-------------|
|1|`GESHU_STRATEGY_REAL_TIME`|实时发送，app 每产生一条消息都会发送到服务器。|
|2|`GESHU_STRATEGY_WIFI_ONLY`|只在 wifi 状态下发送，非 wifi 情况缓存到本地。|
|3|`GESHU_STRATEGY_BATCH`|批量发送，默认当消息数量达到 32 条时发送一次。|
|4|`GESHU_STRATEGY_LAUNCH_ONLY`|只在启动时发送，本次产生的所有数据在下次启动时发送。|
|5|`GESHU_STRATEGY_PERIOD`|间隔一段时间发送，每隔一段时间一次性发送到服务器。|
考虑到WIFI网络环境下上报数据的代价较小，因此默认在WIFI环境下，使用实时上报策略，即智能上报的模式；若要关闭该策略，可以调用以下接口关闭：
/**
智能上报
开启以后设备接入WIFI会实时上报
否则按照全局策略上报
默认打开
*/
@property (nonatomic, assign)BOOL smartReporting;
建议大家在使用过程中，使用默认的智能上报+周期上报的组合模式，即在WIFI环境下使用实时上报策略，在非WIFI环境下使用周期上报策略。这种组合模式可以在保证不消耗用户流量的情况下，尽可能实时地汇报所归整的数据，从而后台可以在第一时间看到最新的分析结果。当然用户可以根据自己产品的特性，有选择性地优化数据上报策略的组合，满足实际的数据汇报需求。
数据分析展示
获得数据后，接下来就是最头疼的大数据分析部分了，但利用个数SDK及其背后积累的多年大数据研发经验，产品运营同学现在只需打开个数的后台，就可以把应用的所有数据分析结果尽收眼底（想抢先体验的同学可以登录后台[查看演示 DEMO](https://dev.getui.com/geshu_n/#/vitalityStatistics/current)）：
其中个数统计部分包括活跃统计、成分统计、页面统计、渠道统计、事件统计。如此多维度的精细化数据分析展示，有效帮助产品运营节省时间，全方位了解产品实际的运营情况。
总结
本文的移动端研发实践部分，使用了iOS应用的数据分析来举例说明，其他平台也可以参考类比。总的来说，产品及运营可以使用个数SDK自动化地处理应用基础数据以及页面统计数据，然后根据项目的实际需求使用更加自主的自定义计时和计数事件埋点。在数据上报策略的选择上，主要根据具体的场景来判定，我们建议采用默认的智能上报+周期上报的组合模式。