移动端数据统计和分析最佳实践

前言

随着移动互联网市场快速发展，以往“跑马圈地”式的粗犷运营时代已成为过去时。大环境的改变，也致使移动端的数据统计分析在产品的研发、决策、运营等方面起着愈来愈重要的做用，“精细化运营”一时间成为热点词——从大厂到创业团队，不管是自建数据统计系统仍是借助于第三方，市场对于简单易用、稳定可靠数据统计方案的需求从未衰减过。

 

挑战

产品运营人员目前迫切地须要更加详尽、多维的移动端数据，同时指望数据可以以直观清晰的方式展示。如果自建应用数据统计系统，则少不了多方的配合与协助：开发人员须要在数据获取方面下必定功夫，尤为是针对无埋点的统计需求；数据人员则须要承担海量数据分析的艰巨任务，部分小型团队缺少数据相关的岗位，只能将这项工做交给服务器端同窗来完成，但后者相对缺少大数据分析经验与能力，难以保证分析质量。

 

所以我的认为，当团队的资源有限时，能够考虑寻求专业的第三方解决方案，既可以让研发同窗没必要为了避免断变动的数据统计需求而绞尽脑汁，也可以让产品运营同事在更专业的数据结果中抽丝剥茧。

 

数据统计分析

从前，移动端的数据主要来自于两个主流系统的应用：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自动化地处理应用基础数据以及页面统计数据，而后根据项目的实际需求使用更加自主的自定义计时和计数事件埋点。在数据上报策略的选择上，主要根据具体的场景来断定，咱们建议采用默认的智能上报+周期上报的组合模式。