移動端app自定義統(tǒng)計埋點新思路

最近剛剛做完手上產(chǎn)品的大改版甥捺,對新版本內(nèi)的統(tǒng)計埋點花了比較大的功夫邮绿,因此在這里記錄下來渠旁,也算是對自己最近一段時間的總結(jié)吧

常見的統(tǒng)計方法

移動端app在做統(tǒng)計時一般有以下兩種方式:

  1. 自建統(tǒng)計sdk,較為安全和靈活船逮,可以設(shè)計成自定義埋點統(tǒng)計或模型統(tǒng)計等
  2. 接入第三方統(tǒng)計sdk顾腊,常見端有友盟、GrowingIO等挖胃,但是自家等數(shù)據(jù)要傳給第三方服務(wù)商杂靶,而且會受到諸多限制(如友盟對數(shù)據(jù)量級就有限制,不允許單個點的量級過大酱鸭,或者統(tǒng)計點數(shù)量過多等等)

自定義統(tǒng)計

自定義統(tǒng)計時吗垮,往往是根據(jù)app內(nèi)的動作或者事件,在動作或事件發(fā)生時凹髓,上報一次數(shù)據(jù)烁登。也正是由于這種特性,自定義統(tǒng)計點最大的缺陷蔚舀,就是“不全面”饵沧。因為需要與動作或者事件做綁定,因此在埋點之前赌躺,就需要產(chǎn)品人員提前考慮到一個自定義點可能涉及到的所有的情況狼牺,并對這些情況提前做埋點,一旦某種情況沒有提前考慮到寿谴,就無法采集到數(shù)據(jù)锁右。

也正是因為這種缺陷,自定義的統(tǒng)計方式往往用于統(tǒng)計單個的孤立事件,或者是做臨時的統(tǒng)計咏瑟,大批量的操作行為統(tǒng)計一般還是采用模型統(tǒng)計的思路拂到,用以全面統(tǒng)計一次用戶行為中的所有事件。

模型統(tǒng)計

模型統(tǒng)計的基本思路是码泞,提前定義好如點擊兄旬、瀏覽等行為,以及需要統(tǒng)計的頁面內(nèi)容(如首頁余寥、banner领铐、內(nèi)容頁等等),將用戶的所有行為數(shù)據(jù)全部上報宋舷,后期產(chǎn)品人員查詢數(shù)據(jù)時绪撵,需要對數(shù)據(jù)做條件對篩選(如選擇“行為 = 瀏覽 & 頁面 = 首頁”),得到所需要對數(shù)據(jù)祝蝠。

我們公司采用的是自建統(tǒng)計sdk的方法音诈,自己進行數(shù)據(jù)的采集和清洗。不過因為種種歷史原因绎狭,我們自己的模型統(tǒng)計存在一定的問題细溅,因此一直以來我們在統(tǒng)計時,都采用埋自定義統(tǒng)計點的方案儡嘶。而這次的改版中的埋點喇聊,主要借鑒了模型統(tǒng)計中的思路,用自定義埋點統(tǒng)計實現(xiàn)蹦狂,可以說是對以往我們的自定義埋點統(tǒng)計的一次大升級誓篱。

自定義統(tǒng)計點基本結(jié)構(gòu)

雖然現(xiàn)在做自定義統(tǒng)計的方式有很多,各家想必都有自己的數(shù)據(jù)結(jié)構(gòu)鸥咖,不過基本的數(shù)據(jù)結(jié)構(gòu)上都是大同小異的燕鸽。一般自定義點上報時還會攜帶其他的基本參數(shù)(如用戶imei、IP地址啼辣、網(wǎng)絡(luò)狀態(tài)等),這里我只用產(chǎn)品人員會涉及到的參數(shù)來隨便舉個例子

"eventID" : "Click_HomePage_Button" , "status" : "login" , "time" : "1500450788987" , "model" : "vivo X9"

可以看到御滩,一條上報數(shù)據(jù)里基本結(jié)構(gòu)就是“屬性 - 屬性值”鸥拧,因此上面的這條數(shù)據(jù)其實是這樣:

一條數(shù)據(jù)的基本結(jié)構(gòu)

Click_HomePage_Button這個統(tǒng)計點在用戶點擊app首頁按鈕時觸發(fā)上報,同時利用參數(shù)status記錄當前用戶的登錄狀態(tài)為login削解,利用參數(shù)time記錄當前的時間戳富弦,參數(shù)model則是記錄了用戶使用的手機機型為vivo X9。這樣一條基本的自定義統(tǒng)計數(shù)據(jù)就完成了氛驮,這個統(tǒng)計點的pv即為點擊“app首頁”的次數(shù)腕柜。

