我們平時看到的報表複雜而多樣，能夠通過多種緯度的資料評估使用者的使用習慣和對應功能的價值。然而這些報表是如何產生的呢?今天咱們就看看上報資料一步一步變成報表的大致流程。
當上報資料設計好後，後續的工作才能正常開展。下面一步一步說。
1、埋點
2、上報
並不是每統計到一次事件或者狀態就會發起資料上報，客戶端統計到的資料會先暫時儲存在記憶體或者磁碟上，當使用者啟動、退出應用程式的時候，或者在其他更合適的時機，將當前週期統計到的事件批量上報到伺服器，這樣做的目的主要是考慮到與伺服器多次建立連線的效能損耗(詳見《不得不知的tcp和udp》) 和流量問題(相同大小的資料分多次傳送比一次傳送要消耗更多流量)，另外客戶端在上報具體的統計事件之外，還會將標識使用者的id一併上報，後續用於計算使用者相關的資料如日使用使用者和留存率等。
3、後台記錄日誌
資料上報到伺服器後，伺服器會將客戶端上報的原始資料儲存到伺服器的磁碟中。一般來說，非強實時性的資料上報到伺服器後，並不會立即參與計算，獲得最終的統計結果，比如乙個功能的日使用次數，日使用者數，日留存等資料，而是等到伺服器負載較低的時間段利用預先配置的計畫任務進行離線處理。這樣處理的目的是為了節約伺服器資源(錢)，因為大家肯定不想因為計算統計資料而影響實時業務的處理效率。
4、計算&入庫
報表中展示的資料，並不是客戶端上報的原始資料，比如「+」的使用次數、使用使用者數、日留存率這三組資料，都是通過對客戶端上報的「click_add_btn」對應value值的累加並結合上報使用者id二次計算得出的。
一般情況下，原始資料經過資料倉儲工具處理後，對應的日誌檔案還會在伺服器上保留一段時間(一般3~7天)，以便追溯統計問題，所以，如果發現統計資料有問題問題，一定要及時反饋給負責的程式猿，否則就會「死」無對證咯。
5、展示
當資料「入庫」後，報表的展示就水到渠成了。報表系統通過前端頁面使用者的輸入獲取查詢條件，然後通過後台資料庫查詢獲得結果，在前端展示出來。
這裡只是簡述了埋點資料上報、統計的大致流程，每個過程中還有很多細節要解決，如後台日誌亂碼問題、客戶端異常導致資料丟失等。一旦資料出現問題，經常需要聯絡各方人員定位原因。在此呼籲廣大的產品大蝦一定要關心、愛護為你做統計需求的程式猿，他們上輩子都是偷了蟠桃的孫悟空。
對咯，今天別忘了看報表哦。
開發經驗 nginx收集埋點資料
二 nginx配置 使用nginx收集頁面上報的資訊，並且解析。通常頁面請求後端介面都是get請求或者post請求，http還有head的請求方式，head請求的特點是不返回訊息體，head請求主要用來檢查資源有效性。在資料上報的時候也可以使用head請求。通過傳送http ip 埠 log.gif...
無埋點資料收集和adb monkey測試遮蔽通知欄
值得注意的是從編譯專案並啟動執行開始，5分鐘左右後即可在 上看到對應的啟動資料！windows系統配置好adb環境後,開啟cmd視窗,輸入adb shell monkey p 應用包名 v 點選次數 desktop log.txt 去stackoverflow上找到乙個有效的解決辦法,現在分享給大家...
你買了什麼它都知道！看超市如何利用大資料吸金
我們一直說，大資料時代，資料就像金子一樣值錢 大資料是對海量資料的分析，大資料對企業多麼多麼重要，總說理論沒意思，今天就讓我們看看真實的例子。樂購大家應該都知道吧，各大城市都有的連鎖超市，大多數超市會員卡只有積分 打折的簡單功能。而樂購卻利用 大資料 對消費者每次採購的總量 偏愛哪類產品 產品使用頻...