WordPress GTM+GA4 串接教學：安裝到事件追蹤

GTM 是把網站動作轉成分析事件的其中一種管道。GA4 也能透過 Google tag、外掛、網站程式碼或伺服器端整合接收事件；可依需要的事件與維護方式選擇。當即時報表只有 page_view、session_start，而加入購物車、表單成功或聯絡按鈕沒有資料時，GTM 會是方便集中管理的選項。

這篇聚焦在 WordPress 上安裝 GTM、把事件送進 GA4，並完成驗證。Google Analytics 使用廣泛（W3Techs 2026 年 6 月的統計），但是否選用與要追哪些事件，仍應從網站目標、隱私要求與維護能力決定。

核心重點：六個動作跑完整套流程

如果你只想先抓順序，把這個架構記起來，後面每一段都是在把其中一步講透。

1. 先決定 GA4 帳戶結構（正式資源與測試資源分開）。
2. 建立 GTM 容器，把第一段代碼放在 <head> 盡量靠前的位置，第二段 noscript 放在開啟 <body> 後。
3. 在 GTM 裡新增「Google 代碼」，貼入 Web 串流的評估 ID／Tag ID。
4. 在 GA4 後台開啟「增強型評估」，讓自動事件先上線。
5. 針對生意關鍵動作，用 GTM 自訂事件補上（表單、按鈕、下載）。
6. 用 DebugView 與 GTM 預覽模式逐個驗證，再標記關鍵事件。

換句話說，就一句話：GTM 負責「在對的時機收訊號、分發訊號」，GA4 負責「把訊號變成報表」。如果你完全沒碰過 GTM 的基本觀念，建議先讀過GTM 是什麼的入門介紹再回來看實戰會更順。對 GA4 本身還很陌生的話，Google Analytics 的完整教學可以當作並行閱讀的底稿。

WordPress 為什麼特別需要 GTM 當中間層？

GA4 可以透過官方整合外掛或代碼管理方式安裝，不一定需要 GTM。若需求只有基本頁面瀏覽，直接安裝通常較容易維護；需要集中管理多種事件與代碼時，再評估 GTM。

但真實的生意現場，你會想知道的事情通常長這樣：

• 哪一篇文章的「立即諮詢」按鈕被點最多次？
• Elementor 表單送出成功率是多少？多少人填到一半離開？
• 商品頁的「加入購物車」到「開始結帳」之間，掉了多少人？
• 側邊欄那顆 LINE 按鈕，到底有沒有真的帶來聯絡？

有些動作會由加強型評估或電商整合自動收集，有些則需要網站在成功時送出明確訊號。GTM 能集中管理這些觸發條件與代碼；遇到訂單金額、商品資料或表單成功狀態，仍可能需要外掛或開發者把資料推進 dataLayer。

無論使用 GTM、外掛或直接實作，都要處理以下管理問題：

GTM 把所有代碼收進一個後台，用「代碼、觸發器、變數」三層邏輯管理，但新的商業事件若缺少成功訊號或資料，仍需調整外掛或網站程式碼。對沒有專屬工程師的中小型網站來說，這份彈性才是它真正的價值。

先把三個角色講清楚：GTM、GA4、Site Kit 怎麼分工？

這三個名字常常被搞混，我把它們拆成一張分工表，你只要記住「誰負責收、誰負責算、誰是捷徑」就好。

Site Kit 與 GTM 的選擇取決於追蹤需求。只需要基本 GA4 報表與 Search Console 整合時，可從Site Kit by Google開始；需要集中管理廣告標籤、Consent Mode 或較複雜的自訂事件時，GTM 通常更合適。兩者可以安裝在同一網站，但應確認同一個 GA4 評估 ID 只由預定路徑送出，避免重複計算。

第零步：先設計 GA4 帳戶結構，再開始裝任何代碼

帳號一開、資源一建、代碼一貼，若沒有先想過正式站、測試站與權限結構，之後做實驗或排除測試流量會較難。安裝前先決定環境與命名方式。

