在我們使用 GTM 時，強調了設定完畢之後必須使用「預覽」功能進入 Tag Assistant 來測試代碼的重要性，同時，也必須要來到 GA4 中的「DebugView」觀察相對應的 GA4 資源是否有收到 GTM 發出的「GA4 事件」。（當然，前提是你用 GTM 安裝 GA4）
但事情往往可能沒有那麼順利，就像是使用 GTM 預覽功能時，也可能會因為一些原因出錯，這也是為什麼我們撰寫了一篇類似檢查清單的文章，當 GTM「預覽」模式有問題時，可以透過該文章來排查可能的狀況。
而今天這篇文章，我們則來看看，幫助我們觀察 GA4 是否正確接收資料的「DebugView」，如果沒有正常運作的時候，例如：GTM 中的「GA4 事件」有啟動，但是「DebugView」中卻沒有看到資料進來，我們可以怎麼辦？
讓我們繼續看下去。
ㅤ
本篇重點
DebugView 在哪裡？
點選 GA4 介面左下角的齒輪 > 展開「資源設定」區塊 > 展開「資料顯示」 > 選擇「DebugView」
ㅤ
#1 阻擋廣告的擴充套件
這是最常遇到的情況了，許多人在瀏覽器中安裝了阻擋廣告的擴充套件，且習慣到早已忘記有安裝這個東西，於是就掉入了「抓破頭也想不透為什麼 DebugView 沒有收到資料的深淵當中」，最後才發現是瀏覽器中阻擋廣告的擴充套件在作祟，例如 Adguard, Adblocker 或是 Ghostery 這些都會影響到 GA4 以及 GTM 代碼的運作。
因此正確來說，不是這些擴充套件阻擋了「DebugView」的運作，而是阻擋了整個 GA4 以及 GTM 的運作，也難怪會看不到了。
ㅤ
#2 GA4 資料篩選器的阻擋
仔細想一下，在使用「DebugView」時，你的電腦是否使用公司的網路？而網站的 GA4 資源阻擋了來自公司的 IP 流量，也難怪「DebugView」不會正常運作了。
點選 GA4 介面左下角的齒輪 > 展開「資源設定」區塊 > 選擇「資料收集和修改」 > 選擇「資料串流」> 「進行代碼設定」 > 「定義內部流量」
ㅤ
如果是這樣的情況，可以先轉換至自己的手機網路或是使用 VPN 去進行測試，或是到後台的「資料篩選器」當中，將「內部流量」與「開發人員流量」的篩選器暫停，「DebugView」應該就會有資料進來了。
點選 GA4 介面左下角的齒輪 > 展開「資源設定」區塊 > 選擇「資料收集和修改」 > 選擇「資料篩選器」 > 點擊「內部流量」後面三個點 > 在原本是「有效」的狀態下，會出現「停用篩選器」
ㅤ
#3 選錯裝置（或沒得選）
（最常見）
這也是很常見的錯誤，在使用「DebugView」時，需注意左上角的「偵錯裝置」是否有選對？
ㅤ
在這種情境下會有三種情況：
- 沒選到（你沒選擇偵錯裝置）
- 選錯（明明只有你在測試，卻跑出好多裝置）
- 沒有偵錯裝置顯示（顯示為 0）
這邊的裝置，指的其實就是你所使用的電腦，例如，我們使用 Apple 筆電，那麼這邊就會顯示 Apple（如下圖）。
ㅤ
#3-1 沒選到
因此，如果「DebugView」一直沒有資料進來，首先可以先確認左上角的「偵錯裝置」選單是否有選到裝置，有時會出現有裝置，但沒選到的狀況。
ㅤ
#3-2 選錯
有時你可能會納悶，明明只有我一個人在管理 GTM/GA4，但為什麼會有其它裝置的出現呢？
其實 DebugView 判斷是否為同一裝置的依據是來自於 GA4 在你瀏覽器中儲存的「使用者 Cookie」，如果今天不小心在偵錯的過程當中，清除了該「使用者 Cookie」，那麼當你再度透過打開 GTM 預覽模式回到網站時，就會被判定為另一個裝置。
（這邊說的「使用者 Cookie」其實就是 GA4 中的 Client ID）
ㅤ
為了講述這個現象，所以講到了 Client ID，但扯得有點遠了，想要多瞭解這部分的朋友，可以跳去看這篇文章：「GA4 中的 Client ID 和 User ID 分別是什麼意思？」
而在同樣的情況下，如果你沒有清除「使用者 Cookie」卻還是出現多裝置的原因，就是 GA4 自己的 Bug 了，這個在初期很偶爾會碰到，隨著 GA4 越趨穩定目前幾乎是沒有見過這樣的情況。
ㅤ
#3-3 沒有裝置顯示
請重新整理畫面或是關閉整個 GA4 的頁籤重新進到「 DebuView 」，或是點擊「下拉選單」的箭頭，通常就會有裝置顯示且有資料進來了。
ㅤ
#4 內容安全策略 CSP 阻擋了 GA4 的啟動
「內容安全策略 (Content Security Policy, CSP) 」是一種網頁安全標頭，主要是用在防止跨站腳本攻擊 (Cross-Site Scripting, XSS)、資料注入攻擊等常見的網頁攻擊，如果你有在網頁 <head></head> 的位置看到類似下圖的代碼，就必須要跟網站工程師討論，是否有阻擋 GA4 或是 GTM 的載入，如果有，請工程師允許網站載入 GA4 的網域 analytics.google.com。
ㅤ
或是到開發者工具當中的「Console」頁籤觀察，是否有出現以下畫面？ 因為「內容安全策略」的影響，拒絕了外部 script 的載入。
（下圖為示意，因為我們測試網站的 GA4 是透過 GTM 安裝的，因此會看到後面的網址為 www.googletamanager.com，而不是 analytics.google.com，因為 GTM 容器先被擋住了，GA4 追蹤代碼當然也不會出現 ）
ㅤ
#5 「同意聲明工具」的影響
「同意聲明工具」是用來讓使用者選擇是否要授權給網站追蹤的，有時候 GTM 操作人員可能「忘了」自己最近清理過瀏覽器的 Cookie，或是在測試時沒有點選「同意聲明工具」，那麼 GA4 或是 GTM 的追蹤代碼就不會啟動，也因此 GA4 DebugView 不會收到資料了。
ㅤ
如果真是如此，你的 GTM 「預覽」模式應該也不會啟動，這點我們在之前的文章「11 個 GTM預覽功能無法啟動的原因」也有提到，想進一步瞭解的朋友可以去參考該篇內容。
延伸閱讀》如何用 GTM 設定「Google 同意聲明模式（Consent Mode）」
ㅤ
#6 啟動 DebugView 的方式錯誤
如果想要使用 GA4 的 DebugView，有以下這些方式：
- 使用 GTM 預覽模式
- 使用 Chrome 擴充套件「 GA Debugger 」
- 在事件參數中，加入 debug_mode 等於 true
#6-1 GTM 預覽模式
使用 GTM 「預覽」模式這部分就不多做介紹了，相信大家應該都會了？
如果不熟悉的朋友，可以參考這篇文章》如何用 GTM 「預覽模式」檢查代碼有無設定成功？
ㅤ
#6-2 GA Debugger 擴充套件
如果覺得每次測試都要打開 GTM「預覽」模式很麻煩，那麼可以使用這個 Chrome 瀏覽器專屬的套件「GA Debugger」，在想要測試的頁面打開之後重新整理畫面，相對應於該網站的 GA4 DebugView 就能夠收到測試資料了。
最後，測試完畢之後記得關掉，否則你的正常瀏覽，也會變成 Debug 模式。
ㅤ
#6-3 加入 debug_mode 參數
（謹慎使用）
GA4 DebugView 之所以會收到測試資料，是因為網頁發送給 GA4 的數據中，加入了 _dbg=1 的參數，GA4 因此判斷此為測試資料，我們可以透過網頁開發者工具看到如下圖的資訊。
打開「GA Debugger」或透過 GTM 「預覽」功能來到測試網站 > 網頁上點選右鍵 > 於展開的表單選擇「檢查」 > 選擇「Network」頁籤 > 搜尋「 collect 」 > 點擊下方的收集事件 > 右側的 Request URL 中可以看到 _dbg=1
ㅤ
除了上述兩個方法，我們也可以在 GTM 的 Google Tag 代碼或是特定 GA4 事件代碼中加入 debug_mode 等於 true 的參數，就可以使得每次收集的事件或是特定事件帶有 _dbg=1 的參數，GA4 DebugView 也就能收到測試資料了。
ㅤ
需要注意的是，當你發布容器後，如果是在 Google Tag 中加入了 debug_mode 等於 true 的參數設定，那麼網站上所有的事件，都會變成測試事件（包含一般使用者瀏覽網站或是觸發相關事件的行為等），當然，如果是在特定事件中加入 debug_mode 等於 true，那麼該事件未來會不斷在 GA4「DebugView」中出現，即便是正常瀏覽的情況下也是一樣，且上述這兩個情形還會產生另一個結果就是：「你的 DebugView 中會出現超級多的測試裝置！（因為正常使用者也被判定為測試裝置了）」
如果只是想透過 GA4「DebugView」 來進行測試，其實可以不需要使用這個方式，使用 GTM 預覽模式或是「GA Debugger」擴充套件就已經足夠了。
ㅤ
#7 數據處理延遲
數據處理延遲指的是從用戶觸發事件到這些事件顯示在 DebugView 中可能需要幾秒鐘到數分鐘不等的時間，這種延遲主要受 GA4 的即時處理和傳輸過程的影響。
當用戶觸發某個事件（例如點擊按鈕或訪問網頁）後，事件數據需要從用戶的設備發送到 Google Analytics 的伺服器，並進行處理和分類。這個過程通常是幾秒鐘內完成，但在網速較慢、伺服器負載較高或事件數據量較大時，可能需要更多時間。
另外，DebugView 的數據更新頻率大約為每 10-20 秒一次，但在部分情況下可能需要等待更長的時間才會顯示最新的數據，因此當你在 DebugView 中測試事件時，如果頻繁觸發事件，可能會導致 DebugView 內的數據暫時無法及時更新。
因此，如果前述的情況都已經嘗試過了，那麼可以稍等一下，可能只是因為單純的延遲所造成的不正常運作。
ㅤ
#8 重新載入 GA4
這應該是屬於 GA4 Bug 的部分，如果 DebugView 依然沒有收到資料，可以嘗試重新整理畫面或是將整個頁籤關閉，甚至是將瀏覽器整個重啟之後，重新進入 GA4「DebugView」介面，有時候就會恢復正常了。
ㅤ
#9 用到了 Brave 瀏覽器？
雖然使用 Brave 瀏覽器的人相對的少，但還是寫一下，避免千嘗試萬嘗試，就是沒嘗試排除這個問題，這是一款隱私保護的瀏覽器，在不用裝任何擴充套件的情況之下，會自動阻擋 GA4 追蹤代碼，因此 GA4「DebugView」當然也不會啟動。
ㅤ
總結一下
我們在許多文章中千叮嚀萬交代，儘管 GTM 中設定好了「GA4 事件」代碼觸發成功了，也一定要來到 GA4「DebugView」觀察是否有收到資料，因此了解「DebugView」觀察沒有正常啟動的可能原因，就是相當重要的一件事情。
隨著 GA4 日漸成熟，過去常見的一些狀況，在今天都已經很少遇到了，最常碰到的大概就是沒選到、選錯裝置，或是 DebugView 裝置顯示為 0，但是點擊下拉選單之後，測試裝置就出現了，因此當遇到有人詢問 GA4 DebugView 沒反應時，我們都會請他先看看裝置選單的部分，未來，我們應該都會直接貼這篇排錯清單，方便大家一一排錯。
你還有遇過什麼 GA4 DebugView 沒有正常運作，但是用了上述之外的方法排除的情況嗎？歡迎告訴我們，我們可以將其加入文章當中分享給更多人知道，畢竟，相信你我都知道那種照著正常程序操作，但卻依然沒有得到想要結果的苦 🫨
ㅤ
延伸閱讀
如果你很喜歡這篇文章並且覺得內容有幫助，又剛有些多餘時間，歡迎看看其它文章，繼續探索（這坑？這地獄？這片樂土？）
同時，如果對於內容有疑問或是建議，也歡迎你留言告訴我們：）