摘要：第二層境界框架式埋點(diǎn)框架式埋點(diǎn)也稱可視化埋點(diǎn)?？蚣苁铰顸c(diǎn)很好地解決了代碼埋點(diǎn)的埋點(diǎn)代價(jià)大和更新代價(jià)大兩個(gè)問(wèn)題。

魯迅先生說(shuō)：世界上本沒(méi)有埋點(diǎn)，需要數(shù)據(jù)的人多了，也就有了埋點(diǎn)。

在最初的互聯(lián)網(wǎng)世界中,并沒(méi)有埋點(diǎn)的概念。大家并不關(guān)心流量從哪里來(lái)，用戶在網(wǎng)站上做了什么事，一切都是野蠻生長(zhǎng)。

隨著業(yè)務(wù)的增長(zhǎng)，訪問(wèn)網(wǎng)站的人越來(lái)越多，用戶的需求越來(lái)越復(fù)雜，運(yùn)營(yíng)人員就需要一些關(guān)鍵的數(shù)據(jù)作為參考。

一般來(lái)說(shuō)，互聯(lián)網(wǎng)公司到了 A 輪以后，都會(huì)有專門(mén)的數(shù)據(jù)團(tuán)隊(duì)或者兼職數(shù)據(jù)人員，對(duì)公司的一些業(yè)務(wù)指標(biāo)負(fù)責(zé)。即使為了拿到這些基本的業(yè)務(wù)指標(biāo)，一般也要工程團(tuán)隊(duì)去配合做一些數(shù)據(jù)采集工作。正所謂天下武功唯快不破，所有事情都要給產(chǎn)品迭代升級(jí)讓路，快的都沒(méi)有時(shí)間做數(shù)據(jù)采集了。

但是，沒(méi)有數(shù)據(jù)指標(biāo)的支撐，又怎么衡量這個(gè)功能升級(jí)是不是合理的呢？互聯(lián)網(wǎng)產(chǎn)品并不是功能越多就越好，產(chǎn)品是否經(jīng)得起用戶考驗(yàn)，還是要基于數(shù)據(jù)說(shuō)話的，然后學(xué)習(xí)新知識(shí)，用于下一輪的迭代。

于是，埋點(diǎn)誕生了！

最初的埋點(diǎn)是在代碼的關(guān)鍵部位植入N行代碼，追蹤用戶的行為,得到想要的數(shù)據(jù)。挖開(kāi)產(chǎn)品本身,找到收集點(diǎn).進(jìn)行源源不斷的傳遞數(shù)據(jù)。

簡(jiǎn)單的說(shuō),找節(jié)點(diǎn),布代碼,收數(shù)據(jù)。

隨著業(yè)務(wù)的規(guī)模越來(lái)越大，運(yùn)營(yíng)人員發(fā)現(xiàn),要收集的數(shù)據(jù)越來(lái)越多，需要埋的點(diǎn)也越來(lái)越多。

這時(shí)候，代碼埋點(diǎn)的缺陷就暴露出來(lái)：

每次埋點(diǎn)部署比較慢，需要產(chǎn)品和開(kāi)發(fā)反復(fù)溝通，如果埋點(diǎn)中出現(xiàn)問(wèn)題，重新埋點(diǎn)的代價(jià)特別大。這兩點(diǎn)問(wèn)題的存在將整個(gè)數(shù)據(jù)收集周期拖長(zhǎng)到半月甚至一個(gè)月，收集成本很高但效率卻不高。如果算上大型測(cè)試，簡(jiǎn)直不能忍。

于是有了第二層境界。

框架式埋點(diǎn)也稱“可視化埋點(diǎn)”。

既然寫(xiě)代碼代價(jià)大，每一個(gè)埋點(diǎn)都需要寫(xiě)代碼，那么，我們可以用框架式交互手段來(lái)代替純手工寫(xiě)代碼嘛。

