客戶端埋點一般分為訪問級、頁面級、頁內行為級。用戶訪問一個網站或啟動一個移動應用時幾乎所有的廠商都會自動採集上報用戶的訪問；當用戶訪問不同頁面時，有一部分廠商就會選擇不默認自動採集，而將其作為一個選項交給用戶；而對於用戶在某一個頁面內詳細的操作行為，只有極少數廠商支持自動採集上報。實現了後兩種自動採集的廠商，通常會說自己是全埋點。但頁內行為級的採集也還可以進一步探討其採集的範圍。最常見的就是自動採集可交互元素和自動採集所有元素的差別。可交互元素包含：鏈接、表單項（如按鈕、輸入框等）、HTML 的對象級元素等。不可交互元素就太多了，絕大多數的頁面元素都屬於此類。由於實際上網頁和移動應用中的大家可以看得到的界面很多都並不是標準元素，所以實際上界面上很多看似可交互的元素也都是無法自動採集上報的。這一點不可不謂之遺憾。

不過我們還是來看看優點。

首先，全埋點確實會自動採集非常多的數據，而且未來在使用數據的時候就可以從資料庫中直接查詢，不會面臨我想看的時候因為沒有埋點採集而獲取不到的情況。這是非常受分析師喜愛的方式，因此經常會聽到「能採集就盡量都採集，後續分析總能用得到」。其次，埋點是比較耗時的工作，需要業務方提供方案，工程師進行埋點，測試團隊進行測試。而由於實際工作中埋點數量比較多，每次發布新功能或新活動都需要新的埋點，所以埋點不但費時，而且錯誤率也難以控制。有了全埋點，數據用不用都先收回來，由於都是程序自動完成，業務人員想要 A 而工程師埋成 B 這種錯誤也幾乎不存在。

然而任何事務都有它的兩面性。

首先，全埋點的「全」並非真的全部。基本的電腦瀏覽器和移動應用中頁面內常見的用戶操作包括滑鼠行為、鍵盤行為和手指行為。例如網頁端常見的滑鼠點擊、滑鼠滑動、屏幕滾動、鍵盤錄入、游標選取甚至靜止等，移動端除了類似點擊的按下，還有多指開合、拉動、用力按下等等行為。但這些操作並不會都被「埋點」，能埋點的通常僅限點擊或者按下，這顯然是遠遠不夠的，甚至我們都不能稱之為全埋點。

其次，全埋點的「全」以採集上報的數據量為代價，隨著數據量上升導致客戶端崩潰的概率也會上升。尤其是移動端，更多的數據量意味著更多的電量、流量和內存消耗。從這個角度來看，想做到真正的「全」在現階段也是很難。

第三，即使全部行為數據可以被接收回來，具體分析時的二次梳理和加工也無法避免，甚至痛苦。因為機器無法在採集時能按照我們想要的方式對全部事件進行有意義的命名，甚至無法保證採集上來的事件都正好是正確的。於是前期埋點時節省下來的人力成本，這個時候又都搭進去了。

第四，現階段全埋點對於用戶身份信息和行為附帶的屬性信息也幾乎無能為力。

那麼這個功能到底是我需要的嗎？這其實是個度的問題。關於這個問題，只能說得結合你實際情況，如果你更需要隨機探索過去點擊行為的趨勢，那麼這個功能就還合適，否則還有更好的選擇。

可視化埋點：一種所見即所得的埋點方式

代碼埋點和全埋點並沒有在易用性和準確性方面達到平衡。可視化埋點，很多時候也被稱為「無碼埋點」。前文提到，代碼埋點的缺點對於網站還好，但對於移動應用來講無疑是格外低效的。為了解決這個問題，在一部分廠商選擇全埋點的同時也有大量廠商選擇了一種所見即所得埋點的道路，即可視化埋點。

可視化埋點的好處是可以直接在網站或移動應用的真實界面上操作埋點，而且埋點之後立即可以驗證埋點是否正確，這還不算完，將埋點部署到所有客戶端也是幾乎實時生效的。因為可視化埋點的這些好處，分析的需求方，業務人員，沒有許可權觸碰代碼或者不懂得編程的人都可以非常低的門檻獲取到用於分析的數據。可謂是埋點的一大進步。

可視化埋點的部署原理

支持可視化埋點的 SDK 會在被監測的網站或移動應用被訪問時向伺服器校驗是否有新的埋點，如果發現更新的埋點，則會從伺服器下載並且立即生效。這樣就能確保伺服器收到最新的埋點後，所有客戶端都能在下一次訪問時得到部署了。

