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

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

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

站在產品的視角，經常會問如下幾個問題：

• 1.產品有沒有用戶使用
• 2.用戶用得怎么樣
• 3.系統會不會經常出現異常
• 4.如何更好地滿足用戶需求服務用戶

當站在技術視角時，經常會問如下幾個問題：

• 1.系統出現異常的頻率如何
• 2.異常出現后如何快速進行定位追蹤
• 3.如何分析解決問題

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

• 1.我的存量用戶多少，未來還有多少潛力
• 2.多少用戶在系統內進行了消費

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

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

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

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

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

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

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

數據監(jiān)控

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

性能監(jiān)控

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

異常監(jiān)控

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

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

現有方案

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

(1) 頁面進入(pageIn)

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

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

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

(3) 頁面離開(pageOut)

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

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

后續(xù)演進

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

(1) 性能數據上報

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

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

(2) 接口數據上報

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

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

四、前端數據可視化

對于已經采集上來的數據經由數倉清洗之后的可視化玩法就千變萬化了。可以針對不同元數據按不同指標緯度聚合，產生不同的數據分析側重點。再通過各類可視化工具進行展示，例如：混儀系統、小采BI等。

混儀系統

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

小采BI

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

結語

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

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

最新評論