Google Tag Manager：追蹤碼不用再找工程師改

Photo by Filip Barna on Unsplash

行銷同事想在官網加一段新的轉換追蹤碼，流程通常長這樣：寫信給工程師、等排程、兩週後上線、再花一週確認有沒有裝對。等數字能看了，那檔活動也結束了。

反過來的情況也很常見。官網跑了五年，版型檔案裡陸陸續續被塞進十幾段來路不明的程式碼，有的是前一任行銷裝的，有的是代理商留下的，現在沒人說得出哪一段還在用、哪一段可以拔。改版的時候工程師不敢動，只好整包複製過去。

Google Tag Manager（以下簡稱 GTM）就是為了這兩件事存在的。它不會讓你的數字變準，但它會讓「誰在什麼時候裝了什麼」這件事，第一次有地方可以查。

GTM 到底做了什麼事

先釐清一個常見誤會：GTM 不是分析工具，它不產生任何報表。它比較像一個收納櫃——網站上只留一段 GTM 的容器碼，之後所有追蹤碼都掛進這個櫃子裡，由 GTM 決定什麼時候執行哪一段。

操作上只有三個名詞要搞懂：

• 代碼（Tag）：實際要執行的那段程式。GA4 的事件、Meta Pixel、Google Ads 的轉換追蹤，都是一個代碼。
• 觸發條件（Trigger）：什麼時候執行。瀏覽特定頁面、點擊某顆按鈕、送出表單、捲動到頁面七成的位置。
• 變數（Variable）：執行時要一起帶出去的資料。訂單金額、按鈕上的文字、目前頁面網址、表單類型。

所以一件事情講完整會是：「當訪客送出聯絡表單時（觸發條件），執行 Google Ads 轉換代碼（代碼），並帶上這張表單是詢價還是售後（變數）。」整段設定在 GTM 後台用下拉選單選完，網站的程式碼一個字都不用改。

搬進去之前，先盤點現在掛了幾段

Photo by Kier in Sight Archives on Unsplash

最常見的錯誤，是一開容器就急著把新的碼掛上去，舊的放著不管。結果櫃子有了，地上那堆線還在。

導入前先做一件沒什麼技術含量但很關鍵的事：打開官網，在瀏覽器按右鍵檢視原始碼，或裝 Google 官方的 Tag Assistant 之類的檢查工具，把目前頁面上跑了哪些第三方程式碼列出來。常見的發現包括：

• 同一組 GA4 評估 ID 裝了兩次，一次在版型、一次在佈景主題的設定欄位
• 已經停止服務的舊版 Universal Analytics 追蹤碼還留著，每次載入都多打一次沒人接收的請求
• 前一家代理商的廣告像素還在跑，合約早就結束了
• 某個聊天機器人或熱圖工具，試用期過了但碼沒拔

建議做成一張表，欄位只要四個：代碼名稱、裝在哪個檔案或後台欄位、當初是誰要求裝的、現在還有沒有人在看那份報表。第四欄填不出來的，多半就是可以拔的。先拔再搬，不要把垃圾一起搬進新櫃子。

三個最常踩的坑

一、重複計數

這是導入 GTM 最常出事的地方。舊的轉換碼還寫在版型檔案裡，又在 GTM 裡重新裝了一次，於是同一筆訂單被記錄兩遍。

症狀很好認：GA4 或廣告後台的轉換數跟實際訂單對不上，而且差距大約就是兩倍。麻煩的是這不只是報表難看——Google Ads 的自動出價是吃轉換數字在跑的，數字灌水兩倍，系統會以為這個受眾很值錢，於是把預算往那邊推，廣告費就這樣燒掉了。

檢查方式是用 GTM 內建的預覽模式，實際走一次下單流程，看同一個事件被觸發了幾次。搬完的一週內務必對一次，不要等月報才發現。

二、觸發條件抓得太寬鬆

