轉載：http://www.chinawebanalytics.cn/auto-event-tracking-good-bad-ugly/

所謂“埋點”，是數據采集領域（尤其是用戶行為數據采集領域）的專業術語，指的是針對特定用戶行為或事件進行捕獲、處理和發送的相關技術及其實施過程。

例如我們在產品或者服務轉化關鍵點進行埋點，即可以幫助產品運營領域或者營銷領域的業務人員定義和分析準備的業務數據。

?

我總覺得應該寫一篇文章以正視聽。

實際上，在2014年我去舊金山參加eMetrics Summit的時候，Heap Analytics就展出了他們的“無埋點”產品——這家公司也是以不需要埋點就能實現監測作為最主要賣點的（見我的這篇文章：明天的數字營銷分析工具（下））。Heap的負責人告訴我，他們在2013年已推出了無埋點監測技術，為此才成立這家公司。采用類似技術的公司還有數家，因此這完全不是一個新技術，更不是一個壟斷技術。

?

只是，那個時候還沒有人把它稱為無埋點，大家稱它為“可視化監測部署”，或者“所見即所得的監測部署”。而且在2014年，中國幾乎沒有什么有影響力的創新digital analytics工具，而附著于這類工具之上的可視化或者不可視化、埋點或不埋點，自然無人提及。除了我的那篇文章，整個行業了無波瀾。

似有好東西被埋沒，養在深閨無人識的遺憾。或者你也該明白起一個好名字該有多重要。:P?而此時的彼岸，這一技術方案已然進入尋常百姓家，已非帶著光環的神秘之物。

不過，隨著我們國家的互聯網數據行業突然蓬勃起來，諸多廠商一齊出現在世人視野，“無埋點”甫一喊出，舉座皆驚，但是否真是神器？有什么優點和問題？待我一一道來。

監測代碼、SDK和埋點

我們知道，我們能夠監測網站上用戶的行為，或者app上用戶的行為，是需要在網站的每一頁或者app中加上一些程序代碼的（這里就不考慮日志分析這種方法了）。這樣的程序代碼，在網站上叫監測代碼，在app中叫SDK（Software Development Kit）。無論你是要監測網站，還是要監測app，你都必須加上這類代碼，不加代碼就收集不到數據。

所以，埋點不埋點跟你在網站上或者app上加代碼是無關的，無論是埋點方法，還是不埋點方法，你想要對一個網站或者app進行用戶數據的收集，你都必須要加監測代碼，毫無例外。

那么，“無埋點”又是什么，其中的“點”又是什么，為什么不需要埋？為了說明無埋點，我們必須先講講埋點。

談到埋點，跟我們在網站上或者app上的監測需求有關。剛才我們講的那些監測代碼，雖然是為了收集數據必須要加的，但是只能叫做基礎代碼。基礎代碼不能不加，但是你要想收集到所有用戶行為的數據，光有基礎代碼又是不夠的。簡單講，無論是網站上，還是app上（尤其是app上），總有一些特殊的用戶操作行為是不能靠基礎代碼捕獲的。

這一類基礎代碼不能捕獲的用戶操作行為，最典型的，是被稱為event（事件）的一類行為。對于什么是event（事件），在網頁上，是那些非http類型的交互：JavaScript的、Flash的、Silverlight的、AJAX的、各種頁面插件的交互等等；而在app上，則包含用戶點擊在內的所有交互。你可以直接理解一個規律，那就是凡是遵守http協議的交互（最典型的就是網頁的鏈接），皆是可以由基礎監測代碼直接監測到數據的，但非http類型的用戶交互，基礎監測代碼都無能為力。至于app上的所有可點擊交互都是event并不難理解，因為app不遵循http協議，所以基礎監測代碼對它們都無效。

