前言
隨着移動互聯網市場快速發展，以往“跑馬圈地”式的粗獷運營時代已成為過去時。大環境的改變，也導致移動端的數據統計分析在產品的研發、決策、運營等方面起着越來越重要的作用，“精細化運營”一時間成為熱點詞——從大廠到創業團隊，無論是自建數據統計系統還是借助於第三方，市場對於簡單易用、穩定可靠數據統計方案的需求從未衰減過。
挑戰
產品運營人員目前迫切地需要更加詳盡、多維的移動端數據，同時期望數據能夠以直觀清晰的方式展現。若是自建應用數據統計系統，則少不了多方的配合與協助：開發人員需要在數據獲取方面下一定功夫，尤其是針對無埋點的統計需求；數據人員則需要承擔海量數據分析的艱巨任務，部分小型團隊缺乏數據相關的崗位，只能將這項工作交給服務器端同學來完成，但后者相對缺乏大數據分析經驗與能力，難以保證分析質量。
因此個人認為，當團隊的資源有限時，可以考慮尋求專業的第三方解決方案，既能夠讓研發同學不必為了不斷變更的數據統計需求而絞盡腦汁，也能夠讓產品運營同事在更專業的數據結果中抽絲剝繭。
數據統計分析
從前，移動端的數據主要來自於兩個主流系統的應用：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自動化地處理應用基礎數據以及頁面統計數據，然后根據項目的實際需求使用更加自主的自定義計時和計數事件埋點。在數據上報策略的選擇上，主要根據具體的場景來判定，我們建議采用默認的智能上報+周期上報的組合模式。