用盡可能少的點統(tǒng)計更多信息

從上面的例子可以知道,一條數(shù)據(jù)在上報時,除了產(chǎn)品人員定義的參數(shù)外盏缤,還會攜帶很多其他的參數(shù)來統(tǒng)計基礎(chǔ)信息砰蠢。因此每條統(tǒng)計數(shù)據(jù)中,基礎(chǔ)信息的參數(shù)可能占到了很大的比例唉铜。

對于產(chǎn)品人員定義的一些“沒有參數(shù)”的統(tǒng)計點台舱,一條數(shù)據(jù)中基礎(chǔ)信息所占的空間可能已經(jīng)超過了90%。雖然一條數(shù)據(jù)可能只有幾k潭流,但是百萬甚至千萬級別以上的數(shù)據(jù)量級下竞惋,一條數(shù)據(jù)中產(chǎn)品人員真正關(guān)心的參數(shù)占比如此的低,對于數(shù)據(jù)部門的存儲來說灰嫉,也是一種極大的浪費拆宛。

因此,利用好每一條上報數(shù)據(jù)讼撒,讓每一條數(shù)據(jù)的價值最大化浑厚,是每一個產(chǎn)品人員都應(yīng)該關(guān)心的問題,在這個基礎(chǔ)上椿肩,盡量提升數(shù)據(jù)的靈活程度瞻颂,也能極大地提升我們后期查詢和整理數(shù)據(jù)的效率。

我的做法

在這次我負責的數(shù)據(jù)埋點方案中郑象,我的核心思路就是上面提到的盡可能提高每一條上報數(shù)據(jù)的價值贡这,以頁面為單位,將頁面內(nèi)的所有操作一次性上報厂榛。

因此我們需要轉(zhuǎn)變以往的“每個行為都上報一次”的埋點和上報思路盖矫,而是對同一維度內(nèi)的操作做統(tǒng)一的上報。

舉個例子

以常見的視頻或直播頁面為例吧击奶,一個頁面內(nèi)集中了大量的功能辈双,這種類型的頁面就很適合進行統(tǒng)計點的精簡和整合

某視頻軟件界面

可以看到,在“首頁-推薦”這個頻道內(nèi)柜砾,集中了點贊湃望、評論、轉(zhuǎn)發(fā)痰驱、播放暫停等幾個主要功能证芭,他們的操作路徑并不復(fù)雜,在統(tǒng)計時只需要統(tǒng)計他們的狀態(tài)即可(如是否點過贊担映,是否有過評論等)废士。

因此在做統(tǒng)計點設(shè)計時,可考慮將這些操作合并到一個統(tǒng)計點內(nèi)蝇完,用幾個參數(shù)來分別代表這幾個操作官硝,并用對應(yīng)的參數(shù)值來代表各個功能對應(yīng)的狀態(tài)矗蕊。

頁面內(nèi)操作的統(tǒng)計點

可以看到,在這個點里除去統(tǒng)計點名稱之外一共有4個參數(shù)氢架,分別記錄了點贊傻咖、評論、評論內(nèi)容达箍、轉(zhuǎn)發(fā)這幾個操作的狀態(tài)没龙。其中需要提前約定參數(shù)值的含義,在這里我定義參數(shù)值數(shù)字1為“有該操作”缎玫,0為“無該操作”硬纤,因此例子中這條數(shù)據(jù)的含義即為“有點贊、評論操作赃磨,沒有轉(zhuǎn)發(fā)”筝家;而參數(shù)word下直接存放評論內(nèi)容。

對參數(shù)值的定義

如此一來邻辉,這條數(shù)據(jù)上報時溪王,會攜帶點贊、評論值骇、轉(zhuǎn)發(fā)三個操作的狀態(tài)莹菱,相比于這三個操作用單獨的統(tǒng)計點上報,合并上報會有效提升單條數(shù)據(jù)的價值吱瘩。而在分析數(shù)據(jù)時道伟,只需要針對各個參數(shù)去統(tǒng)計里面參數(shù)值數(shù)量即可得到這個功能操作對應(yīng)的pv和uv。

需要注意的地方

