在這篇文章里面，我們會對數(shù)據(jù)采集的一些基本概念進(jìn)行闡述，然后，會針對目前市面上新增的一些前端埋點(diǎn)技術(shù)，如可視化埋點(diǎn)與“無埋點(diǎn)”的技術(shù)細(xì)節(jié)做一個具體的介紹，并且闡述我們自己對于這些技術(shù)的理解和認(rèn)識。

1. 數(shù)據(jù)采集是核心問題

一個典型的數(shù)據(jù)平臺，對于數(shù)據(jù)的處理，是由如下的5個步驟組成的：

其中，我們認(rèn)為，第一個步驟，也即數(shù)據(jù)采集是最核心的問題。數(shù)據(jù)采集是否豐富，采集的數(shù)據(jù)是否準(zhǔn)確，采集是否及時，都直接影響整個數(shù)據(jù)平臺的應(yīng)用效果。

在我們手冊中闡述了使用 Sensors Analytics 時，在確定數(shù)據(jù)采集方案時應(yīng)該遵循的兩個基本原則：

優(yōu)先在后端收集數(shù)據(jù)；

屬性盡可能采集全面。

雖然我們之前已經(jīng)詳細(xì)描述過前端埋點(diǎn)的一些問題。例如，需要等待網(wǎng)絡(luò)情況良好才能發(fā)送數(shù)據(jù)，需要積攢一定的量才發(fā)送數(shù)據(jù)，需要在本地暫存而本地暫存空間有限等一系列在數(shù)據(jù)傳輸性和數(shù)據(jù)可靠性上的一些問題。

但是，前端埋點(diǎn)畢竟有一些后端采集數(shù)據(jù)所無法替代的地方，例如，分析前端界面設(shè)計是否合理，分析一些在與后端沒有交互的前端行為等，還是必須采用前端埋點(diǎn)方案的。前端埋點(diǎn)作為一個比較成熟并且被廣泛采用的數(shù)據(jù)接入手段，Sensors Analytics 也提供了一系列相應(yīng)的解決方案。因此，在這里，我們覺得有必要詳細(xì)介紹一下目前市面上主流的前端埋點(diǎn)方案的技術(shù)細(xì)節(jié)，并且結(jié)合我們的產(chǎn)品，來闡述我們對于這些埋點(diǎn)方案的一些看法。

2. 前端埋點(diǎn)技術(shù)介紹

目前常見的前端埋點(diǎn)技術(shù)，有三類：在某個控件操作發(fā)生時通過預(yù)先寫好的代碼來發(fā)數(shù)據(jù)的代碼埋點(diǎn)；通過可視化界面配置控件操作與事件發(fā)生關(guān)系的可視化埋點(diǎn)；先收集所有數(shù)據(jù)再在后端篩選需要分析的對象的“無埋點(diǎn)”。

下面，我們分別對這三種方案進(jìn)行介紹，然后再闡述我們的觀點(diǎn)。

2.1 代碼埋點(diǎn)

代碼埋點(diǎn)出現(xiàn)的時間很早了，在 Google Analytics 年代，就已經(jīng)出現(xiàn)了類似的方案了。目前，國內(nèi)的主要第三方數(shù)據(jù)分析服務(wù)商，如百度統(tǒng)計、友盟、TalkingData 等都提供了這一方案。Sensors Analytics 也一樣提供了 iOS、Android、Web 等主流平臺的代碼埋點(diǎn)方案。

它的技術(shù)原理也很簡單，在APP或者界面初始化的時候，初始化第三方數(shù)據(jù)分析服務(wù)商的SDK，然后在某個事件發(fā)生時就調(diào)用SDK里面相應(yīng)的數(shù)據(jù)發(fā)送接口發(fā)送數(shù)據(jù)。例如，我們想統(tǒng)計APP里面某個按鈕的點(diǎn)擊次數(shù)，則在APP的某個按鈕被點(diǎn)擊時，可以在這個按鈕對應(yīng)的 OnClick 函數(shù)里面調(diào)用SDK提供的數(shù)據(jù)發(fā)送接口來發(fā)送數(shù)據(jù)。

下面，我們看友盟提供的兩個例子。

第一個例子是在使用者的某個 Android APP 里面，統(tǒng)計某個由 Activity 構(gòu)成的頁面的訪問次數(shù)，下面是友盟官方給出的例子：