固化相應(yīng)代碼的做為SDK,方便直接調(diào)用.這是一個(gè)非常大的進(jìn)步。

框架式埋點(diǎn)很好地解決了代碼埋點(diǎn)的埋點(diǎn)代價(jià)大和更新代價(jià)大兩個(gè)問(wèn)題。

因此，對(duì)于框架式埋點(diǎn)這種方案，在上傳事件時(shí)，就只能上傳 SDK 自動(dòng)收集的設(shè)備、地域、網(wǎng)絡(luò)等默認(rèn)屬性，以及一些通過(guò)代碼設(shè)置的全局公共屬性了；最后，作為前端埋點(diǎn)的一種方案，框架式埋點(diǎn)也依然沒(méi)有解決傳輸時(shí)效性和數(shù)據(jù)可靠性的問(wèn)題。

由于互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)神一般的發(fā)展速度，互聯(lián)網(wǎng)公司的數(shù)據(jù)規(guī)模得到了極大的擴(kuò)張，大數(shù)據(jù)時(shí)代的到來(lái)意味著數(shù)據(jù)量的爆炸，也意味著收集數(shù)據(jù)的難度將大幅增加。

簡(jiǎn)單的封裝SDK還是有很多問(wèn)題，所以我們?cè)谙?，有沒(méi)有辦法更簡(jiǎn)單一點(diǎn)。

框架式埋點(diǎn)能夠覆蓋的功能有限，關(guān)鍵在于不是所有的控件操作都可以通過(guò)這種方案進(jìn)行定制。

框架式埋點(diǎn)先通過(guò)界面配置哪些控件的操作數(shù)據(jù)需要收集；“無(wú)埋點(diǎn)”則是先盡可能收集所有的控件的操作數(shù)據(jù)，然后再通過(guò)界面配置哪些數(shù)據(jù)需要在系統(tǒng)里面進(jìn)行分析。所謂無(wú)埋點(diǎn)技術(shù)，并非完全不用埋點(diǎn)，只是不需要工程師不斷部署代碼. 客戶加載了一段定義好的JS或SDK代碼后，就可以在產(chǎn)品處半自動(dòng)進(jìn)行埋點(diǎn)，智能抓取關(guān)鍵用戶行為，快速收集數(shù)據(jù)。

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

當(dāng)然，與框架式埋點(diǎn)一樣，“無(wú)埋點(diǎn)”依然有自己的問(wèn)題，不能靈活地自定義屬性，傳輸時(shí)效性和數(shù)據(jù)可靠性欠佳這幾個(gè)缺點(diǎn)。甚至由于所有的控件事件都全部搜集，反而會(huì)給服務(wù)器和網(wǎng)絡(luò)傳輸帶來(lái)更大的負(fù)載。再加上神一般的安全性問(wèn)題。好吧,我想靜靜。(我的數(shù)據(jù)全要向平臺(tái)傳輸)

這三重境界，是一個(gè)慢慢演變的過(guò)程。

無(wú)埋點(diǎn)并不是只能運(yùn)用在業(yè)務(wù)功能上，其實(shí)也可以運(yùn)用在業(yè)務(wù)風(fēng)險(xiǎn)控制領(lǐng)域。

不僅如此，我們?cè)谙?，是不是可以找到另外一個(gè)數(shù)據(jù)更全,緯度最多,全量還原的數(shù)據(jù)采集方式呢?

其實(shí)，所有的信息交互都有一個(gè)根源：流量。

通過(guò)流量可以得到所有維度的數(shù)據(jù)，用戶的行為、轉(zhuǎn)化等等。同時(shí)，流量解決了數(shù)據(jù)“回溯”的問(wèn)題：埋點(diǎn)之前的數(shù)據(jù)也可以查看。

事實(shí)上，豈安科技的業(yè)務(wù)風(fēng)險(xiǎn)控制平臺(tái) WARDEN 就是這樣實(shí)踐的。

反爬蟲(chóng)
來(lái)源：www.bigsec.com