數(shù)據(jù)收集原理分析

簡(jiǎn)單來(lái)說(shuō)，網(wǎng)站統(tǒng)計(jì)分析工具需要收集到用戶瀏覽目標(biāo)網(wǎng)站的行為（如打開(kāi)某網(wǎng)頁(yè)、點(diǎn)擊某按鈕、將商品加入購(gòu)物車等）及行為附加數(shù)據(jù)（如某下單行為產(chǎn)生的訂單金額等）。早期的網(wǎng)站統(tǒng)計(jì)往往只收集一種用戶行為：頁(yè)面的打開(kāi)。而后用戶在頁(yè)面中的行為均無(wú)法收集。這種收集策略能滿足基本的流量分析、來(lái)源分析、內(nèi)容分析及訪客屬性等常用分析視角，但是，隨著Ajax技術(shù)的廣泛使用及電子商務(wù)網(wǎng)站對(duì)于電子商務(wù)目標(biāo)的統(tǒng)計(jì)分析的需求越來(lái)越強(qiáng)烈，這種傳統(tǒng)的收集策略已經(jīng)顯得力不能及。

后來(lái)，Google在其產(chǎn)品谷歌分析中創(chuàng)新性的引入了可定制的數(shù)據(jù)收集腳本，用戶通過(guò)谷歌分析定義好的可擴(kuò)展接口，只需編寫少量的JavaScript代碼就可以實(shí)現(xiàn)自定義事件和自定義指標(biāo)的跟蹤和分析。目前百度統(tǒng)計(jì)、搜狗分析等產(chǎn)品均照搬了谷歌分析的模式。

其實(shí)說(shuō)起來(lái)兩種數(shù)據(jù)收集模式的基本原理和流程是一致的，只是后一種通過(guò)JavaScript收集到了更多的信息。下面看一下現(xiàn)在各種網(wǎng)站統(tǒng)計(jì)工具的數(shù)據(jù)收集基本原理。

1 第三方統(tǒng)計(jì)工具

第一種是直接使用友盟、百度統(tǒng)計(jì)這樣的第三方統(tǒng)計(jì)工具，通過(guò)嵌入 App SDK 或 JS SDK，然后就可以看統(tǒng)計(jì)數(shù)據(jù)了。這種方式的好處是簡(jiǎn)單、免費(fèi)，因此使用非常普及。對(duì)于看一些網(wǎng)站訪問(wèn)量、活躍用戶量這樣的宏觀數(shù)據(jù)需求，基本能夠滿足。但是，現(xiàn)在一些訂單相關(guān)的產(chǎn)品，越來(lái)越不滿足于看這些宏觀統(tǒng)計(jì)數(shù)據(jù)，還想做一些深度的用戶渠道轉(zhuǎn)化、留存、多維度交叉分析等操作，這個(gè)時(shí)候就會(huì)發(fā)現(xiàn)很難滿足。這里的問(wèn)題倒不是出在分析能力的薄弱，而是出現(xiàn)數(shù)據(jù)采集的不完整。

通過(guò)這種 SDK 只能夠采集到一些基本的用戶行為數(shù)據(jù)，比如設(shè)備的基本信息，用戶執(zhí)行的基本操作等。但是服務(wù)端、數(shù)據(jù)庫(kù)中的數(shù)據(jù)并沒(méi)有采集，對(duì)于一些提交操作，比如提交訂單對(duì)應(yīng)的成本價(jià)格、折扣情況等信息也沒(méi)有采集，這樣就導(dǎo)致后續(xù)的分析成了“巧婦難為無(wú)米之炊”。

通過(guò)客戶端 SDK 還有一個(gè)問(wèn)題就是經(jīng)常覺(jué)得統(tǒng)計(jì)的不準(zhǔn)，和自己的業(yè)務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)對(duì)不上，出現(xiàn)丟數(shù)據(jù)的情況。這是前端數(shù)據(jù)采集的先天缺陷，因?yàn)榫W(wǎng)絡(luò)異常，或者統(tǒng)計(jì)口徑不一致，都會(huì)導(dǎo)致數(shù)據(jù)對(duì)不上。