GA4 的層級是「帳戶（Account）→ 資源（Property）→ 資料串流（Data Stream）」。一個帳戶可以有多個資源，一個資源可以有多個資料串流。對 WordPress 站長來說，最實用的切法是這樣：

測試環境可使用獨立資源或其他明確隔離方式，避免大量測試事件混入正式報表。採用哪一種要看環境數量、權限與維護方式；關鍵是把正式與測試評估 ID 記錄清楚。

建立資源時也要確認報表時區與幣別。這些設定可以變更，但會影響變更後的報表處理與比較，應依主要營運地區與交易幣別選擇並留下紀錄。

兩個要主動確認的 GA4 資料與廣告設定

帳戶結構決定後，應在安裝代碼時一併檢查資料保留與廣告功能；它們不是每個網站都要採用相同設定。

第一個是「資料保留（Data Retention）」。GA4 標準版預設兩個月，可改為十四個月；它主要影響探索與使用者層級、事件層級資料，不影響多數標準彙總報表。若需要較長的探索視窗，可到「管理 → 資料收集與修改 → 資料保留」調整，延長保留期也適用於已收集且尚未刪除的資料；已刪除資料無法恢復（見 Google 的資料保留說明）。

第二個是廣告功能與 Google Signals。是否啟用要看再行銷、人口特徵資料、同意狀態與適用政策，不是每個 GA4 資源都必須開。啟用前確認隱私揭露、同意管理與 Google Ads 連結需求。

較長的資料保留不會回復已過期的探索明細，廣告功能也不會替未符合條件的過去資料補建受眾。設定前先確認分析目的、同意狀態與政策，而不是一律開啟。

第一步：把 GTM 容器裝進 WordPress 的三條路徑

GTM 容器需要兩段代碼，一段放在 <head> 開頭盡量靠前，一段放在 <body> 開頭。在 WordPress 上把這兩段放進去，常見有三條路徑，我會直接告訴你選哪一條。

我的建議是選 A，搭配 GTM4WP 這類專用外掛。理由很單純：它不只幫你插入容器代碼，可依啟用的功能把 WordPress 資料及 WooCommerce 電商事件提供給 dataLayer；要先核對欄位與觸發時機，並避免送出姓名、Email 等個人資料。如果你還不熟悉 WordPress 外掛的安裝流程，可以先看WordPress 外掛安裝的三種方法，把外掛裝好再回來設定。日後若想把廣告代碼、驗證碼也集中管理，可以再看看Ad Inserter 這類程式碼插入外掛，它跟 GTM 在分工上互補。

不過要特別提醒一件事：很多佈景主題與快取外掛會把 JavaScript 做合併或延遲載入的處理。GTM 容器的第一段代碼必須盡早在 <head> 執行，否則會漏掉頁面剛載入時的事件。如果你用了快取外掛或網站層級的網站快取設定，先測試是否漏掉必要事件，再加入所需排除；同意管理應依設計先初始化，不要為了提早追蹤而繞過同意設定。

安裝後以 Tag Assistant、網頁原始碼與實際請求確認容器。後台安裝診斷可能延後更新，單靠狀態圖示不能證明每個事件已正確送出。

第二步：在 GTM 裡把 GA4 接起來

容器裝好後，接著在 GTM 建立「Google 代碼」，讓網站把資料送到指定的 GA4 Web 串流。介面舊稱「GA4 設定代碼」，目前已由 Google 代碼取代。

1. 進入 GTM 後台，左側選「代碼（Tags）」→「新增」。
2. 代碼類型選「Google 代碼」（Google tag）。
3. 在「Tag ID」欄位貼上你的 GA4 評估 ID，格式是 G-XXXXXXXXXX。
4. 依官方設定選 Initialization – All Initialization Events（介面可能顯示 Initialization – All Pages），並先安排同意初始化。
5. 命名這張代碼（例如「GA4 基本設定」），按儲存。
6. 先以 Preview 驗證，再按「提交（Submit）」→「發布（Publish）」讓正式訪客使用。

