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

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

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

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

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

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

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

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

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

2.1 代碼埋點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

2.2 可視化埋點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

從上面我們介紹的可視化埋點(diǎn)的方案可以看出，可視化埋點(diǎn)很好地解決了代碼埋點(diǎn)的埋點(diǎn)代價(jià)大和更新代價(jià)大兩個(gè)問題。但是，可視化埋點(diǎn)能夠覆蓋的功能有限，目前并不是所有的控件操作都可以通過這種方案進(jìn)行定制；同時(shí)，Mixpanel 為首的可視化埋點(diǎn)方案是不能自己設(shè)置屬性的，例如，一個(gè)界面上有一個(gè)文本框和一個(gè)按鈕，通過可視化埋點(diǎn)設(shè)置點(diǎn)擊按鈕為一個(gè)“提交”事件時(shí)，并不能將文本框的內(nèi)容作為事件的屬性進(jìn)行上傳的，因此，對(duì)于可視化埋點(diǎn)這種方案，在上傳事件時(shí)，就只能上傳 SDK 自動(dòng)收集的設(shè)備、地域、網(wǎng)絡(luò)等默認(rèn)屬性，以及一些通過代碼設(shè)置的全局公共屬性了；最后，作為前端埋點(diǎn)的一種方案，可視化埋點(diǎn)也依然沒有解決傳輸時(shí)效性和數(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)”這個(gè)方案也出來的比較早，Heap作為一個(gè)第三方數(shù)據(jù)分析服務(wù)商，在2013年就已經(jīng)推出了“無埋點(diǎn)”這個(gè)技術(shù)方案。而如果不局限于第三方，百度在2009年就已經(jīng)有了“點(diǎn)擊猴子”這個(gè)技術(shù)，用無埋點(diǎn)的方案分析一個(gè)頁面各個(gè)元素的點(diǎn)擊情況；在2011年，百度質(zhì)量部也推出了一項(xiàng)內(nèi)部服務(wù)，用以錄制安卓 App 的全部操作，并且進(jìn)行回放，以便找出 App 崩潰的原因；而豌豆莢大約也在2013年左右，在自己的 App 內(nèi)部，添加了對(duì)所有控件的操作情況的記錄。第三方數(shù)據(jù)分析服務(wù)GrowingIO 在2015年，也推出了類似于 Heap 的服務(wù)。

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

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

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

在前面，我們已經(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ú)羅列。

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

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

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

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

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

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

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

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

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

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

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

博文設(shè)置

總結(jié)

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

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