GA4 事件追蹤完全指南：從自動事件到自訂轉換的設定教學

GA4 事件追蹤完全指南：從自動事件到自訂轉換的設定教學

TL;DR -- GA4 的資料模型以「事件」為核心，所有使用者互動都是事件。本文從四層事件結構（自動收集、增強型衡量、建議事件、自訂事件）出發，手把手示範如何透過 Google Tag Manager 設定自訂事件、註冊自訂維度、標記關鍵事件（Key Events），並以 DebugView 驗證資料正確性。最後以 iGaming 產業的跨域導流、註冊與首存追蹤分離等實戰場景，帶你避開最常踩的坑。

---

GA4 vs Universal Analytics：核心差異

Quick Answer：GA4 採用事件驅動（event-based）模型，取代 Universal Analytics 的工作階段模型（session-based），沒有跳出率（bounce rate），改用互動率（engagement rate），並原生支援 BigQuery export。

如果你還在用 Universal Analytics（UA）的思維操作 GA4，踩坑只是時間問題。兩者的底層架構完全不同：

比較項目	Universal Analytics	GA4
資料模型	工作階段（Session）+ 匹配（Hit）	事件（Event）+ 參數（Parameter）
頁面瀏覽	獨立匹配類型 pageview	事件之一 page_view
跳出率	Bounce Rate（單頁工作階段 / 全部工作階段）	已移除，改用 Engagement Rate（互動率）
電子商務	需要獨立 ecommerce hit	全部走事件模型（purchase、add_to_cart 等）
跨裝置	需額外 User-ID View	原生 User-ID + Google Signals 整合
資料匯出	360 版才有 BigQuery	免費版即可 BigQuery Export
自訂維度	Hit / Session / User / Product 四級	Event-scoped / User-scoped 兩級

最關鍵的轉變：UA 的世界裡，「頁面瀏覽」跟「事件」是不同層級的概念；在 GA4，一切都是事件。page_view 是事件、scroll 是事件、purchase 也是事件。理解這一點，才能正確規劃你的追蹤架構。

GA4 原生支援免費 BigQuery Export，這對需要做進階分析、建立自訂歸因模型的廣告主來說是巨大升級。你可以直接用 SQL 查詢原始事件資料，不再受制於 GA4 介面的維度限制。

想進一步了解 GA4 與其他分析工具的比較，請參考我們的 GA4 與主流分析工具比較。

---

GA4 四層事件結構

Quick Answer：GA4 的事件分為自動收集（automatically collected）、增強型衡量（enhanced measurement）、建議事件（recommended）、自訂事件（custom）四層，優先使用前三層，只在沒有對應事件名稱時才建立自訂事件。

第一層：自動收集事件

安裝 GA4 代碼後自動觸發，無需任何設定。包括 first_visit、session_start、user_engagement 等基礎事件。這些事件提供最基本的流量數據，你無法關閉或修改它們。

第二層：增強型衡量事件

在 GA4 管理介面的「資料串流 > 增強型衡量」中以開關控制。包含六種事件：

事件名稱	追蹤內容	預設狀態
page_view	頁面瀏覽（含瀏覽記錄變更）	開啟
scroll	頁面捲動超過 90%	開啟
click（outbound）	外連連結點擊	開啟
site_search	站內搜尋	開啟
video_engagement	YouTube 嵌入影片互動（開始/進度/完成）	開啟
file_download	檔案下載（PDF、DOCX 等）	開啟

對大多數網站來說，增強型衡量已經涵蓋了基本互動追蹤。但注意：scroll 只追蹤 90% 捲動深度，如果你需要追蹤 25%、50%、75% 等分段，仍然需要透過 GTM↗ 設定自訂事件。

第三層：建議事件（Recommended Events）

Google 為不同產業定義的標準事件名稱，例如 login、sign_up、purchase、generate_lead。使用建議事件名稱的好處是 GA4 的機器學習功能、預設報表和受眾建立功能都針對這些事件做了最佳化。

完整的建議事件清單可參考 Google 官方 GA4 事件參考文件↗。

第四層：自訂事件（Custom Events）

當前三層都無法滿足需求時，才建立自訂事件。例如 click_reg（點擊註冊按鈕）、view_pricing（瀏覽定價頁）、calculator_use（使用計算工具）。自訂事件的名稱完全由你決定，但必須遵守 GA4 的命名規則：僅限英文字母、數字和底線，長度不超過 40 個字元，區分大小寫。

---

透過 GTM 設定自訂事件：完整步驟

