GA4 與 GTM 教學：一套可以重複套用的追蹤骨架

GA4↗ 與 GTM↗ 教學：一套可以重複套用的追蹤骨架

太長不看版： 追蹤做不好，多數時候不是因為你 GTM 不熟，是因為你在還沒決定要量什麼之前就先把容器裝上去了。裝完再想事件，結果每個案子的事件名都不一樣，報表沒辦法橫向比。這篇給的是一組固定骨架：四個事件、一種 dataLayer 寫法、一份自訂維度清單、一套驗證順序。骨架固定下來之後，新案子的追蹤是「照抄再改參數」，不是「重新設計」。

我看過太多人的 GTM 容器長這樣：三十幾個代碼，事件名有 button_click、有 click_cta、有 按鈕點擊，同一件事在三個案子叫三個名字。要比較 A 客戶跟 B 客戶哪個 LP 的 CTA 點擊率高，得先花半小時把名字對起來。

問題不在工具，在順序。

先決定要量什麼，再開 GTM

正確的順序是：先在紙上（或任何地方）把這個案子的成交路徑寫出來，再決定路徑上哪幾個點值得量，最後才打開 GTM。

多數人反過來。先裝容器、接上 GA4，然後看著介面想「還可以追什麼」。這種做法的結果一定是事件越加越多、每個都追一點、每個都追不完整，而且因為是想到才加，命名毫無章法。

寫成交路徑不用很複雜，一個案子三行就夠：

落地頁 → 點主 CTA → 加 LINE 好友 → 業務回報成交

這條路徑上有四個節點，你的事件就是這四個，不多也不少。頁面上還有什麼「分享按鈕點了幾次」、「捲動到 75%」，先不要。這些數字很好看，但你不會拿它做任何決定。

判斷一個事件該不該追，只有一個標準：這個數字變了，你會改什麼？答不出來就不追。

一組固定的事件命名

骨架的核心是這四個，任何案子都套得上：

重點不在這四個名字有多聰明，在於它們跨案子固定。

固定命名的好處在你手上有第二個案子的時候才會浮現。所有案子的 cta_click 都指同一件事，你就可以把三個品牌的 GA4 併在同一張表上看到站率跟意圖率，一眼看出誰的 LP 卡在哪一段。命名各自為政的話，這件事永遠做不成。你會停在「先把資料整理成一致格式」，而那一步每次都得重做。

差異放在參數，不放在事件名。同一個 cta_click，用 cta_position: hero / cta_position: footer 區分位置，用 cta_text 記按鈕文字。這樣事件數量不會膨脹，而你要拆的維度一個都沒少。

順帶一提，如果你的終點是 Meta 廣告↗，事件名還要對得上 Meta 的標準事件（Lead、Purchase 那組）。自己發明名字會讓 Meta 的最佳化找不到訊號。

dataLayer 該放什麼、放在哪

dataLayer 是網頁跟 GTM 之間唯一的正式介面。網頁把發生的事情丟進去，GTM 從裡面取。

兩個位置問題先講清楚：

第一，dataLayer 的初始化必須在 GTM 容器碼之前。 這是 GTM 教學裡最常被跳過的一行，但它是硬規則。容器載入的當下會讀一次 dataLayer，你在容器之後才宣告，那一次讀取就是空的，靠 dataLayer 決定的初始設定全部失效。

<!-- GTM 容器碼放在這行下面 -->

第二，事件用 push，不是重新賦值。 window.dataLayer = [...] 會把之前的東西整個蓋掉，包含 GTM 自己塞進去的內部資料。永遠用 push。

window.dataLayer.push({
  event: 'cta_click',
  cta_position: 'hero',
  cta_text: '立即領取'
});

至於該放什麼，原則是放「網頁才知道、GTM 猜不到」的東西。網址、來源、裝置這些 GTM 自己有內建變數，不用重複塞。要塞的是商業層的資訊：這是哪一種頁面、哪一個品牌、方案價格、會員等級。這些只有你的後端知道。

自訂參數一定要註冊成自訂維度

這是 GA4 事件設定裡最多人踩的一個，而且它的症狀特別會騙人：資料收得到，但報表查不到。

你在 GA4 的即時報表點開事件，看到 cta_position: hero 好好地躺在那裡，於是判定「設定完成」。三天後你要拉一張「各 CTA 位置的點擊分佈」，發現維度清單裡根本沒有 cta_position 這個選項。

原因是 GA4 對自訂參數的處理分兩段：收集是自動的，可查詢不是。參數要進到報表，得先去「管理 → 自訂定義 → 自訂維度」把它註冊起來。沒註冊的參數就靜靜地存在事件裡，你看得到單筆，但沒辦法拿它做任何彙總。