2 使用業(yè)務(wù)數(shù)據(jù)庫(kù)

第二種是直接使用業(yè)務(wù)數(shù)據(jù)庫(kù)做統(tǒng)計(jì)分析。一般的互聯(lián)網(wǎng)的產(chǎn)品，后端都是有業(yè)務(wù)數(shù)據(jù)庫(kù)，里面存儲(chǔ)了訂單、用戶注冊(cè)信息等數(shù)據(jù)，基于這些數(shù)據(jù)，一些常用的統(tǒng)計(jì)分析都能夠搞定了。這種方式天然的就能分析業(yè)務(wù)數(shù)據(jù)，并且是實(shí)時(shí)、準(zhǔn)確的。但不足之處有兩點(diǎn)：一是業(yè)務(wù)數(shù)據(jù)庫(kù)在設(shè)計(jì)之初就是為了滿足正常的業(yè)務(wù)運(yùn)轉(zhuǎn)，給機(jī)器讀寫訪問(wèn)的。為了提升性能，會(huì)進(jìn)行一些分表等操作。一個(gè)正常的業(yè)務(wù)都要有幾十張甚至上百?gòu)垟?shù)據(jù)表，這些表之間有復(fù)雜的依賴關(guān)系。這就導(dǎo)致業(yè)務(wù)分析人員很難理解表含義。即使硬著頭皮花了兩三個(gè)月時(shí)間搞懂了，隔天工程師又告訴你因?yàn)樾阅軉?wèn)題拆表了，你就崩潰了。二是業(yè)務(wù)數(shù)據(jù)表的設(shè)計(jì)在于高并發(fā)低延遲的小操作，而數(shù)據(jù)分析常常是針對(duì)大數(shù)據(jù)進(jìn)行批量操作，這樣就導(dǎo)致性能很差。

3 通過(guò) Web 日志

第三種是通過(guò) Web 日志進(jìn)行統(tǒng)計(jì)分析。這種方式相比基于業(yè)務(wù)數(shù)據(jù)庫(kù)的方式，完成了解耦，使業(yè)務(wù)運(yùn)行和統(tǒng)計(jì)分析兩個(gè)數(shù)據(jù)流相分離。這里的問(wèn)題是打印日志往往是工程師順便搞搞，完全是以 Debug 的需求來(lái)打印日志字段，但在業(yè)務(wù)分析上，往往發(fā)現(xiàn)缺斤少兩。并且從打印日志到處理日志到輸出統(tǒng)計(jì)結(jié)果，整個(gè)過(guò)程很容易出錯(cuò)，我在百度就花了幾年的時(shí)間解決這一問(wèn)題。

以上三種方式都多多少少解決了一部分?jǐn)?shù)據(jù)采集的問(wèn)題，但又都解決的不徹底。

存在問(wèn)題

一般數(shù)據(jù)采集有點(diǎn)很多，每次數(shù)據(jù)產(chǎn)品經(jīng)理提了數(shù)據(jù)采集的需求，工程師就會(huì)按照要求給做了，然后交給數(shù)據(jù)產(chǎn)品經(jīng)理去驗(yàn)證。數(shù)據(jù)產(chǎn)品經(jīng)理在試用的時(shí)候也感覺(jué)不到異常，可等上線之后，發(fā)現(xiàn)埋的不對(duì)，再進(jìn)行升級(jí)發(fā)版操作，整個(gè)效率就比較低了。一個(gè)公司發(fā)展到一定程度，沒(méi)有專人去負(fù)責(zé)埋點(diǎn)管理工作，數(shù)據(jù)采集完全沒(méi)有準(zhǔn)確性可言。還有產(chǎn)品上線之后，才發(fā)現(xiàn)數(shù)據(jù)采集的工作沒(méi)有做，也就是漏埋了。

