GTM 除錯清單：11 個可能造成 GTM 代碼沒有啟動的原因

有時候，即使我們已經設定好了追蹤代碼，開啟 GTM 的預覽模式時卻發現代碼並沒有按照預期運作，或是代碼明明顯示啟動了，但我的 GA4 卻接收不到任何的事件資料，偏偏老闆又急著要追蹤這個網站事件，當下卻抓破頭也想不透到底發生了什麼事情？

在這種情況下，進行 GTM 的除錯程序就顯得尤為重要。

在這篇文章中，我們將告訴你可以如何一步步檢查和找出可能的問題原因，當遇到代碼無法如預期運作的狀況時，雖然可能出現的問題原因有千百種，但我們會專注於幾個最基本且常見的設定錯誤。

這樣做的目的是讓你能夠快速排查是否有一些簡單的設定失誤導致了代碼無法正常啟動，從而有效地縮小問題範圍。

1. 打錯字

這大概是最常見的錯誤之一，也是最常被忽略的，我們往往把重點放在設定觸發條件的正確性，卻沒注意到打錯字這個可能性。

例如：在使用「點擊-僅連結」的觸發條件類型時，連結網址明明是 mktgholic.local/contact–us/ ，而在設定 Click URL 時卻硬是打成 mktgholic.local/contact_us/，就是「底線」跟「連結號」的細微差異就足以影響整個設定。

或是變數選擇了 Click Text，你很有自信地用打字的方式進行設定，但卻因此出了錯。

因此，當遇到這類情況時，我們建議直接從網站上複製所需的文字或網址，然後在 GTM 中進行貼上操作，這樣可以有效避免類似的錯誤。

抑或我們使用「可見度元素」作為觸發條件時，若在選擇 CSS 選取器或輸入元素的 ID 時輸入了錯誤的名稱，這也是一個常見的問題，對於那些還不太習慣閱讀 HTML 代碼的人來說，很容易打錯字或弄錯名稱。

在這類情況下，直接從網頁上複製所需的元素名稱，然後在 GTM 中進行貼上，仍然是最安全且有效的方法。

因此，如果發現代碼沒有如預期般啟動，先檢查一下設定的觸發條件是不是打錯字了，這個最基本的錯誤往往可以一解你心頭的心煩意亂。

所以，當你遇到代碼沒有按預期啟動的情況時，首先應該檢查的是觸發條件設定中是否有打錯字，這種基本的錯誤常常是導致設定失敗的主要原因，解決了這個簡單的問題，往往也一解你心頭的心煩意亂。

2. 把所有條件都放在同個 Trigger

這也是初期很常見的錯誤之一，之前的文章有提過，假設我們今天想要追蹤 3 個特定頁面，來到這 3 個頁面的使用者在執行某行為之後，啟動 GA4 事件代碼，假設這 3 個頁面的網址分別為：

mktgholic.local/event/Xmas-Eve
mktgholic.local/event/Merry-Chrimas
mktgholic.local/event/New-Year-Ready

於是我設定了一個網頁瀏覽的觸發條件類型，將 3 個網址放置在一起，變成下圖這個樣子：

當然，這絕對是行不通的，因為一個頁面只會有一個網址，不可能有同時存在 3 個網址的情況。

正確的做法是使用適當的規則運算式來精確定義觸發條件，進一步設定的細節，可以參考這篇文章內的：如何在同一個觸發條件裡使用不同網址？

3. 觸發條件未符合或是部分符合

當代碼沒有按預期啟動時，首先要檢查的通常是觸發條件設定，我們可以在 GTM 的預覽模式下查看未正確啟動的代碼卡片，瀏覽該卡片的底部，檢查是否所有條件都被標記為「綠勾」（表示滿足條件）或「紅 X」（表示不滿足條件）。這能幫助我們快速辨識問題所在，並針對觸發條件設定中的特定部分進行進一步的檢查與調整。

假設我設定的「點擊-僅連結」觸發條件如下圖所示，當點擊的連結符合mktgholic.local/contact-us/ 且該頁面主機名稱（Page Hostname）符合 mktgholic.com 時，就會啟動代碼。

如果發現綁定該觸發條件的代碼沒有啟動，我們可以先透過預覽模式中去點擊未啟動的代碼卡片，發現代碼卡片展開後，呈現如下圖這樣：

此時就可以知道是因為觸發條件設定有誤，所以必須要回到相對應的觸發條件中去修正，而不是修正代碼。

4. 設定成一個頁面只能啟動一次代碼

在 代碼設定頁面 > 進階設定 > 代碼觸發選項 的設定中，如果選擇了「每個網頁一次」，顧名思義就是你的代碼在這個頁面上不管符合觸發條件多少次，都只會啟動一次。

最常見的晴望就是頁面上設置了許多「點擊」追蹤事件，但因為設定到了「每個網頁一次」，造成後面其他點擊都無法啟動事件代碼。不過這部分不需要太過擔心，通常在設定代碼時，不會去碰觸到這個地方（預設都是每個事件一次），除非是有特定需求才會設定「每個網頁一次」這個代碼觸發限制。

