淺談數據採集之無埋點與可視化埋點

04-29

作者：閆鵬（公眾號：yanpeng-info），轉載請註明作者及出處。

無埋點，即前端全自動埋點；可視化埋點，即前端半自動埋點。為了表述更達意、簡練，下面我會將「無埋點」稱作「全埋點」，將二者統稱為「自動埋點」。

註：二者都是前端埋點方案，初衷是替代前端人工埋點；而對於後端來說，「自動埋點」則無從談起。

全埋點和可視化埋點，初衷都是希望免開發。

這就很難實現給特定事件攜帶上特定屬性。

很多人會舉類似這樣的例子來說明這個問題：

「用戶在電商購買商品時，對應的套餐類型、數量、折扣等信息通過自動埋點無法採集，也就無法統計分析」

我覺得這個例子舉得不好，因為這個數據顯然是服務端（後端）能獲取到的，並且我認為前端埋點和後端埋點本就不可互相替代。

因此，應該讓「前端自動埋點」與「前端手動埋點」做對比，不要把後端埋點摻和進來混淆視聽。

我舉一個例子，比如工具類產品的使用，因為他們大多數的使用場景都是不需要與服務端進行交互的，那麼我們想要收集數據，必然要在前端埋點。

比如我在使用某衛士的清理功能，清理前它會讓我選擇清理哪幾類垃圾，選項有：垃圾文件、插件、註冊表、cookie、使用痕迹、低分軟體等。

正常埋點的話，記錄這個清理事件時，我會給該事件加一條LIST類型的屬性，用於記錄用戶選擇了哪幾類的垃圾進行清理。

目的是未來在做分析的時候，可以知道各選項的使用率高低，從而針對性地優化或閹割。

然而，自動埋點是記錄不到這條屬性的，因為程序不會知道頁面上的哪些元素能夠成為哪個事件的特有屬性，它最多只能把頁面上所有元素作為所有事件的屬性，但這樣成本太高。

不過，對於屬性的缺失，我認為並不是完全沒有解決之道，但對於全埋點來說，解決了屬性的缺失，就會面臨數據的過載。

而對於可視化埋點，我覺得讓使用者選完事件再選事件的特有屬性，倒是可以實現，值得嘗試。

有些數據只存在於前端或後端，自然只能用前端或後端埋點，我就不多說了。

那麼說說那些既存在於前端又存在於後端的數據，為什麼要優先後端採集：

1.前端採集的數據可能會因各種原因丟失：如網路不佳，採用批量上報策略時還可能會在上報之前被用戶清理掉數據，或用戶長時間不聯網造成本地存儲的數據溢出。而用戶與伺服器成功交互的數據則不會丟失，因為交互成功的同時，數據已經到服務端了，此時只需內網傳輸存儲一下就好了。所以後端採集會更全更准。

2.如果前後端都去採集這部分數據，則會造成數據冗餘，並且浪費流量、存儲和清理成本。

因此，我們需要在前端採集的數據應該只是後端數據的補充，是後端拿不到的那些數據，如請求交互失敗時的數據或不需與伺服器交互的數據等。

很多人總是想從海量的數據中挖掘價值，因此想儘可能多地保存數據，以防各種萬一。

但是海量數據同樣是個坑，拋開成本不說，數據太多是會干擾我們分析的。

就好比你把一個書店的書不作區分全部買了下來，反而會選擇困難不知道從何讀起，並且其中一定有很多書是你用不到的。

那麼如果你說你有方向，有計劃，有清單，為什麼不照著計劃一批一批地買書和看書呢。

所以，無論是最初的數據埋點，還是最終的挖掘分析，我認為一定要有方向，要有理論依據，要有取捨，否則很容易被數據的大海所淹沒。

並且，如果你的產品不是足夠的簡單暴利，那麼當你埋了過多的點（或使用了全埋點）時，這些數據所產生的傳輸、存儲、清洗成本可能是你所承受不起的。

當然，我認為隨著技術的發展，帶寬、存儲和計算成本在不久將來都不再是問題，但是雖說不久，至少也要5年。而且怕就怕數據量的增速比硬體的發展更快。

數據回溯不應倚仗全埋點。

一是成本太高，為了幾個可能存在的需要回溯的點，導致傳輸、存儲、清洗成本數量級的提升是否值得？

二是全埋點先天缺陷導致屬性太少，進而導致每個點的回溯價值低。

所以，我認為我們還是要有預判，可以多埋一些暫時不用但是可能有價值的點，而數據的回溯也盡量依靠我們預判的埋點。

優先後端埋點，前端埋點作為後端埋點的補充。

如果產品很簡單，沒什麼複雜的功能，也不需要精細的分析，那麼當然可以使用自動埋點，它比較方便。

如果產品並不簡單，那麼：

在產品量級還比較小的時候，可以嘗試全埋點，這個時候可以盡情地挖掘、回溯、熟悉數據。

當用戶量級起來之後，我們應該已經清楚該埋哪些點了，那麼人工埋點效果會更好，雖然成本也高一些。

而可視化埋點，就等到它可以讓產品運營人員方便地選擇各事件的特有屬性時再用吧。