于是數(shù)據(jù)相關(guān)的同學(xué)甚至管理者都在幻想，既然埋點(diǎn)這么容易出問(wèn)題，有沒(méi)有不埋點(diǎn)就可以解決所有問(wèn)題？這就像尋找可以祈求風(fēng)調(diào)雨順的神靈。百度曾經(jīng)做了一個(gè)產(chǎn)品，只要頁(yè)面上嵌入 SDK，就可以采集下來(lái)頁(yè)面上所有的點(diǎn)擊行為，然后就可以繪制出用戶點(diǎn)擊的熱力圖，這種方式對(duì)于一些探索式的調(diào)研還是比較有用的。后來(lái)國(guó)外的Heap Analytics，把這種方式更近一步，將 App 的操作盡量多的采集下來(lái)，然后通過(guò)界面配置的方式對(duì)關(guān)鍵行為進(jìn)行定義，這樣就可以不用工程師的配合就可以完成數(shù)據(jù)采集操作了，這是其中的一個(gè)優(yōu)點(diǎn)。這里要說(shuō)明的是，要使用這種方案，必須在產(chǎn)品里實(shí)現(xiàn)嵌入 SDK，等于做了一個(gè)統(tǒng)一的埋點(diǎn)，所以“無(wú)埋點(diǎn)”這種叫法本身就不嚴(yán)謹(jǐn)，這種方式更像是“全埋點(diǎn)”。

這種方式只能是進(jìn)行前端的數(shù)據(jù)采集，后端服務(wù)器和數(shù)據(jù)庫(kù)中的數(shù)據(jù)，依舊是無(wú)可奈何的。即使進(jìn)行前端的數(shù)據(jù)采集，也不能夠進(jìn)行細(xì)粒度的數(shù)據(jù)采集。比如對(duì)于提交訂單操作，訂單的運(yùn)費(fèi)、成本價(jià)格之類的維度信息，等于都丟失掉了，只剩下提交這么一個(gè)行為類型。

對(duì)于非技術(shù)人員，容易被這種方式的名稱和直接優(yōu)勢(shì)所吸引，但很快又會(huì)發(fā)現(xiàn)許多深度數(shù)據(jù)分析需求無(wú)法直接滿足，進(jìn)而有種被忽悠的感覺(jué)，會(huì)感到失望。原理的關(guān)鍵點(diǎn)：一是事先在產(chǎn)品上埋一個(gè) SDK，二是通過(guò)可視化的方式，生成配置信息，也就是事件名稱之類的定義，三是將采集的數(shù)據(jù)按照配置重命名，進(jìn)而做分析。

埋點(diǎn)和無(wú)埋點(diǎn)

用戶行為數(shù)據(jù)收集技術(shù)主要有兩種：埋點(diǎn)和無(wú)埋點(diǎn)

1 埋點(diǎn)

所謂埋點(diǎn)就是為了數(shù)據(jù)分析的需求在原本的復(fù)雜的代碼邏輯之上在加上N行獲取數(shù)據(jù)的代碼。比如如果想獲取某商品的點(diǎn)擊數(shù)量，就得在點(diǎn)擊事件的中搜集點(diǎn)擊的商品數(shù)據(jù)，發(fā)出包含商品名稱和點(diǎn)擊事件的數(shù)據(jù)（{productname,clicktime}）。

1.1 埋點(diǎn)的優(yōu)勢(shì)

1）埋點(diǎn)最大的優(yōu)勢(shì)就是數(shù)據(jù)都是手動(dòng)編碼產(chǎn)生的，靈活性比較大，可以更好得支持一些擴(kuò)展數(shù)據(jù)。

2）埋點(diǎn)由于是按照埋點(diǎn)邏輯進(jìn)行的預(yù)處理，所以對(duì)之后的分析友好，分析效果也比較好。

1.2 埋點(diǎn)的劣勢(shì)

1）埋點(diǎn)最重要的前提條件是必須十分清楚目標(biāo)，即需要收集什么樣的數(shù)據(jù)必須提前確定。所以埋點(diǎn)最容易出現(xiàn)的問(wèn)題就是漏埋，一般來(lái)說(shuō)在發(fā)布前一定要經(jīng)過(guò)謹(jǐn)慎的校驗(yàn)和測(cè)試，因?yàn)橐坏┌姹景l(fā)布出去而數(shù)據(jù)采集出了問(wèn)題。