很多人用「瀏覽感謝頁」當作成交的判準。問題是感謝頁的網址可以直接被輸入、可以被加入書籤、客戶重新整理一次就再算一次，而且有些爬蟲也會走到那裡。

比較穩的做法是用表單實際送出成功的事件當觸發條件；如果是電商，則在感謝頁帶上訂單編號當變數，同一個編號只認列一次。這兩件事在 GTM 裡都設定得出來，但要先想清楚才設，而不是先設了再看數字對不對。

三、同意管理被當成裝飾

台灣適用的是個人資料保護法，規範方式跟歐盟 GDPR 不同，但只要官網會接到歐盟訪客——外銷型企業幾乎都會——情況就不一樣了。

比較常看到的落差是：官網底下擺了一條 Cookie 同意條，訪客按不按都沒差，追蹤碼照樣在同意前就全部載入。GTM 有同意模式（Consent Mode）可以設定，讓代碼等到訪客同意後才執行。如果同意條只是擺著好看，那它既沒有合規效果，又平白擋掉一部分訪客的視線。

版本與權限：GTM 真正值錢的地方

Photo by Charly Álvarez on Unsplash

如果只是為了少麻煩工程師，那 GTM 的價值其實被低估了。對一間沒有專職技術人員的公司來說，它最實際的好處在另外兩件事。

第一是版本紀錄。GTM 每次發布都會存成一個版本，可以寫備註說明這次改了什麼。萬一發布後官網出狀況，或是數字突然不對，可以一鍵回到前一個版本。直接改版型檔案是做不到這件事的——那只能靠工程師記得先備份。

第二是權限分層。GTM 的權限分成檢視、編輯、核准、發布四級。這讓「讓代理商自己裝碼」這件事變得可控：給代理商編輯權限，讓他們把要裝的東西設好，但發布的按鈕留在公司自己手上。對方做了什麼、什麼時候做的，紀錄都在。

還有一個容易被忽略的細節：容器要開在公司自己的 Google 帳號底下，不要掛在員工的個人帳號。這跟網域、主機要登記在公司名下是同一個道理，差別只在於等到發現時，前者通常已經是離職交接的現場了。

什麼情況不適合全部丟進 GTM

GTM 不是萬用解。有幾種情況，用它反而會製造新問題。

會改動畫面的程式碼要謹慎。有些 A/B 測試工具會透過 GTM 去替換頁面上的標題或按鈕。因為 GTM 是頁面載入後才執行的，訪客有機會先看到原本的版面、再看到被換掉的版本，畫面閃一下。這同時會影響 Core Web Vitals 裡的版面位移分數，而那是 Google 納入評估的項目。

跟錢有關、必須準確的紀錄不要只靠前端。瀏覽器的擋廣告外掛、網路中斷、使用者提前關掉分頁，都會讓前端的追蹤漏掉。營收數字請以金流後台和自家訂單系統為準，GTM 收到的數字拿來看趨勢和分配廣告預算就好。

碼堆太多會拖慢頁面。容器本身很輕，但裡面每一段代碼都要下載、解析、執行。十幾個第三方工具同時跑，手機上的體感差距很明顯。建議半年清一次，把不再使用的工具停用。

如果要開始，先做這三件事

一、盤點。把官網目前跑的第三方程式碼列成一張表，標記哪些還有人在看。這一步不需要任何工具採購，也最容易被跳過。

二、開對帳號。用公司的 Google 帳號建立容器，一開始就把權限分層設好，而不是等人要離職了才處理。

三、搬完要對數字。上線後一週內，用預覽模式實際走一次詢問單或下單流程，確認每個事件只被記錄一次，並且跟後台的實際筆數對得上。

說到底，GTM 解決的不是「怎麼追蹤得更準」，而是「這件事到底歸誰管」。一間公司的官網上跑著什麼程式碼、是誰決定裝的、什麼時候可以拔掉——這些問題如果沒有地方可以查，追蹤再多指標也只是把混亂記錄得更詳細而已。