public void onResume() { super.onResume();MobclickAgent.onPageStart("SplashScreen"); //統(tǒng)計頁面(僅有Activity的應(yīng)用中SDK自動調(diào)用，不需要單獨(dú)寫。"SplashScreen"為頁面名稱，可自定義)MobclickAgent.onResume(this); //統(tǒng)計時長 }public void onPause() { super.onPause();MobclickAgent.onPageEnd("SplashScreen"); // （僅有Activity的應(yīng)用中SDK自動調(diào)用，不需要單獨(dú)寫）保證 onPageEnd 在onPause 之前調(diào)用,因?yàn)?onPause 中會保存信息。"SplashScreen"為頁面名稱，可自定義MobclickAgent.onPause(this); }

這個例子其實(shí)非常簡單，就是在 Activity 控件相應(yīng)的觸發(fā)器函數(shù)里面，調(diào)用友盟提供的接口統(tǒng)計數(shù)據(jù)即可。

第二個例子稍微復(fù)雜點(diǎn)，它不再是統(tǒng)計頁面訪問這樣一個默認(rèn)的事件，而是統(tǒng)計一個自定義事件。例如，一個電商APP，在用戶點(diǎn)擊“購買”按鈕時，想統(tǒng)計“購買”這個自定義事件的相應(yīng)信息，那么，可以使用下面的代碼：

HashMap<String,String> map = new HashMap<String,String>(); map.put("type","book"); map.put("quantity","3"); MobclickAgent.onEvent(mContext, "purchase", map);

必須說明的是，友盟歸根結(jié)底還是一個統(tǒng)計工具，并沒有提供完整的多維分析功能，姑且不算數(shù)據(jù)傳輸?shù)臅r效性以及對自定義屬性上的各種限制，僅僅是為了統(tǒng)計某個數(shù)值，友盟還要單獨(dú)區(qū)分出“計數(shù)事件”和“計算事件”，這一點(diǎn)上，就遠(yuǎn)遠(yuǎn)不如 Sensors Analytics 的靈活了。

從上面這兩個例子可以看出，代碼埋點(diǎn)的優(yōu)點(diǎn)是一方面使用者控制精準(zhǔn)，可以非常精確地選擇什么時候發(fā)送數(shù)據(jù)；同時使用者可以比較方便地設(shè)置自定義屬性、自定義事件，傳遞比較豐富的數(shù)據(jù)到服務(wù)端。

當(dāng)然，代碼埋點(diǎn)也有一些劣勢。首先，埋點(diǎn)代價比較大，每一個控件的埋點(diǎn)都需要添加相應(yīng)的代碼，不僅工作量大，而且限定了必須是技術(shù)人員才能完成；其次是更新的代價比較大，每一次更新埋點(diǎn)方案，都必須改代碼，然后通過各個應(yīng)用市場進(jìn)行分發(fā)，并且總會有相當(dāng)多數(shù)量的用戶不喜歡更新APP，這樣埋點(diǎn)代碼也就得不到更新了；最后，就是所有前端埋點(diǎn)方案都會面臨的數(shù)據(jù)傳輸時效性和可靠性的問題了，這個問題就只能通過在后端收集數(shù)據(jù)來解決了。

2.2 可視化埋點(diǎn)

從前端埋點(diǎn)到可視化埋點(diǎn)其實(shí)是一個非常順理成章的演進(jìn)。既然埋點(diǎn)代價大，每一個埋點(diǎn)都需要寫代碼，那么，就參考 Visual Studio 等一系列現(xiàn)代 IDE 的做法，用可視化交互手段來代替寫代碼即可；既然每次埋點(diǎn)更新都需要等待APP的更新，那么，就參考現(xiàn)在很多手游的做法，把核心代碼和配置、資源分開，在APP啟動的時候通過網(wǎng)絡(luò)更新配置和資源即可。

正是出于這種自然而然的做法，在國外，以?Mixpanel?為首的數(shù)據(jù)分析服務(wù)商，都相繼提供了可視化埋點(diǎn)的方案，Mixpanel將之稱作為 codeless。而國內(nèi)的 TalkingData、諸葛IO 等也都提供了類似的技術(shù)手段。 順帶一提，Sensors Analytics 在1.3版本的更新中，也已經(jīng)給使用者提供可視化埋點(diǎn)方案，以降低使用者的數(shù)據(jù)接入成本。

特別需要強(qiáng)調(diào)的是，Mixpanel 非常無私地開源了它們的iOS 和 Android 端的 SDK 的源代碼，我們在開發(fā)中也參考了它們的貢獻(xiàn)，并且也貢獻(xiàn)了一些 bug 的提交，非常感謝 Mixpanel 對整個領(lǐng)域的貢獻(xiàn)。

