應用統(tǒng)計|移動端數(shù)據(jù)統(tǒng)計和分析最佳實踐

前言

隨著移動互聯(lián)網(wǎng)市場快速發(fā)展，以往“×××圈地”式的粗獷運營時代已成為過去時。大環(huán)境的改變，也導致移動端的數(shù)據(jù)統(tǒng)計分析在產(chǎn)品的研發(fā)、決策、運營等方面起著越來越重要的作用，“精細化運營”一時間成為熱點詞——從大廠到創(chuàng)業(yè)團隊，無論是自建數(shù)據(jù)統(tǒng)計系統(tǒng)還是借助于第三方，市場對于簡單易用、穩(wěn)定可靠數(shù)據(jù)統(tǒng)計方案的需求從未衰減過。

挑戰(zhàn)

產(chǎn)品運營人員目前迫切地需要更加詳盡、多維的移動端數(shù)據(jù)，同時期望數(shù)據(jù)能夠以直觀清晰的方式展現(xiàn)。若是自建應用數(shù)據(jù)統(tǒng)計系統(tǒng)，則少不了多方的配合與協(xié)助：開發(fā)人員需要在數(shù)據(jù)獲取方面下一定功夫，尤其是針對無埋點的統(tǒng)計需求；數(shù)據(jù)人員則需要承擔海量數(shù)據(jù)分析的艱巨任務，部分小型團隊缺乏數(shù)據(jù)相關的崗位，只能將這項工作交給服務器端同學來完成，但后者相對缺乏大數(shù)據(jù)分析經(jīng)驗與能力，難以保證分析質(zhì)量。

因此個人認為，當團隊的資源有限時，可以考慮尋求專業(yè)的第三方解決方案，既能夠讓研發(fā)同學不必為了不斷變更的數(shù)據(jù)統(tǒng)計需求而絞盡腦汁，也能夠讓產(chǎn)品運營同事在更專業(yè)的數(shù)據(jù)結(jié)果中抽絲剝繭。

數(shù)據(jù)統(tǒng)計分析

從前，移動端的數(shù)據(jù)主要來自于兩個主流系統(tǒng)的應用：iOS應用和Android應用；而最近，十大廠商在大力推廣基于Android平臺的快應用，快應用也在急速發(fā)展中，有望成為應用市場的第三極。因此，現(xiàn)階段的數(shù)據(jù)統(tǒng)計工作應涵蓋三種應用統(tǒng)計對象，即：iOS應用、Android應用和快應用。

目前市場上主流的移動端統(tǒng)計類SDK，只有個推出品的個數(shù)·應用統(tǒng)計支持這三種應用統(tǒng)計。雖然不同平臺接入個數(shù)SDK的方式也有所差異，但數(shù)據(jù)分析的對象是一致的，本文以個數(shù)iOS SDK的接入和使用為例，分享移動端數(shù)據(jù)統(tǒng)計分析的最佳實踐，以及自己的一些思考。

移動端的數(shù)據(jù)統(tǒng)計分析，主要分為兩部分，即數(shù)據(jù)歸納與可視化展示。

數(shù)據(jù)統(tǒng)計

個數(shù)iOS SDK的集成教程可以查看：iOS SDK集成文檔，本文不再贅述具體集成過程。

移動端的數(shù)據(jù)可以分為兩部分：

一部分是應用的基礎數(shù)據(jù)，如：應用的新增用戶、活躍用戶、啟動次數(shù)、活躍時長等。通常基礎數(shù)據(jù)也是一款應用整體活躍質(zhì)量最為直觀的表現(xiàn)，因而精準度至關重要。這部分數(shù)據(jù)可以在集成并啟動個數(shù)SDK后，由SDK自動化記錄和匯報。

#import 'GTCountSDK.h'
#define kGcAppId @"xxxxxxx"

@implementation AppDelegate

• (BOOL)application:(UIApplication )application didFinishLaunchingWithOptions:(NSDictionary )launchOptions {
  // 啟動個數(shù) SDK，即可自動采集應用基礎數(shù)據(jù)
  [GTCountSDK startSDKWithAppId:kGcAppId withChannelId:@"appstore"];
  return YES;
  }x

另一部分是精細化的頁面數(shù)據(jù)、事件數(shù)據(jù)和計數(shù)統(tǒng)計事件。

在個數(shù)SDK中，基于無埋點的方案可實現(xiàn)對頁面的精確統(tǒng)計。針對集成了個數(shù)SDK的應用，個數(shù)會統(tǒng)計相關頁面的啟動次數(shù)、活躍時長等，有效解決了傳統(tǒng)手動埋點的痛點，實現(xiàn)了流程的自動化。