若要評估不同根網域間的同一段旅程，應在 GA4 Web 串流的 Google 代碼設定中配置跨網域評估，列出需要連結的網域，再用 Tag Assistant 驗證 linker 參數是否正確傳遞。沒設定時可能產生新的工作階段或自我參照，但不會一律歸為 direct。子網域通常可由同一個 Cookie 網域處理，仍要確認各頁都載入同一實作。

發布這個動作非常重要。很多人把代碼設好、儲存，就以為大功告成，結果 GTM 還停留在工作區草稿狀態，前端根本沒收到任何改動。請記得一個原則：在 GTM 裡，草稿可以在預覽模式測試，但正式訪客仍使用已發布的版本。

第三步：增強型評估 vs 自訂事件，該靠哪一邊？

GA4 的「加強型評估（Enhanced Measurement）」可自動收集網頁瀏覽、90% 捲動、外連點擊、站內搜尋、部分表單互動、YouTube 影片參與與檔案下載等事件。實際是否觸發取決於頁面結構與設定，不能用固定比例估算它涵蓋多少需求。

增強型評估有以下邊界：

• 它認得的「下載」是根據副檔名清單（pdf、zip、docx 等）判斷，你網站上特有的檔案類型它不一定追得到。
• 它的「外連點擊」只認「連到不同網域」的點擊，站內特定按鈕（例如聯絡按鈕）不算外連。
• 它可收集 form_start 與 form_submit，但 form_submit 不一定等於後端寄信、付款或資料處理成功；關鍵表單仍要監聽成功訊號。
• 自動事件會帶部分連結、表單或檔案參數，但若要依商業語意區分按鈕，仍需自訂事件或參數。

所以真正的策略不是二選一，而是分層：增強型評估當底，先把基本的事件鋪好；再針對「跟生意直接相關、需要精準判斷結果」的少數動作，用 GTM 自訂事件補上。這樣你既不會把時間浪在重複造輪子，也不會在關鍵轉換上失準。

第四步：WordPress 站最該追蹤的五個自訂事件

這一段是整篇最值得動手做的部分。我列出 WordPress 站最常需要、可依網站需求選擇的五個自訂事件，每一個都附上觸發器設計的概念。實際的 GTM 介面細節（變數怎麼建、觸發器條件怎麼下），可以對照GTM 完整設定流程一步一步操作。

1. 聯絡表單送出成功（generate_lead）

這是絕大多數形象網站、服務網站最重要的轉換動作。追蹤它的關鍵不在「點擊送出按鈕」，而在「表單真的送出成功」。因為使用者可能填錯驗證碼、必填欄位沒填，按下送出後其實沒送出去，如果你只追點擊，會把失敗也算成轉換。

Contact Form 7 的 wpcf7mailsent 是 DOM 事件，GTM 自訂事件觸發器不會直接聽到它。需由外掛整合或 JavaScript 監聽成功事件，再執行 dataLayer.push({ event: "cf7_success" })，讓 GTM 以 cf7_success 觸發 GA4 generate_lead；不要把表單輸入內容送出。Elementor Pro 的表單同樣要先核對目前版本的成功訊號與橋接方式，成功送信也不等於客戶已成為合格商機。

2. LINE、WhatsApp 等通訊按鈕點擊（contact_click）

若網站提供通訊軟體浮動按鈕，可用「點擊 - 僅連結」觸發器，依實際 Click URL 或元素 class 設定條件。按鈕點擊量與表單量誰較高，要看自己的資料。