2.2.1 iOS 和 Android 平臺的可視化埋點(diǎn)

下圖是演示一個簡單的 iOS SDK 使用 Mixpanel 的 codeless 埋點(diǎn)功能：

從這個界面可以看出，使用起來還是非常簡單的，點(diǎn)擊某個支持的控件類型的實(shí)例，這個例子中是右上角的刷新按鈕，然后在彈出的窗口中，設(shè)置點(diǎn)擊這個按鈕是發(fā)送 “Refresh” 事件。然后點(diǎn)擊 Deploy 按鈕，把這個配置下發(fā)下去。那么，所有安裝有嵌入了 Mixpanel 的 SDK 的這個 APP ，則都會在 APP 啟動時或者定時獲取相應(yīng)的配置。以后，真實(shí)的用戶使用時，點(diǎn)擊這個按鈕，就會真正地發(fā)送 “Refresh” 事件到后端了。

下面我們以 iOS 端為例，進(jìn)一步闡述可視化埋點(diǎn)的實(shí)現(xiàn)細(xì)節(jié)。

在嵌入了 SDK 的 APP 開啟可視化埋點(diǎn)模式，與后端聯(lián)通時，SDK 會應(yīng)后端的要求，定期（例如每秒）做一次截圖，而 SDK 在為 App 截圖的同時，會從 keyWindow 對象開始進(jìn)行遍歷它的subviews()，得到當(dāng)前視圖下所有 UIView、UIResponder 對象的層級關(guān)系。對于屏幕上的任何一個UIView對象，如 Button、Textfield 等，它都有一條唯一的從 keyWindow 到它的路徑，這個路徑上每個節(jié)點(diǎn)，都由 ClassName、它是父節(jié)點(diǎn)的第幾個subview、.text()等屬性的值等標(biāo)識。相對于父節(jié)點(diǎn)的坐標(biāo)、長寬高等可視化方面的信息，是作為這個節(jié)點(diǎn)的屬性存在。

服務(wù)端根據(jù)截屏和可視化信息來重新進(jìn)行頁面渲染，并且根據(jù)控件的類型，來識別哪些控件是可以增加可埋點(diǎn)的，并且將之標(biāo)識出來。

當(dāng)使用者在后臺的截屏畫面上點(diǎn)擊了某個可埋點(diǎn)的控件時，后臺會要求使用者做一些事件關(guān)聯(lián)方面的配置，并且將配置信息進(jìn)行保存和部署。

SDK 在啟動或者例行輪詢時拿到這些配置信息，則會通過.addTarget:action:forControlEvents:接口，為每個關(guān)聯(lián)的控件添加的點(diǎn)擊或者編輯行為的監(jiān)聽，并且在回掉函數(shù)里面調(diào)用 Sensors Analytics SDK 的接口發(fā)送相應(yīng)事件的 track 信息。

整個 iOS 端的埋點(diǎn)的流程圖，如下圖所示：

Android 端的可視化埋點(diǎn)方案，與 iOS 端基本一致。

必須說明的是，上面描述的這一套可視化埋點(diǎn)的配置方案，其實(shí)也可以讓開發(fā)者在 iOS 或者 Android 的可視化 IDE 里面完成，但是考慮到可視化埋點(diǎn)主要面臨的是非技術(shù)人員，所以最終業(yè)內(nèi)都采用了 Mixpanel 的這種后臺截屏操作的方案。

2.2.2 Web 端的可視化埋點(diǎn)

Mixpanel 沒有提供 Web 端的可視化埋點(diǎn)方案，在這里，我們以 Sensors Analytics 的 Web 端可視化埋點(diǎn)方案來舉例：

使用者在自己的網(wǎng)頁引入 Sensors Analytics 的 JavaScript SDK 代碼后，從 Sensors Analytics 的后臺可視化埋點(diǎn)管理界面跳轉(zhuǎn)到使用者的網(wǎng)站界面時，會自動進(jìn)入到可視化埋點(diǎn)模式。在這個模式下，使用者在網(wǎng)頁上點(diǎn)擊任意 html元素時，Sensors Analytics 都會取到這個元素的url，層級關(guān)系等信息來描述這個 html 元素，當(dāng)使用者設(shè)置了這個元素和某個事件相關(guān)聯(lián)時，SDK 會把這些關(guān)聯(lián)信息和客戶生成配置信息，并且存放在 Sensors Analytics 提供的相應(yīng)保存位置。當(dāng)真正的用戶以普通模式訪問這個網(wǎng)頁時，SDK 會自動加載配置信息，從而在相應(yīng)的元素被點(diǎn)擊時，使用 Sensors Analytics 的數(shù)據(jù)發(fā)送接口來 track 事件。

