行銷追蹤升級：從傳統 GTM 外掛轉向 Google Tag Gateway

發佈日期: 作者:

Google 在本月推出了 Google 代碼閘道（Google Tag Gateway, GTG），提供更簡單的設定方式，讓 Google 代碼可以改成第一方的端點來傳遞數據，而非傳統透過 Google 網域載入(第三方)。這樣的作法有助於提升數據隱私，改善因瀏覽器限制導致的訊號遺失問題(第三方 Cookie 的限制)，並讓資料更完整地傳送給 Google。

若您的網站是使用 Cloudflare 作為 CDN，可以直接透過 Cloudflare 與 Google Tag Manager 整合設定 GTG。這樣不僅能加強對標籤與資料傳輸的控制，也有助於提高 Google Analytics 數據的準確性，進一步優化廣告成效與轉換率，相關介紹請參考 掌握 Google 代碼閘道，提升數據力與行銷成效。

從傳統 GTM 升級至 Google 代碼閘道：保留客製化事件追蹤的重要性

大家都了解 Google 代碼閘道的優點之後，接下來的問題就是，如何將現有的 GTM 設定，改成透過 Google 代碼閘道呢?

直接透過 Cloudflare 啟用 Google 代碼閘道並停用原本的 GTM 功能，看似是最快速的升級方式，但這種一刀切的替換可能導致數據遺失，數據追蹤可分為兩個關鍵環節：事件資訊的捕獲與事件資訊向追蹤平台的傳輸，無論是傳統 GTM 或透過 Cloudflare 啟用的 Google 代碼閘道，都涵蓋這兩個部分，雖然 Google 代碼閘道能顯著提升數據傳輸的可靠性，降低被阻擋的風險，但傳統 GTM 往往針對網站進行了客製化，具備捕獲許多需要特定程式設計才能實現的事件及其資訊的能力，貿然停用原有的 GTM 並完全替換為 Google 代碼閘道，並不會自動繼承這些客製化的事件捕獲邏輯。

因此，在這種情況下，保留原有的事件捕獲機制，僅將數據傳輸管道替換為 Google 代碼閘道，才是更穩妥且高效的做法。

以 WordPress 為例：傳統 GTM 外掛嵌入追蹤碼

理解上一段文章所說的內容之後，就知道最好是能保留現有 GTM 的功能，僅替換嵌入網頁 head 的那段追蹤碼，是較理想的處理方式。

然而不同的網站系統或開店平台，都有各自客製化的 GTM 功能模組或外掛，要如何只替換嵌入追蹤碼的部份，並沒有一套通用的做法，必須洽詢相關的工程人員，但基本上這並不是很大的工程，就看廠商是否願意重視，並積極升級數據追蹤的品質與成效。

為了展示單純只替換嵌入追蹤碼的部份是可行的，底下我將用 WordPress+WooCommerce 的系統來實際印證。

安裝 WordPress 網站

首先，我以 WordPress+WooCommerce 架設了一個電子商務網站，安裝了熱門的 Astra 佈景主題，並從 pexels.com 免費圖庫相片網站，下載了 4 張照片作為虛擬商品圖片，再請 ChatGTP 依據圖片幫我命名商品名稱，以及寫一段商品描述，完成的網站在 Woo 網路商店測試站。

建立一個 GA 資源

接著，到 GA4 申請一個新的資源，並設定網頁串流，網路上已有很多這類教學，需要的人請自行爬文，這邊就不再教學。

到代碼管理工具建立一組容器

到 Google 代碼管理工具，建了一組 GTM 容器，放進前面建立的 GA4 資源 ID，並簡單設定了一些 Ecommerce Events。

透過 GTM 容器來載入 GA4 比直接嵌入 GA4 有更多優點，除非你有特殊的需求或限制，否則建議改用 GTM。這邊也不提供教學，需要教學的人請自行爬文，這種教學文章網路上也是不少。

用傳統外掛方式嵌入 GTM

接著為 WordPress 安裝 GTM4WP，這是一套受歡迎的 GTM 外掛，支援 GA4 的電子商務事件(加入購物車、結帳之類的)，然後填入Google 代碼管理工具容器 ID，設定啟用容器代碼，此時一個典型的購物網站 + GTM 的追蹤設定已大致完成。

如果你是一個 WordPress 新手，打算用 WordPress 來架設購物網站，我建議你可以嘗試這樣的組合，因為很常見，所以能幫你的人會比較多。

檢測 Google 代碼是否正常運作

檢測 Google 代碼是否正確被嵌入，我通常會先檢視網頁的原始碼，看看相關代碼是不是找得到，如下圖紅框所示，GTM4WP 的追蹤碼已被嵌入網頁的 <head> 段中，不過位置有點偏後(在 357 行起)，甚至接近 <head> 底部(下圖下方的紅色箭頭)，script 所在的位置會影響追蹤碼載入執行的時機，太晚載入執行，有可能會錯失捕捉一些事件，這與網站的速度有關，網站速度快一點的，或是再入外部資源少一點的，可能影響不大，反之，就可能常常都在漏掉一些數據。

使用 GTM 的預覽功能來檢測代碼，是最標準的作法，進到 Google 代碼管理工具，容器的工作區，點擊[預覽]。

此時會彈跳出下面的視窗，貼上你的網站網址點擊連結，就會在彈出另一個視窗，開啟您的網站，而這個 Tag Assistant 視窗則會切換到監控面板畫面，可以查看你網站傳送過來的追蹤事件及參數。

在網站的視窗上進行操作，由於我們主要是要測試電子商務的功能，所以我們點擊[加入購物車]的按鈕(上圖)，並在 Tag Assistant 視窗(下圖) 中，看到 Google 代碼確實傳送了加入購物車的事件(add_to_cart)，顯示 Google 代碼的運作正常。

