魯迅先生說：世界上本沒有埋點，需要數據的人多了，也就有了埋點。

埋點的誕生

在最初的互聯網世界中,并沒有埋點的概念。大家并不關心流量從哪里來，用戶在網站上做了什么事，一切都是野蠻生長。

隨著業務的增長，訪問網站的人越來越多，用戶的需求越來越復雜，運營人員就需要一些關鍵的數據作為參考。

一般來說，互聯網公司到了 A 輪以后，都會有專門的數據團隊或者兼職數據人員，對公司的一些業務指標負責。即使為了拿到這些基本的業務指標，一般也要工程團隊去配合做一些數據采集工作。正所謂天下武功唯快不破，所有事情都要給產品迭代升級讓路，快的都沒有時間做數據采集了。

但是，沒有數據指標的支撐，又怎么衡量這個功能升級是不是合理的呢？互聯網產品并不是功能越多就越好，產品是否經得起用戶考驗，還是要基于數據說話的，然后學習新知識，用于下一輪的迭代。

于是，埋點誕生了！

第一層境界：代碼埋點

最初的埋點是在代碼的關鍵部位植入N行代碼，追蹤用戶的行為,得到想要的數據。挖開產品本身,找到收集點.進行源源不斷的傳遞數據。

簡單的說,找節點,布代碼,收數據。

隨著業務的規模越來越大，運營人員發現,要收集的數據越來越多，需要埋的點也越來越多。

這時候，代碼埋點的缺陷就暴露出來：

每次埋點部署比較慢，需要產品和開發反復溝通，如果埋點中出現問題，重新埋點的代價特別大。這兩點問題的存在將整個數據收集周期拖長到半月甚至一個月，收集成本很高但效率卻不高。如果算上大型測試，簡直不能忍。

于是有了第二層境界。

第二層境界： 框架式埋點

框架式埋點也稱“可視化埋點”。

既然寫代碼代價大，每一個埋點都需要寫代碼，那么，我們可以用框架式交互手段來代替純手工寫代碼嘛。

固化相應代碼的做為SDK,方便直接調用.這是一個非常大的進步。

框架式埋點很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。

因此，對于框架式埋點這種方案，在上傳事件時，就只能上傳 SDK 自動收集的設備、地域、網絡等默認屬性，以及一些通過代碼設置的全局公共屬性了；最后，作為前端埋點的一種方案，框架式埋點也依然沒有解決傳輸時效性和數據可靠性的問題。

由于互聯網和移動互聯網神一般的發展速度，互聯網公司的數據規模得到了極大的擴張，大數據時代的到來意味著數據量的爆炸，也意味著收集數據的難度將大幅增加。

簡單的封裝SDK還是有很多問題，所以我們在想，有沒有辦法更簡單一點。

第三層境界：無埋點

框架式埋點能夠覆蓋的功能有限，關鍵在于不是所有的控件操作都可以通過這種方案進行定制。

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

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

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

從流量另辟蹊徑

這三重境界，是一個慢慢演變的過程。

無埋點并不是只能運用在業務功能上，其實也可以運用在業務風險控制領域。

不僅如此，我們在想，是不是可以找到另外一個數據更全,緯度最多,全量還原的數據采集方式呢?

其實，所有的信息交互都有一個根源：流量。

通過流量可以得到所有維度的數據，用戶的行為、轉化等等。同時，流量解決了數據“回溯”的問題：埋點之前的數據也可以查看。

事實上，豈安科技的業務風險控制平臺 WARDEN 就是這樣實踐的。

反爬蟲

總結

以上是生活随笔為你收集整理的python埋点测试_埋点进化论：从埋点到无埋点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。