上一篇梳理了前端監控的主要場景和類型，從本文開始，討論下我知道的一些技術實現。前端黑科技層出不窮，個人眼界有限，盡量把了解到的實現方式都羅列出來，希望對大家有些啟發，同時也歡迎流言討論。

限于篇幅，按照第一篇的場景來進行拆分，本文只討論行為監控的技術實現方案：

總體思路

監控系統設計的總體思路上，最重要的是“無痛”或者“無侵入”。

任何監控代碼，不在業務系統需要自定義的情況下，需要侵入到業務代碼里面，都是不可取的設計。同時接入配置應該盡量簡單。

如何做到無痛？主要方式是攔截和重寫。

比如，很多監控系統都會重寫 xhr（XMLHttpRequest）/ fetch來攔截請求， 例子：xhr 重寫上報示例代碼

proxyAjax.send = XMLHttpRequest.prototype.send;proxyAjax.open = XMLHttpRequest.prototype.open;// 重寫 openXMLHttpRequest.prototype.open = function(){// 先在此處取得請求的url、method等信息并記錄等處理// 調用原生 open 實現重寫proxyAjax.open.apply(this, arguments);}// 重寫 sendXMLHttpRequest.prototype.send = function () {// 調用原生sendproxyAjax.send.apply(this, arguments);// 在onleadend ontimeout等事件中上報，上報處理函數 handleMonitorthis.onloadend = function() {handleMonitor(someParams)}}// 上報函數handleMonitor = function(params) {this.send(params)}

比如，在對頁面事件的點擊記錄時，給document對象綁定click事件收集點擊就是攔截的一種。

例子：要注意的是在捕獲階段綁定，防止業務代碼中的阻止冒泡捕獲不到事件

document.addEventListener("click", function(event) {handleClick(event);}, false);

1、用戶使用場景

下面按照統計維度來說明一下統計指標的技術實現：

1.1 pv，uv

通常的方式對訪問當前域名的一個用戶植入一個cookies用于標識用戶身份，以傳統的統計口徑來看，對于pv，每次刷新頁面都 + 1，對于uv，在今天內訪問的用戶只會 + 1。這里有幾個注意點:

• 1、統計口徑：對于不同的產品，pv的統計口徑可能是不一樣的，有的要求首頁完全加載完才算一個pv，有的要求曝光1/4，有的需要dom加載完。根據需求的不同，綁定上報事件的時機也不同。對于監控系統來說，一般會實現通用口徑的pv統計，如果有其他不同需求，可以走后文提到的自定義上報流程。
• 2、防刷：對于pv/uv，有很多刷流量的方式，比如刪掉cookies，重新加載一次。對有賬號體系的系統，cookies和賬號綁定就可以防刷。對沒有賬號體系的系統，可以使用ip來限制，同ip發起多少次都算一個uv。防刷是個比較有趣的話題，限于篇幅，這兒簡略提一下，有興趣的同學可以一起進一步探討。
• 3、spa網頁：由于前端路由的存在，spa結構的網頁，傳統的pv很難反應網站的真實狀況，推薦使用uv或者rpv來觀測。

1.2 ip數

訪問ip數的統計有多種方式，這里介紹兩種主要方式：

• 1、接入層直接記錄：在接入層入口直接記錄來源ip，收到就 + 1，如有需要詳情也可以記錄更多信息，這種方式可能會增加當前系統的一些負擔。改造成MQ或者其他的異步方式，可以減輕對主干系統的影響。
• 2、分析日志：主流做法，分析接入層日志，對日志做統計即可得出ip數。

1.3 跳出率

根據上文提到的跳出率公式，需要計算當前頁面的打開次數，對于非spa且非hash的頁面，都可以用接入層統計的方式來計算url的打開次數。對使用hash路由的spa頁面，需要綁定hashchange事件或者框架提供的路由事件來進行上報。總訪問頁數同理。

1.4 平均訪問時長 / 平均訪問深度

根據計算公式，統計方法類似跳出率。

1.5 會話數量

這個沒太多好說的，服務端統計就完事了。

1.6 路由切換量（rpv）

重點講下這個，隨著前端路由系統的普及，當前 spa 是web系統的主要形態之一，對spa系統來說，統計的實現方式和 mpa 系統有很多的不同，一般來說統計路由切換量（rpv）需要手動開啟配置，比如阿里云arms就需要配置enableSPA = true。

前端路由主要是通過hash和history api來實現的，使用hash路由時hash值不會上傳服務器，需要前端來做捕獲上報，而history api的情況url是變化的，可以在后臺統計到。

hash路由的捕獲上報實現：

// hash路由綁定onhashchange事件if("onhashchange" in window) {window.onhashchange = handler}// history api類型路由的上報// 監聽popstatewindow.addEventListener('popstate', (event) => {// 上報處理handler()})

如果前端需要通過 history api來統計，這里也給出一些代碼實例

// history 只監聽 popstate事件可以處理掉大部分的api觸發window.addEventListener("popstate", function() {// 上報邏輯});// pushState 和 replaceState 不會觸發 popstate 事件，可以采用類似xhr的方式重寫

2、埋點，點擊流

埋點的實現上面其實已經提到了，本質上就是對事件的攔截，這里主要提一下自定義埋點上報的實現。

2.1 自定義埋點

自定義埋點上報，涉及到各監控系統api設計，一般來說，各監控系統的接入sdk都會給出自定義上報的方法，供業務系統自己控制上報時機和上報內容。 舉例：

// 自定義埋點實例,指定類型type，服務器解析數據并呈現monitor.diysend({type:'monitor', value: 't1=1&t2=2'})

2.2 點擊流

點擊流其實是通過根據統一的用戶標識把一系列的事件上報的用戶行為串起來的一種方式，結合以上的數據上報和頁面切換，可以構造出一個基于時間軸的用戶點擊操作流程。 示例頁面

點擊流示例頁面

3、場景回放，錄屏

場景回放和錄屏的技術實現，總的來主要有如下實現方式：

• dom 背景 + 回放操作：用當前頁面做背景，方法：1、iframe加載目標頁面放在下層做背景，2、用phantomjs截取當前頁面做背景，在背景之上根據上報數據重現用戶操作。這種實現不用特殊上報，只需要有點擊流的坐標數據即可。但其最大的問題在于回放操作和背景沒有交互，即使在背景中實現模擬操作，也可能存在一定的延遲。
• html2canvas：顧名思義，此方案的思路是把當前dom結構轉化成一張截圖，然后按照每秒24幀上傳圖片，后端和用戶操作組合一下，組成一個可播放視頻。這種方法的悲催在于上傳的圖片體積過大，導致出現一些性能問題。
• chrome 插件方式：使用chrome的插件權限實現錄屏，缺點是完全沒有兼容性，而且裝插件對用戶體驗不友好。
• dom 上報重建：思路是上報dom并重建，實現：上報首次的dom結構做基礎，后續使用增量上報方式，上報dom結構的變化，然后通過后端平臺，將數據組裝成可播放的視頻，這種方式的典型代表有rrweb等實現。這種方式對于canvas之類的非dom表現元素，需要做特殊處理，但已經是個比較成熟可用的方案了。

總的來說，以上錄屏方案中，dom上報回放是一個比較成熟的方案了，也有類似rrweb等成熟實踐，比較不容易遇到坑，可以考慮使用。

手已敲麻，行為監控的實現先寫這么多吧，下篇開始總結下異常監控的技術實現。

總結

以上是生活随笔為你收集整理的实现pv uv统计_聊聊前端监控（二）--行为监控的技术实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。