2）在產(chǎn)品的迭代過(guò)程中，如果代碼再迭代的時(shí)候忽略了埋點(diǎn)邏輯的更改，從而導(dǎo)致后續(xù)的分析邏輯不準(zhǔn)，甚至導(dǎo)致產(chǎn)品bug。更甚于對(duì)于產(chǎn)品迭代比較快的場(chǎng)景，埋點(diǎn)就是一個(gè)定時(shí)炸彈。

2 無(wú)埋點(diǎn)

埋點(diǎn)技術(shù)和無(wú)埋點(diǎn)技術(shù)都需要在原有的業(yè)務(wù)代碼上進(jìn)行改動(dòng)。無(wú)埋點(diǎn)就是通過(guò)編程語(yǔ)言自身的特點(diǎn)來(lái)完成數(shù)據(jù)收集的自動(dòng)化過(guò)程。比如前臺(tái)無(wú)埋點(diǎn)其實(shí)就是通過(guò)監(jiān)聽(tīng)JS事件，把頁(yè)面上發(fā)生的所有事件都采集下來(lái)。后臺(tái)無(wú)埋點(diǎn)實(shí)現(xiàn)比較復(fù)雜，但是說(shuō)起來(lái)很簡(jiǎn)單，其實(shí)就是將網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行旁路反解析，前后端交互的數(shù)據(jù)肯定都會(huì)經(jīng)過(guò)網(wǎng)絡(luò)，所以網(wǎng)絡(luò)中應(yīng)該包含了絕大多數(shù)業(yè)務(wù)數(shù)據(jù)。

2.1 無(wú)埋點(diǎn)的優(yōu)勢(shì)

1) 相對(duì)于埋點(diǎn)方式帶來(lái)的收益就是正好就是埋點(diǎn)容易產(chǎn)生的問(wèn)題，由于采集的是全量數(shù)據(jù)，所以產(chǎn)品迭代過(guò)程中是不需要關(guān)注埋點(diǎn)邏輯的，也不會(huì)出現(xiàn)漏埋、誤埋等現(xiàn)象。

2）無(wú)埋點(diǎn)方式因?yàn)槭占氖侨繑?shù)據(jù)，可以大大減少運(yùn)營(yíng)和產(chǎn)品的試錯(cuò)成本，試錯(cuò)的可能性高了，可以帶來(lái)更多啟發(fā)性的信息。

3）最后一點(diǎn)，也是最清楚的一點(diǎn)，就是減少了因?yàn)槿藛T流動(dòng)帶來(lái)的溝通成本。

2.2 無(wú)埋點(diǎn)的缺陷

無(wú)埋點(diǎn)的缺陷，也是無(wú)埋點(diǎn)存在的一些質(zhì)疑點(diǎn)：

1）適用大部門，通用的場(chǎng)景，有少部分需要埋點(diǎn)的場(chǎng)景覆蓋不了。

2）無(wú)埋點(diǎn)采集全量數(shù)據(jù)，給數(shù)據(jù)傳輸和服務(wù)器增加壓力

根據(jù)前面關(guān)于埋點(diǎn)和無(wú)埋點(diǎn)的科普，我們都明白其實(shí)兩個(gè)方式都有其自身的優(yōu)勢(shì)和缺陷，知乎和其他技術(shù)博客上關(guān)于這兩個(gè)討論點(diǎn)的文章也有很多，有人在批埋點(diǎn)，有人在批無(wú)埋點(diǎn)。關(guān)于技術(shù)，我們還是理性看待吧，它們兩個(gè)不是你死我活的關(guān)系，通過(guò)我們調(diào)研的得到的情況是，目前沒(méi)有方案能夠完美解決無(wú)埋點(diǎn)問(wèn)題，但是我們致力于研究最大限度通過(guò)通用方式解決埋點(diǎn)問(wèn)題，盡量減少埋點(diǎn)代碼，埋點(diǎn)代碼越少，出錯(cuò)的可能性就越低。我們選擇使用前臺(tái)無(wú)埋點(diǎn)和后臺(tái)無(wú)埋點(diǎn)技術(shù)相結(jié)合的方式來(lái)獲取用戶數(shù)據(jù)。