這種對于統(tǒng)計點的整合處理使碾,有兩個地方需要注意

  1. 選擇恰當?shù)墓δ苓M行合并統(tǒng)計
    并不是所有的統(tǒng)計點都適合用這種方式做精簡和合并蜜徽,這種方法只適合于在同一場景下的一些簡單的、路徑較短的操作票摇。如果一個操作時線性的且路徑較深托修,上一步和下一步操作之間有很強的關(guān)聯(lián)性(如需要下一步叭首、下一步的功能),就不太適合用這種方法了污抬。

  2. 統(tǒng)計點的上報時機
    上一個點內(nèi)也提到工育,在同一場景下的簡單操作可以精簡和合并键兜,因為只有同一場景下(如視頻的詳情頁)胡控,才可以方便的找到一個統(tǒng)一上報數(shù)據(jù)的時機茎辐,如“離開視頻詳情頁”這樣的時機將統(tǒng)計點及時上報。

如果是在多個復(fù)雜場景下使用一個統(tǒng)計點峡扩,那么統(tǒng)計的參數(shù)值數(shù)據(jù)則需要提前在客戶端本地存儲,到約定的時機再上報(如每天上報一次)障本,這樣做的客戶端的實現(xiàn)成本以及數(shù)據(jù)的準確性都有待商榷教届。

總結(jié)

這種統(tǒng)計點上報的方法响鹃,借鑒了模型統(tǒng)計的思路,在一定的條件下案训,提高了自定義埋點的方法的數(shù)據(jù)效率和價值买置,同時由于在一條數(shù)據(jù)內(nèi)包含了多個參數(shù),也就使得在分析數(shù)據(jù)時强霎,可以將多個參數(shù)自由靈活的聯(lián)立組合忿项,從而得到更詳細的分析結(jié)果。

但是這種方法也存在著一定的局限性城舞,最顯著的變化就是將原來自定義統(tǒng)計點“實時上報”的特性轩触,變?yōu)榱诉x擇特定的上報時機“延時上報”,因此涉及到了客戶端內(nèi)對數(shù)據(jù)的存儲家夺,以及這樣上報的準確性等問題都需要研發(fā)人員針對自己的產(chǎn)品進行詳細的評估脱柱。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市拉馋,隨后出現(xiàn)的幾起案子榨为,更是在濱河造成了極大的恐慌煌茴,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,324評論 6 498
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件蔓腐,死亡現(xiàn)場離奇詭異矩乐,居然都是意外死亡合住,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,356評論 3 392
  • 文/潘曉璐 我一進店門透葛,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人僚害,你說我怎么就攤上這事∪希” “怎么了靶草?”我有些...
    開封第一講書人閱讀 162,328評論 0 353
  • 文/不壞的土叔 我叫張陵岳遥,是天一觀的道長。 經(jīng)常有香客問我浩蓉,道長宾袜,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,147評論 1 292
  • 正文 為了忘掉前任驾窟,我火速辦了婚禮庆猫,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘绅络。我一直安慰自己月培,他們只是感情好,可當我...
    茶點故事閱讀 67,160評論 6 388
  • 文/花漫 我一把揭開白布恩急。 她就那樣靜靜地躺著杉畜,像睡著了一般。 火紅的嫁衣襯著肌膚如雪假栓。 梳的紋絲不亂的頭發(fā)上寻行,一...
    開封第一講書人閱讀 51,115評論 1 296
  • 那天,我揣著相機與錄音匾荆,去河邊找鬼拌蜘。 笑死,一個胖子當著我的面吹牛牙丽,可吹牛的內(nèi)容都是我干的简卧。 我是一名探鬼主播,決...
    沈念sama閱讀 40,025評論 3 417
  • 文/蒼蘭香墨 我猛地睜開眼烤芦,長吁一口氣:“原來是場噩夢啊……” “哼举娩!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起构罗,我...
    開封第一講書人閱讀 38,867評論 0 274
  • 序言:老撾萬榮一對情侶失蹤铜涉,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后遂唧,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體芙代,經(jīng)...
    沈念sama閱讀 45,307評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,528評論 2 332
  • 正文 我和宋清朗相戀三年盖彭,在試婚紗的時候發(fā)現(xiàn)自己被綠了纹烹。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,688評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡召边,死狀恐怖铺呵,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情隧熙,我是刑警寧澤片挂,帶...
    沈念sama閱讀 35,409評論 5 343
  • 正文 年R本政府宣布,位于F島的核電站贞盯,受9級特大地震影響宴卖,放射性物質(zhì)發(fā)生泄漏滋将。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,001評論 3 325
  • 文/蒙蒙 一症昏、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧父丰,春花似錦肝谭、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,657評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至更哄,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間成翩,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,811評論 1 268
  • 我被黑心中介騙來泰國打工栅炒, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人赢赊。 一個月前我還...
    沈念sama閱讀 47,685評論 2 368
  • 正文 我出身青樓级历,卻偏偏與公主長得像,于是被迫代替她去往敵國和親鱼喉。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,573評論 2 353

推薦閱讀更多精彩內(nèi)容