使用 Google Tag Manager 可以快速地進行追蹤碼埋設，但當出錯時也會耗費大量時間排查，這篇文章想與大家分享有效率的除錯技巧，這篇文章將鎖定在『在怎樣的情況下必須記錄數據』，涵蓋『預覽模式、觸發條件設定、觸發條件與常見的排錯技巧』。
假設你進行了以下設定“當使用者完成購買時，進行 Google Ads 轉換 – 購買事件的埋設“ (也受用於 GA4 / Meta 的 Purchase)，的除錯步驟。
第一步 – GTM 容器是否已經確實安裝
請再次確認 GTM 是否確實安裝，有 2 種方式，根據情況進行選擇。
- Tag Assistant 能否偵測到容器: 在沒有權限的情況下，快速確認。
- 預覽模式是否能開啟: 在有權限的情況下，進行最確實的確認。
Tag Assistant 能否偵測到容器
這是最快的方式，如果網站不複雜，應該都只有裝一套的話，只要在 Tag Assistant 直接輸入網址就可以進行 Google Tags 的檢測，例如下圖表示了，網站內包含 2 個 Google Tags，一個 GTM 以及 GA4 代碼。
預覽模式是否能開啟
請在 GTM 後台的容器頁面內右上角，點擊『預覽』，如果成功在畫面右下角將會看到『預覽模式面板』。
接著輸入網址
點擊 Connect 後，如果能夠確實看到右下角的資訊面板，那代表容器已經確實安裝。
第二步 – 版本是否發布且線上正在使用
這是容易被忽略的環節，請再次確認你做好的變更是否已經發布，並且上線。
第三步 – 觸發條件除錯
如果環境確認沒有問題，就可以來關注觸發條件本身，
通常不外乎是打錯字、用錯變數，或者 GTM 運作不如你的預期，
你可以在開啟預覽模式下，自己走一次流程，觀察完成動作的當下的相關資訊。
先點擊左邊的事件，再點擊 Tags Not Fired 區塊裡的代碼，就能夠開啟以下面板，幫助你釐清是哪個條件不被滿足。
從圖片中可以看出來，很明顯是選錯變數了，應該要選擇的是 Page URL 才對，你可以根據你的設定條件，逐一排錯，
這也是為什麼前面最一開要強調觸發條件是用來定義『在怎樣的情況下必須記錄數據』。
同場加映 – 購買數據為什麼重複?
我們將會以 Google Analytics 4 Event- Purchase 為例，這份數據普遍被認為是重要的。
一樣與觸發時機有關，我們再來看到這張圖，這張圖有兩個條件，_event 其實就是觸發條件類型，也被稱為 GTM 網頁事件，如果網頁事件重複產生，就會導致代碼被啟動多次，導致重複數據。
假設以自訂事件觸發條件為例
我設定了每當有 purchase 事件發生在特定頁面，就啟動代碼，但事實上有可能因為某種原因，使該網頁出現多次相同的事件。
一樣打開預覽模式，先確認是否有重複啟動的情況；點擊左邊的頁面標籤，鎖定範圍是在購買完成頁，接著查看 Tags Fired 區塊，每個代碼將會顯示在當前頁面，代碼啟動了幾次，如圖片看到是 Fired 2 time(s)。
因為 purchae
如何解決
以下幾種方式，可以同時使用，來最大限度避免重複資料。
- 聯絡網頁工程師
- 代碼在頁面僅觸發一次
- 代碼附帶去重複的資料
聯絡網頁工程師
解鈴還須繫鈴人，必須將這樣的現象反應出去，因為難保是否其他地方也有類似的情況，如果是自家工程師，請帶上一杯星巴克，如果是 WordPress 可以反應給外掛提供商，而對於 Shopline 跟 Shopfy 的情況，之後會另開一集來做討論。
觸發條件在頁面僅觸發一次
如果等工程師修要個好幾天，那數據不就會一直錯下去了嗎? 有個快速的方法，在代碼進行進階設定，避免代碼重複啟動。
可以看到預設是 每個事件一次 ，可以改為每個網頁一次。
代碼附帶去重複的資料
各家廣告廠商其實也知道會有這樣的問題，像是 Google Ads 與 Google Analytics 4 的購買行為追蹤，都是有附帶去重複功能，只要你在送數據時提供訂單編號，預設就會幫你排掉這種重複送數據的情況。
例如 Google Ads 代碼裡有個 交易 ID 欄位，使用資料層變數就可以將訂單編號動態的填入此欄位，有機會我們將另開一集來討論。