每一個需要我們監測的event互動，都被稱為一個“監測點”，你可以想象，web上的監測點不會特別多（因為大部分都是http互動，所以基礎代碼能搞定），而app上則布滿了監測點。為了讓這些監測點上的用戶互動行為數據被我們收集到，我們必須在這些監測點上部署上專用的事件監測代碼（即event tracking code），這些代碼需要手工一個一個添加在想要獲取數據的監測點上。這個過程被形象化的稱為埋點。在我的博客中，埋點相關的內容經常出現，只不過我使用了更為準確的表述——event tracking部署，或事件監測部署。沒錯，埋點就是我常常講的事件監測部署，完全不是一個新鮮的事物。

那么，有的讀者朋友腦洞大開，說，我只想監測那些event，是不是直接做事件監測（埋點）就可以了，而不需要加基礎代碼了？所以這里涉及到另外一個規律：事件監測（埋點）只有在基礎代碼工作的情況下才能發揮作用，并且各家數據監測工具的基礎代碼只能用它們自家的event監測。這意味著，你想用Google Analytics的事件監測，前提是你必須已經在頁面上部署好了Google Analytics基礎監測代碼（被稱為GATC，Google Analytics Tracking Code），不能不部署基礎代碼，也不能部署別家的基礎代碼。

埋點和無埋點

大家知道了埋點的意思，那么，什么是無埋點呢？

還是從埋點開始。由于埋點（事件監測部署）需要網頁工程師（或者app開發者）將一個一個專用的監測代碼加在每一個監測點上，還需要保證這些代碼跟監測點一一對應（因為每一個監測點不同，所以加的專用事件監測代碼在命名和屬性設定上也不同，每個監測點都要加一個專屬于自己的事件監測代碼），不能錯加或者漏加，這是一個繁瑣的工作，且很容易出現錯誤。因此，人們特別想改進這種方法。

人們想到，我想監測的每一個具體的事件（監測點）都在網頁上或者app上有明確的位置，那么，有沒有可能，我們能有一種“指哪打哪”的監測，即，在頁面上，直接用鼠標點擊我想監測的這些事件所在的位置，然后監測系統就能知道并且記錄下來這個地方，并且開始進行自動的監測呢？

一旦想出了好點子，技術的實現就不會是問題。大家的解決方法都大同小異——首先部署監測工具的基礎代碼，然后在監測工具的后臺開啟“無埋點部署選項”，當你開啟這個選項之后，你再進入你要監測的頁面或者app的時候，你的鼠標（或者手指）點擊操作，就變成了為監測工具指定監測點的操作。你用鼠標（或者手指）點擊某一個用戶交互的位置，一個監測工具安排的彈窗會打開，在這個彈窗中你可以為這個監測點命名，然后工具就開始為你記錄這個位置的用戶互動數據了。并且人們發現，這個方法不僅僅可以用在對event（事件）監測上，對普通的http的交互，同樣適用。例如下面的圖示：

上圖是Heap的“無埋點”界面

上圖是鉑金分析（Ptengine）的“無埋點”界面

　　很難說明這種想法到底是哪家公司或者哪個人發明的，Heap在成立的時候推出了這種方法，可以認為也許他們在2013年或更早就想到了這種方法并付諸實施。同樣，鉑金智慧（Ptmind）在2013年也商業化了這個方法，并且在2014年推向日本市場的時候，詳細介紹了這種方法（見他們的博客：https://www.ptengine.jp/blog/index.php/event_tracking/）。國內不少廠商也說他們“獨創”了這個方法，但問世時間就要晚不少了。

現在，連百度統計都在宣傳自己擁有“無埋點”方法了！這個方法看來要變得非常“稀疏平常”了。:p

不僅僅web上可以實現無埋點的監測，app上也可以，有兩種方法，一種是手指取代鼠標，直接在手機上操作設置。另外一種是在電腦瀏覽器端操作，類似于一個模擬器，將app的屏幕模擬在電腦屏幕上，然后用鼠標操作。第二種方法具有更好的用戶友好性，所以更被接受。例如我們熟悉的Talkingdata或者Mixpanel都是采用的這種方法。不過，無論哪種方法，都還是需要在app中加上實現基礎監測的SDK。

上圖：鉑金分析（Ptmind）的app無埋點監測設置界面