稍後我們將測試改用 Google 代碼閘道，所以下面我們將先啟用 Google 代碼閘道的功能。

申請 Google 代碼閘道(Google Tag Gateway)

目前優先與 Google 合作推出 Google 代碼閘道(Google Tag Gateway) 的 CDN 廠商是 Cloudflare，不管是 Google Analytics、Google Tag Manager、Google Ads，都提供了代碼閘道的設定功能。

以上為 GA4 的 Google 代碼閘道的設定畫面，以下為 Google 代碼管理工具的 Google 代碼閘道設定畫面。

當前的設定方式，只有透過 Cloudflare 唯一一種方式，不過 Google 也先預告了，之後會有 Fastly、Google Cloud CDN 等更多 CDN 廠商加入。

在你啟用了 Google 代碼閘道 之後，請登入你的 Cloudflare 管理介面，找到 [Google 標籤閘道] 再選擇您正在操作啟用的網域進入編輯。

點擊上圖的[更新設定]，會彈出下圖的視窗，其中的 [設定標籤]，說明 Cloudflare 會自動在傳送網頁前將 Google 代碼的追蹤碼嵌入網頁的 <head> 標籤內，而且會是在 <head> 緊接者之後的位置，讓 Google 代碼能最優先、最快速被瀏覽器載入，提早部屬運作，相較於傳統 GTM 外掛嵌入的位置(請捲到上頭回顧一下)，這種的位置的安排，就可能產生明顯的差異，減少事件捕捉的錯失機會。

在這裡我們先將 [設定標籤] 的功能關閉，以便等一下測試 GTM4WP 停用容器代碼時，找不到有效的 Google 代碼，之後再啟用這個 [設定標籤] 的功能，以確定到時候網頁只有一組來自 Cloudflare 的 Google 代碼。

以 WordPress 為例：替換 GTM 嵌入碼，改成透過 Google 代碼閘道

GTM4WP 這個外掛提供了一個停用容器代碼的功能，這個功能並不是完全暫停 GTM 外掛的運作，而是僅僅不把 GTM 容器的追蹤碼嵌入網頁中而已，資料層的 dataLayer 變數和相關的 JavaScript 程式碼仍然可以繼續運作(見下圖紅框處)。

這個功能可能是為了支援 Server Side GA 所開發，當然也有其他可能，反正這個功能用來搭配 Cloudflare 的 Google 代碼閘道，似乎是可行的，我這邊就將它停用看看，而前面我們也暫時關閉了 Cloudflare 的 [設定標籤] 功能，所以此時網頁應該是沒有任何 Google 代碼存在的。

回到 WordPress 測試商店重刷網頁幾次，再打開 Tag Assistant 檢測，確定在 GTM4WP 停用容器代碼之後，GTM 代碼確實已經檢測不到任何 Google 代碼了。

我們重新啟用 Cloudflare 的 [設定標籤] 功能，讓網頁改用 Cloudflare 嵌入的 Google 代碼，重刷了幾次之後(真的是重刷了好幾次才出現，我不確定是為什麼，可能是 Cloudflare 的 Cache 機制或其他原因)，Tag Assistant 偵測到了 Google 代碼。

打開檢視網頁原始碼，可以看到 GTM 的追蹤碼被插入在緊接者 <head> 後面海景第一排的位置(上方的紅框)，src 則為 /gtm/ 目錄，這是我們在 Cloudflare 設定的代理路徑，讓 gtm.js 不再從 Google 額伺服器載入，改由網站第一方的路徑。

第二個紅框可以看到由 GAT4WP 外掛嵌入的 dataLayer 物件相關的 javascript 碼依然存在，而用 GTM 容器的 ID 去搜尋整個網頁，已找不到第 2 個符合的目標，確定 GAT4WP 外掛的 Google 代碼部份並沒有嵌入，證明前面 Tag Assistant 所偵測到的 Google 代碼，就是 Cloudflare 所嵌入的這一組。

來自 Cloudflare 的 Google 代碼及 GTM4WP 的資料層物件，都已如預期的被嵌入到網頁中，接下來就要檢測這樣的組合是不是能正常運作。

一樣到 Google 代碼管理工具，為我們的 GTM 容器執行預覽，開啟網頁後點擊加入購物車。

查看 Tag Assistant 視窗的事件資訊(如下圖)，不只預設事件都順利偵測到，加入購物車的事件(add_to_cart)及其變數資料，初步看起來也都正常運作，至此，已經可以大致確認，用既有的 GTM 外掛或功能，並將 gtm.js 改由 Cloudflare 的 Google 代碼閘道負責載入，看起來是有機會替換成功，在保留原有事件捕捉能力的請況下，轉成新的第一方的 Google 代碼閘道來傳送數據的。

現在適合導入 Google 代碼閘道嗎？

如果您的網站仍處於建置階段，或剛開始營運，可以考慮優先導入 Google 代碼閘道（Google Tag Gateway, GTG）。不過在實施前，建議先確認您所使用的網站系統、平台或合作的開發廠商是否具備處理相關技術調整的能力。

對於已穩定營運中的網站，目前（2025 年 5 月中）則不建議立即切換。畢竟 GTG 是一項相對新的技術，仍可能面臨穩定性或設定規則上的調整，不過長遠來看，這將是一項值得規劃的升級方向，隨著第三方 Cookie 的逐步退場，Google 明顯將代碼閘道作為主要的解決方案之一。

您不一定要立刻採用，但從整體趨勢來看，這可能是未來少數值得信賴的選項之一。