Quick Answer：透過 Google Tag Manager 設定自訂事件需要三個元件——變數（Variable）定義資料來源、觸發條件（Trigger）決定何時觸發、代碼（Tag）負責將事件發送到 GA4。

以下以「追蹤使用者點擊註冊按鈕」為例，示範完整的 Tag / Trigger / Variable 設定流程。

步驟一：定義 dataLayer 推送

在網站的註冊按鈕點擊事件中，加入 dataLayer push：

// 註冊按鈕被點擊時執行
document.querySelector('#register-btn').addEventListener('click', function() {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'click_reg',
    button_location: 'hero_section',
    page_type: 'landing_page'
  });
});

步驟二：建立變數（Variables）

在 GTM 中建立「資料層變數」（Data Layer Variable），分別對應 button_location 和 page_type：

1. 進入 GTM > 變數 > 使用者定義的變數 > 新增
2. 變數類型選擇「資料層變數」
3. 資料層變數名稱填入 button_location
4. 命名為 DLV - button_location

對 page_type 重複相同步驟。

步驟三：建立觸發條件（Trigger）

1. 進入 GTM > 觸發條件 > 新增
2. 觸發條件類型選擇「自訂事件」
3. 事件名稱填入 click_reg（必須與 dataLayer push 的 event 值完全一致）
4. 命名為 CE - click_reg

步驟四：建立代碼（Tag）

1. 進入 GTM > 代碼 > 新增
2. 代碼類型選擇「Google Analytics↗：GA4 事件」
3. 選擇你的 GA4 設定代碼（或填入 Measurement ID）
4. 事件名稱填入 click_reg
5. 在「事件參數」中新增：
   • 參數名稱 button_location，值選擇變數 DLV - button_location
   • 參數名稱 page_type，值選擇變數 DLV - page_type
6. 觸發條件選擇剛才建立的 CE - click_reg
7. 命名為 GA4 Event - click_reg

步驟五：預覽測試 > 發布

使用 GTM Preview Mode 進入預覽，在網站上點擊註冊按鈕，確認事件正確觸發且參數值正確後，再發布容器版本。

---

自訂維度註冊——最容易被忽略的致命步驟

Quick Answer：自訂事件的參數（如 button_location）被 GA4 收集後，如果沒有在管理介面的「自訂定義」中註冊為自訂維度，這些參數的資料就無法在報表中查詢或分析。這是 GA4 追蹤設定中最常見、代價最高的錯誤。

這一點值得用粗體字重複三次：GA4 會收集未註冊的事件參數，但你在報表中完全看不到它們。 這意味著你可能花了一週設定了完美的 dataLayer 推送和 GTM 代碼，事件也確實在 DebugView 中出現，但打開報表卻發現「怎麼沒有資料」——因為你忘了註冊自訂維度。

註冊步驟

1. 進入 GA4 管理介面 > 資料顯示 > 自訂定義
2. 點擊「建立自訂維度」
3. 維度名稱：填入人類可讀的名稱（如「按鈕位置」）
4. 範圍：選擇「事件」（Event-scoped）
5. 事件參數：填入你在 GTM 中設定的參數名稱（如 button_location）
6. 儲存

標準版限制

GA4 標準版（免費版）的自訂維度有嚴格的數量限制：

維度類型	標準版上限	GA4 360 上限
事件範圍（Event-scoped）	50 個	125 個
使用者範圍（User-scoped）	25 個	100 個

50 個事件範圍的自訂維度聽起來很多，但在多品牌、多產品線的場景下很容易用完。規劃追蹤架構時，務必先列出所有需要的維度，優先使用 GA4 內建的維度（如 page_location、page_title），只在內建維度不夠用時才建立自訂維度。

---

轉換事件（Key Events）設定

Quick Answer：GA4 在 2024 年 3 月將「轉換」（Conversions）正式更名為「關鍵事件」（Key Events）。任何事件都可以標記為關鍵事件，一旦標記，GA4 會在歸因報表中追蹤其轉換路徑。

設定方式

1. 進入 GA4 管理介面 > 資料顯示 > 事件
2. 找到你要標記的事件（如 click_reg）
3. 將「標示為關鍵事件」的開關打開

標記為關鍵事件後，該事件會出現在「廣告 > 歸因」報表中，你可以看到使用者在轉換前經歷了哪些接觸點。這對廣告投放的 ROAS 歸因至關重要。

與 Google Ads↗ 轉換的關係

GA4 的關鍵事件與 Google Ads 的轉換追蹤是分開的。如果你需要將 GA4 的關鍵事件匯入 Google Ads 做出價最佳化，必須在 Google Ads 中另外設定「匯入 GA4 轉換」。兩者各自獨立計算，不會自動同步。

