文章出自：聽雲博客
大數據時代的到來意味着數據量的爆炸，也意味着收集數據的難度將大幅增加。為了將海量的數據收集起來，埋點技術應運而生。然而隨着大數據的發展和深入，用戶的要求越來越高，埋點技術開始變得力不從心。
近期，一些公司開始以“無埋點技術”為賣點，開始到處宣傳無埋點比埋點好，那么到底事實如何了？
埋點技術的時代
埋點技術通過在代碼的關鍵部位植入統計代碼，追蹤用戶的點擊行為;或者植入多段代碼，追蹤用戶的連續行為;並通過建立模型等方法，得出用戶操作行為;最終作為建立產品數據系統的一個環節准確的收集數據。
那么為什么通過埋代碼就可以准確的收集數據呢?
原因有三：
-
首先，每個操作的界面都有其獨立的標示性，具有無重復性，利用此可以統計訪問、訪客等;
-
其次，每個界面的事件針對當前頁面都是獨立的、唯一的，相互之間具有獨立性，對此進行埋代碼后可以統計事件行為;
-
最后，在任一界面都會有一個或者多個事件，每個事件會有不同的參數，每個事件參數都具有完整性，在埋點后通過建模可以得出准確的數據，最終目的是為未來產品優化方向做指導的。
這是筆者在以前公司時候，寫的前端代碼：
<%= link_to "全部雇員#{corp.staffers_count}", employees_corp_path(corp.pretty_abbrev, from: 'corps_detail_all_employee'), class: 'more', onclick: "addGaTrackEvent('corps_detail','goto_all_employee','corps_detail_right')" %>
像這樣addGaTrackEvent的onclick事件幾乎遍布整個項目，而且因為瀏覽器的兼容問題，有時候還不得不采用這種簡單粗暴的方式添加“埋點”
埋點技術的弊端
其實，從上面的代碼就看出了這種“埋點技術”的弊端
-
首先，IT人員在埋點的時候，必須先清楚要收集的是什么數據，這些數據用來做什么，在什么地方收集這些數據，而且往往會導致代碼的丑陋。
-
其次，一旦數據有問題，想要糾正則需要重新進行埋點，使得之前的工作變成無用功。
-
最后，埋點增加了測試的難度，需要考慮業務其外的東西。
所謂無埋點技術，並非完全不用埋點，而是不用在設置代碼前先行定義需要采集的事件或功能
大多對於可交互式的應用程序，例如Android應用，iOS應用，網站，Windows Phone應用，Windows的窗體程序、Java的窗體程序等等，其實在界面渲染時都有幾點共性：
-
圖形背后都有圖形樹，我們所看到的輸入框、文本框、按鈕等等其實都是view，而view的擺放其實也都是有對應的視圖方式，例如線性布局、網格布局、表格布局、相對、絕對等等，然后view加布局就組成了我們要看到的界面，比如最簡單的就是網站的DOM結構了，有層級關系，對於Android而言就是View視圖的層級關系了，調用系統級API基本上都能獲取這個樹結果。
-
窗體都有生命周期，比如Android的Activity的生命周期
-
對於我們可視的這些界面元素，當他們顯示出來、被點擊了、被選中了、被滑動等等操作的時候，系統也都會有相應的接口給開發者通知他們去處理，所以也就是對於View而言可以綁定或者委托或者是監聽他們的一些觸發事件，比如剛剛提到的加載、點擊、選中等操作。
講到這里，應該很清楚了，應用程序在呈現程序界面的時候，其實有一套生命周期的准則在里面，控制了從界面元素創造到響應用戶操作到銷毀，同時也有一個圖形樹的准則在里面，控制了這些界面元素的顯示層級和順序，最后在用戶交互（包括展現）各個界面元素的時候，會給開發者提供一系列的接口，讓開發者去處理這些行為。
所以原理清楚了，后續無埋點其實也就能想到怎么做了，現在市面上主流有兩種，一種是預先跟蹤所有的渲染信息，一種是滯后跟蹤的渲染信息。兩種做法不太一樣，后者要簡單一些，前者要重一些，但是也有一些辦法優化（不交互的元素肯定多於交互元素），各家也就都有自己的方法在里面。
無埋點技術的弊端：只看數據采集的方式，而不考慮數據的傳輸，存儲，分析，可視化反饋，都是耍流氓。
因為你根本沒辦法定義“所有的信息”。抓取的信息越多，也就意味着浪費的流量也越多，存儲和索引的成本也越高。
信息檢索有一個最關鍵的概念是 precision/recall。無埋點是盡可能地提高 recall，而這個成本一部分是終端客戶承受，另一部分是在 SaaS 服務的數據管線上增加壓力。對於 PC 端的應用，這可能不是問題。但是對於移動端的應用，這就意味着更多的移動數據成本和耗電，此外還有相關的隱私風險。