埋點的誕生

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

隨著業(yè)務的增長惠桃，訪問網站的人越來越多浦夷，用戶的需求越來越復雜，運營人員就需要一些關鍵的數據作為參考辜王。

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

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

于是纪隙，埋點誕生了!

第一層境界：代碼埋點

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

簡單的說,找節(jié)點,布代碼,收數據。

隨著業(yè)務的規(guī)模越來越大熙兔，運營人員發(fā)現,要收集的數據越來越多悲伶，需要埋的點也越來越多。

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

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

于是有了第二層境界蛾找。

第二層境界： 框架式埋點

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

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

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

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

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

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

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

第三層境界：無埋點

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

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

“無埋點”相比框架式埋點的優(yōu)點湃密，一方面是解決了數據“回溯”的問題特愿，例如，在某一天勾缭，突然想增加某個控件的點擊的分析，如果是框架式埋點方案目养，則只能從這一時刻向后收集數據俩由，而如果是“無埋點”，則從部署 SDK 的時候數據就一直都在收集了;另一方面癌蚁，“無埋點”方案也可以自動獲取很多啟發(fā)性的信息幻梯，例如，“無埋點”可以告訴使用者這個界面上每個控件分別被點擊的概率是多大努释，哪些控件值得做更進一步的分析等等碘梢。

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

從流量另辟蹊徑

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

無埋點并不是只能運用在業(yè)務功能上搅裙，其實也可以運用在業(yè)務風險控制領域皱卓。

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

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

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

本文由豈安科技 劉文韜投稿，未經允許融虽，禁止轉載享完！