大數(shù)據(jù)時(shí)代的到來(lái)意味著數(shù)據(jù)量的爆炸，也意味著收集數(shù)據(jù)的難度將大幅增加。為了將海量的數(shù)據(jù)收集起來(lái)，埋點(diǎn)技術(shù)應(yīng)運(yùn)而生。然而隨著大數(shù)據(jù)的發(fā)展和深入，用戶(hù)的要求越來(lái)越高，埋點(diǎn)技術(shù)開(kāi)始變得力不從心。

近期，一些公司開(kāi)始以“無(wú)埋點(diǎn)技術(shù)”為賣(mài)點(diǎn)，開(kāi)始到處宣傳無(wú)埋點(diǎn)比埋點(diǎn)好，那么到底事實(shí)如何了？

埋點(diǎn)技術(shù)的時(shí)代

埋點(diǎn)技術(shù)通過(guò)在代碼的關(guān)鍵部位植入統(tǒng)計(jì)代碼，追蹤用戶(hù)的點(diǎn)擊行為;或者植入多段代碼，追蹤用戶(hù)的連續(xù)行為;并通過(guò)建立模型等方法，得出用戶(hù)操作行為;最終作為建立產(chǎn)品數(shù)據(jù)系統(tǒng)的一個(gè)環(huán)節(jié)準(zhǔn)確的收集數(shù)據(jù)。

那么為什么通過(guò)埋代碼就可以準(zhǔn)確的收集數(shù)據(jù)呢?

原因有三：

• 首先，每個(gè)操作的界面都有其獨(dú)立的標(biāo)示性，具有無(wú)重復(fù)性，利用此可以統(tǒng)計(jì)訪問(wèn)、訪客等;

• 其次，每個(gè)界面的事件針對(duì)當(dāng)前頁(yè)面都是獨(dú)立的、唯一的，相互之間具有獨(dú)立性，對(duì)此進(jìn)行埋代碼后可以統(tǒng)計(jì)事件行為;

• 最后，在任一界面都會(huì)有一個(gè)或者多個(gè)事件，每個(gè)事件會(huì)有不同的參數(shù)，每個(gè)事件參數(shù)都具有完整性，在埋點(diǎn)后通過(guò)建模可以得出準(zhǔn)確的數(shù)據(jù)，最終目的是為未來(lái)產(chǎn)品優(yōu)化方向做指導(dǎo)的。

這是筆者在以前公司時(shí)候，寫(xiě)的前端代碼：

<%= 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事件幾乎遍布整個(gè)項(xiàng)目，而且因?yàn)闉g覽器的兼容問(wèn)題，有時(shí)候還不得不采用這種簡(jiǎn)單粗暴的方式添加“埋點(diǎn)”

埋點(diǎn)技術(shù)的弊端?

其實(shí)，從上面的代碼就看出了這種“埋點(diǎn)技術(shù)”的弊端，

• 首先，IT人員在埋點(diǎn)的時(shí)候，必須先清楚要收集的是什么數(shù)據(jù)，這些數(shù)據(jù)用來(lái)做什么，在什么地方收集這些數(shù)據(jù)，而且往往會(huì)導(dǎo)致代碼的丑陋。

• 其次，一旦數(shù)據(jù)有問(wèn)題，想要糾正則需要重新進(jìn)行埋點(diǎn)，使得之前的工作變成無(wú)用功。

• 最后，埋點(diǎn)增加了測(cè)試的難度，需要考慮業(yè)務(wù)其外的東西。

所謂無(wú)埋點(diǎn)技術(shù)，并非完全不用埋點(diǎn)，而是不用在設(shè)置代碼前先行定義需要采集的事件或功能

大多對(duì)于可交互式的應(yīng)用程序，例如Android應(yīng)用，iOS應(yīng)用，網(wǎng)站，Windows Phone應(yīng)用，Windows的窗體程序、Java的窗體程序等等，其實(shí)在界面渲染時(shí)都有幾點(diǎn)共性：

• 圖形背后都有圖形樹(shù)，我們所看到的輸入框、文本框、按鈕等等其實(shí)都是view，而view的擺放其實(shí)也都是有對(duì)應(yīng)的視圖方式，例如線(xiàn)性布局、網(wǎng)格布局、表格布局、相對(duì)、絕對(duì)等等，然后view加布局就組成了我們要看到的界面，比如最簡(jiǎn)單的就是網(wǎng)站的DOM結(jié)構(gòu)了，有層級(jí)關(guān)系，對(duì)于Android而言就是View視圖的層級(jí)關(guān)系了，調(diào)用系統(tǒng)級(jí)API基本上都能獲取這個(gè)樹(shù)結(jié)果。

• 窗體都有生命周期，比如Android的Activity的生命周期
  

• 對(duì)于我們可視的這些界面元素，當(dāng)他們顯示出來(lái)、被點(diǎn)擊了、被選中了、被滑動(dòng)等等操作的時(shí)候，系統(tǒng)也都會(huì)有相應(yīng)的接口給開(kāi)發(fā)者通知他們?nèi)ヌ幚?#xff0c;所以也就是對(duì)于View而言可以綁定或者委托或者是監(jiān)聽(tīng)他們的一些觸發(fā)事件，比如剛剛提到的加載、點(diǎn)擊、選中等操作。

講到這里，應(yīng)該很清楚了，應(yīng)用程序在呈現(xiàn)程序界面的時(shí)候，其實(shí)有一套生命周期的準(zhǔn)則在里面，控制了從界面元素創(chuàng)造到響應(yīng)用戶(hù)操作到銷(xiāo)毀，同時(shí)也有一個(gè)圖形樹(shù)的準(zhǔn)則在里面，控制了這些界面元素的顯示層級(jí)和順序，最后在用戶(hù)交互（包括展現(xiàn)）各個(gè)界面元素的時(shí)候，會(huì)給開(kāi)發(fā)者提供一系列的接口，讓開(kāi)發(fā)者去處理這些行為。

所以原理清楚了，后續(xù)無(wú)埋點(diǎn)其實(shí)也就能想到怎么做了，現(xiàn)在市面上主流有兩種，一種是預(yù)先跟蹤所有的渲染信息，一種是滯后跟蹤的渲染信息。兩種做法不太一樣，后者要簡(jiǎn)單一些，前者要重一些，但是也有一些辦法優(yōu)化（不交互的元素肯定多于交互元素），各家也就都有自己的方法在里面。

無(wú)埋點(diǎn)技術(shù)的弊端：只看數(shù)據(jù)采集的方式，而不考慮數(shù)據(jù)的傳輸，存儲(chǔ)，分析，可視化反饋，都是耍流氓。

因?yàn)槟愀緵](méi)辦法定義“所有的信息”。抓取的信息越多，也就意味著浪費(fèi)的流量也越多，存儲(chǔ)和索引的成本也越高。

信息檢索有一個(gè)最關(guān)鍵的概念是 precision/recall。無(wú)埋點(diǎn)是盡可能地提高 recall，而這個(gè)成本一部分是終端客戶(hù)承受，另一部分是在 SaaS 服務(wù)的數(shù)據(jù)管線(xiàn)上增加壓力。對(duì)于 PC 端的應(yīng)用，這可能不是問(wèn)題。但是對(duì)于移動(dòng)端的應(yīng)用，這就意味著更多的移動(dòng)數(shù)據(jù)成本和耗電，此外還有相關(guān)的隱私風(fēng)險(xiǎn)。

總結(jié)

以上是生活随笔為你收集整理的从“埋点技术已死?”开始说起的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。