2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

前言

隨著移動互聯(lián)網(wǎng)市場快速發(fā)展，以往“跑馬圈地”式的粗獷運營時代已成為過去時。大環(huán)境的改變，也導(dǎo)致移動端的數(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)。若是自建應(yīng)用數(shù)據(jù)統(tǒng)計系統(tǒng)，則少不了多方的配合與協(xié)助：開發(fā)人員需要在數(shù)據(jù)獲取方面下一定功夫，尤其是針對無埋點的統(tǒng)計需求；數(shù)據(jù)人員則需要承擔(dān)海量數(shù)據(jù)分析的艱巨任務(wù)，部分小型團隊缺乏數(shù)據(jù)相關(guān)的崗位，只能將這項工作交給服務(wù)器端同學(xué)來完成，但后者相對缺乏大數(shù)據(jù)分析經(jīng)驗與能力，難以保證分析質(zhì)量。

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

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

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

目前市場上主流的移動端統(tǒng)計類SDK，只有個推出品的[個數(shù)·應(yīng)用統(tǒng)計](http://docs.getui.com/geshu/start/ios/)支持這三種應(yī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集成文檔](http://docs.getui.com/geshu/start/ios/)，本文不再贅述具體集成過程。

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

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

?

#import 'GTCountSDK.h'

#define kGcAppId @"xxxxxxx"

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

????// 啟動個數(shù) SDK，即可自動采集應(yīng)用基礎(chǔ)數(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的應(yīng)用，個數(shù)會統(tǒng)計相關(guān)頁面的啟動次數(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"}];

}

?

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

?

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

?

|編號|策略名稱|策略說明|

|:------------- |:-------------|:-------------|

|1|`GESHU_STRATEGY_REAL_TIME`|實時發(fā)送，app 每產(chǎn)生一條消息都會發(fā)送到服務(wù)器。|

|2|`GESHU_STRATEGY_WIFI_ONLY`|只在 wifi 狀態(tài)下發(fā)送，非 wifi 情況緩存到本地。|

|3|`GESHU_STRATEGY_BATCH`|批量發(fā)送，默認當(dāng)消息數(shù)量達到 32 條時發(fā)送一次。|

|4|`GESHU_STRATEGY_LAUNCH_ONLY`|只在啟動時發(fā)送，本次產(chǎn)生的所有數(shù)據(jù)在下次啟動時發(fā)送。|

|5|`GESHU_STRATEGY_PERIOD`|間隔一段時間發(fā)送，每隔一段時間一次性發(fā)送到服務(wù)器。|

?

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

?

?

/**

?智能上報

?開啟以后設(shè)備接入WIFI會實時上報

?否則按照全局策略上報

?默認打開

?*/

@property (nonatomic, assign)BOOL smartReporting;

?

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

?

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

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


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

總結(jié)

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

轉(zhuǎn)載于:https://my.oschina.net/u/1782938/blog/1863327

總結(jié)

以上是生活随笔為你收集整理的移动端数据统计，精细化运营的永动机的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。