如果你想知道更細的細節（例如是哪一頁的按鈕被點、是側邊浮動按鈕還是文章結尾的按鈕），可以在事件裡帶上 page_location 與一個自訂的 button_position 參數。實際的點擊追蹤設定細節，可以參考用 GTM 追蹤 LINE 按鈕點擊的完整教學，概念可用於 WhatsApp 與 Messenger，但仍需核對實際連結或 JavaScript 按鈕結構；點擊不等於對話已開始。

3. 電子郵件與電話連結點擊（contact_click）

網站上的 mailto: 與 tel: 連結也可合併成 contact_click，再用 link_type 區分。這只能代表點擊郵件或電話連結，不等於郵件已寄出或電話已接通。

4. 重要檔案下載（file_download）

GA4 加強型評估的 file_download 會依一組常見副檔名觸發，並帶出 file_name、file_extension、link_url 等參數。只有特殊檔案類型、非連結式下載或需要額外商業分類時，才要用 GTM 補充。

5. 影片參與（video_progress）

在啟用 JavaScript API 的 YouTube 嵌入影片上，加強型評估可收集 video_start、10%、25%、50%、75% 的 video_progress 與 video_complete。需要其他門檻或非 YouTube 播放器時，再用 GTM 自訂。

資料層（dataLayer）是什麼？它決定你追蹤能追多深

講到這裡，有一個觀念一定要先講清楚，否則你做電商追蹤、會員追蹤時一定會卡關：dataLayer（資料層）。它的名字聽起來很技術，但概念很樸素，它是夾在「你的網站」與「GTM」中間的一個資料佇列，像一個共用的置物箱。

運作邏輯是這樣的：你的網站或 WordPress 外掛在做某個動作時，可以把一份結構化的資料「推（push）」進這個置物箱；GTM 隨時在監聽這個置物箱，一發現有新資料進來，就會根據你設定的規則，決定要不要把訊號送給 GA4。換句話說，dataLayer 是網站與 GTM 之間的共同語言。網站負責把事實寫進去，GTM 負責讀出來再轉發。

舉個 WordPress 上很常見的例子。你想區分「登入會員」與「訪客」的行為差異，就要讓網站在每個頁面載入時，把會員狀態推進 dataLayer。GTM4WP 這類外掛可在啟用相關設定後提供登入狀態資料，實際欄位名稱和值要在 Preview 核對，不要把示意的 visitorLoginState: "logged-in" 當作固定格式。你在 GTM 裡把它定義成一個「資料層變數」，就能拿來當觸發條件、或當事件的參數，例如只追蹤登入使用者的點擊，或把會員身分附在每個事件上送進 GA4。

點擊監聽能提供連結或元素資訊，但交易金額、商品與成功狀態應取自可信的商店資料。GTM 路線通常透過 dataLayer 傳遞；直接使用 Google tag 或專用整合，也可以發送電商事件，不必強制經過 GTM。

事件命名先定規矩，半年後報表才不會變垃圾山

這件事很少有教學會提早講，但它會在你上線半年後狠狠咬你一口。當你一開始隨手命名事件，有人用 click_button、有人用 ButtonClick、有人用「按鈕點擊」中文，半年後你打開 GA4 報表，會發現同一個動作散落在三個事件名稱裡，根本沒辦法加總，也沒辦法做比較。事件名稱可以調整後續的收集規則，但不會回頭改寫歷史事件；改名時應記錄切換日期與新舊定義。

所以請在寫第一個事件之前，就定下一套命名規則並寫成文件。我自己的慣例是這樣，給你參考：

把這份規則寫進一份試算表，每新增一個事件就登記一行（事件名稱、觸發條件、參數清單、負責人）。這份文件就是你日後交接、除錯、做各種報表與儀表板時的唯一真相來源。沒有它，三個月後連你自己都會忘記 generate_lead 與 lead_submit 到底差在哪。

WooCommerce 電商追蹤的真相：GTM 一個人撐不起來

如果你的 WordPress 是搭配 WooCommerce 開電商，事件追蹤會進入另一個難度。這裡要先打破一個誤解：很多人以為只要在 GTM 裡追「加入購物車按鈕被點」就好。問題是，光知道按鈕被點，GA4 不知道被加入購物車的是「哪一個商品、單價多少、數量幾件」。