　　“無埋點”方法是怎么實現的呢？講解有點點偏技術，如果不擅長技術看不懂就略過。原來，在進行事件設置的時候，“無埋點工具”會利用它部署在網站頁面（或者app）上的基礎代碼對網站（或app）上所有的可交互事件元素進行解析，獲取它們的DOM path。采集用戶行為時，監測工具也會通過它的基礎代碼對頁面上所有的DOM上的用戶操作行為進行監聽，當有操作行為（交互事件）發生時，監測工具會進行記錄，并且同時記錄對應的cookie（或device ID）信息，將跟用戶設置的信息關聯起來。所以，這也是為什么頁面上所有的交互（包括基于http的鏈接交互）都可以通過這一方式可視化的被監測的原因。

看了上面的技術解釋（或者不看也不要緊），下面的事情就很容易理解了：無埋點與埋點一樣，想要發揮功能，都必須要加上監測工具的基礎代碼。不加上基礎代碼，無論埋點與否，都不能實現對event（事件）的監測。準確地添加基礎代碼，是一切的前提。

無埋點和全埋點

隨著無埋點的走紅，行業中又出現了新名詞：“全埋點”。但本質上跟無埋點并無不同，因為上面所介紹的這類“可視化事件監測方法”都是直接對頁面中所有的交互元素的用戶行為進行監聽，因此即使你不需要監測的部分，它也照樣會將用戶行為數據和對應的發生地信息照單全收下來。因此，你會發現，在你選定某個event（事件）進行監測設置的時候，有些工具直接就會彈出一個浮層或窗口，將這個event對應的歷史數據直接呈現給你。如下圖所示：

　　從這個界面（Ptengine的可視化事件監測界面）可以看到，我并未對“數據驅動的互聯網運營課程”有任何事先的設定，只是點擊它之后，該交互鏈接的歷史點擊數據就直接呈現在我的面前了。

這是無埋點的另一個相當有價值的優勢。而埋點的方式，即前面講的需要在每一個監測點上添加額外的專門代碼（即添加event tracking code）的這種方法，則只能獲取添加代碼之后的數據，埋點之前的數據不可見。如下圖所示：

　　

上圖：GA采用埋點監測event（事件）的方法，在部署event tracking code前的數據無法提供

　　無論是“無埋點”還是“全埋點”，這些說法都有些抽象，我還是喜歡“可視化事件監測”這樣的準確用語。

看到這里，你會明白，所謂的無埋點，絕非我們的革新首創，但還是很有用的，同樣絕非噱頭。

無埋點的問題

前面下了定論，無埋點不是革命 ，但確實非常有價值，在使用體驗上有顯著優于傳統事件監測（埋點）部署方法的地方。但，這并不意味著這種方法完美無缺，傳統埋點的方法也不能完全被取代。

無埋點方法有幾個值得關注的缺陷。

其一：用戶的交互行為，如果沒有具體的“地點”，無埋點方法不適用。比如，用戶上滑屏幕時內容瀑布流的底部載入新的內容（像網易新聞、今日頭條之類），這種交互用戶可以一直進行下去，但卻沒有一個明確的監測點位置。在可視化事件監測設置的界面上你找不到這類交互，因為這類交互是不可見的。

其二：可視化的無埋點部署，能夠為交互行為設置的屬性是非常有限的。所謂交互行為的屬性，用人話來說，就是對這個交互行為背后的信息進行記錄，或者添加說明。一般的無埋點部署，只能給交互行為起一個名字，然后機械的記錄這個交互行為發生的次數。但是一個交互行為可能帶有很多屬性，比如，點擊播放一個視頻，交互行為就是一個播放，但播放的背后，我們還想知道這個視頻的名字、視頻的類別、視頻的作者等等信息。可視化的無埋點部署記錄不了這么多內容。而埋點方法（傳統的事件監測方法），則可以非常好的添加event背后的屬性，例如Google Analytics支持為每個event添加6個屬性，這樣在數據的維度上，能夠大大擴展事件追蹤報告的效能。