另外值得一提的就是，這個設定是凌駕於所有觸發條件之上的，儘管今天所有觸發條件都符合，但因為「每個網頁一次」的限制，你的代碼卡片會變成像下圖這樣：

觸發條件全部都是「綠勾」，但代碼卻沒有觸發，這時就可以回到該代碼之中去檢查，是否有被「每個網頁一次」的限制，這點是在設定時可以留意的部分。

5. 新增例外項目/狀況（觸發條件）

當遇到代碼未如預期啟動的情況，請首先檢查代碼的觸發條件中是否設有「例外狀況」（如下圖）。

尤其是在接手前人設定的代碼時，你可能會發現大部分點擊都能觸發代碼，但某個特定連結卻無法觸發，這時候，就需要注意是否在該代碼的觸發條件中設定了某些「例外狀況」。

例如，可能設定排除了某特定 URL 或特定元素的點擊，導致代碼未能如預期那樣被觸發。

如果透過預覽模式查看，我們點開未啟動的代碼卡片，在卡片的下方，我們會看到一個名為「Blocking Triggers」的區塊，這邊顯示的就是「例外狀況」的觸發條件。

從圖中我們可以觀察到，啟動代碼的觸發條件和「Blocking Triggers」的觸發條件都被標記為綠勾。這表示該事件同時符合啟動的觸發條件以及「例外狀況」的條件。在 GTM 的優先級設定中，「例外狀況」擁有更高的優先度，因此當一個事件符合「例外狀況」時，即使它也符合啟動條件，代碼依然不會啟動。

注意觸發條件類型要一樣

上一段我們解釋了「例外狀況」可能是造成代碼不啟動的原因，如果今天你希望追蹤同一個頁面上所有的連結點擊，唯獨某一個特定連結不需要被追蹤，就可以利用這個方式來處理。

必須要注意的是，「例外狀況」的觸發條件類型需與啟動代碼的觸發條件類型是一樣的（如下圖），才可以有效運作，去阻止代碼的啟動。

反過來說，如果「例外狀況」的觸發條件類型與啟動代碼的觸發條件類型是不一樣的，以下圖為例，儘管使用者位在符合「例外狀況」條件的頁面中，那此代碼依然會被啟動，想要用「例外狀況」阻止代碼的啟動，你只能用同類觸發條件阻擋，異類觸發條件是無法溝通的。

6. 設定了觸發條件順序

接下來，我們將討論相反的情形：當你在 GTM 預覽模式中看到某些意外的代碼被觸發了，但在檢查代碼卡片時卻發現沒有相應的觸發條件，這種情況可能會讓人感到困惑：沒有設定觸發條件的代碼，是怎麼被啟動的呢？

在預覽模式中，我們無法透過代碼卡片看到這個代碼啟動的原因，主要是因為它沒有被設定觸發條件，也因此無法得知代碼被啟動的原因。

此時我們就必須要回到 GTM 代碼（Tag）介面中 > 找到被啟動的代碼名稱 > 點進去會看到觸發條件顯示如下：

在 GTM 「代碼」設定中有一個非常棒的功能，你可以指定某個代碼在另一個特定代碼啟動之前或之後執行，例如：設定在 A 代碼啟動之後，也啟動 B 代碼，儘管 B 代碼沒有任何觸發條件也會被啟動，但嚴格來說，「A 代碼啟動之後」就是其觸發條件。

以上圖的範例可以看到，我們的代碼會在「GA4Event-Click_link」之後觸發，接著找到「GA4Event-Click_link」的代碼設定介面 > 展開進階設定 > 代碼觸發順序 就會看到相關設定，如下圖：

另外還有一點需要注意的是，如果今天代碼有被設定到觸發條件以及代碼觸發順序，當這個代碼同時符合這兩個條件時，這個代碼是會被啟動 2 次的。

例如：我們指定當使用者來到這個頁面時觸發一次代碼，同時該頁面有另個代碼啟動後也會觸發這個代碼，這麼一來，這個代碼就會啟動 2 次，這種重複觸發的情況可能會導致數據追蹤上的誤差，因此在設定代碼時需要特別注意這一點，以避免不必要的重複追蹤和數據錯誤。

7. 設定了代碼啟動排程

GTM 提供了一項功能，允許你指定代碼「僅在」特定的時間範圍內啟動，這類似於社群媒體上的貼文發布排程，你可以在 代碼設定介面 > 進階設定 > 勾選自訂標記觸發時段 找到相關設定。

有時，由於設定的代碼過多，你可能會忘記某個特定代碼僅在設定的時間範圍內被啟動。因此，在進行 GTM 代碼管理時，特別需要留意這類時間範圍限制的設定，以確保所有追蹤活動都如期進行。

在「自訂標記觸發時段」被啟用的情況下，如果在預覽模式中點開代碼事件卡，你會看到「Blocking Trigger」區塊出現了如「schedule_start_xxxxxx」之類的訊息，這種訊息表明代碼僅在特定時間啟動，若當前時間不在這個預定的時段內，代碼自然不會執行。