注意事項

• 每個 GA4 資源最多可標記 30 個關鍵事件
• purchase 事件預設就是關鍵事件，無需額外設定
• 關鍵事件的計算方式有「每次事件」和「每次工作階段」兩種，預設為「每次事件」——這意味著同一個使用者在同一次造訪中觸發三次 click_reg，會被計為三次轉換。如果你只想計算「有多少使用者轉換」，應改為「每次工作階段」

---

除錯工具：三劍客

Quick Answer：GA4 事件除錯有三個核心工具——GTM Preview Mode 驗證代碼觸發邏輯、GA4 DebugView 確認事件到達 GA4 且參數正確、即時報表（Realtime Report）確認資料進入報表系統。

GTM Preview Mode

按下 GTM 工作區右上角的「預覽」按鈕，會開啟 Tag Assistant。在你的網站上觸發事件後，可以看到：

• 哪些代碼被觸發（Fired）、哪些沒有觸發（Not Fired）
• 觸發條件是否符合
• 資料層的完整內容和推送順序

這是排查「事件為什麼沒觸發」的第一站。

GA4 DebugView

進入 GA4 管理介面 > 管理 > DebugView。DebugView 只顯示處於 debug 模式的裝置發送的事件，不會顯示所有使用者的資料。啟用方式：

• 透過 GTM Preview Mode（自動啟用 debug 模式）
• 安裝 Google Analytics Debugger Chrome 擴充功能
• 在 GA4 Config Tag 中設定 debug_mode: true

DebugView 會即時顯示事件流，點擊個別事件可以檢視其攜帶的所有參數和值。如果你在 DebugView 中看到事件和參數都正確，但報表中看不到對應的維度，那幾乎可以確定是忘了註冊自訂維度。

即時報表（Realtime Report）

GA4 首頁的即時報表可以顯示過去 30 分鐘內的事件計數。與 DebugView 不同的是，即時報表顯示所有使用者的資料，不限於 debug 模式裝置。用它來確認事件在非 debug 環境下也正常運作。

---

常見錯誤與排查

Quick Answer：GA4 事件追蹤最常見的四個錯誤：dataLayer push 時機不對導致漏事件、同一事件被多個觸發條件重複觸發、忘記註冊自訂維度導致報表空白、GA4 Data API 撞 quota 靜默回傳空資料。

錯誤一：dataLayer push 時機錯誤

最典型的情境：使用者點擊連結後立即跳轉，dataLayer.push 的 JavaScript 還沒執行完畢，瀏覽器就已經開始導航到新頁面。解法是在 GTM 代碼中使用「所有代碼觸發後才導航」的設定，或在 dataLayer push 後加入短暫延遲。

錯誤二：重複觸發

同一個按鈕同時觸發了 GTM 的「所有元素點擊」觸發條件和自訂事件觸發條件，導致同一事件被發送兩次。解法：為觸發條件加入更精確的篩選條件（如 CSS 選擇器、click class、dataLayer 事件名稱），避免泛用觸發條件。

錯誤三：忘記註冊自訂維度

前面已經詳細說明——事件參數被收集但未註冊為自訂維度，報表中完全看不到。這個錯誤的可怕之處在於 DebugView 會顯示參數值，讓你以為一切正常。直到你打開報表查詢時才發現資料不見了。

錯誤四：GA4 Data API quota 靜默回傳空資料

如果你使用 GA4 Data API（通常用於建立自訂報表或儀表板），當連續發送多個 API 請求撞到配額上限時，API 會靜默回傳空的 rows，不會拋出錯誤。這會讓你誤判「沒有資料」。解法是在每個 API 請求之間加入至少 500 毫秒的延遲，並在收到 429 狀態碼時實作重試機制。如果回傳 0 筆資料，先單獨重新測試該查詢，不要直接下結論。

更多追蹤除錯技巧，請參考 廣告追蹤稽核清單。

---

iGaming 場景的追蹤實戰

Quick Answer：iGaming 產業的 GA4 追蹤面臨三大特殊挑戰——跨域導流（landing page 與遊戲平台不同網域）、註冊與首存事件必須分離追蹤、多品牌共用 GA4 property 時需靠 user_properties 區分品牌歸屬。

跨域導流追蹤

iGaming 的典型漏斗是：廣告 > landing page（自有域名）> 遊戲平台（客戶域名）。由於 landing page 和遊戲平台是不同網域，如果不設定跨域追蹤，使用者從 LP 點擊到平台時會被視為新的工作階段，UTM 來源會遺失。

