數據收集原理分析

簡單來說，網站統計分析工具需要收集到用戶瀏覽目標網站的行為（如打開某網頁、點擊某按鈕、將商品加入購物車等）及行為附加數據（如某下單行為產生的訂單金額等）。早期的網站統計往往只收集一種用戶行為：頁面的打開。而后用戶在頁面中的行為均無法收集。這種收集策略能滿足基本的流量分析、來源分析、內容分析及訪客屬性等常用分析視角，但是，隨著Ajax技術的廣泛使用及電子商務網站對于電子商務目標的統計分析的需求越來越強烈，這種傳統的收集策略已經顯得力不能及。

后來，Google在其產品谷歌分析中創新性的引入了可定制的數據收集腳本，用戶通過谷歌分析定義好的可擴展接口，只需編寫少量的JavaScript代碼就可以實現自定義事件和自定義指標的跟蹤和分析。目前百度統計、搜狗分析等產品均照搬了谷歌分析的模式。

其實說起來兩種數據收集模式的基本原理和流程是一致的，只是后一種通過JavaScript收集到了更多的信息。下面看一下現在各種網站統計工具的數據收集基本原理。

1 第三方統計工具

第一種是直接使用友盟、百度統計這樣的第三方統計工具，通過嵌入 App SDK 或 JS SDK，然后就可以看統計數據了。這種方式的好處是簡單、免費，因此使用非常普及。對于看一些網站訪問量、活躍用戶量這樣的宏觀數據需求，基本能夠滿足。但是，現在一些訂單相關的產品，越來越不滿足于看這些宏觀統計數據，還想做一些深度的用戶渠道轉化、留存、多維度交叉分析等操作，這個時候就會發現很難滿足。這里的問題倒不是出在分析能力的薄弱，而是出現數據采集的不完整。

通過這種 SDK 只能夠采集到一些基本的用戶行為數據，比如設備的基本信息，用戶執行的基本操作等。但是服務端、數據庫中的數據并沒有采集，對于一些提交操作，比如提交訂單對應的成本價格、折扣情況等信息也沒有采集，這樣就導致后續的分析成了“巧婦難為無米之炊”。

通過客戶端 SDK 還有一個問題就是經常覺得統計的不準，和自己的業務數據庫數據對不上，出現丟數據的情況。這是前端數據采集的先天缺陷，因為網絡異常，或者統計口徑不一致，都會導致數據對不上。

2 使用業務數據庫

第二種是直接使用業務數據庫做統計分析。一般的互聯網的產品，后端都是有業務數據庫，里面存儲了訂單、用戶注冊信息等數據，基于這些數據，一些常用的統計分析都能夠搞定了。這種方式天然的就能分析業務數據，并且是實時、準確的。但不足之處有兩點：一是業務數據庫在設計之初就是為了滿足正常的業務運轉，給機器讀寫訪問的。為了提升性能，會進行一些分表等操作。一個正常的業務都要有幾十張甚至上百張數據表，這些表之間有復雜的依賴關系。這就導致業務分析人員很難理解表含義。即使硬著頭皮花了兩三個月時間搞懂了，隔天工程師又告訴你因為性能問題拆表了，你就崩潰了。二是業務數據表的設計在于高并發低延遲的小操作，而數據分析常常是針對大數據進行批量操作，這樣就導致性能很差。

3 通過 Web 日志

第三種是通過 Web 日志進行統計分析。這種方式相比基于業務數據庫的方式，完成了解耦，使業務運行和統計分析兩個數據流相分離。這里的問題是打印日志往往是工程師順便搞搞，完全是以 Debug 的需求來打印日志字段，但在業務分析上，往往發現缺斤少兩。并且從打印日志到處理日志到輸出統計結果，整個過程很容易出錯，我在百度就花了幾年的時間解決這一問題。

以上三種方式都多多少少解決了一部分數據采集的問題，但又都解決的不徹底。

存在問題

一般數據采集有點很多，每次數據產品經理提了數據采集的需求，工程師就會按照要求給做了，然后交給數據產品經理去驗證。數據產品經理在試用的時候也感覺不到異常，可等上線之后，發現埋的不對，再進行升級發版操作，整個效率就比較低了。一個公司發展到一定程度，沒有專人去負責埋點管理工作，數據采集完全沒有準確性可言。還有產品上線之后，才發現數據采集的工作沒有做，也就是漏埋了。

