移動網際網路資料分析 移動客戶端流量統計 移動客戶端資料統計

原創文章,轉載請註明原地址

在這個公司兩年多了,期間做了移動客戶端資料分析,視訊播放器資料分析,短地址資料分析等資料分析方面的工作,

公司提供的平臺還算大,每日分析的資料好幾千萬,期間積累了一些經驗和教訓,和大家一起分享一下.

歡迎批評指正.

這裡主要講的是移動客戶端資料的分析

資料分析肯定要有一個數據產生的過程,然後才是資料收集與資料分析,將分為三段來講

一.資料的產生

傳統的web資料來源大概分為兩種,一種是瀏覽器訪問伺服器產生的日誌,一種是在web頁面上使用js獲取相應的資料,然後向伺服器傳送資料.

第一種方法,想獲取的資料和其它資料一起混雜在伺服器日誌中,不方便分析,而且瀏覽器訪問產生的資料有限,沒法做更多分析,一般是簡單統計的系統,採用這種方法.

第二種方法比較好一點,js能夠獲取的資料較多,較全面,統計資料和其它資料分開,能獲得比較"純"的資料

移動客戶端的資料分析大概也有這兩種方法,不過移動客戶端沒法執行js,一般是針對不同的平臺,寫不同的類庫,

這需要和客戶端開發人員進行合作,如android可以寫一個通用的jar包,ios可以一個通用的類庫,寫好後,就可以供相同平臺的移動應用程式進行呼叫.

值得說明的是,移動客戶端收集的資料有兩點需要注意:

一是可擴充套件性,客戶端可以獲得的資料很多,開始的時候,只獲取關心的資料,但是隨著時間的推移,可能需要獲取更多的資料,

這個時候就要保證客戶端收集資料的可擴充套件性,即能在舊的協議格式上隨意擴充套件,一般可以用json格式.

二是資料注意壓縮,因為我國移動資費還比較貴,1M流量大概一塊錢,如果不考慮這一點,像web一樣無限制地收集資料,併發送到伺服器,

手機流量將會非常大.資料壓縮有兩方面,一方面,如果使用json格式的話,key可以壓縮,比如"app_version":"1.0.1"代表應用版本號是1.0.1,

壓縮後可以這樣,"av":"1.0.1",儘量壓縮key,反正只要伺服器端知道key的含義就行.另一方面是指使用壓縮協議,比如可以將資料使用gzip壓縮,

這樣資料量會更小了.

三是要注意資料上傳的時機.由於移動裝置cpu,記憶體啥的都比較弱,如果頻繁地傳送資料,肯定會對應用的體驗產生影響,一般都是將資料積累一定的時間,

然後一次上傳,這樣能減輕對使用者的干擾,但是有些實時資料,還是需要實時上傳的,這個可以看情況而定.

原創文章,轉載請註明原地址