現在的你，應該已經逐漸熟悉 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的路上更加順暢。
延伸閱讀
如果你很喜歡這篇文章並且覺得內容有幫助，又剛有些多餘時間，歡迎你看看其它文章，繼續探索（這坑？這地獄？這片樂土？）
同時，如果對於內容有疑問或是建議，也歡迎你留言或是到右邊的社群上找我們，我們都會盡我們所知道的進行回覆：）
