導讀

埋點分析，是一種常用的數據采集方法。經過不斷演化發展，由此所演變出的數據采集方式，已出現很多類型，并各具特點。為了讓大家更系統、更細致的了解，我們將圍繞“埋點”的概念、演變形式、應用實例等推出系列講解內容，系統闡述，獻出行業年度最溫柔一講。

 

講埋點的文章的那么多，我們為什么還要寫它？首先，這不是一篇純技術文章，而是從一個非技術人員的角度，希望通過淺顯的語言描述，讓大家能快速了解這些技術概念。此外，目前市面上說埋點的文章，要么沒有進行系統性的知識梳理，要么不夠客觀，存在偏向性，而我們則希望讓大家透過表象，通過系統的講解和梳理，從而了解埋點的真正含義。

 

埋點方式大匯總

 

▌為什么要專門埋點？

互聯網應用（網站、APP）在研發時往往不會專門記錄用戶身份和行為數據，也不會包含專業的數據分析功能。但有時為了分析用戶產生某些動作或不產生某些動作的深層原因，就需要詳細的用戶數據進行分析。這個時候就需要用到專業的用戶分析工具以及埋點了。

 

數據獲取是任何一個數據平臺的起始動作。對于互聯網應用來說，用戶行為的捕捉及獲取是重中之重。如果沒有準確、全面的用戶身份和行為數據作為輸入，在后續分析中得到準確洞察的可能性就會存在不確定性，營銷閉環也會缺少過程數據依據，精細化運營更難以開展。

 

▌埋點原理

對基于用戶行為的數據平臺來說，發生在用戶界面的，能獲取用戶信息的觸點就是用戶數據的直接來源，而建立這些觸點的方式就是埋點。當這些觸點獲取到用戶行為、身份數據后，會通過網絡傳輸到服務器端進行后續的處理。

 

埋點從準確性角度考慮，分為客戶端埋點和服務端埋點。客戶端埋點，即客戶操作界面中，在客戶產生動作時對用戶行為進行記錄，這些行為只會在客戶端發生，不會傳輸到服務器端；而服務端埋點則通常是在程序和數據庫交互的界面進行埋點，這時的埋點會更準確地記錄數據的改變，同時也會減小由于網絡傳輸等原因而帶來的不確定性風險。

 

從分析的角度出發，數據越準確、越全面就越能達到理想狀態；但在實際生產過程中卻不得不考慮數據獲取可行性等問題。由于數據分析工具的最終用戶可能是企業內部的各種角色，如工程師、產品運營、市場甚至其他業務人員；大家會在不同時間，在產品不同的模塊中，以不同的規則向產品中注入自己關心的采集代碼。遵循傳統方式，常見工作流程如下：

 

團隊內部還會使用一種表格來搜集各個團隊的埋點需求，然后再交給工程師。如下圖：

實際上，即使是赫赫有名的數據分析服務商Mixpanel，在很長一段時間內也只能將這種工作流程作為它所建議的最佳實踐，甚至不得不花篇幅在文檔中心提供了幾種不同風格的文檔，以此幫助大家熟悉這種工作流程。

 

 

 

 

▌傳統埋點的不足

 

一遍又一遍的迭代，使行為采集及埋點管理這兩個動作構成了這個工作流的一個閉環，但這個閉環卻存在幾個明顯的弊端，因此，它們也是現在實際工作中讓大家非常苦惱的地方：

 

• 人力成本增加，即需要投入對業務和技術都具備一定專業水平的人專門負責
• 溝通成本增加，即前期需要同多方協作
• 犯錯成本增加，即發現錯漏無法快速事后補救
• 管理成本增加高，即跨版本后，廢點會造成代碼垃圾也會影響性能

 

實際工作過程中，部分企業一方面強調數據獲取的重要性，另一方面卻依然沒有真正把重心投入進來。

 

對行業從業者來說，數據獲取及管理，從來不是一個做到某種程度就夠用的問題，而是只要數據業務還在發展，就要不斷通過自行迭代，去探索更好的獲取及管理方式的問題。時至今日，Mixpanel等著名國外廠商依然在努力挖掘提供更高效、準確的埋點方式；國內的廠商，也還有很大的提升進步空間。

 

聊完“埋點”這個大的概念，其細分概念隨即出現，如“無埋點”、“全埋點”、“無痕埋點”、“無碼埋點”、“可視化埋點”等等。而站在用戶的角度，如果仍然對這些概念不甚了解，那么結合業務做好數據采集就難以展開，選擇適合自己團隊和業務的埋點方法也無法進行......

 

下面我將所有可能遇到的埋點方式和它們的名稱梳理并做簡單講解，需要對你的工作有幫助。

▌代碼埋點：最可控的埋點方式

 

代碼埋點是最經典的幫助工程師了解用戶是如何使用產品的埋點方式。因為是工程師人工將埋點結合到代碼邏輯中，理論上只要是客戶端種的操作，再復雜也能采集到。常見的如：頁面停留時間，頁面瀏覽深度，視頻播放時長，用戶鼠標軌跡，表單項停留及終止等等。尤其是一些非點擊的、不可視的行為，是非要代碼埋點來實現不可了。所以如果我們需要對埋點有更加精準的控制力，那么代碼埋點是最好的選擇。

 

也許你還分不清集成和埋點。為了進行埋點，廠商通常都提供一個代碼包，可以理解為一個工具包，里面包含常用的工具。想埋點就要先有這個工具包，也就是集成SDK。然后根據里面的說明書，再使用這個工具包制作出各種東西，也就是埋點了。

 

當然弊端也是很明顯的，前文說描述的那些苦惱幾乎全是代碼埋點相關的。為了能讓埋點過程更高效，廠商們做了很多努力。

 

▌全埋點：讓我歡喜讓我憂

 

全埋點，一些國內的團隊也稱“無埋點”、“無痕埋點”以及“自動埋點”。是一種對全自動的埋點方式的探索，而且從名字看仿佛是個一勞永逸的解決方案，那我們先看看什么是“全埋點”。

 

客戶端埋點一般分為訪問級、頁面級、頁內行為級。用戶訪問一個網站或啟動一個移動應用時幾乎所有的廠商都會自動采集上報用戶的訪問；當用戶訪問不同頁面時，有一部分廠商就會選擇不默認自動采集，而將其作為一個選項交給用戶；而對于用戶在某一個頁面內詳細的操作行為，只有極少數廠商支持自動采集上報。實現了后兩種自動采集的廠商，通常會說自己是全埋點。但頁內行為級的采集也還可以進一步探討其采集的范圍。最常見的就是自動采集可交互元素和自動采集所有元素的差別。

 

可交互元素包含：鏈接、表單項（如按鈕、輸入框等）、HTML 的對象級元素等。不可交互元素就太多了，絕大多數的頁面元素都屬于此類。由于實際上網頁和移動應用中的大家可以看得到的界面很多都并不是標準元素，所以實際上界面上很多看似可交互的元素也都是無法自動采集上報的。這一點不可不謂之遺憾。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

可視化埋點的部署原理

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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