從上面我們介紹的可視化埋點(diǎn)的方案可以看出，可視化埋點(diǎn)很好地解決了代碼埋點(diǎn)的埋點(diǎn)代價大和更新代價大兩個問題。但是，可視化埋點(diǎn)能夠覆蓋的功能有限，目前并不是所有的控件操作都可以通過這種方案進(jìn)行定制；同時，Mixpanel 為首的可視化埋點(diǎn)方案是不能自己設(shè)置屬性的，例如，一個界面上有一個文本框和一個按鈕，通過可視化埋點(diǎn)設(shè)置點(diǎn)擊按鈕為一個“提交”事件時，并不能將文本框的內(nèi)容作為事件的屬性進(jìn)行上傳的，因此，對于可視化埋點(diǎn)這種方案，在上傳事件時，就只能上傳 SDK 自動收集的設(shè)備、地域、網(wǎng)絡(luò)等默認(rèn)屬性，以及一些通過代碼設(shè)置的全局公共屬性了；最后，作為前端埋點(diǎn)的一種方案，可視化埋點(diǎn)也依然沒有解決傳輸時效性和數(shù)據(jù)可靠性的問題。

附帶一提，雖然 Mixpanel 比較早就推出了可視化埋點(diǎn)方案，但是卻一直沒有重點(diǎn)宣傳，并且也并不是它們的推薦數(shù)據(jù)接入方案，這種做法也是與 Mixpanel 一直強(qiáng)調(diào)的 "Actions speak louder than page views." 是一致的。

2.3 “無埋點(diǎn)”

與可視化埋點(diǎn)一樣，“無埋點(diǎn)”這個方案也出來的比較早，Heap作為一個第三方數(shù)據(jù)分析服務(wù)商，在2013年就已經(jīng)推出了“無埋點(diǎn)”這個技術(shù)方案。而如果不局限于第三方，百度在2009年就已經(jīng)有了“點(diǎn)擊猴子”這個技術(shù)，用無埋點(diǎn)的方案分析一個頁面各個元素的點(diǎn)擊情況；在2011年，百度質(zhì)量部也推出了一項(xiàng)內(nèi)部服務(wù)，用以錄制安卓 App 的全部操作，并且進(jìn)行回放，以便找出 App 崩潰的原因；而豌豆莢大約也在2013年左右，在自己的 App 內(nèi)部，添加了對所有控件的操作情況的記錄。第三方數(shù)據(jù)分析服務(wù)GrowingIO 在2015年，也推出了類似于 Heap 的服務(wù)。

下圖是一個使用 Heap 的例子：

從界面上看，和可視化埋點(diǎn)很像。而從實(shí)際的實(shí)現(xiàn)上看，二者的區(qū)別就是可視化埋點(diǎn)先通過界面配置哪些控件的操作數(shù)據(jù)需要收集；“無埋點(diǎn)”則是先盡可能收集所有的控件的操作數(shù)據(jù)，然后再通過界面配置哪些數(shù)據(jù)需要在系統(tǒng)里面進(jìn)行分析。

“無埋點(diǎn)”相比可視化埋點(diǎn)的優(yōu)點(diǎn)，一方面是解決了數(shù)據(jù)“回溯”的問題，例如，在某一天，突然想增加某個控件的點(diǎn)擊的分析，如果是可視化埋點(diǎn)方案，則只能從這一時刻向后收集數(shù)據(jù)，而如果是“無埋點(diǎn)”，則從部署 SDK 的時候數(shù)據(jù)就一直都在收集了；另一方面，“無埋點(diǎn)”方案也可以自動獲取很多啟發(fā)性的信息，例如，“無埋點(diǎn)”可以告訴使用者這個界面上每個控件分別被點(diǎn)擊的概率是多大，哪些控件值得做更進(jìn)一步的分析等等。

當(dāng)然，與可視化埋點(diǎn)一樣，“無埋點(diǎn)”依然沒有解決覆蓋的功能優(yōu)先，不能靈活地自定義屬性，傳輸時效性和數(shù)據(jù)可靠性欠佳這幾個缺點(diǎn)。甚至由于所有的控件事件都全部搜集，反而會給服務(wù)器和網(wǎng)絡(luò)傳輸帶來更大的負(fù)載。

