週五下午五點，客戶的行銷專員在 GTM 裡加了一個表單送出的代碼，按下「提交」就下班了。下週一我們打開 Google Ads，發現轉換數從每天十幾筆變成每天一百多筆，自動出價已經照著這個錯誤數字跑了整個週末。
原因很單純：觸發條件設成「所有點擊」，而不是「表單送出」。只要在發布前開一次預覽模式，花五分鐘點一點，這個問題當場就會被看到。
GTM 最大的好處是不用改網站程式就能埋追蹤碼，最大的風險也是這個。改起來太容易，大家就容易跳過檢查。這篇要講的就是那五分鐘到底該檢查什麼。
為什麼 GTM 改完一定要先預覽？
因為 GTM 發布後是立刻對所有訪客生效的，錯誤的代碼會直接污染正式數據，而且這些數據事後刪不掉。預覽模式讓你在只有自己看得到的情況下，模擬整個容器在網站上的運作，確認沒問題再發布。
很多人覺得「我只是改一個小地方」，但 GTM 的代碼、觸發條件、變數是互相牽連的。改了一個變數的名稱，可能讓三個代碼同時失效；複製一個代碼忘了改觸發條件，就會變成重複計算。
我們接手新客戶時會先把整個容器跑一次預覽，老實說，十個容器裡大概有三、四個藏著重複觸發或根本沒在運作的代碼。如果你對 GTM 的代碼、觸發條件、變數這三個基本元件還不熟，建議先讀這篇 Google Tag Manager 完全教學，再回來看除錯會比較好懂。
怎麼開啟預覽模式？
在 GTM 工作區右上角按「預覽」，會開啟 Tag Assistant 頁面，輸入要測試的網址後按「Connect」，系統會開一個新分頁載入你的網站。網站分頁的角落出現「已連線」的小視窗，就代表預覽模式成功啟動。
這時候你會同時有兩個分頁：一個是你的網站，一個是 Tag Assistant 的除錯畫面。在網站分頁裡的每個動作（換頁、點按鈕、送出表單），都會即時出現在 Tag Assistant 左側的事件列表。
連不上的話，最常見的原因是廣告攔截外掛或瀏覽器擋了第三方 Cookie，建議開一個乾淨的瀏覽器設定檔專門用來除錯。網站如果分成多個網域（例如結帳頁在另一個網域），跳過去後預覽可能斷線，要在 Tag Assistant 裡把新網域也加進來。
Tag Assistant 畫面要看哪些地方？
除錯畫面分成左右兩塊。左邊是事件時間軸，右邊是你選取那個事件當下的詳細狀態。看懂這兩塊，九成的問題都能自己找出來。
左側的事件時間軸
每載入一頁，左側就會新增一組事件，依序是「Consent Initialization」「Initialization」「Container Loaded」「DOM Ready」「Window Loaded」。之後你在頁面上的點擊、表單送出、自訂事件，會一個一個往下排。
點選任何一個事件，右邊就會顯示「在這個時間點」哪些代碼觸發了、變數的值是多少。這個「時間點」的概念很重要：同一個變數在 Container Loaded 和 Window Loaded 時的值可能不一樣。
右側的四個分頁
代碼（Tags）：分成「已觸發的代碼」和「未觸發的代碼」兩區，這是最常看的地方。
變數（Variables）：列出每個變數在該事件當下的值，用來確認觸發條件拿到的值對不對。
資料層（Data Layer）：顯示網站推送給 GTM 的原始資料，電商追蹤除錯時特別常用。
錯誤（Errors）：代碼執行出錯時會在這裡顯示。
上線前要檢查的五件事
預覽模式打開之後，不要只是確認「有觸發」就收工。我們內部的檢查清單是這五項，每次發布前逐一跑過。
第一，該觸發的有觸發。 在網站上實際走一次要追蹤的流程：瀏覽商品、加入購物車、送出表單。每一步都到 Tag Assistant 確認對應的代碼出現在「已觸發」區塊。
第二，不該觸發的沒觸發。 這一項最常被跳過。點一下頁面上其他不相干的按鈕、換到其他頁面，確認表單代碼沒有跟著觸發。開頭那個週末暴增的轉換，就是死在這一項。
第三，每個代碼只觸發一次。 同一個事件底下，如果同一個代碼出現兩次，或者兩個不同代碼送了同一個事件，報表上的數字就會加倍。
第四，送出去的參數值正確。 點開已觸發的代碼，看它實際送出的參數。訂單金額是數字還是字串？幣別有沒有帶？商品名稱是不是空白？
第五，GA4 那端真的收到。 GTM 顯示「已觸發」只代表代碼有執行，不代表資料送到了。最後要到 GA4 的 DebugView 交叉確認，做法在下面。
| 檢查項目 | 在哪裡看 | 常見錯誤 |
|---|---|---|
| 該觸發的有觸發 | 代碼分頁「已觸發」 | 觸發條件的網址或 CSS 選擇器寫錯 |
| 不該觸發的沒觸發 | 點其他元素後的代碼分頁 | 觸發條件設成「所有點擊」 |
| 只觸發一次 | 同一事件下的代碼清單 | 新舊兩版代碼同時啟用 |
| 參數值正確 | 代碼詳細資料、變數分頁 | 金額帶到含逗號的字串 |
| GA4 收到資料 | GA4 DebugView | 評估 ID 填錯或被同意模式擋下 |
第五項怎麼做：GA4 DebugView
GTM 預覽模式開啟時，送往 GA4 的事件會自動帶上除錯標記，所以你可以在 GA4 後台的「管理」→「資料顯示」→「DebugView」即時看到自己這台裝置送出的事件。
點開事件確認名稱拼對、參數有帶到。為什麼不能只看 GTM？因為評估 ID 填錯、同意模式沒取得授權、外掛攔截，都會讓 GTM 顯示「已觸發」但 GA4 什麼都沒收到。DebugView 偶爾會延遲幾十秒，不要看到空白就急著改設定。如果已經上線一陣子才發現數字對不起來，可以參考這篇 GA4 數據不準確的排查方法。
檢查完再發布：版本說明一定要寫
按「提交」時，GTM 會讓你填版本名稱和說明。我們的習慣是「日期＋改了什麼」，例如「0906 新增預約表單送出事件」。另外一次只改一件事，發布隔天回來看事件數量有沒有暴增或歸零，有問題就從「版本」頁面直接回復上一版。
代碼沒有觸發，要從哪裡查？
先看觸發條件，再看變數值，最後看資料層，照這個順序查最快。絕大多數「沒觸發」的問題，都是觸發條件比對的變數值跟你以為的不一樣。
具體做法是：在 Tag Assistant 裡點開那個沒觸發的代碼，畫面會列出它的觸發條件，並在每個條件旁邊標示是否符合。例如條件是「Click Text 等於 立即預約」，但實際抓到的 Click Text 是「立即預約 」（後面多一個空白），條件就不成立。
如果觸發條件依賴的是自訂事件，就到資料層分頁看網站有沒有真的推送那個事件，以及事件名稱的大小寫是否完全一致。GTM 的比對是區分大小寫的，「purchase」和「Purchase」對它來說是兩件事。
還有一種情況是變數根本沒有值。內建的點擊變數（Click Text、Click URL 等）預設是沒有啟用的，要先到「變數」頁面勾選啟用，觸發條件才拿得到值。這個坑我們看過不下十次。
案例：購買事件重複計算的那一週
去年我們協助一家賣保養品的電商網站做追蹤健檢。對方的困擾是 GA4 顯示的月營收比金流後台多了大約八成，老闆完全不相信 GA4 的數字。
我們開預覽模式走了一次結帳流程，到了感謝頁，代碼分頁裡同時出現兩個 GA4 purchase 代碼。追下去發現，前一位接手的工程師升級過電商追蹤，新版代碼用資料層的 purchase 事件觸發，但舊版那個用「感謝頁網頁瀏覽」觸發的代碼沒有停用。另外，感謝頁重新整理一次，舊代碼又會再送一次。
處理方式是停用舊代碼，新代碼的觸發條件加上交易編號判斷，同一個交易編號只送一次。發布前再用預覽模式重跑三次結帳，包含重新整理感謝頁，確認每次只有一個 purchase。
修正後隔月比對，GA4 營收跟金流後台的差距縮到 4% 以內，剩下的差距主要來自擋追蹤的瀏覽器，這在可接受範圍。更重要的是，Google Ads 的目標廣告投資報酬率出價終於拿到正確的訂單價值。
已觸發不等於資料正確，發布前要看的是送出去的數字。
常見問題
Q：預覽模式會影響正式網站的訪客嗎？
不會。預覽模式只對連上 Tag Assistant 的那個瀏覽器分頁生效，其他訪客看到的仍然是目前已發布的版本。但預覽期間你自己送出的事件會進到 GA4 正式資源，如果介意，可以搭配內部流量排除。
Q：發布之後才發現錯誤，該怎麼補救？
先到「版本」頁面把上一個正常版本重新發布，止血最重要。已經進到 GA4 的錯誤數據無法刪除，只能在報表上註記異常期間，分析時排除那幾天；Google Ads 的轉換則可以依實際狀況調整或上傳修正。
結語
GTM 的預覽模式不難用，難的是養成「不預覽不發布」的習慣。該觸發的有觸發、不該觸發的沒觸發、只觸發一次、參數正確、GA4 真的收到，這五項跑完再按提交，大部分的數據災難都能擋在門外。
下一步：打開你現在的 GTM 容器，直接按預覽，從首頁走到轉換完成頁，看看有沒有哪個代碼觸發了兩次。很多人第一次這樣做，就會發現一個藏了好幾個月的問題。