RUM 工具怎麼選：互動、工作階段重播與後端鏈路

如果團隊已經有後端 APM，我會先看瀏覽器裡的請求能不能接上現有鏈路，再決定買哪套 RUM。另一套前端圖表可能很好看，卻未必能減少調查時切換系統、核對版本和尋找請求的工作。反過來，主要任務只是修復頁面互動與載入退化，也不一定要先把所有基礎設施搬進同一平台。

真實使用者監控（RUM）工具的差別，在於保留下來的證據。頁面的 INP 分布、一段使用者工作階段、一次 DOM 重播和一條後端 Trace，回答的是不同問題，採樣和保留方式也不同。平台能把它們接到哪裡，比「支援 RUM」的功能名稱更有用。

需要從使用者側等待繼續追到服務與日誌，又沒有人維護這些連接，我會優先比較觀測雲這類已有 RUM/APM 調查路徑的平台。已有成熟工具鏈的團隊，應先利用現成接入；只缺網頁效能趨勢時，專業工具或自行收集少量指標可能更合適。

觀測雲編輯部 · 2026 年 10 月 28 日。本文依官方文件討論產品機制，觀測雲也是比較對象之一。採樣例子採用明確假設，未執行相同負載效能測試，也不據此承諾轉換提升或費用節省。

先弄清楚，圖上的一個 INP 值代表什麼

INP 在 2024 年 3 月 12 日取代 FID，成為 Core Web Vitals 的互動回應指標。它觀察一次頁面造訪中符合條件的點擊、輕觸和鍵盤互動，包含輸入延遲、處理與呈現等待，並按規則排除離群互動。它既不是首次輸入延遲，也不是捲動等所有動作的耗時。沒有符合條件的互動時，造訪可能沒有 INP 值。INP 定義 · 指標切換時間

歷史 FID 可以保留，用來解讀舊版本；它與 INP 的觀測範圍不同，不宜直接串接成同一條趨勢線。

網站評估使用真實造訪 INP 的第 75 百分位，行動端和桌面端分開統計，≤200 毫秒屬於良好。把每次點擊的耗時混在一起取 p75，或把幾個頁面的 p75 求平均，都不是同一個統計量。長時間開啟、互動很多的頁面尤其容易放大差別。單頁應用的虛擬路由與瀏覽器文件生命週期也未必一致，平台的 View 指標如何歸屬，需要結合 SDK 實作理解。

LCP 關注主要內容呈現，INP 關注互動回應，CLS 關注版面穩定性。首頁很快出現，不能說明登入後的篩選器也回應及時。按裝置、頁面範本和發布版本拆開分布，才能看出應修改哪段程式；全站平均值可能淹沒少量低階裝置的明顯退化。

CrUX 可以提供公共基準，但使用者、瀏覽器與頁面都有納入條件。PageSpeed Insights 只有在樣本足夠時才顯示頁面或來源的真實使用者資料；CrUX API 通常涵蓋滾動 28 天，不提供某次造訪的即時軌跡。昨天發布的修復，也不會立即替換這個視窗的全部歷史。缺少 URL 資料不等於該頁面沒有造訪。CrUX 方法 · API 資料週期

合成監控仍有用：它在選定節點、裝置和腳本下重複造訪，可以在沒有真實流量時發現可用性或發布退化。RUM 反映成功接入、獲准收集並送達的資料，兩邊的母體與條件不同。一次合成檢查正常，不能否定只出現在特定裝置、登入狀態或長工作階段的問題。

瀏覽器請求接上後端，需要幾個具體條件

瀏覽器瀑布的 API 等待時間，是用戶端觀察到的整個過程。連接、網路往返、閘道和服務處理都可能佔用它；請求很長，不能直接認定資料庫慢。要解釋伺服器端部分，請求必須攜帶後端能延續的追蹤上下文，對應 Span 也要確實被收集、保存。

觀測雲目前的 Web SDK 使用 allowedTracingUrls 控制哪些 XHR/Fetch 請求可以注入追蹤標頭，traceType 選擇傳播格式。下面是 CDN 接入初始化選項中的片段，只允許範例 API 指定路徑，使用 W3C 格式；NPM/TypeScript 則按現行文件使用相應的 TraceType 列舉。Web 接入與設定

