無埋點實現監測的真相——革新還是噱頭？
原文出處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.無埋點的真正准確說法，應該是：可視化事件監測部署。
好了，歡迎朋友們留言，探討！