8. 只在已發布的容器中觸發這個代碼

在「代碼觸發設定介面」的「進階設定」中，有一個選項是「只在已發布的容器中觸發這個代碼」。如果這個選項被勾選，意味著在 GTM 的預覽模式中，你將無法看到該代碼的觸發情況。

這也是除錯過程中可以檢查的項目，有時候一個帳號可能不止你一個人管理，當看到這個選項被勾選時，請記得先詢問其他共同操作者勾選的原因，以便進行恰當的調整。

當「只在已發布的容器中觸發這個代碼」選項被勾選時，在 GTM 預覽模式的代碼事件卡中，「Blocking Trigger」部分將不會顯示任何阻擋代碼觸發的資訊。這意味著若要找出未觸發代碼的原因，我們需要直接到代碼的設定介面進行檢查。

9. 「引號」的問題

這是一個初期安裝 GTM 容器到網站上很常見到但又卻不容易發現的錯誤，最常發生在你把 GTM 安裝代碼複製貼上給工程師時，因為文字編輯器編碼的差異，造成你的 GTM 代碼被更改變成錯誤的代碼，工程師放到網站上之後發現整個 GTM 容器都沒有被正確啟動。

原本的 GTM 代碼引號是「 ‘ 」，很有可能因為不同文字編輯器的關係，複製貼上出來後變成其它的形式，這點是很常見卻不容易發現的地方。

<!-- Google Tag Manager -->
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-M3345678');
<!-- End Google Tag Manager -->

10. 被限制部署代碼

對於一些大型網站來說，為了防止透過 GTM 安裝可能影響網站運作的 JavaScript 或其他代碼，工程師團隊可能會在資料層（Data Layer）中推送允許清單（allowlist）和封鎖清單（blocklist），用以控制在網站上可使用的 GTM 代碼、觸發條件和變數。更多詳細資料可以閱讀官方資料。

要了解工程師是否在網站上設定了這些限制，我們可以通過 GTM 的預覽模式進行檢查。通常，如果設定了限制性部署，你會在「Consent Initialization」事件之前看到一個與資料層相關的訊息，點擊查看這個訊息，你就可以看到哪些代碼或功能被限制，以及哪些被允許在網站上執行。

當發現這樣的限制影響了你的 GTM 追蹤設定，請與工程師部門聯繫，讓他們了解你想追蹤的項目，經他們評估是否會影響網站運作，再請他們將該項目從限制清單移除即可。

11. 代碼被「同意聲明模式」狀態拒絕

隨著各地區的隱私規範日漸嚴格，Google 為了因應法規，也開始要求使用其部分服務需要取得使用者同意，並傳送「Google 同意聲明模式」讓 Google 知道使用者同意與否。

除了善用「Google 同意聲明模式」控制與 Google 服務相關的追蹤代碼以外，我們也可以用其來控制其他代碼，透過 GTM 內建的「同意聲明總覽」進行設定，因此如果發現網站的代碼沒有正確啟動，我們也可以檢查一下是否因為同意聲明模式狀態為 denied 的關係所造成。

如果是因為這個原因，你會在預覽模式中看到如下圖的畫面：

進一步點開代碼卡片的話，可以看到儘管觸發條件滿足，上發出現了一排紅字 Not fired due to missing consent，更可以確認代碼因為同意聲明狀態為 denied 所以沒有啟動。

因此，如果發現代碼沒有正確啟動，除了檢查是否有我們前面提到的那些因素以外，檢查「同意聲明模式」所造成的代碼封鎖狀況也是可以注意的地方。

如果你對於「Google 同意聲明模式」尚不熟悉，可以參考這篇文章：如何用 GTM 設定 Google 同意聲明模式（Consent Mode）?

如果發現代碼真的是因為這個原因所以沒有啟動，有任何需要調整設定的地方，則可以參考這篇文章進行操作：如何用 GTM 的「同意聲明總覽」控制代碼的啟動？

總結

這篇文章中，我們列出了 10 個在使用 GTM 時常見且容易被忽略的錯誤。例如，許多用戶可能會在 GTM 中錯誤地將 class 標記為「#」，或將 ID 標記為「.」，又或者由於不同文字編輯器間的編碼差異，導致引號在複製貼上給工程師時變形，這些都是常見的錯誤。

當然，導致代碼錯誤或無法啟動的原因還有很多，我們所列出的這些只是冰山一角，相信還有許多錯誤是我們尚未遇到的。

因此，本篇提到的並不能涵蓋所有可能的錯誤情況，未來如果我們遇到其它值得分享的除錯技巧，我們也會更新本文，以供大家參考，現在，讓我們總結一下這篇文章中提到的這 10 個可能出現的錯誤：

下次代碼有問題時，可以將此篇文章當成檢查清單，一步一步確認是否有地方出錯喔！

延伸閱讀

如果你很喜歡這篇文章並且覺得內容有幫助，又剛有些多餘時間，歡迎看看其它文章，繼續探索（這坑？這地獄？這片樂土？）

同時，如果對於內容有疑問或是建議，也歡迎你留言告訴我們：）