一、為什么需要埋點&監(jiān)控

在開始正文之前，我們先想想為什么需要埋點&監(jiān)控？

當我們在分析復(fù)盤一個產(chǎn)品是否成功的時候，不同的角色考慮的方向是不同的。

站在產(chǎn)品的視角，經(jīng)常會問如下幾個問題：

• 1.產(chǎn)品有沒有用戶使用
• 2.用戶用得怎么樣
• 3.系統(tǒng)會不會經(jīng)常出現(xiàn)異常
• 4.如何更好地滿足用戶需求服務(wù)用戶

當站在技術(shù)視角時，經(jīng)常會問如下幾個問題：

• 1.系統(tǒng)出現(xiàn)異常的頻率如何
• 2.異常出現(xiàn)后如何快速進行定位追蹤
• 3.如何分析解決問題

而當站在老板的視角時，問題可能又會變?yōu)椋?/p>

• 1.我的存量用戶多少，未來還有多少潛力
• 2.多少用戶在系統(tǒng)內(nèi)進行了消費

當在回答了上述問題之后，埋點&監(jiān)控便躍然紙上。因為要回答以上問題，只有通過對系統(tǒng)進行數(shù)據(jù)分析的方式才能弄清楚。

其實無論是埋點亦或是監(jiān)控，二者并不是獨立存在，而是相互依存的關(guān)系。

二、埋點&監(jiān)控能做什么

從單個頁面的常規(guī)數(shù)據(jù)角度出發(fā)我們可以通過埋點獲?。涸L問次數(shù)（UV/PV）、地域數(shù)據(jù)（IP）、在線時長、區(qū)域點擊次數(shù)等數(shù)據(jù)。

當我們將這些單點數(shù)據(jù)按照特定的緯度進行數(shù)據(jù)聚合，就可以獲得全流程視角下的數(shù)據(jù)如：用戶留存率/流轉(zhuǎn)率、用戶轉(zhuǎn)化率、用戶訪問深度等數(shù)據(jù)。

而在埋點數(shù)據(jù)進行上報的同時，我們也可以同步收集頁面基礎(chǔ)數(shù)據(jù)/接口相關(guān)數(shù)據(jù)如：頁面加載/渲染時長、頁面異常、請求接口等數(shù)據(jù)。

同時對于前端監(jiān)控來說，大致可以分成三個方向：數(shù)據(jù)監(jiān)控、性能監(jiān)控、異常監(jiān)控。

數(shù)據(jù)監(jiān)控

數(shù)據(jù)監(jiān)控即通過數(shù)據(jù)分析用戶行為，常見的監(jiān)控數(shù)據(jù)包括：PV/UV、頁面停留時長、通過什么入口進入、在頁面觸發(fā)了什么行為等。統(tǒng)計這些數(shù)據(jù)就是為了清楚用戶來源，拓寬產(chǎn)品的推廣渠道；了解用戶在頁面停留的時間情況，針對停留較短的頁面進行分析改進。也就是我們常說的：who(uuid)、when(time)、from where(referrer)、where(x,y)、what(自定義拓展數(shù)據(jù))串成的用戶行為路徑。

性能監(jiān)控

性能監(jiān)控主要是針對前端進行監(jiān)控，比如不同用戶在不同地區(qū)使用不同機型下的首屏加載時間、頁面的白屏時間、靜態(tài)資源下載時間等數(shù)據(jù)。通過針對這些性能數(shù)據(jù)進行監(jiān)控，可以大概反映前端性能的好壞，根據(jù)性能監(jiān)測的結(jié)果可以進一步的去優(yōu)化前端性能。

異常監(jiān)控

前端代碼在執(zhí)行過程中也可能會發(fā)生異常，因此需要引入異常監(jiān)控例如 sentry 等工具及時的上報異常情況，可以避免線上故障的發(fā)上。常見的異常包括：Javascript 的異常監(jiān)控、css 的異常監(jiān)控等。

三、目前埋點方案&后續(xù)演進方向

現(xiàn)有方案

目前公司已經(jīng)存在一套埋點 SDK 在運行，使用的是代碼埋點方案，其埋點上報數(shù)據(jù)可大致分為三類：頁面進入、事件觸發(fā)、頁面離開。

