現在的你，應該已經逐漸熟悉 GTM 的操作了，但有時候仍然會遇到一些讓人摸不著頭緒的情況。例如，為什麼「資料層變數」抓不到值？代碼（Tag）中的參數設定好了，但 GA4 卻沒有接收到？「事件」數怎麼和後台實際訂單數對不上？要設定的「事件」很多，重複的參數也很多，有更有效率的設定方式嗎？
這些意料之外的情況多得數不清，你可能花了一整天試著除錯，卻始終找不到問題所在。
不用擔心，出現錯誤是很正常的，但這些問題都是可以避免的。在這篇文章中，我們將整理出一些在使用 GTM 時常見的忽略錯誤，並提供相關的觀念和注意事項。往往就是這些沒注意到的小細節，耗費了你一整天的工作時間。
不要用「點擊」類型觸發條件追蹤表單「提交」按鈕
這個「錯誤」不算是設定上的錯誤，在預覽模式以及發布容器時都不會有任何問題，只要設定正確，代碼都會正確啟動，GA4 Debug View 也會接收到「 事件 」以及相關參數。
但是。
當你未來比對 GA4 上的「事件」數與實際收到的訂單或表單時，你會發現兩者之間有很大的落差。
這是因為，如果使用「 點擊」類型的觸發條件來進行「 事件」代碼的設定，不管該表單或訂單是否完成，當使用者按下「 提交」或是「 購買」按鈕時，該追蹤事件就會啟動，但這不是我們要的結果，因為我們只需要追蹤 成功提交或是購買的訂單 （也就是後台真正有收到的）。
ㅤ
舉個例子：
假設網站的表單要求使用者要填寫 Email、電話以及姓名，缺一不可，而使用者只填寫了電話以及姓名就按下「 提交」按鈕，畫面彈出警示，告知使用者有欄位尚未填寫。
此時你會注意到，儘管表單沒有提交成功，但使用「 點擊」類型觸發條件的「 表單提交事件」卻啟動了。
結果是，GA4 會收到一個成功提交表單的事件，但實際上並沒有成功提交。
ㅤ
如此一來，就會造成數據上的錯誤，你可能還會以為是網站出了問題，實則不然，其實是代碼設定上的「錯誤」。
要正確追蹤表單提交，請參考文章「 GTM 表單提交追蹤：你應該知道的 5 種設定方式」，如果想要正確追蹤電子商務事件，則可以參考這篇「 如何用 GTM 設定 GA4 電子商務事件？ 」
不要一次更改許多設定，然後一次發布
這也是極度需要避免的事，我們知道你時間很趕，上頭很急著想要追蹤事件盡快上線，以了解頁面的成效。
例如，假設今天需要設定網站的電子商務事件，有「 觀看產品頁面」、「 加入購物車」、「 開始結帳」、「 填寫運送資訊」、「 填寫付款資訊」以及「 購買」總共六個事件，同時也需要進行「 活動表單提交」的追蹤以及部落格文章與「 閱讀體驗 」相關事件。
在這麼多「 事件 」需要設定的情況下，建議不要一次設定，然後一次發布，儘管預覽模式測試都沒有問題，一旦發布到正式網站且出錯了，剛接觸 GTM 的你將很難排查錯誤，因為短時間之內可能無法查出是哪部分的設定造成網站出錯。
因此，我們建議，初期進行設定時，每完成 一到兩項 變更且測試正確之後，就將其發布到網站上，確認運作上都沒有問題，再進行下一容器版本的設定或調整。
不要「不跟」工程師團隊合作
這是許多行銷人員對於 Google 代碼管理工具很大的一個誤解，許多人以為，只要透過 GTM 就不再需要工程師了。
這可是個天大的誤會，我們更需要工程師的協助來幫助完善 GTM 的設定。
我們在過往的文章中強調過許多次，許多設定是需要工程師的協助，行銷人員才能透過 GTM 完成的，例如設定「電子商務事件」時，就會需要工程師幫忙進行「資料層（Data Layer）」的設定，才能抓取到商品相關資料並傳送給 GA4。
延伸閱讀》 如何準備給工程師的 GA4 電子商務 Data Layer 資料層文件？
ㅤ
使用 GTM 的好處是在於可以 減少打擾工程師的次數，簡單的追蹤事件不必麻煩工程師設定，行銷人員自行透過 GTM 完成即可，這點我們過去在文章「 為什麼要用 GTM Google 代碼管理工具？ 」都有提到過。
畢竟行銷的世界千變萬化，常常一覺醒來發現有時事梗可以搭配公司的商品或是服務，中午吃飯前便立馬要推出相關活動頁面，此時如果突然插件，要工程師在中午前於該活動頁面上安裝追蹤事件，萬一當天還是禮拜一，任誰應該都會不開心。
但是千萬不要以為有了 GTM ，就不需要工程師了，未來你可能會需要在網站上安裝你看不懂的 「 Javascript 代碼」，在放上網站之前，最好先請工程師審核該「 Javascript 代碼 」的內容，否則一個惡意的 Javascript 是很有可能會劫持整個網站，讓網站停擺的。
有時「 預覽模式」無法正常運作，可能是「內容安全策略 (Content Security Policy, CSP) 」或是「 Referrer Policy 」的關係，或者是網站安全性考量，部分代碼有被限制部署 ，此時我們也會需要工程師協助調整，才得以讓 GTM 順利運作。
因此，不要「不跟」工程師團隊合作，保持良好的溝通，同理也應用在任何部門，畢竟這世代的行銷，必須要把行銷與客戶、商業環節以及根據數位互動的策略，全部整合在一起，整體才能更流暢地運作。
不要隨意命名你的設定
你可能會想說，反正 GTM 都是我在設定的，那些「代碼」、「觸發條件」以及「變數」的命名只要我看得懂就好了。
不！
千萬別這麼想，你可能會升官，也可能會離開，不管怎麼樣總會有人要接手你的 GTM 容器，盡可能降低下一位接手人員的銜接困難度，是每一位 GTM 操作人員都應有的認知（畢竟本是同根生，相煎何太急）。
舉例來說，假設我們創建了一個「 點擊」事件，用來追蹤文章目錄的點擊，如果該「 事件代碼」的命名為 Click ，僅從名稱就很難理解這個事件的用途。
反之，如果我們將事件代碼命名為 GA4Event | Click Table Of Contents ，會不會讓人更快理解？這樣做不僅讓接手人員不用進去看細節或透過測試才了解，也能更有效地管理和維護 GTM。
ㅤ
除此之外，同樣的道理，在發布容器版本時，寫好每次的版本名稱至關重要。這樣一來，人們從外面看就可以一目瞭然，知道該版本做了什麼主要更新。
救人一命，勝造七級浮屠，請好好命名。
不要讓太多人有「發布」容器的權限
如果每個人都可以隨時隨地隨意地「 發布 」GTM 容器版本，那會造成管理上很大的混亂，沒有經過確認或是急於上線而進行的更改，都可能會導致網站的毀損，更糟糕的是，如果有人選擇在週五下班前更新了容器，萬一出了問題，可能連網站工程師都要陪你加班。
因此，我們建議每個 GTM 容器必須要有一位主要管理員，這位管理員除了擁有唯一的「 發布」權限以外，同時也要 負責維護容器的乾淨以及整齊度，例如「 代碼」、「 觸發條件」、「 變數」的命名規則以及「 資料夾 」的結構，並清楚了解其它操作人員更新了什麼項目，對整個 GTM 容器有一個全面的了解。
為什麼要這樣？
假設未來網站要進行改版，作為對整個 GTM 容器最了解的你，必須知道工程師團隊會修改哪些項目，以及這些修改是否會影響到相關代碼的運作。如果會影響，我們應該如何調整呢？
或是
假設協作人員 A 新增了一個「 變數」。你發現過去已經新增過類似功能的「 變數」，此時你可以建議協作人員 A 直接使用這個現有的「 變數 」，避免 GTM 容器的混亂。
這就是為什麼只有主要管理員擁有「發布」權限這麼重要的原因，千萬不要忽略這一點，保留這個權限給主要管理員，可以確保協作人員透過「工作區」完成的容器版本，都可以經過確認之後，才「發布」上線。
延伸閱讀 》 如何善用 GTM 的「工作區」來進行多人協作？
不要忘了備份你的 GTM
雖然 GTM 容器內的「代碼」、「觸發條件」以及「變數」等設定通常不會無緣無故消失，但是世事難料，有時候可能會發生一些無法預料的情況，讓整個容器不見（例如該 Google 帳號密碼被竄改，無法登入。），此時需要從頭設定的工作真的會讓你欲哭無淚。
GTM 操作介面選擇「管理」頁籤 > 選擇「匯出容器」 > 選擇「工作區」或任一「版本」號 > 「匯出」
記得定期進行備份，這真的非常重要。
不要什麼都想追蹤
這也是很大的一個誤區，當我們發現了 GTM 強大的功能後，開始想要追蹤使用者在網站上每一個可能的動作。
舉例來說，你可能想要追蹤網站上所有的按鈕，無論是哪一個按鈕都想要追蹤。
確實，GTM 是有這樣的能力，但問題是「為什麼要這樣做呢？」
ㅤ
如果你不知道要如何有效地運用這些「追蹤事件」所得到的數據，就不要設定該「追蹤事件」。
過多無意義的「 追蹤事件 」不僅會造成 GTM 容器的混亂，還會增加網站載入的速度，望周知。
不要自訂「會員編號」相關維度
如果網站有會員系統，就可以將「會員編號」透過 GTM 傳送給 GA4，藉此將於不同裝置上瀏覽網站但是有登入的會員，歸為同一位使用者，我們也可以更精準的運用這數據來進行再行銷。
GA4 有提供一個專屬的參數 user_id 可以使用，建議直接沿用作為「會員編號」的維度，當 GA4 收到 user_id 名稱的參數，會自動匹配到相對應的維度當中，我們就不需要去自訂維度，否則很容易因為高基數維度的關係，造成資料無法正確顯示。
ㅤ
至於該如何將會員編號透過 GTM 傳送到 GA4 呢？
可以參考文章：如何用 GTM 傳送 User ID 到 GA4？
錯誤的「資料層」推送順序
這是初期很常被忽略的錯誤，也就是「 順序 」問題。
即使你很確定網站的「 資料層（Data Layer）」上面有你要的資料，也確定 GTM 中的「」已經設定正確，資料層變數名稱的欄位沒有打錯字，但是卻始終無法獲取到該變數的值，它總是顯示為 undefined 。
最常見的原因就是事件發生的順序問題，資料還沒有推送到「 資料層」，但是使用該「 資料層變數 」的代碼卻已經啟動了，如下圖：
下次如果發現「 資料層變數」無法正確抓取到值的情況，請同時檢查是否是 因為推送順序的問題 ，造成這樣的異常。
錯誤的「資料層」推送代碼
如果你使用以下代碼推送網站資料到「 資料層 」，雖然可以運作，但有機會造成資料抓取的錯誤。
因為在 Javascript 中，這樣的寫法等同於定義了一個新的 Javascript 變數，如果頁面上只有單獨這段代碼，那運作上是沒有問題的。
但如果網站上同時有好幾段相同的代碼同時推送資料到「 資料層」，最新的就會覆蓋掉之前推送的，網站上的「 資料層 」將只保留最後一段代碼推送的資料（如下圖）。
因此，如果要請工程師協助推送網站資料到「 資料層」，請使用下方的代碼。較常運用到資料層推送的部分會是在設定「 GA4 電子商務事件」時，此時請務必參考 Google 官方文件 建議的撰寫方式。
初學的階段，如果看不懂 Javascript 代碼沒關係，這階段只需要知道推送到「 資料層 」的正確代碼應該長什麼樣子就夠了。（但如果有餘力，可以慢慢去理解 Javascript，當有些狀況無法透過 GTM 內建的項目完成時，就會需要 Javascript 的協助。）
ㅤ
另外，還有一個觀念需要了解。
在與工程師合作時，我們建議可以先準備好要推送的代碼文件，因為不一定每個工程師都能理解 Data Layer 的運作方式，所以我們不能只是把 Google 官方文件丟給工程師，自己就沒事了。
這關於這部分的設定，可以參考文章： 如何準備給工程師的 GA4 電子商務 Data Layer 資料層文件？
錯誤的「觸發條件」使用邏輯
假設我們為了聖誕節的行銷活動製作了 5 個頁面（辛苦你了設計師），只要有使用者看過其中一個頁面，我們就觸發同一個 GA4 事件代碼，可能是一個促銷彈窗，或是單純的瀏覽事件。
而這五個頁面的網址網域都相同，都是 www.abc.com，唯獨網址路徑（page path）不同，分別是：/Xmas、/HBD、/BlueM、/HNY 以及 /BlackFriday 。
初期剛接觸 GTM 的朋友，可能會如下圖這樣設定觸發條件，直接在 同一個網頁瀏覽觸發條件 下新增多個網址。
這樣的設定方式是行不通的。一個網頁只能有一個網址，因此不可能同時具有五種不同的網址。這樣的設定方式將永遠無法滿足觸發條件，因此「 代碼 」也不會啟動。
關於這個錯誤的解決方法，請參考文章： GTM 中的「或」：用不同啟動時機條件觸發相同代碼
沒有用 GA4 Debug View 確認
好不容易完成了所有 GTM 中的設定，透過「預覽」功能也看到了「事件代碼」正確啟動，並且帶上了該事件應有的參數，大功告成，你準備「提交」這個容器版本到正式站上。
休淡幾勒！
如果你是用 GTM 安裝 GA4 的朋友，不要忘了還要到 GA4 Debug View 中確認 GA4 是否有收到正確的「 事件 」，GTM 負責發送，GA4 負責接收，有時可能發送端沒有問題，但卻在接收端出了狀況，這是個很常被忽略的錯誤（可以理解，畢竟終於設定好了，當然迫不及待想要正式發佈）。
但再等等，確認接收端沒有問題再發佈也不遲。
沒有善用「Google 代碼：事件設定」變數
如果有一些參數在多個「 事件代碼」中會重複使用，建議可以使用「 Google 代碼：事件設定 」變數來為你省去重複設定的麻煩。
例如，「 電子商務事件」相關的代碼通常會需要使用到相同的參數，如 currency、 value 或是 items 等，透過設定一次「Google 代碼：事件設定」變數，就可以在所有「 事件代碼 」的設定中共用參數的設定，如下圖。
（當然，這邊是舉例，如果網站的「資料層」的格式有符合 Google 電子商務資料的規範，只需要在代碼「更多設定」中勾選「傳送電子商務資料」就可以了。）
完成設定後，未來在設定相關事件時，只要「 代碼」設定介面中透過下拉選單選取該「Google 代碼：事件設定」變數，所有參數便會自動帶入「 代碼 」中了。
善用「Google 代碼：事件設定」可以幫助你減少了許多重複設定的動作，是不是很方便呢？
總結一下
這些內容是我們在學習和使用 GTM 初期常見的錯誤和容易混淆的觀念，也是我們過往實踐中曾經踩過的坑。希望透過這篇文章，能幫助初接觸 GTM 的你避免重蹈一樣的覆轍，浪費了你自己的時間，也影響到團隊的運行，尤其是與工程師合作的過程中，越能夠減輕工程師的負擔，你的專案也能越順利的進行。
人非聖賢，孰能無過。
不可能不會犯錯，重要的是如何避免再次犯錯，未來，如果我們有新的經驗可以補充這篇文章，我們也會隨時更新。
如果你有任何過去曾踩過的坑，但這篇文章中未被提及，歡迎留言或在社群媒體上告訴我們，我們將會納入你的建議，使更多初學者在學習GTM的路上更加順暢。
