埋點全解析，你最關心的可視化埋點在這裏！（文末附開源地址）

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

▌爲何要專門埋點？

互聯網應用（網站、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 結合可視化埋點來完成吧。

▌方舟可視化發展方向

方舟可視化目前正在穩步發展中，已經可以支持界面間的交互相關埋點，可是非界面交互相關場景目前尚無能爲力，這也是將來方舟可視化研究的重要方向；除此外支持更多交互場景、適配更多設備與系統、更全面地覆蓋事件和屬性、不斷豐富 SDK 採集的數據、知足更多的業務場景等等衆多方向，方舟可視化在這些方面會不斷髮力。

爲了促進行業發展，方舟可視化於近日正式宣佈開源，以社區的形式促進可視化 SDK 的持續進化，經過開放接口協同創新，方舟願與各位社區開發一塊兒，真正實現企業在一次次快速閉環實踐的精益成長，而且經過可視化埋點這一技術，下降數據門檻，真正可以將數據價值普及開來，讓數據實現真正的大衆化與全民化。

開源地址：

1.java script的開源SDK

https://github.com/analysys/a...

2. ios的開源SDK

https://github.com/analysys/a...

3.android的開源SDK

https://github.com/analysys/a...