(1) 頁面進入(pageIn)

進入頁面時，同步推送頁面基礎(chǔ)信息如：當前頁面的來源頁面、操作系統(tǒng)、瀏覽器、頁面 url，發(fā)生時間等

(2) 事件觸發(fā)(Event)

觸發(fā)事件時，同步推送事件類型(click、hover等)、鼠標位置、附加業(yè)務(wù)參數(shù)等

(3) 頁面離開(pageOut)

離開頁面時，同步推送發(fā)生時間、頁面 url 等

其埋點大致邏輯如下圖，通過生成獨有的四段值+pvid即可定位某個項目的某個頁面在某個區(qū)塊點擊了某個按鈕，同時生成唯一的 pvid 記錄頁面的 pv 數(shù)據(jù)。具體說明可翻閱往期關(guān)于政采云埋點分析系統(tǒng)的文章。

后續(xù)演進

在現(xiàn)有 SDK 的基礎(chǔ)上我們可以發(fā)現(xiàn)，目前的埋點 SDK 只上報了一些用戶的基礎(chǔ)信息數(shù)據(jù)，在性能數(shù)據(jù)和異常數(shù)據(jù)的上報上還存在可拓展的空間。

(1) 性能數(shù)據(jù)上報

在獲取用戶基礎(chǔ)數(shù)據(jù)的同時，后續(xù)可以通過window.performanceAPI獲取前端性能數(shù)據(jù)，在第一次進入頁面時隨 pageIn 一起將頁面初始性能數(shù)據(jù)進行上報。

可進行上報的字段包含如下：

(2) 接口數(shù)據(jù)上報

除了上報性能數(shù)據(jù)外，我們也可將頁面內(nèi)所發(fā)的所有請求通過重寫XMLHttpRequest進行劫持打標上報，即在當前頁面下的所有請求 header 上默認加上當前頁面 ID，將各個請求與當前頁面的 pageId 進行綁定。

通過該類數(shù)據(jù)可以進行統(tǒng)計分析出某一頁面的請求量、請求異常等情況判斷出頁面級別的請求健康度；后期甚至可與 Yapi 接口系統(tǒng)打通，若出現(xiàn)異常情況可直接將實際請求參數(shù)與文檔上的請求參數(shù)進行對比，排除異常是由于請求參數(shù)錯誤造成的。

四、前端數(shù)據(jù)可視化

對于已經(jīng)采集上來的數(shù)據(jù)經(jīng)由數(shù)倉清洗之后的可視化玩法就千變?nèi)f化了?？梢葬槍Σ煌獢?shù)據(jù)按不同指標緯度聚合，產(chǎn)生不同的數(shù)據(jù)分析側(cè)重點。再通過各類可視化工具進行展示，例如：混儀系統(tǒng)、小采BI等。

混儀系統(tǒng)

混儀系統(tǒng)(內(nèi)部系統(tǒng))主要針對埋點進行元數(shù)據(jù)后臺管理，推進埋點平臺的規(guī)范化建設(shè)。同時在此基礎(chǔ)上，優(yōu)化數(shù)據(jù)分析功能，為公司內(nèi)部用戶提供埋點數(shù)據(jù)自助分析平臺，提升數(shù)據(jù)利用率和日常工作效率。

小采BI

小采BI是可視化團隊內(nèi)部搭建系統(tǒng)，分為報表搭建、大屏搭建和看板搭建等模塊。通過內(nèi)部這些搭建工具直接對元數(shù)據(jù)進行展示，組合成面向不同受眾、不同角色的自定義數(shù)據(jù)報表或監(jiān)控大屏等。

結(jié)語

本文只是針對埋點系統(tǒng)和監(jiān)控系統(tǒng)的融合的一點簡單的介紹與探索，實際操作落地上肯定會有各種問題。比如多端情況下的數(shù)據(jù)埋點&上報，比如手動埋點增加了工作量破壞了原有代碼的可讀性等一系列實操上的問題，這些都需要逐步完善優(yōu)化，同時我們也希望各位讀者提出自己意見和建議，一起完善埋點&監(jiān)控的大生態(tài)。

以上就是js前端埋點監(jiān)控解析的詳細內(nèi)容，更多關(guān)于js前端埋點監(jiān)控的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論