解法有兩種路線：

客戶端追蹤路線： 在 GA4 資料串流的「設定代碼設定 > 跨網域衡量」中，加入平台的網域。GA4 會自動在跨域連結中附加 _gl 參數來延續工作階段。

伺服器端追蹤路線： 使用 Server-Side Tracking 搭配 CAPI↗（Conversions API），在伺服器端傳送事件。這種做法不受瀏覽器限制，也不會被 ad blocker 攔截。但需要額外的基礎設施（如 Google sGTM 或 Stape 容器）。

註冊 vs 首存：必須分離

在 iGaming 追蹤中，「註冊」（sign_up）和「首存」（first_deposit）是兩個完全不同的漏斗階段，絕不能混為一談。常見的錯誤是只追蹤註冊，以為「有註冊就有價值」——但在 iGaming 產業中，一個沒有首存的註冊使用者幾乎沒有商業價值。

建議的事件設計：

// 使用者完成註冊
dataLayer.push({
  event: 'sign_up',
  method: 'phone',
  brand: 'brand_a'
});

// 使用者完成首次存款
dataLayer.push({
  event: 'first_deposit',
  deposit_amount: 1000,
  currency: 'TWD',
  brand: 'brand_a'
});

兩個事件都應該標記為關鍵事件（Key Events），但在 Google Ads 轉換匯入時，出價最佳化應優先使用 first_deposit 而非 sign_up，因為它更接近實際商業價值。

多品牌共用 GA4 property 的策略

當一個代理商管理多個品牌，可以選擇為每個品牌建立獨立的 GA4 property，或用一個 property 搭配 user_properties 區分。後者的好處是集中管理、跨品牌比較方便，但缺點是自訂維度配額會被多品牌共用。

實作方式：

// 設定 user_property 標記品牌歸屬
gtag('set', 'user_properties', {
  brand_id: 'brand_a',
  brand_region: 'tw'
});

記得在 GA4 管理介面中，將 brand_id 和 brand_region 註冊為使用者範圍（User-scoped）的自訂維度，否則這些屬性一樣會被收集但無法在報表中使用。

想了解更多跨平台追蹤策略，請參考 跨平台追蹤整合指南。

---

常見問題 FAQ

GA4 的自訂事件數量有上限嗎？

GA4 標準版對「不重複事件名稱」的上限是 500 個。這個限制是指整個 property 生命週期中出現過的不同事件名稱總數，一旦達到上限，新的事件名稱就不會被處理。事件名稱一旦建立就無法刪除（即使不再使用也會計入 500 的配額），因此命名時務必謹慎規劃，避免用日期、使用者 ID 等動態值作為事件名稱。

DebugView 看得到事件，但報表中沒有資料，怎麼辦？

最常見的原因有三個：第一，自訂維度沒有在「管理 > 自訂定義」中註冊——這是最高頻的原因。第二，報表有 24-48 小時的延遲，即時報表可以驗證事件有沒有進來。第三，你可能套用了篩選器（Filter）排除了特定流量。排查順序應該是：先確認自訂維度已註冊 > 再看即時報表 > 最後檢查篩選器。

已經送出去但沒註冊自訂維度的歷史資料，還能補救嗎？

不能。GA4 在收集事件時如果對應的自訂維度尚未註冊，那些參數值不會出現在報表中，且無法回溯套用。註冊自訂維度後，只有從那一刻起新收集的資料才會出現。這就是為什麼自訂維度的註冊必須在事件上線的同時完成，而不是「之後再說」。

---

總結：GA4 追蹤設定檢查清單

把你的 GA4 追蹤設定對照以下清單，確認每一步都沒有遺漏：

1. 確認增強型衡量事件（六種）已全部開啟
2. 優先使用建議事件名稱，只在必要時建立自訂事件
3. 每個自訂事件的參數，都已在 GA4 管理介面中註冊為自訂維度
4. 需要做轉換歸因的事件，已標記為關鍵事件（Key Events）
5. 使用 GTM Preview Mode + GA4 DebugView 完成完整的端到端測試
6. 如果使用 GA4 Data API，加入請求間延遲和空資料防呆機制
7. 跨域場景已設定跨網域衡量或 Server-Side Tracking
8. 多品牌場景已設定 user_properties 並註冊為使用者範圍自訂維度

需要專業團隊協助你建立完整的 GA4 追蹤架構？RedClaw 提供從追蹤規劃、GTM 設定到 Server-Side Tracking 的一站式服務。了解我們的追蹤服務 ->