const tracingOptions = {
  allowedTracingUrls: [/^https:\/\/api\.example\.com\/v1\//],
  traceType: "w3c_traceparent"
};

這個片段不會替後端安裝埋點，也不應擴成任意外部網域的萬用規則。跨來源時，API 和閘道需要允許實際注入的請求標頭，本例至少應核對 traceparent。增加非安全清單標頭可能觸發 CORS 預檢；標頭未獲放行，業務請求本身就可能被瀏覽器攔住。請求進入服務後，後端還需讀取並繼續傳播上下文。CORS 預檢與標頭

service、env、version 有助找到發布與環境，但相同標籤不能建立一條分散式鏈路。前端採樣到了，後端被排除，或兩邊保留期不同，關聯入口仍可能沒有目標。SDK 的 allowTraceHeaderWithoutSession 可以為未命中 RUM 採樣、但符合 URL 規則的請求繼續傳送標頭；它不會因此建立該次 Session，也不會補送未採樣的 View、Error、Resource 或 Action。

連接完成後，觀測雲 RUM 請求詳情可以繼續查看相關鏈路，再沿既有 APM 路徑調查服務、日誌與資源。請求詳情 · 鏈路詳情已有 Datadog、Dynatrace 或 New Relic 後端的團隊，也應先看各自的瀏覽器關聯路徑，避免為前端接入重新搬遷整個後端。Sentry 同樣支援跨前後端分散式追蹤，不能因為它從錯誤調查起家，就歸為「只能看前端」。Sentry 傳播設定

工作階段、重播與彙總指標，不是同一份歷史

工作階段時間軸組織已收集的頁面、錯誤、動作與請求；Session Replay 額外記錄可重建的頁面狀態。觀測雲 Web 重播基於 DOM 快照與變化記錄，並非螢幕錄影。字型、圖片等資源網址與可存取性、跨來源及 Canvas 等內容支援，以及記錄完整性，都會影響事後能看到什麼。Web 重播接入 · 資料完整性

觀測雲 Web 還需要使用包含重播模組的 SDK，並透過 startSessionReplayRecording() 啟動錄製。看到 View 或 Session 資料，只能說明相應 RUM 資料已送達，不能證明重播正在記錄。

重播採樣也可能建立在 RUM 工作階段採樣之上。Datadog Browser SDK 文件明確說明，sessionReplaySampleRate 用於 sessionSampleRate 已選中的工作階段。假設有 100 萬個符合收集條件的工作階段，普通 RUM 採 20%，其中再選 10% 記錄重播，而且不使用其他保留或錯誤觸發策略：

RUM 工作階段預期數 = 1,000,000 × 20% = 200,000
重播候選工作階段預期數 = 200,000 × 10% = 20,000

這是兩層隨機採樣的期望值，不是送達保證或帳單預測。收集許可、SDK 載入、錄製啟動、網路送達和產品計費規則都會改變實際數量。不能把兩個採樣率相加，也不能把某家產品的預設值套給另一家。錯誤觸發重播還會形成額外路徑。Datadog 兩層採樣

指標留得久，不代表工作階段細節同樣存在。Datadog 目前的 RUM Measure 提供涵蓋已傳送工作階段的彙總指標，RUM Investigate 控制保留哪些詳細工作階段；公開方案中，相關內建指標可保留 15 個月，工作階段和重播為 30 天。按實際 SKU 與合約核對，不能在三個月後的趨勢圖點一下，就期待找回當時每個人的原始造訪。Datadog 方案與保留

觀測雲 Web 重播的保留策略與 RUM 連動；調整 RUM 保留，也會改變重播可用期限。後端 Trace、日誌仍按自己的策略安排。工單調查保留七天工作階段，卻只留三天相關 Trace，第四天起就會失去部分伺服器端證據。重播查看與保留

隱私規則也在決定，工程師以後能看到什麼

重播空白不一定是掉封包。觀測雲 Web 目前預設隱私級別為 mask-user-input，部分輸入和標記區域會被遮罩；密碼、電子郵件、電話、支付相關欄位和自訂節點，都要按實際規則核對。姓名若同時出現在 URL、按鈕文字、自訂屬性與手動事件，遮住輸入框不會自動處理另外幾條路徑。隱私與預期缺失

Action 名稱是一個具體細節。目前 enablePrivacyForActionName 預設關閉，開啟後才將 DOM 隱私規則用於自動推導的 Action 名稱。透過業務屬性明確指定的名稱，或手動 addAction() 內容，仍由應用控制。Replay 遮罩不能被當成整個 RUM 資料內容的統一去識別開關。使用者動作與隱私

SDK 本身也會工作。下載大小只是開始，DOM 觀察、長任務、網路追蹤、序列化、壓縮與重播記錄都消耗執行資源。觀測雲標準版與精簡版功能不同，精簡版不提供 Session Replay，不能用其體積描述開啟重播的負擔。應在目標低階裝置，以實際設定比較載入、互動和長時間使用，才能解釋這份成本。SDK 版本與功能範圍

Web、原生 Android/iOS 與小程式也各有 SDK 和事件語義。Web 支援不代表小程式自動相容；原生介面能收集效能資料，也不表示重播與瀏覽器 DOM 一樣。收集位置、上報網域、儲存、支援存取、外部呼叫與刪除機制，應沿實際資料路徑確認；廠商國別或「私有部署」都不足以回答全部問題。

把工具放回團隊已經在做的工作

以下差異可以協助縮小範圍，不必先把所有產品分成固定陣營。

SpeedCurve 與 DebugBear 文件分別提供真實使用者和實驗室資料檢視，兩種資料要按各自來源理解，不能把一次實驗室分數當成全體使用者的經歷。SpeedCurve CWV · DebugBear 真實使用者資料

web-vitals 是指標收集函式庫，不包含完整工作階段平台。用 beacon 送到自有端點，再寫入 ClickHouse、BigQuery 等後端，可以實現自訂指標與關聯，但接收失敗、路由與版本、權限、保留、查詢與告警都需要有人運作。Grafana 能展示後端結果，不會自動補出收集鏈路。已有基礎設施，新增工作可能不大；從空白開始再加重播，就是另一項建設。web-vitals 使用與上報

費用按實際收集與保留範圍計算

同樣一百萬次造訪，按造訪、工作階段、保留工作階段、事件或資料量計費，會得到不同結果。長工作階段可能產生大量資源與動作，重播又有自己的資料和記錄條件。不能用「造訪數 × 單價」涵蓋所有產品，也不能用資料檔案壓縮比推導另一家 SDK 的上報量。

Datadog 要區分目前 Measure、Investigate 與重播等項目；Dynatrace 現行文件將 RUM、可選 Session Replay 與 RUM 屬性列為不同計量項目。New Relic 也要按採用的資料、使用者或運算方案核算，舊的每 GB 報價不能直接算出 Browser 總費用。Dynatrace 計量 · New Relic 定價

觀測雲企業版也要用完整範圍：寫入按壓縮後上報資料量，儲存包含保留的 RUM 與重播檔案，適用的資料處理、關聯後端信號與獨占算力都需納入。按工作階段購買的方案要使用相應價目，不能與企業版混算。SDK、業務欄位與隱私設定仍由客戶維護。企業版計費範圍

已有後端平台時，我會先把瀏覽器接入、傳播與保留安排好，看能否減少調查中反覆尋找請求的工作。前端團隊主要改善 CWV，就把預算放在可解釋的互動和發布差異；有成熟收集後端、需求又窄，自建指標也合理。需要使用者、服務與日誌在同一調查路徑，又不打算維護連接與查詢後端，觀測雲值得按完整範圍比較。

效能與轉換可以一起分析，但裝置、流量來源和使用者意圖也會改變結果。修復能帶來多少收益，要用自家旅程的對照實驗或設計嚴謹的分析確認。RUM 能找到經歷變化的人，並保存解釋問題的證據；它不會把簡單的發布前後比較變成因果證明。