1. 程式人生 > >埋點測試、埋點接口測試

埋點測試、埋點接口測試

好處 2-0 特定 明顯 們的 方案 消息 多看 www.

2018-12-01  15:56:22    http://www.sohu.com/a/257194700_465988

埋點是一種數據分析工具,用來分析用戶行為。捕捉用戶數據,管理數據。埋點是一種客戶端行為采集方式。

分為代碼埋點、全埋點、可視化埋點。

為什麽要專門埋點?

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

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

▌埋點原理

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

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

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

技術分享圖片

檔,以此幫助大家熟悉這種工作流程。

▌傳統埋點的不足

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

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

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

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

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

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

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

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

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

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

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

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

技術分享圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

可視化埋點的部署原理

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

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

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

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

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

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

▌標簽管理器(Tag manager):低調的高手

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

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