隨著移動網際網路時代的興起和資料量的大規模爆發，越來越多的網際網路企業開始重視資料的質量，使用者對資料的需求已經不僅僅侷限於簡單的 PV、UV，而是更加重視使用者使用行為資料的相關分析。在資料分析的道路上，資料採集是重中之重。資料採集的質量直接決定了你的分析是否準確。而隨著企業對資料的要求越來越高，埋點技術也被推到了“風口浪尖”。今天就來聊聊在資料採集的道路上經常會遇到各的問題。

比較常用的網站資料統計分析工具有谷歌分析、百度統計和騰訊分析等等。所有這些統計分析工具的第一步都是網站訪問資料的收集。目前主流的資料收集方式基本都是基於javascript的。

1.  資料收集原理分析

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

後來，Google在其產品谷歌分析中創新性的引入了可定製的資料收集指令碼，使用者通過谷歌分析定義好的可擴充套件介面，只需編寫少量的javascript程式碼就可以實現自定義事件和自定義指標的跟蹤和分析。目前百度統計、搜狗分析等產品均照搬了谷歌分析的模式。

其實說起來兩種資料收集模式的基本原理和流程是一致的，只是後一種通過javascript收集到了更多的資訊。下面看一下現在各種網站統計工具的資料收集基本原理。

2.  資料採集方式及問題

2.1. 採集方式

2.1.1. 第三方統計工具

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

通過這種 SDK 只能夠採集到一些基本的使用者行為資料，比如裝置的基本資訊，使用者執行的基本操作等。但是服務端、資料庫中的資料並沒有採集，對於一些提交操作，比如提交訂單對應的成本價格、折扣情況等資訊也沒有采集，這樣就導致後續的分析成了“巧婦難為無米之炊”。

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

2.1.2.使用業務資料庫

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

2.1.3. 通過 Web 日誌

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

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

2.2. 存在問題

2.2.1.埋點混亂

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

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

這種方式只能是進行前端的資料採集，後端伺服器和資料庫中的資料，依舊是無可奈何的。即使進行前端的資料採集，也不能夠進行細粒度的資料採集。比如對於提交訂單操作，訂單的運費、成本價格之類的維度資訊，等於都丟失掉了，只剩下提交這麼一個行為型別。

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

3.  埋點和無埋點

使用者行為資料收集技術主要有兩種：埋點和無埋點

3.1. 埋點

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

3.1.1. 埋點的優勢

1）埋點最大的優勢就是資料都是手動編碼產生的，靈活性比較大，可以更好得支援一些擴充套件資料。

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

3.1.2.埋點的劣勢：

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

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

3.2. 無埋點

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

3.2.1.無埋點的優勢：

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

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

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

3.2.2.無埋點的缺陷

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

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

2）無埋點採集全量資料，給資料傳輸和伺服器增加壓力

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

3.3. GrowingIO

3.3.1.簡介

growingIO的主要業務，是幫助客戶公司去收集web和移動端的raw logging data，然後從這些資料中提煉出有用的業務資訊。他們提供的工具（SDK）不再硬性要求客戶公司的程式設計師去手動埋點。因為埋點這個操作本來就不是程式設計師喜歡去幹的事情，另外埋點的邏輯源於商務或者運營部門，所以開發的人精確埋點通常是可遇而不求的事情。一般網站、iOS和Android都有大量的埋點工作要做，主要用於使用者資料採集和使用者行為分析等，但是作為開發者覺得這些工作十分痛苦。GrowingIO的採用的方法很“神奇”，只需要植入SDK，然後在他們的控制檯用滑鼠點點，來表明哪些控制元件（e.g. 按鈕，網頁，移動頁面等）你最為關心（這個操作可以交給業務部門做），GrowingIO便會記錄和最後呈現那些控制元件的相關資訊。同時他們還會針對業務型別給出專業的商業分析資料頁（data dashboard）。

GrowingIO的產品，號稱植入SDK，可以使得開發人員不需要為資料追蹤和上報在程式碼中埋點。

3.3.2. 無需埋點分析

通過分析一下app的生命週期，可以大概知道其“無需埋點”的原理。

App的生命週期可以劃為

1. programming：也就是開發人員寫程式碼

2. compiling：編譯程式碼得到App package

3. installing：在device上 安裝 app

4. running：在device上執行 

GrowingIO號稱不需要開發人員埋點，只需要植入SDK，也就是說其 並不是工作在第一階段。

做過Android底層的可能就會想到，在installing和running的時候 通過hook Android runtime 或者 Android framework的程式碼也是可以實現，將其追蹤和上報的工作程式碼植入到app執行過程中的。但是對於 iOS是不可以的。

因此。其也不是工作在第三階段和第四階段的。

那麼，其一定是在編譯期做的工作。也就是說其SDK，應該是在編譯程式碼的時候，將追蹤和上報的程式碼植入到app本身的程式碼裡的。

iOS可以通過攔截的方式來實現 編譯時動態修改原始碼。

Android則可以利用gradle的外掛方法，插入自定義task來完成。