于是數據相關的同學甚至管理者都在幻想，既然埋點這么容易出問題，有沒有不埋點就可以解決所有問題？這就像尋找可以祈求風調雨順的神靈。百度曾經做了一個產品，只要頁面上嵌入 SDK，就可以采集下來頁面上所有的點擊行為，然后就可以繪制出用戶點擊的熱力圖，這種方式對于一些探索式的調研還是比較有用的。后來國外的Heap Analytics，把這種方式更近一步，將 App 的操作盡量多的采集下來，然后通過界面配置的方式對關鍵行為進行定義，這樣就可以不用工程師的配合就可以完成數據采集操作了，這是其中的一個優點。這里要說明的是，要使用這種方案，必須在產品里實現嵌入 SDK，等于做了一個統一的埋點，所以“無埋點”這種叫法本身就不嚴謹，這種方式更像是“全埋點”。

這種方式只能是進行前端的數據采集，后端服務器和數據庫中的數據，依舊是無可奈何的。即使進行前端的數據采集，也不能夠進行細粒度的數據采集。比如對于提交訂單操作，訂單的運費、成本價格之類的維度信息，等于都丟失掉了，只剩下提交這么一個行為類型。

對于非技術人員，容易被這種方式的名稱和直接優勢所吸引，但很快又會發現許多深度數據分析需求無法直接滿足，進而有種被忽悠的感覺，會感到失望。原理的關鍵點：一是事先在產品上埋一個 SDK，二是通過可視化的方式，生成配置信息，也就是事件名稱之類的定義，三是將采集的數據按照配置重命名，進而做分析。

埋點和無埋點

用戶行為數據收集技術主要有兩種：埋點和無埋點

1 埋點

所謂埋點就是為了數據分析的需求在原本的復雜的代碼邏輯之上在加上N行獲取數據的代碼。比如如果想獲取某商品的點擊數量，就得在點擊事件的中搜集點擊的商品數據，發出包含商品名稱和點擊事件的數據（{productname,clicktime}）。

1.1 埋點的優勢

1）埋點最大的優勢就是數據都是手動編碼產生的，靈活性比較大，可以更好得支持一些擴展數據。

2）埋點由于是按照埋點邏輯進行的預處理，所以對之后的分析友好，分析效果也比較好。

1.2 埋點的劣勢

1）埋點最重要的前提條件是必須十分清楚目標，即需要收集什么樣的數據必須提前確定。所以埋點最容易出現的問題就是漏埋，一般來說在發布前一定要經過謹慎的校驗和測試，因為一旦版本發布出去而數據采集出了問題。

2）在產品的迭代過程中，如果代碼再迭代的時候忽略了埋點邏輯的更改，從而導致后續的分析邏輯不準，甚至導致產品bug。更甚于對于產品迭代比較快的場景，埋點就是一個定時炸彈。

2 無埋點

埋點技術和無埋點技術都需要在原有的業務代碼上進行改動。無埋點就是通過編程語言自身的特點來完成數據收集的自動化過程。比如前臺無埋點其實就是通過監聽JS事件，把頁面上發生的所有事件都采集下來。后臺無埋點實現比較復雜，但是說起來很簡單，其實就是將網絡數據進行旁路反解析，前后端交互的數據肯定都會經過網絡，所以網絡中應該包含了絕大多數業務數據。

2.1 無埋點的優勢

1) 相對于埋點方式帶來的收益就是正好就是埋點容易產生的問題，由于采集的是全量數據，所以產品迭代過程中是不需要關注埋點邏輯的，也不會出現漏埋、誤埋等現象。

2）無埋點方式因為收集的是全量數據，可以大大減少運營和產品的試錯成本，試錯的可能性高了，可以帶來更多啟發性的信息。

3）最后一點，也是最清楚的一點，就是減少了因為人員流動帶來的溝通成本。

2.2 無埋點的缺陷

無埋點的缺陷，也是無埋點存在的一些質疑點：

1）適用大部門，通用的場景，有少部分需要埋點的場景覆蓋不了。

2）無埋點采集全量數據，給數據傳輸和服務器增加壓力

根據前面關于埋點和無埋點的科普，我們都明白其實兩個方式都有其自身的優勢和缺陷，知乎和其他技術博客上關于這兩個討論點的文章也有很多，有人在批埋點，有人在批無埋點。關于技術，我們還是理性看待吧，它們兩個不是你死我活的關系，通過我們調研的得到的情況是，目前沒有方案能夠完美解決無埋點問題，但是我們致力于研究最大限度通過通用方式解決埋點問題，盡量減少埋點代碼，埋點代碼越少，出錯的可能性就越低。我們選擇使用前臺無埋點和后臺無埋點技術相結合的方式來獲取用戶數據。