其三：行為數據的分類匯總。埋點方法因為帶有多個屬性，用戶可以輕松的通過這些屬性進行分類數據報告的讀取。比如，剛才講的那個例子，視頻的類別就是一個分類型的屬性。我們讀取報告的時候，可以把某個分類的視頻的event數據一次性全部展現在報告中，而不需要手動一個一個去匯總。而無埋點方法因為缺少對行為屬性的標識，因此做不同event的分類匯總數據，要麻煩得多，并且必須得手動一個一個添加。

所以，我們可以做一個表比較埋點和無埋點方法的優劣勢。

　　

克服缺陷，無埋點方法的升級方案

由于無埋點顯著的優勢，人們確實非常喜愛這種監測部署方法。不過，上面講的問題不克服，這個方法也只能“小用”，而堪不了大用。

業界開始有一些升級無埋點方法的方案，很炫，實用與否大家可以自行嘗試。

例如，mixpanel對下拉菜單這樣的交互行為中，菜單的所有屬性進行自動記錄，以幫助實現更好的數據獲取和分類。在mixpanel中，“無埋點”被稱為“autotrack”，即自動監測。在下圖中，如果你要監測一個下拉菜單“What industry are you in?”中具體每個選項的點擊次數，mixpanel可以自動幫你實現。

上圖：在mixpanel中，監測一個下拉菜單中每個選項被點選的次數，直接選擇并命名這個下拉菜單即可

　　設置之后，在報告中會自動出現下拉菜單中的所有點選項目。在下圖中，每一條線就是上面的下拉菜單中的一個點選項的被點擊的情況。

上圖：每一條曲線就是mixpanel自動獲取的每一個下拉菜單中點選項目的被點擊次數

　　另一款解決方案，鉑金分析（Ptengine），同樣可以直接抓取互動事件的相關屬性。例如，可以直接在用戶點擊“購買”按鈕時，設置抓取該商品的價格、商品名等屬性。并且你可以設置這些屬性的抓取是否是“復選”。所謂復選，是指你設置了這一個地方之后，所有的跟這個地方相同的地方，其數據也會按照你在此地的設置，自動進行抓取。比如，在這個商品的頁面上設置一次之后，在所有的商品頁面上都自動生效，且都能夠在用戶點擊任何商品頁面的“購買”按鈕時，自動抓取商品的名字、價格等信息。這意味著，這個解決方案實際上是一個非常強大的“可視化的電子商務監測”解決方案。

這也是為什么我一直認為這個工具總是帶給我很多震撼想法的原因。

下圖中，紅色的框前的“#”號，就意味著所有這一類頁面（商品頁面）的同樣位置都被將被自動抓取。

上圖：鉑金分析（Ptengine）提供可視化事件監測（無埋點）的自動屬性抓取和全部相同頁面“復選”的智能監測部署功能

　　同樣，在下圖中，每個商品的價格都將被自動記錄下來，并放到“Commerce-Price-Amount”這個屬性中。

上圖：鉑金分析（Ptengine）自動捕捉的商品價格屬性

　　相信假以時日，無埋點的追蹤方法將有可能完全取代埋點方法。未來在“無明確地點”的用戶行為互動上應該也會有較好的突破。

總結

基本上把最近朋友們老問我的問題講解清楚了。還是那幾個關鍵點，我快速總結一下，然后結束這個文章。

1.無埋點不是不加代碼。如果你想監測數據，無論什么情況，都必須添加監測工具的基礎監測代碼。并且每個頁面都要加，每個app也都要加。

2.無埋點并非2016年才出現的新事物，早已有之，但最近才被炒起來。它不神秘，很簡單，但很有用。

3.埋點這種傳統方法仍然具有很多優勢，無埋點不能完全取代埋點。至少現在不可以。

4.無埋點方法目前有很多升級解決方案，以彌補目前一般無埋點存在的缺陷。

5.無埋點的真正準確說法，應該是：可視化事件監測部署。

好了，歡迎朋友們留言，探討！

總結

以上是生活随笔為你收集整理的无埋点实现监测的真相——革新还是噱头？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。