數(shù)據(jù)采集的方式根據(jù)采集數(shù)據(jù)端的不同，主要分為網(wǎng)頁數(shù)據(jù)采集、APP數(shù)據(jù)采集。網(wǎng)頁數(shù)據(jù)的采集主要是使用JS采集，常用的數(shù)據(jù)分析工具主要是Google Analytics，APP數(shù)據(jù)采集主要是通過埋點(diǎn)采集，主要有前端埋點(diǎn)和后端埋點(diǎn)之分，相應(yīng)的移動端數(shù)據(jù)分析廠商也很多。

?

常見的前端埋點(diǎn)技術(shù)有三類：

1.在某個控件操作發(fā)生時，通過預(yù)先寫好的代碼來觸發(fā)數(shù)據(jù)的代碼埋點(diǎn)

2.通過可視化界面，配置控件操作與事件發(fā)生關(guān)系的可視化埋點(diǎn)

3.先收集所有數(shù)據(jù)，再在后端篩選需要分析對象的“無埋點(diǎn)”。

1.代碼埋點(diǎn)

代碼埋點(diǎn)出現(xiàn)時間很早， Google Analytics 年代，就已經(jīng)出現(xiàn)了類似的方案。

目前，國內(nèi)的主要第三方數(shù)據(jù)分析服務(wù)商都提供了這一方案：

↘???????百度統(tǒng)計(jì)

↘???????友盟

↘???????TalkingData

Sensors Analytics 也提供了 iOS、Android、Web 等主流平臺的代碼埋點(diǎn)方案。

?

代碼埋點(diǎn)技術(shù)原理很簡單，在APP、界面初始化時，初始化第三方數(shù)據(jù)分析服務(wù)商的SDK，然后在某個事件發(fā)生時就調(diào)用SDK里面相應(yīng)的數(shù)據(jù)發(fā)送接口發(fā)送數(shù)據(jù)。

例如，我們想統(tǒng)計(jì)APP里面某個按鈕的點(diǎn)擊次數(shù)，則在APP某個按鈕被點(diǎn)擊時，可以在這個按鈕對應(yīng)的 OnClick 函數(shù)里面調(diào)用SDK提供的數(shù)據(jù)發(fā)送接口來發(fā)送數(shù)據(jù)。

?

代碼埋點(diǎn)的優(yōu)點(diǎn)是使用者可以非常精確地選擇什么時候發(fā)送數(shù)據(jù)，同時使用者可以比較方便地設(shè)置自定義屬性、自定義事件，傳遞比較豐富的數(shù)據(jù)到服務(wù)端。代碼埋點(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.可視化埋點(diǎn)

從前端埋點(diǎn)到可視化埋點(diǎn)是一種自然的演進(jìn)。代碼埋點(diǎn)代價大，每一個埋點(diǎn)都需要寫代碼，那么，參考軟件的常用思維，用可視化交互手段來代替寫代碼。

代碼埋點(diǎn)每次更新都需要等待APP的更新，因此，參考大部分游戲的做法，把核心代碼和配置、資源分開，在APP啟動的時候通過網(wǎng)絡(luò)更新配置和資源。

?

正是這樣做法演進(jìn)，以 Mixpanel 為首的數(shù)據(jù)分析服務(wù)商，相繼提供了可視化埋點(diǎn)的方案。國內(nèi)的 TalkingData、諸葛IO 等也都提供了類似的技術(shù)手段。

而且，Mixpanel 非常無私地開源了它們的iOS 和 Android 端的 SDK 的源代碼，大家在開發(fā)中可以參考它們的貢獻(xiàn)，并且貢獻(xiàn)了一些 bug 的提交。

?

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

?

下圖是iOS SDK 使用 Mixpanel 的 codeless 埋點(diǎn)功能：

使用起來非常簡單，點(diǎn)擊某個支持的控件類型的實(shí)例，然后在彈出的窗口中，設(shè)置點(diǎn)擊這個按鈕的發(fā)送事件。再讓 Deploy 按鈕，把這個配置下發(fā)下去。

這時，所有安裝有嵌入了 Mixpanel ?SDK 的APP ，都會在 APP 啟動時或者定時獲取相應(yīng)的配置，真實(shí)的用戶使用時，點(diǎn)擊按鈕，就發(fā)送對應(yīng)的事件到后端了。

?

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

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

?

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

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

?

?

首先，使用者在自己網(wǎng)頁內(nèi)引入 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)保存位置。

