整天看用戶埋點數據,知道數據是咋來的嗎?
我們平時看到的報表復雜而多樣,能夠通過多種緯度的數據評估用戶的使用習慣和對應功能的價值。然而這些報表是如何產生的呢?今天咱們就看看上報數據一步一步變成報表的大致流程。
所有上報的數據都是為了記錄一次事件的發生或者描述一個狀態,具體的上報數據可以設計為KEY-VALUE的形式或者數據組合的形式。KEY-VALUE的形式主要用來統計簡單的計數類上報,如按鈕點擊的次數,某個選項的值等,KEY用來區分不同的事件,VALUE代表事件發生的次數、狀態值等;數據組合的主要用來描述一個事件或者狀態需要多種屬性描述的場景,比如下載成功事件,描述這個事件的數據組合可能包括對應的下載地址、下載渠道來源、下載耗時等信息。
當上報數據設計好后,后續的工作才能正常開展。下面一步一步說。
1、埋點
所謂「埋點」,就是在正常的功能邏輯中添加統計邏輯。拿統計微信右上角「+」的點擊次數為例,上報的數據可以采用KEY-VALUE形式,我們定義KEY為「CLICK_ADD_BTN」,VALUE的值為點擊的次數。當用戶點擊「+」時,展示菜單的代碼會通過按鈕的「回調」(詳見《聊聊同步、異步和回調》)來觸發執行,程序猿在業務代碼執行完后,又加上了統計代碼,把「CLICK_ADD_BTN」對應的VALUE加1,「+」被統計到了一次使用。
2、上報
并不是每統計到一次事件或者狀態就會發起數據上報,客戶端統計到的數據會先暫時存儲在內存或者磁盤上,當用戶啟動、退出應用程序的時候,或者在其他更合適的時機,將當前周期統計到的事件批量上報到服務器,這樣做的目的主要是考慮到與服務器多次建立連接的性能損耗(詳見《不得不知的TCP和UDP》)和流量問題(相同大小的數據分多次發送比一次發送要消耗更多流量),另外客戶端在上報具體的統計事件之外,還會將標識用戶的ID一并上報,后續用于計算用戶相關的數據如日使用用戶和留存率等。
3、后臺記錄日志
數據上報到服務器后,服務器會將客戶端上報的原始數據存儲到服務器的磁盤中。一般來說,非強實時性的數據上報到服務器后,并不會立即參與計算,獲得最終的統計結果,比如一個功能的日使用次數,日用戶數,日留存等數據,而是等到服務器負載較低的時間段利用預先配置的計劃任務進行離線處理。這樣處理的目的是為了節約服務器資源(錢),因為大家肯定不想因為計算統計數據而影響實時業務的處理效率。
4、計算&入庫
報表中展示的數據,并不是客戶端上報的原始數據,比如「+」的使用次數、使用用戶數、日留存率這三組數據,都是通過對客戶端上報的「CLICK_ADD_BTN」對應VALUE值的累加并結合上報用戶ID二次計算得出的。
如果我們的產品達到微信這種日登陸數五六億,那么每天上報的統計數據將是海量的,為了從這種海量的數據中計算出「+」的使用次數、使用用戶數等信息,就需要用到「數據倉庫工具」,比如當下流行的Hive處理工具,它基于Hadoop分布式系統基礎框架,利用計算機集群的能力進行分布式計算。當「數據倉庫工具」計算出最終的結果后,計劃任務會將結果(「+」的日使用次數、日使用用戶數等數據)保存到數據庫中,也就是「入庫」過程?!溉霂臁购蟮臄祿拍芘c前端對接,組成報表展示系統。
一般情況下,原始數據經過數據倉庫工具處理后,對應的日志文件還會在服務器上保留一段時間(一般3~7天),以便追溯統計問題,所以,如果發現統計數據有問題問題,一定要及時反饋給負責的程序猿,否則就會「死」無對證咯。
5、展示
當數據「入庫」后,報表的展示就水到渠成了。報表系統通過前端頁面用戶的輸入獲取查詢條件,然后通過后臺數據庫查詢獲得結果,在前端展示出來。
這里只是簡述了埋點數據上報、統計的大致流程,每個過程中還有很多細節要解決,如后臺日志亂碼問題、客戶端異常導致數據丟失等。一旦數據出現問題,經常需要聯系各方人員定位原因。在此呼吁廣大的產品大蝦一定要關心、愛護為你做統計需求的程序猿,他們上輩子都是偷了蟠桃的孫悟空。
對咯,今天別忘了看報表哦。
#專欄作家#
給產品經理講技術,微信公眾號(pm_teacher),人人都是產品經理專欄作家。資深程序猿,專注客戶端開發若干年,對前端、后臺技術略懂,熱衷于對新的科技領域的探索。
本文原創發布于人人都是產品經理,未經許可,不得轉載。
同問,埋點的時機如何把握
初入行的產品怎么知道埋點的時機的?。??
如何做到無埋點統計來路呢?
?