埋點進化論：從埋點到無埋點
魯迅先生說：世界上本沒有埋點，需要數(shù)據(jù)的人多了，也就有了埋點。
在最初的互聯(lián)網(wǎng)世界中,并沒有埋點的概念。大家并不關心流量從哪里來，用戶在網(wǎng)站上做了什么事，一切都是野蠻生長。
隨著業(yè)務的增長，訪問網(wǎng)站的人越來越多，用戶的需求越來越復雜，運營人員就需要一些關鍵的數(shù)據(jù)作為參考。
一般來說，互聯(lián)網(wǎng)公司到了 A 輪以后，都會有專門的數(shù)據(jù)團隊或者兼職數(shù)據(jù)人員，對公司的一些業(yè)務指標負責。即使為了拿到這些基本的業(yè)務指標，一般也要工程團隊去配合做一些數(shù)據(jù)采集工作。正所謂天下武功唯快不破，所有事情都要給產(chǎn)品迭代升級讓路，快的都沒有時間做數(shù)據(jù)采集了。
但是，沒有數(shù)據(jù)指標的支撐，又怎么衡量這個功能升級是不是合理的呢？互聯(lián)網(wǎng)產(chǎn)品并不是功能越多就越好，產(chǎn)品是否經(jīng)得起用戶考驗，還是要基于數(shù)據(jù)說話的，然后學習新知識，用于下一輪的迭代。
于是，埋點誕生了！
第一層境界：代碼埋點
最初的埋點是在代碼的關鍵部位植入N行代碼，追蹤用戶的行為,得到想要的數(shù)據(jù)。挖開產(chǎn)品本身,找到收集點.進行源源不斷的傳遞數(shù)據(jù)。
簡單的說,找節(jié)點,布代碼,收數(shù)據(jù)。
隨著業(yè)務的規(guī)模越來越大，運營人員發(fā)現(xiàn),要收集的數(shù)據(jù)越來越多，需要埋的點也越來越多。
這時候，代碼埋點的缺陷就暴露出來：
每次埋點部署比較慢，需要產(chǎn)品和開發(fā)反復溝通，如果埋點中出現(xiàn)問題，重新埋點的代價特別大。這兩點問題的存在將整個數(shù)據(jù)收集周期拖長到半月甚至一個月，收集成本很高但效率卻不高。如果算上大型測試，簡直不能忍。
于是有了第二層境界。
第二層境界： 框架式埋點
框架式埋點也稱“可視化埋點”。
既然寫代碼代價大，每一個埋點都需要寫代碼，那么，我們可以用框架式交互手段來代替純手工寫代碼嘛。
固化相應代碼的做為SDK,方便直接調用.這是一個非常大的進步。
框架式埋點很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。
因此，對于框架式埋點這種方案，在上傳事件時，就只能上傳 SDK 自動收集的設備、地域、網(wǎng)絡等默認屬性，以及一些通過代碼設置的全局公共屬性了；最后，作為前端埋點的一種方案，框架式埋點也依然沒有解決傳輸時效性和數(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還是有很多問題，所以我們在想，有沒有辦法更簡單一點。
第三層境界：無埋點
框架式埋點能夠覆蓋的功能有限，關鍵在于不是所有的控件操作都可以通過這種方案進行定制。
框架式埋點先通過界面配置哪些控件的操作數(shù)據(jù)需要收集；
“無埋點”則是先盡可能收集所有的控件的操作數(shù)據(jù)，然后再通過界面配置哪些數(shù)據(jù)需要在系統(tǒng)里面進行分析。
所謂無埋點技術，并非完全不用埋點，只是不需要工程師不斷部署代碼?？蛻艏虞d了一段定義好的JS或SDK代碼后，就可以在產(chǎn)品處半自動進行埋點，智能抓取關鍵用戶行為，快速收集數(shù)據(jù)。
“無埋點”相比框架式埋點的優(yōu)點：
一方面是解決了數(shù)據(jù)“回溯”的問題，例如，在某一天，突然想增加某個控件的點擊的分析，如果是框架式埋點方案，則只能從這一時刻向后收集數(shù)據(jù)，而如果是“無埋點”，則從部署 SDK 的時候數(shù)據(jù)就一直都在收集了；
另一方面，“無埋點”方案也可以自動獲取很多啟發(fā)性的信息，例如，“無埋點”可以告訴使用者這個界面上每個控件分別被點擊的概率是多大，哪些控件值得做更進一步的分析等等。
當然，與框架式埋點一樣，“無埋點”依然有自己的問題，不能靈活地自定義屬性，傳輸時效性和數(shù)據(jù)可靠性欠佳這幾個缺點。甚至由于所有的控件事件都全部搜集，反而會給服務器和網(wǎng)絡傳輸帶來更大的負載。再加上神一般的安全性問題。好吧,我想靜靜。(我的數(shù)據(jù)全要向平臺傳輸)
從流量另辟蹊徑
這三重境界，是一個慢慢演變的過程。
無埋點并不是只能運用在業(yè)務功能上，其實也可以運用在業(yè)務風險控制領域。不僅如此，我們在想，是不是可以找到另外一個數(shù)據(jù)更全，緯度最多，全量還原的數(shù)據(jù)采集方式呢？
其實，所有的信息交互都有一個根源：流量。
網(wǎng)絡流量是最基本的業(yè)務信息。用戶的每個動作都包含了一次請求和響應。網(wǎng)絡流量中的信息鏈代表了每個用戶在應用中的訪問軌跡。而其中細節(jié)可明確展示出用戶的每個動作類型
通過流量采集發(fā)到本機的http/UDP網(wǎng)絡流量,對流量進行重組，重組為http請求或其他標準日志格式，同時可以將滿足特定特征的http日志進行進一步加工，解析為業(yè)務行為的標準信息。
如下一個簡單的請求所示：
聰明如你，是否明白了這包含了你想要提取的什么信息嗎？
展開想像。是不是最完整的信息都在流量里出現(xiàn)過？
所以，通過流量可以得到所有維度的數(shù)據(jù)，用戶的行為、轉化等等。流量同樣也解決了數(shù)據(jù)“回溯”的問題：只要有流量的紀錄，就可以解析信息，還可以完整保存所有相關節(jié)點的前后來往信息進行多緯度的分析。
筆者認為，相對與前面提到的幾種埋點方案，“流量”將不再需要程序員進行代碼的更新，這才是真正的無埋點技術。
End
來源：知乎
想加入iDATA數(shù)據(jù)分析社群的小伙伴 添加微信：lovedata19 備注「社群」即可
