說到埋點，的確是使用者最感興趣的話題之一，優雲Web產品在內測階段便收到了使用者的各種反饋，反覆問我無碼埋點是怎麼做的。在此我專門與大家聊聊埋點以及各種實現方案的利弊。

1、埋點的來歷

先說下埋點的來歷，其實在網際網路沒流行起來之前，埋點並不是用來分析使用者行為的，技術人員為了解決某些問題，就在程式碼裡面加入了些行為邏輯程式碼，如果使用者使用產品的過程中出了問題，就生成一些診斷性質的日誌拿來定位問題。

今天的網際網路已經走入千家萬戶，它突破了時間和空間的限制，基於網際網路出現了大量的商業模式。例如在BAT或一些規模稍大的網際網路公司，使用者資料是非常非常重要的資產，可以說資料是驅動業務的核心動力之一。原因是這些公司的業務都基於網際網路，而網際網路另外一端是一個個鮮活的使用者，他們是這些公司得以生存的基礎。同時，維繫一個大的基數的使用者群是非常不易的，如果沒有詳細的使用者資料幾乎不可能做到。因為，在網際網路上使用者拋棄你的代價低得可憐，關閉瀏覽器永遠不再使用你的產品。

而使用者資料怎麼來？除了一部分可以通過使用者主動註冊獲取外，另外一部分主要就是通過埋點獲取到了。因此埋點太重要了，由於網際網路上使用者體驗的重要性，需要收集資料來推進體驗。而對一些想在網際網路上開展業務的傳統企業而言，骨子裡面的基因是與網際網路企業是本質不同的，如果沒有意識到資料的重要性或者對資料不敏感，基本成功的可能性很小。

2、埋點的方式

埋點總的來說可以分為前端埋點和後端埋點，由於我們聚焦於使用者端層面，因此這裡我們主要談前端埋點，最常見的就是網頁和移動APP。

業界其實對埋點的方式已經有很多討論了，可分為：有碼埋點、視覺化埋點、無碼埋點三種。

A.有碼埋點

熟悉Google Analytics的同學都知道這個，除了PV統計外，GA還提供了追蹤訪客和網站的互動的功能，尤其是追蹤那些不產生新頁面的訪問行為（例如下載檔案），很多類似的產品都叫自定義事件功能，說的就是它。有碼埋點是目前業內最為熟悉且被廣泛採用的一種資料接入手段。

拿Google Analytics為例，可以利用_trackEvent()方法來進行事件追蹤。它的詳細引數如下：_trackEvent(category, action, opt_label, opt_value, opt_noninteraction)

·category（必需）：類別

·action（必需）：和使用者的行為對應，例如“下載”

·label：標籤，其他有關資訊

·value：提供數值型資料

·non-interaction：布林值。

如果你想在追蹤連結的，給需要追蹤的連結呼叫_trackEvent()方法並設定引數，加上呼叫的方法onclick即可。優點是可以對傳送的內容做到精準控制，對於上線後影響因素較小資料埋點它無疑是最適用的。缺點也很明顯，對頁面元素的埋點都需要手工新增程式碼，工作量無疑是巨大的，必須是技術人員參與才能完成，埋點地方過多也容易出錯。程式碼埋點的理想化在於事先把資料收集方案都想明白，而在實際情況下很難做到。

B.視覺化埋點

有碼埋點無疑是苦逼的，成本高而且容易出錯，如果想修改的話還得重新上線，尤其對APP開發者來說更是苦難，漫長的稽核期客戶端的更新成本都是不容忽略的。

所以為了解決這些問題，有些專業做資料分析的廠商提出來更加敏捷和聰明的方案，以Kissmetrics和Mixpanel為代表的資料分析服務商提供了視覺化埋點的方案，以Click to Track的方式代替了手工埋點，實現了埋點的配置與應用本身的分離，每次使用者開啟應用時，只需要把新的埋點配置重新下載到客戶端即可，而無須頻繁更新客戶端版本。拿Kissmetrics為例，