而事件統(tǒng)計和計數(shù)統(tǒng)計可以計算某些用戶自定義埋點的發(fā)生時間以及次數(shù)，例如廣告點擊、短信數(shù)量等，具有很高的自主性：

（1）次數(shù)統(tǒng)計：統(tǒng)計指定行為被觸發(fā)的次數(shù)。

（2）時長統(tǒng)計：統(tǒng)計指定行為消耗的時間，單位為秒；需要eventBegin和eventEnd接口成對使用才可生效。

通過調(diào)用SDK的API接口，開發(fā)者可以方便地進行統(tǒng)計工作，如在某段ID為music001 的音樂播放開始和結(jié)束位置埋點：

-(void) musicStart{
// 為了正確統(tǒng)計，要確保開始和結(jié)束接口的參數(shù) self.eventProperty 內(nèi)存地址是一致的。
self.eventProperty = @{@"key":@"value1"};
[GTCountSDK trackCustomKeyValueEventBegin:@"music001" withArgs:self.eventProperty];
}

• (void) musicStop{
  [GTCountSDK trackCustomKeyValueEventEnd:@"music001" withArgs:self.eventProperty];
  }

或者統(tǒng)計某個ID為 goods001 商品的購買按鈕的點擊次數(shù)：

• (IBAction) buyButtonClick:(id)sender {
  [GTCountSDK trackCountEvent:@"goods001" withArgs:@{@"cKey1":@"cValue1"}];
  }

有了相應的數(shù)據(jù)以后，為了應對不同的網(wǎng)絡環(huán)境所產(chǎn)生的各類問題，完善的數(shù)據(jù)緩存和匯報機制也是非常重要的，因此我們需要設置一個符合當前網(wǎng)絡環(huán)境和最優(yōu)化用戶體驗的數(shù)據(jù)上報策略。個數(shù)SDK使用了豐富的上報策略，能夠適合各類網(wǎng)絡環(huán)境：

個數(shù)SDK的數(shù)據(jù)上報策略包括以下5種（默認為GESHU_STRATEGY_PERIOD，周期為60分鐘）：

考慮到WIFI網(wǎng)絡環(huán)境下上報數(shù)據(jù)的代價較小，因此默認在WIFI環(huán)境下，使用實時上報策略，即智能上報的模式；若要關閉該策略，可以調(diào)用以下接口關閉：

/
智能上報
開啟以后設備接入WIFI會實時上報
否則按照全局策略上報
默認打開
*/
@property (nonatomic, assign)BOOL smartReporting;
**

建議大家在使用過程中，使用默認的智能上報+周期上報的組合模式，即在WIFI環(huán)境下使用實時上報策略，在非WIFI環(huán)境下使用周期上報策略。這種組合模式可以在保證不消耗用戶流量的情況下，盡可能實時地匯報所歸整的數(shù)據(jù)，從而后臺可以在第一時間看到最新的分析結(jié)果。當然用戶可以根據(jù)自己產(chǎn)品的特性，有選擇性地優(yōu)化數(shù)據(jù)上報策略的組合，滿足實際的數(shù)據(jù)匯報需求。

數(shù)據(jù)分析展示

獲得數(shù)據(jù)后，接下來就是最頭疼的大數(shù)據(jù)分析部分了，但利用個數(shù)SDK及其背后積累的多年大數(shù)據(jù)研發(fā)經(jīng)驗，產(chǎn)品運營同學現(xiàn)在只需打開個數(shù)的后臺，就可以把應用的所有數(shù)據(jù)分析結(jié)果盡收眼底（想搶先體驗的同學可以登錄后臺查看演示 DEMO）：

其中個數(shù)統(tǒng)計部分包括活躍統(tǒng)計、成分統(tǒng)計、頁面統(tǒng)計、渠道統(tǒng)計、事件統(tǒng)計。如此多維度的精細化數(shù)據(jù)分析展示，有效幫助產(chǎn)品運營節(jié)省時間，全方位了解產(chǎn)品實際的運營情況。

總結(jié)

本文的移動端研發(fā)實踐部分，使用了iOS應用的數(shù)據(jù)分析來舉例說明，其他平臺也可以參考類比?？偟膩碚f，產(chǎn)品及運營可以使用個數(shù)SDK自動化地處理應用基礎數(shù)據(jù)以及頁面統(tǒng)計數(shù)據(jù)，然后根據(jù)項目的實際需求使用更加自主的自定義計時和計數(shù)事件埋點。在數(shù)據(jù)上報策略的選擇上，主要根據(jù)具體的場景來判定，我們建議采用默認的智能上報+周期上報的組合模式。