電商追蹤需要的不只是點擊訊號，還要有商品 ID、名稱、單價、數量、交易金額與幣別等資料。若走 GTM 路線，WooCommerce 外掛或網站程式需在正確時機提供交易資料，常見做法是推進 dataLayer，再由 GTM 送出 GA4 電商事件；也可採用直接整合或 Google tag。無論使用哪一條路徑，都應用訂單紀錄核對 purchase、交易 ID、金額與幣別。

要追蹤完整的電商漏斗，你需要的不只是 purchase 一個事件，而是一連串階段性事件，這些事件可供標準報表或自訂探索使用，但並非以下每一列都會出現在同一份預設漏斗報表：

GTM4WP 或其他 WooCommerce 整合能提供哪些事件，會受外掛版本、佈景主題、結帳區塊與金流流程影響，不能假設前七個一定完整。逐項在 Preview 與 DebugView 驗證，特別檢查 add_payment_info、purchase、訂單 ID 與金額，並避免重新整理感謝頁造成重複購買事件。商品頁 SEO 可另參考商品頁的 SEO 設定。

實務上有兩條比較穩的做法：

不管走哪一條，都要確認WooCommerce 購物網站的金流、物流與訂單完成頁能正常運作。瀏覽器端 purchase 常在訂單完成頁送出，跳轉、阻擋或頁面錯誤都可能造成遺漏；可用 DebugView 與訂單紀錄對照，重要場景再評估伺服器端補強。

第五步：用 DebugView 與預覽模式驗證每一個事件

GA4 標準報表可能延遲處理，不能等報表出現才驗證。設定錯誤期間的資料通常無法事後完整補回，因此上線前應使用 Preview、Tag Assistant 與 DebugView 當場檢查。

這裡有兩個工具要搭配使用：

• GTM 預覽模式（Preview Mode）：進 GTM 後台點右上角「預覽」，它會打開一個除錯視窗，顯示每個頁面載入時「哪些代碼被觸發、哪些觸發器成立、dataLayer 收到什麼資料」。這是你判斷代碼邏輯對不對的第一手工具。
• GA4 DebugView：在 GA4 後台的「管理 → 資源設定 → DebugView」，它會顯示帶有除錯訊號的事件；可以用預覽、Debugger 或 debug_mode 啟用。實際顯示仍受網路、同意與資源設定影響。

驗證流程可以是：開 GTM 預覽模式，確認代碼有觸發；切到 GA4 DebugView，確認事件名稱與參數；再測下一個事件。另用瀏覽器 Network 與後端訂單／表單紀錄交叉比對。

DebugView 沒資料時，先核對 debug_mode、目標資源、同意狀態、請求是否送出，以及阻擋或過濾規則。預覽看到代碼觸發，不等於 GA4 已收到事件。

把事件標記成關鍵事件，再接到 Google Ads

事件追出來之後，它還只是「發生過的事」。要讓它變成可以拿來優化廣告的「轉換」，你必須在 GA4 後台把它標記成「關鍵事件」（舊稱轉換，Key Event）。

在 GA4 的事件或關鍵事件管理介面中，找到已驗證的事件（例如 generate_lead、purchase）並標示為關鍵事件。介面路徑可能調整，以目前後台和官方說明為準；標記前先確認事件不會重複、參數正確。

如果你的網站同時在跑Google Ads，可先連結 GA4 與 Google Ads，確認要匯入的 GA4 事件已標記為關鍵事件，再依目前介面從 Google Ads 或 GA4 的轉換管理功能建立廣告轉換。建立後要核對「主要／次要」設定、計數方式與事件定義；新建的廣告轉換不會補計匯入前的歷史資料，資料也可能需要一段處理時間才會顯示。若要用於出價，還需確認它已設為適當的主要轉換。