更痛的是註冊之前的資料不會回溯。今天才註冊，就只有今天以後的資料能用那個維度切。前面兩週的資料等於白收。

所以流程要反過來：只要你在 dataLayer 裡新增一個參數，同一輪就把自訂維度註冊掉。 別留到「之後要看報表時再說」。

註冊時記得看範圍：跟著單次事件走的（CTA 位置、按鈕文字）選事件範圍，跟著使用者走的（會員等級、來源管道）選使用者範圍。選錯的話報表會出現對不上的數字，而且不能改，只能重建一個新的。

配額也要留意，事件範圍的自訂維度有數量上限。這又是「先決定要量什麼」比較划算的一個理由。每個能追的都追，配額會先被垃圾參數吃掉。

驗證：GTM 說 fired 不等於成功

這是我最想講的一段。

GTM 預覽模式（Preview / Tag Assistant）告訴你的只有一件事：在這個瀏覽器裡，這個代碼被觸發了。它不知道資料有沒有離開瀏覽器、GA4 有沒有收、參數在傳輸中有沒有被丟掉。

只看預覽模式就結案，你會漏掉這些：GA4 評估 ID 貼錯（代碼照樣 fired，資料進了別人家的資源）、參數名稱有大小寫或空白差異、同一個事件被兩個代碼重複送、內部流量被過濾規則擋掉。

驗證要走完兩層：

1. GTM 預覽模式：確認觸發條件對、變數取到值、代碼有跑。這一層只證明「你的容器邏輯是對的」。
2. GA4 即時報表：開啟「即時」，點進「事件計數」，找到你剛觸發的那個事件，再點進去看參數有沒有帶上、值對不對。

第二層才是真的。只做第一層，你證明的是自己的設定意圖，不是結果。

還有一個：GA4 的內部流量過濾。你把自己的 IP 加進過濾清單之後，用同一台電腦測，即時報表就是空的。這時候很容易誤判成追蹤壞了，回頭去改根本沒問題的代碼。

兩個會讓你查很久的坑

Lookup Table 變數一定要設 default

用查詢表（Lookup Table）把事件對應到不同的值，是 GTM 裡很常見的做法，例如把各種內部事件名對應到 Meta 的標準事件名。

問題是：沒對到的輸入值，查詢表會回傳空的，而代碼還是會照樣送出去。沒有錯誤、沒有警告，那個事件就帶著一個空值上路，然後在 GA4 或 Meta 那頭被歸到「未設定」或直接被忽略。

你發現的時候通常是一個月後看報表，覺得某一類轉換的數字怎麼少了三成。

修法很簡單：查詢表下面有一個「設定預設值」的選項，勾起來，填一個一看就知道是漏網的值，例如 unmapped。這樣沒對到的事件會帶著 unmapped 進報表，你在報表上一眼就看得到有東西沒對應，而不是它安靜地消失。

容器 ID、評估 ID 要放進自己的變數

不要把 G-XXXXXXX 或 GTM-XXXXXX 直接寫死在每個代碼的設定欄位裡。

建一個常數變數（Constant）叫 GA4 Measurement ID，值放進去，所有代碼引用這個變數。

理由是換帳號的時候。客戶換 GA4 資源、你把測試環境的容器複製去正式環境、或者接手別人做的容器。寫死的話你得一個一個代碼點開改，而且一定會漏掉一個。漏掉的那個不會報錯，它會繼續把資料送去舊的資源，而你在新資源的報表上看到的數字永遠少一塊。

用變數的話，改一個地方，全部跟著換。

骨架的價值在第二個案子

第一次照這套做，會比你隨手裝 GTM 慢，大概多花半小時在「決定要量什麼」上面。

回本點在第二個案子。事件名不用想，dataLayer 的結構照抄，自訂維度清單直接複製，驗證流程有固定順序不會漏。原本一個案子的追蹤要半天，之後大概一小時，而且品質是一致的，不會這個案子有帶參數、那個案子忘了，也不會兩個案子的報表拼不起來。

工具會改版，介面會長得不一樣，但「先決定要量什麼、命名固定、參數註冊、雙層驗證」這四件事不會過期。

接著看哪裡

追蹤設完只是起點，接下來會遇到的是事件送出去了、Meta 那邊卻對不上，那通常不是 GTM 的問題。如果你的轉換 API↗ 也接了，卻在測試事件面板看到一片空白，五個依序要查的位置在這裡，查的順序跟這篇一樣，都是從終點往回追。

想要一份可以直接匯入的容器，我們把這套骨架做成了現成的 GTM 容器檔（含四個事件、dataLayer 規格、自訂維度對照表），放在 iGaming 買量實戰課 的第 4 章，匯入之後改參數就能上線。

---

了解我們的追蹤與數據服務 →