從“埋點技術已死?”開始說起

大資料時代的到來意味著資料量的爆炸，也意味著收集資料的難度將大幅增加。為了將海量的資料收集起來，埋點技術應運而生。然而隨著大資料的發展和深入，使用者的要求越來越高，埋點技術開始變得力不從心。

近期，一些公司開始以“無埋點技術”為賣點，開始到處宣傳無埋點比埋點好，那麼到底事實如何了？

埋點技術的時代

埋點技術通過在程式碼的關鍵部位植入統計程式碼，追蹤使用者的點選行為;或者植入多段程式碼，追蹤使用者的連續行為;並通過建立模型等方法，得出使用者操作行為;最終作為建立產品資料系統的一個環節準確的收集資料。

那麼為什麼通過埋程式碼就可以準確的收集資料呢?

原因有三：

• 首先，每個操作的介面都有其獨立的標示性，具有無重複性，利用此可以統計訪問、訪客等;

• 其次，每個介面的事件針對當前頁面都是獨立的、唯一的，相互之間具有獨立性，對此進行埋程式碼後可以統計事件行為;

• 最後，在任一介面都會有一個或者多個事件，每個事件會有不同的引數，每個事件引數都具有完整性，在埋點後通過建模可以得出準確的資料，最終目的是為未來產品優化方向做指導的。

這是筆者在以前公司時候，寫的前端程式碼：

<%= 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 端的應用，這可能不是問題。但是對於移動端的應用，這就意味著更多的移動資料成本和耗電，此外還有相關的隱私風險。