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