更新時間:2021年09月24日14時33分 來源:傳智教育 瀏覽次數(shù):
數(shù)據埋點是數(shù)據采集的一種重要方式,主要用來記錄和收集終端用戶的操作行為,其基本原理是在App/H5/PC等終端部署采集的SDK代碼,當用戶的行為滿足某種條件的時候,比如進入某個頁面、點擊某個按鈕等,會自動觸發(fā)記錄和存儲,然后這些數(shù)據會被收集并被傳輸?shù)浇K端提供商,或者是通過后端采集用戶使用服務過程中的請求數(shù)據。
一個典型的埋點采集處理流程如下圖所示:
終端提供商在收集到埋點數(shù)據之后,通過大數(shù)據處理、數(shù)據統(tǒng)計、數(shù)據分析、數(shù)據挖掘等加工處理,可以得到衡量產品狀態(tài)的一些基本指標,比如活躍、留存、新增等大盤數(shù)據,從而洞察產品的狀態(tài)。此外更重要的是隨著數(shù)據挖掘等技術的興起,埋點采集到的數(shù)據在以下方面的作用也越來越凸顯:
驅動決策:ABtest、漏斗優(yōu)化、用戶增長、bug修復、精準營銷、流失用戶預警
驅動產品智能:智能推薦(千人千面)、場景化提示(私人助理)等
驅動安全:風險識別
埋點的分類
從位置上分為前端埋點和后端埋點,從形式上分為顯性埋點和隱性埋點,從路徑上又可以分為路徑埋點和獨立埋點,從需求上分為業(yè)務埋點和監(jiān)測埋點。
由于埋點的主要操作過程是以終端的交互界面為基礎,制定數(shù)據采集的方案,其它的埋點分類也只是從不同的角度來進行埋點設計。前端埋點是當前主要采用的埋點方式,下面主要對前端埋點進行闡述。
前端埋點
前端埋點是在用戶端(APP、Web、客戶端)等嵌入數(shù)據采集代碼,比如友盟等均采用的是前端埋點,比如通過嵌入一段代碼就就可以對網頁數(shù)據的訪問數(shù)據進行采集。相比于后端埋點,前端埋點能方便收集到用戶在界面上的行為數(shù)據,比如用戶點了哪個按鈕、頁面之間的跳轉次序、停留時長等,這些數(shù)據是后面進行數(shù)據分析的主要來源。
前端埋點技術有以下三類:
代碼埋點
代碼埋點是直接將采集SDK集成在終端,然后不斷在此基礎上添加調整采集方案,是目前主流的埋點采集方案,其優(yōu)缺點如下:
優(yōu)點:
高度定制、控制精準、采集的數(shù)據豐富準確
缺點:
首先是每當有采集需求,需要開發(fā)人員不斷添加采集代碼,工作量大;
其次變更采集策略,需要發(fā)布新版本,代價巨大,存在滯后效應;
最后由于采集代碼常駐終端,不斷將采集的用戶行為數(shù)據進行記錄和上報,對于終端尤其是移動終端來說還有耗電、消耗數(shù)據流量等負載,此外在數(shù)據上報傳輸?shù)倪^程中也存在丟失數(shù)據的風險。
可視化埋點
由于代碼埋點需要終端開發(fā)人員來執(zhí)行采集方案,對業(yè)務的功能開發(fā)侵入性較高。有的公司開發(fā)出了可視化埋點技術,只需要產品與運營人員通過GUI界面進行鼠標簡單點擊,就可以隨時增加、取消、調整采集數(shù)據的位置和方式,此種埋點方式避開了終端開發(fā)人員的介入,由需求人員直接執(zhí)行采集,減輕了需求傳遞過程中的信息損耗和誤解,另外可視化埋點技術往往由服務端直接下發(fā)采集的配置文件,而不用跟隨版本發(fā)布,從而加快了數(shù)據采集的流程。
具體實現(xiàn)方式參考:
具體實現(xiàn)是SDK定時做界面截圖,在截圖的同時從界面UI的根對象開始遍歷所有的可視化子對象,得到其層級關系。根據截圖和UI元素的可視化信息重新渲染頁面,識別可埋點的控件。當產品人員在后臺管理端的截屏畫面上點擊可埋點控件,設置事件關聯(lián)方面的配置,服務器保存這些配置,客戶端在獲取到這些配置信息以后,按照新配置采集數(shù)據。
無埋點
無埋點與可視化埋點原理基本一致,區(qū)別在于無埋點是先遍歷所有的控件和操作行為的組合情況,然后將這些組合情況交給埋點后臺,由數(shù)據分析人員選擇對哪些組合的埋點數(shù)據進行分析,其優(yōu)缺點如下:
優(yōu)點:
收集數(shù)據全面,無漏報
缺點:
采集數(shù)據量巨大,增加了終端流量消耗和服務器存儲負擔。
埋點的上報時機相對呆板,不能靈活的根據特定的場景進行特殊設置
前端埋點的注意事項:
頁面和控件標示上報要從頂層進行合理的設計,層次感要明顯
埋點數(shù)據的漏報和重復上報如何衡量
前端埋點不僅可以處理不需要和服務器交互的曝光和點擊事件,也可以將與服務器交互的結果,比如關注成功、分享成功、優(yōu)惠券領取成功等原屬于后端埋點里的事件放在前端來上報。
后端埋點
后端埋點為了避免前端埋點的以下問題:
前端埋點需要對采集的數(shù)據壓縮、暫存,為減少移動端的數(shù)據流量,除一些需要實時上報的重要事件不限制網絡環(huán)境,其它事件一般只在wifi情況下上報,因此數(shù)據會有延遲,丟數(shù)據等弊端,而在后端采集數(shù)據,由于數(shù)據是在內網傳輸,數(shù)據傳輸?shù)募磿r性強,丟失數(shù)據的風險小。
前端埋點采集程序由于需要常駐,監(jiān)測實時和延遲埋點上報,不可避免的帶來額外的耗電。
前端埋點若要新增或調整采集方案,需要開發(fā)人員修改客戶端代碼,然后發(fā)版之后才能解決,受發(fā)布周期的影響較大,而且通常用戶的版本更新并不會及時,這將導致新方案不能及時覆蓋所有用戶。雖然現(xiàn)在部分埋點管理后臺也支持熱配置更新,但功能一般都很弱,只支持一些基礎的埋點事件熱更新部署,
注意:
很多時候并不把后端埋點獨立出來,而是混合在前端埋點中,等用戶和服務器端的交互返回結果之后,將結果進行上報。
對一下需要精確采集的數(shù)據,比如代金券發(fā)放等,實施的時候盡量采用后端埋點,除非后端無法采集到所需要的數(shù)據,前端埋點只是用來參考。此外也可以將業(yè)務數(shù)據庫代金券領取數(shù)據同步到數(shù)據倉庫中進行分析。
其它埋點
路徑埋點和獨立埋點
這部分的埋點根據業(yè)務對路徑的追蹤需求和SDK的開發(fā)能力,可為每個事件設計上下文的路徑信息,路徑信息的組成一般由頁面、控件、行為三部分組成,而路徑的深度也不宜太深,一般小于五層。
顯性埋點和隱性埋點
顯性和隱性是從用戶有感和無感來區(qū)分的,有感事件是用戶的主動事件,比如展示和點擊事件;無感事件主要用來處理后臺的數(shù)據請求和拉取,用以監(jiān)控和服務器的數(shù)據交互是否正常等,無感事件中常用的是掃描采集,比如app啟動之后,掃描各設置開關的狀態(tài)信息進行上報等
業(yè)務埋點和監(jiān)測埋點
業(yè)務埋點是從業(yè)務需求的角度而言,比如產品需要統(tǒng)計某個頁面的曝光和點擊,算法人員需要的推薦項點擊率等;而監(jiān)測埋點是從業(yè)務的流程上來講的,一般是指隱性的(比如服務器交互的內容拉取情況、本地潛在信息的生成情況等),此外業(yè)務埋點中的關鍵部分也可以用作監(jiān)測埋點。
為什么要做數(shù)據分析?數(shù)據分析有什么意義?