可視化埋點和全埋點有著對埋點和分析全然不同的追求。可視化埋點的理念是提升原工作流程的效率——依然要梳理需求、設計埋點；全埋點則是將工作流都進行了簡化——反正數據會被採集回來，這兩步的必要性就容易被忽視。這裡不能說孰優孰略，因為事先嚴謹的計劃和事後發散的探索都是分析中的不同角度。況且這兩種埋點也完全不是排他的，完全可以同時使用。

可視化埋點局限性也很多。

首先，可視化埋點也只是針對點擊可見元素的，其中可見元素最常見的就是點擊行為了。對於點擊操作的埋點也確實是目前可視化埋點的主攻點。但從實際情況看，複雜頁面、不標準頁面、動態頁面都給可視化埋點增加不可用的風險，一旦遇到就還是只能代碼埋點了。

其次，對於點擊操作附帶的業務屬性，雖然也可通過進一步選取屬性所在元素來獲取屬性信息，但國內廠商支持得好的就比較少了。

第三，為了確保埋點準確性，可視化埋點也逐步整合了更為複雜的高級設置，例如：「同頁面」、「同版本」、「同層級」、「同文本」……，加上了這些複雜設置的可視化埋點也是那個為提效而生的可視化埋點嗎？

標籤管理器（Tag manager）：低調的高手

大家可能對標籤比較陌生，但用於採集網頁數據的 SDK 大家已經不陌生，這些嵌入到網頁中，能採集網頁上、移動應用或者視頻中的數據的，就是監測類的標籤。但標籤的用途遠不止於此，通過在網站中嵌入代碼，工程師可以對網站提供很多額外的能力。除了剛剛提到的數據監測，還可能為網站提供一些額外的功能，最常見的就是推送個性化的內容，例如：A/B 測試，消息推送，個性化廣告等等。

假如網站或者移動應用藉助標籤的能力實現很多功能，那麼就需要用到很多標籤，而且標籤可能也需要頻繁更新或改動。同樣網頁還好，上線很容易，但移動應用可就難了，假如再出現了錯漏，改正就要面臨非常長的改正周期。這種情況下，標籤管理器就派上了用場。

標籤管理器提供了一個容器，工程師只需要在網頁或移動應用中正確嵌入這個容器，之後不懂技術的團隊也能通過在線管理的方式將後續各種標籤發布到網頁或移動應用中。這樣就實現了技術人員和業務人員工作的各自為戰。聽起來是不是跟可視化埋點很像？是的，他們的原理是幾乎一模一樣的。只不過可視化埋點更傾向於針對客戶端的用戶點擊行為提供了直觀的方法，而標籤管理器是代碼層面的，能做的事情會更多一些。

標籤管理器非常強大的地方在於能免去代碼埋點而通過 DataLayer 就能獲取到頁面中的變數，如每個用戶不同的用戶ID、用戶等級、登錄狀態、購買的產品的名稱以及價格等；而通過觸發器能在這些變數符合一定的時才觸發事件的上報。是不是非常厲害！

目前最著名的標籤管理器是谷歌推出 Google Tag manager，簡稱 GTM，佔據了 83% 的份額。個人版是免費的，但依然提供了極其強大的功能，一般團隊用都足夠了。想進一步地了解 GTM 的功能，可以閱讀它的官網，裡面有非常豐富的講解和案例。

綜上，目前客戶端中對用戶數據的獲取並不存在既簡單又萬能的解決方案，大家應該在合適的場景選擇相應的埋點方式，平衡成本和收益來進行。好在現在廠商也基本上都支持以上多種客戶端行為採集方式。未來，對於客戶端埋點來說，整合了標籤管理器的某些特性的可視化埋點一定能更多地替代代碼埋點，解決工作中常見的所有客戶端行為採集需求。

就像早期論壇的編輯框，只能通過發布或者預覽功能才能看到帖子的效果，但後來所見即所得的編輯器出現使得文字的編輯變得非常高效和愉悅。目前開源社區流行的 Markdown 格式依然沿用了這種方式，在諸多流行的 Markdown 編輯器中，依然是一側編輯、一側實時預覽，或直接就以最終格式的方式來編輯。

隨著 IoT 時代的帶來，越來越多的用戶界面會出現在電腦和手機之外，越來越多的內容是因人而異的。屆時，未來越來越多的 SDK 集成後會自動採集更多標準的用戶行為，而對於非標準以及業務含義強的，需要計算的，或者需要按照特定條件生效的埋點，則可以交給可視化埋點來完成。但目前這個階段，最好的組合恐怕還是 GTM 結合可視化埋點來完成吧。

謝謝大家閱讀。

推薦閱讀：