簡單說下實現方式吧。通常來說，Web應用或APP的頁面都有其結構，在集成了採集的sdk後，會自動獲取頁面中各個物件的層級關係，對Web來說就是DOM結構，對APP來說就是UIView、UIResponder等之間的關係。當使用者通過Click to

Track點選了某個元素時，系統會記錄元素的位置，自動把事件相關的配置（主要是時間名稱、屬性之類）儲存到後端，下次使用者訪問到頁面時將配置資訊實時部署到客戶端。

視覺化埋點是個巨大的進步，不懂程式碼的人也可以通過後臺配置統計錨點並實時下發到客戶端生效。直接避免手工修改程式碼，需要更新版本成本才能生效的笨拙方式。當然有利也有弊，視覺化埋點能夠覆蓋的功能有限的，目前並不是所有的控制元件操作都可以通過這種方案進行定製，Kissmetrics可以支援頁面上的元素作為自定義屬性，也支援js變數；此外，資料的可靠性也是個問題。

C.無碼埋點

無碼埋點最近在國內突然火了起來，某些廠商把無碼埋點技術作為噱頭大吹特吹，其實無碼埋點方案並不稀奇。在國外，Heap Analytics是“無碼埋點”方案的先行者。拿Heap為例，它提供了一個名叫Event Visualizer的工具，可以方便的對元素進行“標記”：

注意，我這裡說的是“標記”，而不是埋點。為啥呢？Heap是儘可能全量收集所有的元素的操作資料，然後再通過“標記”介面，把資料“拿”出來分析而已。

因此，儘管從介面上看，無埋點和視覺化埋點看起來很像。但兩者的本質是不同的，視覺化埋點是先配置再收集，而無埋點方案是儘可能自動化收集，需要的時候去拿。聰明的你肯定想到了，本質上“無埋點”給大家準備了後悔藥可以吃，如果某天突然想對某個頁面元素進行的分析，可以從歷史庫裡面直接拿數而無須等待。

我們上篇文章其實還說到了方案的不完美性，那就是無埋點方案固然能降低工作量，把很多工作交給雲端去做，但隨之而來的是抓取的資訊越多，也就意味著浪費的流量也越多，儲存和索引的成本也越高。

優雲Web體驗監控產品採用了無碼埋點與HeapAnalytics儘管在技術方面大家有相似性，但我們解決的問題域是不同的，採集的資料也較大差別（參考上一篇）。就使用者體驗監控而言，我們借鑑了無碼埋點技術來解決自動化指標聚合分析的需求，僅僅是產品整個環節的一部分。此外，由於我們要的是基於大資料的結論，把握大趨勢，資料有少許誤差又有什麼關係呢？

3、選擇適合自己的方案

不管你採用哪種埋點方案，我們的目的都是一致的——獲取我們需要的資料，從資料中發現規律和問題。

埋點之後，在上線初期產品團隊要幹什麼呢？對，關注各類收集到的資料，及時發現問題修復問題。

1.看使用者行為：首先看使用者關注點在什麼地方，關注什麼功能，看些什麼內容，典型的操作順序是怎麼樣的，另外關注哪些頁面或元素漏埋的（這種情況無埋點的優勢就出來了，有時我們會發現使用者關注的地方我們卻沒注意到，這時我們重新標記一下即可而無需重新上線）。

2.看應用質量：產品的效能是否有改善，達到預期的目標了嗎？前端的錯誤是偶發的還是有規律的？哪裡的使用者訪問比較慢？拉取效能和錯誤資料與之前版本做比較，拿資料證明應用質量是否提高。

3.看活躍使用者：找到釋出後一段時間內活躍的使用者群，分析其關鍵特徵，如哪裡的使用者活躍，男性還是女性等等。

很明顯，我們的資料對產品經理、開發測試人員、運維人員都是有非常重要的意義的，那麼我們該怎麼看資料呢？且看下回分解《如何看資料（乾貨總結）》，歡迎一起交流。

作者簡介：

王川林

•優雲軟體產品經理

•四年UI設計師、三年商務智慧產品、五年IT運維產品