2.4 各種不同采集方案的數(shù)據(jù)獲取能力的對比

在前面，我們已經(jīng)介紹了代碼埋點(diǎn)、可視化埋點(diǎn)、“無埋點(diǎn)”三種前端埋點(diǎn)方案，而也強(qiáng)調(diào)了我們一直推薦在后端采集數(shù)據(jù)。因此，在這里，我們覺得有必要比較一些可視化埋點(diǎn)、代碼埋點(diǎn)與后端采集數(shù)據(jù)三種方案在數(shù)據(jù)獲取能力上的差異，“無埋點(diǎn)”的數(shù)據(jù)獲取能力與可視化埋點(diǎn)基本相當(dāng)，在這里不再單獨(dú)羅列。

我們以京東的一個訂單提交頁面為例來進(jìn)行對比：

對于可視化埋點(diǎn)，在這個地方，基本只能采集到某時某刻某人提交了一個訂單；對于前端代碼埋點(diǎn)，則還能拿到訂單金額、商品名稱、用戶級別等在前端有記錄的一些信息；而如果在后端接入數(shù)據(jù)，則還能拿到商品庫存、商品成本、用戶風(fēng)險級別等只在后端有記錄的一些信息。

由此可以看出，可視化埋點(diǎn)雖然使用和部署比較簡單，但是在數(shù)據(jù)獲取能力上相比代碼埋點(diǎn)還有一定的劣勢；而前端埋點(diǎn)天然的劣勢，則是拿不到在前端不保存的信息。這也是為什么，我們一直推崇后端數(shù)據(jù)采集數(shù)據(jù)這一方案的重要原因。

3. 我們的觀點(diǎn)

Sensors Analytics 一貫認(rèn)為，數(shù)據(jù)采集是構(gòu)建數(shù)據(jù)平臺的核心要素。為了方便使用者采集數(shù)據(jù)，我們完全開放了全功能的數(shù)據(jù)接入 API，基于 API 封裝了代碼埋點(diǎn)和可視化埋點(diǎn)兩種前端接入方案，并且提供了 PHP、Java、Python 等常見后端語言的 SDK 以方便在后端接入數(shù)據(jù)，同時，為了滿足使用者導(dǎo)入已有文件或者格式化數(shù)據(jù)的需要，我們也封裝了 LogAgent、BatchImporter、FormatImporter 等各式導(dǎo)入工具。同時為了降低使用者的安全方面的疑慮，并且回饋業(yè)內(nèi)，我們的相關(guān) SDK 的代碼也在github上全部開源，可視化埋點(diǎn)的具體實(shí)現(xiàn)的代碼會隨著1.3版本的發(fā)布 release，敬請期待。

我們認(rèn)為，并不存在某種普遍完美的可以適應(yīng)一切場景的數(shù)據(jù)接入方案，而是應(yīng)該根據(jù)不同的產(chǎn)品，不同的分析需求，不同的系統(tǒng)架構(gòu)，不同的使用場景，選擇最合適的一種接入方案。下面是一些典型的例子：

僅僅是分析UV、PV、點(diǎn)擊量等基本指標(biāo)，可以選擇代碼埋點(diǎn)或者可視化埋點(diǎn)等前端埋點(diǎn)方案；

精細(xì)化分析核心轉(zhuǎn)化流程，則可能需要利用后端 SDK 或者 LogAgent 接入后端日志；

活動/新功能快速上線迭代時的效果評估，則可以利用可視化埋點(diǎn)快速完成；

對客服服務(wù)質(zhì)量的考核，或者不 同快遞在不同省份運(yùn)送不同品類產(chǎn)品的速度的比較，則需要使用后端 SDK 來對接第三方系統(tǒng)以便導(dǎo)入數(shù)據(jù)。

一個產(chǎn)品首次使用 Sensors Analytics 時，初期采用可視化埋點(diǎn)方案，快速完成部署，以便快速評估分析效果，做出快速決策；而對可視化埋點(diǎn)得到的數(shù)據(jù)，在分析解讀后，再針對性地逐步采用其它數(shù)據(jù)采集方案，獲取更詳盡、更全面的數(shù)據(jù)分析結(jié)果。

博文設(shè)置

總結(jié)

以上是生活随笔為你收集整理的一篇讲清：数据采集与埋点的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。