匯入 GA4 關鍵事件與直接建立廣告轉換是兩條不同路徑。若兩者追同一動作，要明確設定哪一個是主要轉換，避免重複納入出價。跨多個廣告平台時，也要一併規劃 UTM 追蹤碼命名規則。

在符合使用者同意與平台政策的前提下，GA4 目標對象可連結到支援的廣告產品。比較多個廣告管道時，可用 ROAS（廣告投資報酬率）搭配成本、毛利與歸因限制解讀；追蹤基礎失準時，下游指標也會受影響。

三個最常見的 GTM + GA4 地雷

以下三種狀況是常見的排查方向：

地雷一：GA4 代碼被裝了兩次，數據從頭到尾都膨脹

Site Kit、GTM、主題與其他外掛可能重複安裝同一評估 ID。這可能使 page_view 或其他事件重複，但使用者與工作階段不會因此必然全部翻倍；應核對具體事件與識別方式。

排查時用 Tag Assistant 核對頁面上的 Tag ID 與 page_view 來源，再在 Network 檢查請求參數。一次載入可能正常送出多個不同事件，所以「collect 超過一筆」不能直接判定重複；真正要找的是同一評估 ID、同一動作、同一時間被重複送出。保留哪一種安裝方式，依現有事件與維護流程決定。

地雷二：同意介面與標籤行為不一致

Cookie 同意橫幅是否在同意前完全阻擋 GA4 與廣告代碼，取決於同意管理與標籤設定。沒有正確串接 Consent Mode 時，橫幅顯示狀態與實際標籤行為可能不一致，造成不該收的資料或不必要的資料缺口。

同意模式（Consent Mode）v2 需要同意管理平台、網站與 GTM 配合。基本模式可在同意前阻擋標籤；進階模式則可能在預設拒絕狀態送出不含 Cookie 的訊號，兩者行為不同。應依適用法律、平台政策與所選模式設定並驗證，不能只看橫幅是否出現。

地雷三：自己的測試流量汙染報表

每天在自家網站上測試、改文章、看前後台，只要頁面有追蹤且未被同意設定或過濾規則排除，就可能進入 GA4；WordPress 後台不一定安裝追蹤。對流量大的網站影響不大，但對每天只有幾十、幾百人造訪的小站來說，你一個人的測試可能就佔了工作階段的顯著比例，把參與度、跳出率全部帶歪。

測試可使用獨立資源。正式資源若要排除內部流量，先在 Web 串流的代碼設定定義內部 IP 與 traffic_type，再建立資料篩選器；先用 Testing 驗證，確認後才設 Active。啟用排除會永久影響後續資料處理，動態 IP 也需維護。

下一步：今天就能動手的五件事

看完一大篇，如果沒有化成一個具體的下一步，知識很快就會沉下去。我把最該先做的動作濃縮成五項，照順序做就好。

1. 盤點你要追的轉換動作：在紙上列出 3 到 5 個「對你生意最重要的使用者動作」（例如填表、加 LINE、下載型錄、完成購買），這就是你這週要追完的清單。
2. 建好 GA4 正式與測試兩個資源：依營運需求設定時區與幣別；日後雖可修改，仍需記錄比較上的影響。
3. 用相容方式把容器裝上：確認 head 與 body 兩段位置正確；只有實測發生衝突時，才加入必要的快取或延遲排除。
4. 開啟增強型評估，再補上自訂事件：先讓自動事件上線，再針對你列出的關鍵動作一一補上 GTM 自訂事件。
5. 用 DebugView 逐個驗證，標記關鍵事件：每驗證一個就打勾，全部驗完再標成關鍵事件，接到 Google Ads 收尾。

穩定的 GTM 與 GA4 架構能降低後續新增事件與儀表板的維護成本，但每個新整合仍要個別驗證。先追蹤少數真正影響決策的事件，記錄定義、觸發條件、參數與測試結果，再逐步擴充。