資訊專欄INFORMATION COLUMN
摘要：第二層境界框架式埋點框架式埋點也稱可視化埋點?？蚣苁铰顸c很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。
魯迅先生說：世界上本沒有埋點，需要數(shù)據(jù)的人多了，也就有了埋點。
埋點的誕生在最初的互聯(lián)網(wǎng)世界中,并沒有埋點的概念。大家并不關(guān)心流量從哪里來，用戶在網(wǎng)站上做了什么事，一切都是野蠻生長。
隨著業(yè)務(wù)的增長，訪問網(wǎng)站的人越來越多，用戶的需求越來越復(fù)雜，運營人員就需要一些關(guān)鍵的數(shù)據(jù)作為參考。
一般來說，互聯(lián)網(wǎng)公司到了 A 輪以后，都會有專門的數(shù)據(jù)團隊或者兼職數(shù)據(jù)人員，對公司的一些業(yè)務(wù)指標(biāo)負責(zé)。即使為了拿到這些基本的業(yè)務(wù)指標(biāo)，一般也要工程團隊去配合做一些數(shù)據(jù)采集工作。正所謂天下武功唯快不破，所有事情都要給產(chǎn)品迭代升級讓路，快的都沒有時間做數(shù)據(jù)采集了。
但是，沒有數(shù)據(jù)指標(biāo)的支撐，又怎么衡量這個功能升級是不是合理的呢？互聯(lián)網(wǎng)產(chǎn)品并不是功能越多就越好，產(chǎn)品是否經(jīng)得起用戶考驗，還是要基于數(shù)據(jù)說話的，然后學(xué)習(xí)新知識，用于下一輪的迭代。
于是，埋點誕生了！
第一層境界：代碼埋點最初的埋點是在代碼的關(guān)鍵部位植入N行代碼，追蹤用戶的行為,得到想要的數(shù)據(jù)。挖開產(chǎn)品本身,找到收集點.進行源源不斷的傳遞數(shù)據(jù)。
簡單的說,找節(jié)點,布代碼,收數(shù)據(jù)。
隨著業(yè)務(wù)的規(guī)模越來越大，運營人員發(fā)現(xiàn),要收集的數(shù)據(jù)越來越多，需要埋的點也越來越多。
這時候，代碼埋點的缺陷就暴露出來：
每次埋點部署比較慢，需要產(chǎn)品和開發(fā)反復(fù)溝通，如果埋點中出現(xiàn)問題，重新埋點的代價特別大。這兩點問題的存在將整個數(shù)據(jù)收集周期拖長到半月甚至一個月，收集成本很高但效率卻不高。如果算上大型測試，簡直不能忍。
于是有了第二層境界。
第二層境界： 框架式埋點框架式埋點也稱“可視化埋點”。
既然寫代碼代價大，每一個埋點都需要寫代碼，那么，我們可以用框架式交互手段來代替純手工寫代碼嘛。
固化相應(yīng)代碼的做為SDK,方便直接調(diào)用.這是一個非常大的進步。
框架式埋點很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。
因此，對于框架式埋點這種方案，在上傳事件時，就只能上傳 SDK 自動收集的設(shè)備、地域、網(wǎng)絡(luò)等默認屬性，以及一些通過代碼設(shè)置的全局公共屬性了；最后，作為前端埋點的一種方案，框架式埋點也依然沒有解決傳輸時效性和數(shù)據(jù)可靠性的問題。
由于互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)神一般的發(fā)展速度，互聯(lián)網(wǎng)公司的數(shù)據(jù)規(guī)模得到了極大的擴張，大數(shù)據(jù)時代的到來意味著數(shù)據(jù)量的爆炸，也意味著收集數(shù)據(jù)的難度將大幅增加。
簡單的封裝SDK還是有很多問題，所以我們在想，有沒有辦法更簡單一點。
第三層境界：無埋點框架式埋點能夠覆蓋的功能有限，關(guān)鍵在于不是所有的控件操作都可以通過這種方案進行定制。
框架式埋點先通過界面配置哪些控件的操作數(shù)據(jù)需要收集；“無埋點”則是先盡可能收集所有的控件的操作數(shù)據(jù)，然后再通過界面配置哪些數(shù)據(jù)需要在系統(tǒng)里面進行分析。所謂無埋點技術(shù)，并非完全不用埋點，只是不需要工程師不斷部署代碼. 客戶加載了一段定義好的JS或SDK代碼后，就可以在產(chǎn)品處半自動進行埋點，智能抓取關(guān)鍵用戶行為，快速收集數(shù)據(jù)。
“無埋點”相比框架式埋點的優(yōu)點，一方面是解決了數(shù)據(jù)“回溯”的問題，例如，在某一天，突然想增加某個控件的點擊的分析，如果是框架式埋點方案，則只能從這一時刻向后收集數(shù)據(jù)，而如果是“無埋點”，則從部署 SDK 的時候數(shù)據(jù)就一直都在收集了；另一方面，“無埋點”方案也可以自動獲取很多啟發(fā)性的信息，例如，“無埋點”可以告訴使用者這個界面上每個控件分別被點擊的概率是多大，哪些控件值得做更進一步的分析等等。
當(dāng)然，與框架式埋點一樣，“無埋點”依然有自己的問題，不能靈活地自定義屬性，傳輸時效性和數(shù)據(jù)可靠性欠佳這幾個缺點。甚至由于所有的控件事件都全部搜集，反而會給服務(wù)器和網(wǎng)絡(luò)傳輸帶來更大的負載。再加上神一般的安全性問題。好吧,我想靜靜。(我的數(shù)據(jù)全要向平臺傳輸)
從流量另辟蹊徑這三重境界，是一個慢慢演變的過程。
無埋點并不是只能運用在業(yè)務(wù)功能上，其實也可以運用在業(yè)務(wù)風(fēng)險控制領(lǐng)域。
不僅如此，我們在想，是不是可以找到另外一個數(shù)據(jù)更全,緯度最多,全量還原的數(shù)據(jù)采集方式呢?
其實，所有的信息交互都有一個根源：流量。
通過流量可以得到所有維度的數(shù)據(jù)，用戶的行為、轉(zhuǎn)化等等。同時，流量解決了數(shù)據(jù)“回溯”的問題：埋點之前的數(shù)據(jù)也可以查看。
事實上，豈安科技的業(yè)務(wù)風(fēng)險控制平臺 WARDEN 就是這樣實踐的。
反爬蟲
來源：www.bigsec.com
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/40671.html
摘要：異常監(jiān)控包括前端腳本執(zhí)行報錯等。本文針對整個前端監(jiān)控，設(shè)計適用的方案。前端埋點系統(tǒng)的前后端通信加密在上報數(shù)據(jù)的前后端通信中，需要和端協(xié)商加密機制，利用庫來實現(xiàn)的加密，已經(jīng)是一個廣泛被采用的加密算法。 在線上項目中,需要統(tǒng)計產(chǎn)品中用戶行為和使用情況，從而可以從用戶和產(chǎn)品的角度去了解用戶群體，從而升級和迭代產(chǎn)品，使其更加貼近用戶。用戶行為數(shù)據(jù)可以通過前端數(shù)據(jù)監(jiān)控的方式獲得，除此之外，前端還...
摘要：異常監(jiān)控包括前端腳本執(zhí)行報錯等。本文針對整個前端監(jiān)控，設(shè)計適用的方案。前端埋點系統(tǒng)的前后端通信加密在上報數(shù)據(jù)的前后端通信中，需要和端協(xié)商加密機制，利用庫來實現(xiàn)的加密，已經(jīng)是一個廣泛被采用的加密算法。 在線上項目中,需要統(tǒng)計產(chǎn)品中用戶行為和使用情況，從而可以從用戶和產(chǎn)品的角度去了解用戶群體，從而升級和迭代產(chǎn)品，使其更加貼近用戶。用戶行為數(shù)據(jù)可以通過前端數(shù)據(jù)監(jiān)控的方式獲得，除此之外，前端還...
閱讀 2391·2023-04-25 19:27
閱讀 3500·2021-11-24 09:39
閱讀 3917·2021-10-08 10:17
閱讀 3407·2019-08-30 13:48
閱讀 1939·2019-08-29 12:26
閱讀 3131·2019-08-28 17:52
閱讀 3545·2019-08-26 14:01
閱讀 3542·2019-08-26 12:19