最后，用戶以普通模式訪問網(wǎng)頁時，SDK 就自動加載配置信息，在相應(yīng)的界面元素被點(diǎn)擊時，使用 Sensors Analytics 的數(shù)據(jù)發(fā)送接口來收集事件。

?

從上面的可視化埋點(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ù)可靠性問題。

3.“無埋點(diǎn)” ?

?“無埋點(diǎn)”方案出現(xiàn)的也較早，Heap在2013年就推出了“無埋點(diǎn)”技術(shù)方案。百度在2009年用無埋點(diǎn)的方案分析一個頁面各個元素的點(diǎn)擊情況；2011年，百度質(zhì)量部推出了一項(xiàng)內(nèi)部服務(wù)，錄制安卓 App 的全部操作，通過回放找出 App 崩潰的原因

?

下圖是Heap 的例子：

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

?

“無埋點(diǎn)”的優(yōu)點(diǎn)：

1.解決了數(shù)據(jù)“回溯”的問題

例如，某一天，突然想增加某個控件的點(diǎn)擊的分析，如果是可視化埋點(diǎn)方案，只能從這一時刻向后收集數(shù)據(jù)，“無埋點(diǎn)”，則從部署 SDK 的時候數(shù)據(jù)就一直都在收集了；

2.“無埋點(diǎn)”方案可以自動獲取很多啟發(fā)性的信息

如“無埋點(diǎn)”可以告訴使用者這個界面上每個控件分別被點(diǎn)擊的概率是多大，哪些控件值得做更進(jìn)一步的分析等等。

?

但與可視化埋點(diǎn)一樣，“無埋點(diǎn)”依然沒有解決覆蓋功能的范圍，靈活地自定義屬性，傳輸時效性和數(shù)據(jù)可靠性欠佳這幾個缺點(diǎn)。

甚至在所有的控件事件全部搜集時，反而給服務(wù)器和網(wǎng)絡(luò)傳輸帶來更大的負(fù)載。

?

4

前端采集與后端采集的對比

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

前端埋點(diǎn)獲取數(shù)據(jù)

用可視化埋點(diǎn)，在購物車頁，能采集到某時某刻某人提交了一個訂單；再使用前端代碼埋點(diǎn)，還能拿到訂單金額、商品名稱、用戶級別等在前端有記錄信息

?

后端埋點(diǎn)獲取數(shù)據(jù)

在后端接入數(shù)據(jù)，還能拿到商品庫存、商品成本、用戶風(fēng)險級別等只在后端有記錄的信息。

?

可見，可視化埋點(diǎn)使用、部署簡單，但數(shù)據(jù)獲取能力相比代碼埋點(diǎn)要弱；另外，前端埋點(diǎn)天然劣勢拿不到未在前端保存的信息。

因此，后端數(shù)據(jù)采集是用戶行為數(shù)據(jù)采集的另一個重要方案。但后端數(shù)據(jù)采集同樣存在其優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

↘???????實(shí)時收集，數(shù)據(jù)很準(zhǔn)確，不存在延時上報

↘???????當(dāng)要改變埋點(diǎn)時，只要改變，上報數(shù)據(jù)就會改變

↘???????能夠收集不在APP內(nèi)發(fā)生的行為，只要請求服務(wù)器就行，而客戶端只能收集在客戶端中的操作行為，如統(tǒng)計(jì)從其他APP引流的安裝量。

缺點(diǎn)：

↘???????不能收集不需要請求服務(wù)器的數(shù)據(jù)

↘???????用戶沒聯(lián)網(wǎng)的時候不能夠采集數(shù)據(jù)