移動端數據統計和分析最佳實踐

前言

隨着移動互聯網市場快速發展，以往「跑馬圈地」式的粗獷運營時代已成爲過去時。大環境的改變，也致使移動端的數據統計分析在產品的研發、決策、運營等方面起着愈來愈重要的做用，「精細化運營」一時間成爲熱點詞——從大廠到創業團隊，不管是自建數據統計系統仍是藉助於第三方，市場對於簡單易用、穩定可靠數據統計方案的需求從未衰減過。

 

挑戰

產品運營人員目前迫切地須要更加詳盡、多維的移動端數據，同時指望數據可以以直觀清晰的方式展示。如果自建應用數據統計系統，則少不了多方的配合與協助：開發人員須要在數據獲取方面下必定功夫，尤爲是針對無埋點的統計需求；數據人員則須要承擔海量數據分析的艱鉅任務，部分小型團隊缺少數據相關的崗位，只能將這項工做交給服務器端同窗來完成，但後者相對缺少大數據分析經驗與能力，難以保證分析質量。

 

所以我的認爲，當團隊的資源有限時，能夠考慮尋求專業的第三方解決方案，既可以讓研發同窗沒必要爲了避免斷變動的數據統計需求而絞盡腦汁，也可以讓產品運營同事在更專業的數據結果中抽絲剝繭。

 

數據統計分析

從前，移動端的數據主要來自於兩個主流系統的應用：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自動化地處理應用基礎數據以及頁面統計數據，而後根據項目的實際需求使用更加自主的自定義計時和計數事件埋點。在數據上報策略的選擇上，主要根據具體的場景來斷定，咱們建議採用默認的智能上報+週期上報的組合模式。