在這篇文章裏面，我們會對數據採集的一些基本概念進行闡述，然後，會針對目前市面上新增的一些前端埋點技術，如可視化埋點與“無埋點”的技術細節做一個具體的介紹，並且闡述我們自己對於這些技術的理解和認識。
1. 數據採集是核心問題
一個典型的數據平臺，對於數據的處理，是由如下的5個步驟組成的：
其中，我們認爲，第一個步驟，也即數據採集是最核心的問題。數據採集是否豐富，採集的數據是否準確，採集是否及時，都直接影響整個數據平臺的應用效果。
在我們手冊中闡述了使用 Sensors Analytics 時，在確定數據採集方案時應該遵循的兩個基本原則：
- 優先在後端收集數據；
- 屬性儘可能採集全面。
雖然我們之前已經詳細描述過前端埋點的一些問題。例如，需要等待網絡情況良好才能發送數據，需要積攢一定的量才發送數據，需要在本地暫存而本地暫存空間有限等一系列在數據傳輸性和數據可靠性上的一些問題。
但是，前端埋點畢竟有一些後端採集數據所無法替代的地方，例如，分析前端界面設計是否合理，分析一些在與後端沒有交互的前端行爲等，還是必須採用前端埋點方案的。前端埋點作爲一個比較成熟並且被廣泛採用的數據接入手段，Sensors Analytics 也提供了一系列相應的解決方案。因此，在這裏，我們覺得有必要詳細介紹一下目前市面上主流的前端埋點方案的技術細節，並且結合我們的產品，來闡述我們對於這些埋點方案的一些看法。
2. 前端埋點技術介紹
目前常見的前端埋點技術，有三類：在某個控件操作發生時通過預先寫好的代碼來發數據的代碼埋點；通過可視化界面配置控件操作與事件發生關係的可視化埋點；先收集所有數據再在後端篩選需要分析的對象的“無埋點”。
下面，我們分別對這三種方案進行介紹，然後再闡述我們的觀點。
2.1 代碼埋點
代碼埋點出現的時間很早了，在 Google Analytics 年代，就已經出現了類似的方案了。目前，國內的主要第三方數據分析服務商，如百度統計、友盟、TalkingData 等都提供了這一方案。Sensors Analytics 也一樣提供了 iOS、Android、Web 等主流平臺的代碼埋點方案。
它的技術原理也很簡單，在APP或者界面初始化的時候，初始化第三方數據分析服務商的SDK，然後在某個事件發生時就調用SDK裏面相應的數據發送接口發送數據。例如，我們想統計APP裏面某個按鈕的點擊次數，則在APP的某個按鈕被點擊時，可以在這個按鈕對應的 OnClick 函數裏面調用SDK提供的數據發送接口來發送數據。
下面，我們看友盟提供的兩個例子。
第一個例子是在使用者的某個 Android APP 裏面，統計某個由 Activity 構成的頁面的訪問次數，下面是友盟官方給出的例子：
public void onResume() {
super.onResume();
MobclickAgent.onPageStart("SplashScreen"); //統計頁面(僅有Activity的應用中SDK自動調用，不需要單獨寫。"SplashScreen"爲頁面名稱，可自定義)
MobclickAgent.onResume(this); //統計時長
}
public void onPause() {
super.onPause();
MobclickAgent.onPageEnd("SplashScreen"); // 僅有Activity的應用中SDK自動調用，不需要單獨寫）保證 onPageEnd 在onPause 之前調用,因爲 onPause 中會保存信息。"SplashScreen"爲頁面名稱，可自定義
MobclickAgent.onPause(this);
}
這個例子其實非常簡單，就是在 Activity 控件相應的觸發器函數裏面，調用友盟提供的接口統計數據即可。
第二個例子稍微複雜點，它不再是統計頁面訪問這樣一個默認的事件，而是統計一個自定義事件。例如，一個電商APP，在用戶點擊“購買”按鈕時，想統計“購買”這個自定義事件的相應信息，那麼，可以使用下面的代碼：
HashMap<String,String> map = new HashMap<String,String>();
map.put(“type”,“book”);
map.put(“quantity”,“3”);
MobclickAgent.onEvent(mContext, “purchase”, map);
必須說明的是，友盟歸根結底還是一個統計工具，並沒有提供完整的多維分析功能，姑且不算數據傳輸的時效性以及對自定義屬性上的各種限制，僅僅是爲了統計某個數值，友盟還要單獨區分出“計數事件”和“計算事件”，這一點上，就遠遠不如 Sensors Analytics 的靈活了。
從上面這兩個例子可以看出，代碼埋點的優點是一方面使用者控制精準，可以非常精確地選擇什麼時候發送數據；同時使用者可以比較方便地設置自定義屬性、自定義事件，傳遞比較豐富的數據到服務端。
當然，代碼埋點也有一些劣勢。首先，埋點代價比較大，每一個控件的埋點都需要添加相應的代碼，不僅工作量大，而且限定了必須是技術人員才能完成；其次是更新的代價比較大，每一次更新埋點方案，都必須改代碼，然後通過各個應用市場進行分發，並且總會有相當多數量的用戶不喜歡更新APP，這樣埋點代碼也就得不到更新了；最後，就是所有前端埋點方案都會面臨的數據傳輸時效性和可靠性的問題了，這個問題就只能通過在後端收集數據來解決了。
2.2 可視化埋點
從前端埋點到可視化埋點其實是一個非常順理成章的演進。既然埋點代價大，每一個埋點都需要寫代碼，那麼，就參考 Visual Studio 等一系列現代 IDE 的做法，用可視化交互手段來代替寫代碼即可；既然每次埋點更新都需要等待APP的更新，那麼，就參考現在很多手遊的做法，把核心代碼和配置、資源分開，在APP啓動的時候通過網絡更新配置和資源即可。
正是出於這種自然而然的做法，在國外，以 Mixpanel 爲首的數據分析服務商，都相繼提供了可視化埋點的方案，Mixpanel將之稱作爲 codeless。而國內的 TalkingData、諸葛IO 等也都提供了類似的技術手段。 順帶一提，Sensors Analytics 在1.3版本的更新中，也已經給使用者提供可視化埋點方案，以降低使用者的數據接入成本。
特別需要強調的是，Mixpanel 非常無私地開源了它們的iOS 和 Android 端的 SDK 的源代碼，我們在開發中也參考了它們的貢獻，並且也貢獻了一些 bug 的提交，非常感謝 Mixpanel 對整個領域的貢獻。
2.2.1 iOS 和 Android 平臺的可視化埋點
下圖是演示一個簡單的 iOS SDK 使用 Mixpanel 的 codeless 埋點功能：
從這個界面可以看出，使用起來還是非常簡單的，點擊某個支持的控件類型的實例，這個例子中是右上角的刷新按鈕，然後在彈出的窗口中，設置點擊這個按鈕是發送 “Refresh” 事件。然後點擊 Deploy 按鈕，把這個配置下發下去。那麼，所有安裝有嵌入了 Mixpanel 的 SDK 的這個 APP ，則都會在 APP 啓動時或者定時獲取相應的配置。以後，真實的用戶使用時，點擊這個按鈕，就會真正地發送 “Refresh” 事件到後端了。
下面我們以 iOS 端爲例，進一步闡述可視化埋點的實現細節。
在嵌入了 SDK 的 APP 開啓可視化埋點模式，與後端聯通時，SDK 會應後端的要求，定期（例如每秒）做一次截圖，而 SDK 在爲 App 截圖的同時，會從 keyWindow 對象開始進行遍歷它的subviews()，得到當前視圖下所有 UIView、UIResponder 對象的層級關係。對於屏幕上的任何一個UIView對象，如 Button、Textfield 等，它都有一條唯一的從 keyWindow 到它的路徑，這個路徑上每個節點，都由 ClassName、它是父節點的第幾個subview、.text()等屬性的值等標識。相對於父節點的座標、長寬高等可視化方面的信息，是作爲這個節點的屬性存在。
服務端根據截屏和可視化信息來重新進行頁面渲染，並且根據控件的類型，來識別哪些控件是可以增加可埋點的，並且將之標識出來。
當使用者在後臺的截屏畫面上點擊了某個可埋點的控件時，後臺會要求使用者做一些事件關聯方面的配置，並且將配置信息進行保存和部署。
SDK 在啓動或者例行輪詢時拿到這些配置信息，則會通過.addTarget:action:forControlEvents:接口，爲每個關聯的控件添加的點擊或者編輯行爲的監聽，並且在回掉函數裏面調用 Sensors Analytics SDK 的接口發送相應事件的 track 信息。
整個 iOS 端的埋點的流程圖，如下圖所示：
Android 端的可視化埋點方案，與 iOS 端基本一致。
必須說明的是，上面描述的這一套可視化埋點的配置方案，其實也可以讓開發者在 iOS 或者 Android 的可視化 IDE 裏面完成，但是考慮到可視化埋點主要面臨的是非技術人員，所以最終業內都採用了 Mixpanel 的這種後臺截屏操作的方案。
2.2.2 Web 端的可視化埋點
Mixpanel 沒有提供 Web 端的可視化埋點方案，在這裏，我們以 Sensors Analytics 的 Web 端可視化埋點方案來舉例：
使用者在自己的網頁引入 Sensors Analytics 的 JavaScript SDK 代碼後，從 Sensors Analytics 的後臺可視化埋點管理界面跳轉到使用者的網站界面時，會自動進入到可視化埋點模式。在這個模式下，使用者在網頁上點擊任意 html元素時，Sensors Analytics 都會取到這個元素的url，層級關係等信息來描述這個 html 元素，當使用者設置了這個元素和某個事件相關聯時，SDK 會把這些關聯信息和客戶生成配置信息，並且存放在 Sensors Analytics 提供的相應保存位置。當真正的用戶以普通模式訪問這個網頁時，SDK 會自動加載配置信息，從而在相應的元素被點擊時，使用 Sensors Analytics 的數據發送接口來 track 事件。
從上面我們介紹的可視化埋點的方案可以看出，可視化埋點很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。但是，可視化埋點能夠覆蓋的功能有限，目前並不是所有的控件操作都可以通過這種方案進行定製；同時，Mixpanel 爲首的可視化埋點方案是不能自己設置屬性的，例如，一個界面上有一個文本框和一個按鈕，通過可視化埋點設置點擊按鈕爲一個“提交”事件時，並不能將文本框的內容作爲事件的屬性進行上傳的，因此，對於可視化埋點這種方案，在上傳事件時，就只能上傳 SDK 自動收集的設備、地域、網絡等默認屬性，以及一些通過代碼設置的全局公共屬性了；最後，作爲前端埋點的一種方案，可視化埋點也依然沒有解決傳輸時效性和數據可靠性的問題。
附帶一提，雖然 Mixpanel 比較早就推出了可視化埋點方案，但是卻一直沒有重點宣傳，並且也並不是它們的推薦數據接入方案，這種做法也是與 Mixpanel 一直強調的 “Actions speak louder than page views.” 是一致的。
2.3 “無埋點”
與可視化埋點一樣，“無埋點”這個方案也出來的比較早，Heap作爲一個第三方數據分析服務商，在2013年就已經推出了“無埋點”這個技術方案。而如果不侷限於第三方，百度在2009年就已經有了“點擊猴子”這個技術，用無埋點的方案分析一個頁面各個元素的點擊情況；在2011年，百度質量部也推出了一項內部服務，用以錄製安卓 App 的全部操作，並且進行回放，以便找出 App 崩潰的原因；而豌豆莢大約也在2013年左右，在自己的 App 內部，添加了對所有控件的操作情況的記錄。第三方數據分析服務GrowingIO 在2015年，也推出了類似於 Heap 的服務。
下圖是一個使用 Heap 的例子：
從界面上看，和可視化埋點很像。而從實際的實現上看，二者的區別就是可視化埋點先通過界面配置哪些控件的操作數據需要收集；“無埋點”則是先儘可能收集所有的控件的操作數據，然後再通過界面配置哪些數據需要在系統裏面進行分析。
“無埋點”相比可視化埋點的優點，一方面是解決了數據“回溯”的問題，例如，在某一天，突然想增加某個控件的點擊的分析，如果是可視化埋點方案，則只能從這一時刻向後收集數據，而如果是“無埋點”，則從部署 SDK 的時候數據就一直都在收集了；另一方面，“無埋點”方案也可以自動獲取很多啓發性的信息，例如，“無埋點”可以告訴使用者這個界面上每個控件分別被點擊的概率是多大，哪些控件值得做更進一步的分析等等。
當然，與可視化埋點一樣，“無埋點”依然沒有解決覆蓋的功能優先，不能靈活地自定義屬性，傳輸時效性和數據可靠性欠佳這幾個缺點。甚至由於所有的控件事件都全部蒐集，反而會給服務器和網絡傳輸帶來更大的負載。
2.4 各種不同採集方案的數據獲取能力的對比
在前面，我們已經介紹了代碼埋點、可視化埋點、“無埋點”三種前端埋點方案，而也強調了我們一直推薦在後端採集數據。因此，在這裏，我們覺得有必要比較一些可視化埋點、代碼埋點與後端採集數據三種方案在數據獲取能力上的差異，“無埋點”的數據獲取能力與可視化埋點基本相當，在這裏不再單獨羅列。
我們以京東的一個訂單提交頁面爲例來進行對比：
對於可視化埋點，在這個地方，基本只能採集到某時某刻某人提交了一個訂單；對於前端代碼埋點，則還能拿到訂單金額、商品名稱、用戶級別等在前端有記錄的一些信息；而如果在後端接入數據，則還能拿到商品庫存、商品成本、用戶風險級別等只在後端有記錄的一些信息。
由此可以看出，可視化埋點雖然使用和部署比較簡單，但是在數據獲取能力上相比代碼埋點還有一定的劣勢；而前端埋點天然的劣勢，則是拿不到在前端不保存的信息。這也是爲什麼，我們一直推崇後端數據採集數據這一方案的重要原因。
3. 我們的觀點
Sensors Analytics 一貫認爲，數據採集是構建數據平臺的核心要素。爲了方便使用者採集數據，我們完全開放了全功能的數據接入 API，基於 API 封裝了代碼埋點和可視化埋點兩種前端接入方案，並且提供了 PHP、Java、Python 等常見後端語言的 SDK 以方便在後端接入數據，同時，爲了滿足使用者導入已有文件或者格式化數據的需要，我們也封裝了 LogAgent、BatchImporter、FormatImporter 等各式導入工具。同時爲了降低使用者的安全方面的疑慮，並且回饋業內，我們的相關 SDK 的代碼也在github上全部開源，可視化埋點的具體實現的代碼會隨着1.3版本的發佈 release，敬請期待。
我們認爲，並不存在某種普遍完美的可以適應一切場景的數據接入方案，而是應該根據不同的產品，不同的分析需求，不同的系統架構，不同的使用場景，選擇最合適的一種接入方案。下面是一些典型的例子：
- 僅僅是分析UV、PV、點擊量等基本指標，可以選擇代碼埋點或者可視化埋點等前端埋點方案；
- 精細化分析核心轉化流程，則可能需要利用後端 SDK 或者 LogAgent 接入後端日誌；
- 活動/新功能快速上線迭代時的效果評估，則可以利用可視化埋點快速完成；
- 對客服服務質量的考覈，或者不 同快遞在不同省份運送不同品類產品的速度的比較，則需要使用後端 SDK 來對接第三方系統以便導入數據。
一個產品首次使用 Sensors Analytics 時，初期採用可視化埋點方案，快速完成部署，以便快速評估分析效果，做出快速決策；而對可視化埋點得到的數據，在分析解讀後，再針對性地逐步採用其它數據採集方案，獲取更詳盡、更全面的數據分析結果。
