更新時間：2026年6月5號
完成GA4設定後，最重要的工作不是立即查看報表，而是先確認資料是否正確送出。
GA4提供了一個內建的即時偵錯工具DebugView，可以即時查看事件、參數及使用者屬性的傳送情況，是GA4實作與驗證過程中不可或缺的重要工具。
本篇將帶你完整認識DebugView的功能、啟用方式、介面說明，以及常見問題排查技巧。
認識DebugView
DebugView是GA4內建的即時偵錯功能，可讓開發人員、分析師或行銷人員即時查看事件傳送狀況，方便驗證資料蒐集是否正確。
透過DebugView，你可以：
- 驗證事件是否成功觸發
- 檢查事件參數是否正確傳送
- 確認使用者屬性設定是否生效
- 測試電商追蹤資料
- 驗證自訂事件與轉換事件
進入路徑：在GA4點擊「管理」——「資源設定」——「資料顯示」——「DebugView」：
啟用DebugView的三種方式
在網站環境中，最常見的 DebugView啟用方式共有三種：
- 使用Chrome裡的擴充功能Google Analytics Debugger
- 使用GTM的預覽模式
- 添加debug_mode參數
方法一：使用 Google Analytics Debugger
首先於Chrome安裝Google Analytics Debugger擴充功能。
安裝完成後，點擊瀏覽器右上角的擴充功能圖示，將 Google Analytics Debugger 固定至工具列：
打開要偵錯的頁面，然後點擊Google Analytics Debugger，點擊它會顯示on，就表示進入偵錯模式
此時回到GA4的DebugView頁面，如果開始出現事件資料，即表示設定成功。
方法二：使用GTM預覽模式（推薦）
這是目前最常用的偵錯方式。
在GTM中點擊右上角的“預覽”進入Tag Assistant偵錯模式，完成網站連線後，所有透過GTM送出的GA4事件都會自動進入DebugView。
回到DebugView，若能看到事件資料，即表示已成功進入偵錯模式。
方法三：添加debug_mode參數
除了上述兩種方式外，也可以透過新增debug_mode參數，讓資料直接進入DebugView，有兩種方式：
- 一種是添加Google Analytics 4的基本設定，GTM中所有的設定（事件）都會生效，我的GA4基本設定是“Google Analytics 4 Basic Tracking”
- 一種是僅添加在要偵錯的設定，如你相對某個事件做偵錯，那麼就只在該事件的代碼添加debug_mode
如果你不知道用哪種方式，就選用第一種即可，接下來給大家示範如何添加debug_mode參數，打開GA4基本設定是“Google Analytics 4 Basic Tracking”，在「要設定的欄位」裡做如下設定：
debug_mode設定為true，GTM 裡點擊預覽調試後，如果在DebugView看到有資料，就表示成功進入偵錯模式。
注意：DebugView雖然屬於即時報表，但仍可能有數秒至數十秒的延遲，通常不超過 1 分鐘。
DebugView的介面導覽
DebugView的介面如下：
DebugView 主要可分為五個區塊：
- 偵錯裝置當前進入偵錯、測試狀態的裝置
- 分動態：以分為單位顯示事件數，圈裡的數值就是事件總數，一點擊它，秒動態就會顯示裡面所有的事件
- 秒動態：以秒為單位顯示事件數，圈裡的數值就是事件總數
- 熱門事件：過去30分鐘觸發的事件
- 使用者屬性目前有效：過去30分鐘觸發的使用者屬性
偵錯裝置
左上角的「偵錯裝置」可切換不同測試設備。
若有多位人員同時進行偵錯，可以透過下拉選單選擇自己的裝置，避免資料混淆。
分動態
畫面中央的圓圈代表：每一分鐘內觸發的事件數量
點擊任一圓圈後，下方秒級事件流便會顯示該分鐘內所有事件。
秒動態
此區塊顯示：最近 60 秒內收到的事件，每筆事件都會附帶時間戳記。
點選任一事件可查看相關的參數：
隨著使用者屬性值在應用程式使用期間有所改變，串流動態中會持續顯示相關事件，最晚發生的事件會顯示在最上方。
熱門事件
顯示在30分鐘期間記錄的熱門事件：
可以點擊右上角的圖標去過濾。
使用者屬性目前有效
顯示目前使用者屬性，你可以點擊右上角的圖標，可以查看過去30分鐘的變更記錄：
DebugView實際偵錯範例
用DebugView的偵錯調試用法是：進入偵錯模式後，在頁面模擬行為或事件，然後返回DebugView，偵錯裝置裡找到你自己的調試裝置，先點擊分動態，然後在秒動態中找到對應的事件：
點擊該事件，查看相關的參數和使用者屬性是否準確：
如果準確，就表示事件追蹤設定沒問題。
常見問題與排除方式
DebugView出現重複事件
最近（2023年3月24號）很多人會在DebugView裡調試的時候會遇到有重複事件，如：
原因：排除重複部署和重複觸發，這其實是Bug，很多用戶都遇到
处理方式：等官方修復
DebugView中價格顯示錯誤
如果你用DebugView去調試，你會看到price多了很多了6個0：
原因：GA4 為了提升儲存與運算效率，內部會將浮點數轉換為整數格式處理。
处理方式：這不會影響正式報表中的金額數據，可直接忽略。
Debugview偵錯裝置有很多個
如果你在偵錯裝置裡看到很多的設備：
原因：通常是將debug_mode被誤發佈到正式網站。
处理方式：將“要設定的欄位”裡的debug_mode設定移除，在發佈到線上，然後等30分鐘就可以。
DebugView裡沒資料
- 资料延时：DebugView了的资料会有一些延时，但最多不超过1分钟
- 資料篩選器：被資料篩選器過濾，所以沒有資料
- 瀏覽器插件：瀏覽器插件屏蔽發給GA4的資料或影響報告介面
- Bug: 2025年5月9號起，GTM預覽調試的時候，Debugview裡沒有資料，多次刷新後，有時會有部分資料，估計是bug
第二個網頁的UTM參數丟失
有些人在使用DebugView的時候可能會留意到，比如著陸頁的 https://www.haranhuang.com?utm_source=admin
- 第一個page_view事件是有source參數admin
- 第二個page_view事件就沒有source參數
有些人就擔心，source參數是不是丟失了。
其實不是的，UTM是工作階段級別的，它一進來的時候，UTM參數就和工作階段ID綁定，後面的事件都會和工作階段ID綁定，所以默認就打通的了。
工作階段ID在Cookie _ga_<container-id>裡。
為什麼我更推薦使用Tag Assistant？
雖然DebugView可以驗證資料是否成功送達GA4，但它有一個限制：無法告訴你事件為什麼沒有觸發。
例如：
- 觸發條件設定錯誤
- Data Layer 沒有推送資料
- 變數取值失敗
這些問題DebugView都無法協助定位。
因此實務建議Tag Assistant為主，DebugView為輔（甚至可以不用）