更新時間：2025年5月9號
隨著瀏覽器隱私保護機制越來越嚴格，許多網站管理員發現GA4資料遺失的情況日益嚴重。因此Google推出了Google Tag Gateway，希望透過第一方網域（First-Party Domain）傳送追蹤資料，提高資料收集的穩定性。
Google Tag Gateway在早期測試階段曾被稱為 First-Party Mode（FPM），因此在部分舊文章或技術文件中，仍可看 First-Party Mode 的名稱，兩者實際上指的是同一項功能。
本篇將介紹：
- 什麼是Google Tag Gateway
- Google Tag Gateway與傳統GA4部署方式的差異
- Google Tag Gateway的優點
- Cloudflare設定教學
- Google Tag Gateway與Server-side Tagging的比較
什麼是 Google Tag Gateway？
Google Tag Gateway 是Google提供的第一方資料收集解決方案。。
在傳統的GA4部署方式中：GTM程式碼從Google網域下載，資料直接傳送到GA4網域
而在Google Tag Gateway中：GTM程式碼由自己的網域提供，追蹤資料先傳送到自己的網域，再由自己的網域轉送至GA4
簡單來說：
GTM程式碼與GA4資料流量，會先經過你的網站網域，再轉送給Google。
Google Tag Gateway 與傳統GA4部署方式的差異
傳統部署方式（第三方模式）
目前大部分網站採用的都是傳統部署方式。
例如：GTM程式碼來源https://www.googletagmanager.com，GA4資料傳送目的地https://www.google-analytics.com，由於這些網域不屬於網站本身，因此被視為第三方網域（Third-party Domain）。
Google Tag Gateway（第一方模式）
Google Tag Gateway則改為：GTM程式碼來源是https://www.haranhuang.com/gtm，資料先傳送位置https://datacenter.haranhuang.com，再由CDN轉送至GA4。
從瀏覽器角度來看，這些請求來自網站自己的網域，因此屬於第一方網域請求，所以也叫第一方模式
如果你曾使用過Adobe Analytics，會發現這種架構與Adobe的CNAME 部署非常相似。
Google Tag Gateway 的優點
Google Tag Gateway最大的價值，在於提高追蹤資料的成功率。
降低瀏覽器隱私保護機制的影響
目前主流瀏覽器皆強化了追蹤防護功能，例如：
- Firefox ETP（Enhanced Tracking Protection）
- Safari ITP（Intelligent Tracking Prevention）
- Brave Shields
這些功能會主動識別第三方追蹤請求，並進行封鎖。
當GA4的請求來自google-analytics.com，較容易被辨識為第三方追蹤，而第一方模式改由網站自己的網域發送資料，可降低被攔截的機率。
減少 Content Security Policy（CSP）限制
部分企業網站會設定嚴格的 CSP（Content Security Policy）。
例如只允許script-src ‘self’，這種情況下，Google網域可能被阻擋。
透過第一方模式，可讓GTM從自己的網域載入，較容易符合企業資安政策。
提高資料收集穩定性
由於廣告攔截器（Ad Blocker）、隱私外掛、瀏覽器追蹤保護，通常都是針對GA4網域進行封鎖。
第一方模式能降低部分封鎖情況，讓GA4收集到更多資料。
Google Tag Gateway的前提條件
使用Google Tag Gateway之前，需要具備以下條件：
- 已安裝Google Tag或Google Tag Manager
- 擁有CDN或負載平衡器（Load Balancer）
- 可將流量轉送至Google指定端點
目前Google官方支援的有Cloudflare、Google Cloud、Fastly，未來可能支援更多服務商。
Google Tag Gateway設定教學（Cloudflare）
本文以Cloudflare為例說明。
需符合以下條件：
- 網站使 Cloudflare CDN
- GA4管理員帳戶與Cloudflare管理員帳戶為同一帳號
Step 1：進入Google Tag Gateway
可以用以下任意方式進入：
- 在GTM裡點擊管理」——「Google tag gateway」
- 在GA4的網頁串流詳情裡點擊「進行代碼設定」——「管理」——「Google tag gateway」
點擊「繼續」就可以開始設定。
Step 2：設定代碼放送路徑
此步驟是設定Google Tag的載入路徑。
你可以用/metrics、/securemetric、/analytics，也可以自訂，只要是沒有用過的就可以，這裡我設定為/gtm:
Step 3：連接Cloudflare
將GA4與Cloudflare帳戶連接。
Step 4：選擇網域
如果Cloudflare帳戶中管理多個網站，需選擇要啟用 First-Party Mode 的網域：
Step 5：更新網站追蹤碼
將網站中的Google Tag或GTM載入網址改為新的第一方路徑
Step 6：驗證設定
設定完成後，可以利用瀏覽器開發者工具（Network）檢查：Google 代碼或代碼管理工具容器追蹤碼是從www.haranhuang.com/gtm加載:
資料是發送到www.haranhuang.com/gtm:
Google Tag Gateway VS 傳統部署 VS Server-side Tagging
很多人第一次看到Google Tag Gateway時，會以為它就是Server-side Tagging（SST）。
其實兩者並不相同。
| 項目 | 傳統 GA4 部署 | Google Tag Gateway | Server-side Tagging |
|---|---|---|---|
| Google Tag 載入位置 | Google 網域 | 自己網域 | 自己網域 |
| 資料傳送位置 | Google 網域 | 自己網域轉送 Google | Server Container |
| 需要 CDN | ❌ | ✅ | ❌ |
| 需要伺服器 | ❌ | ❌ | ✅ |
| 可降低瀏覽器封鎖 | ❌ | ✅ | ✅ |
| 可修改資料內容 | ❌ | ❌ | ✅ |
| 可移除敏感資訊 | ❌ | ❌ | ✅ |
| 支援 FPID | ❌ | ❌ | ✅ |
| 部署難度 | 低 | 中 | 高 |
| 維護成本 | 低 | 低 | 高 |
Google Tag Gateway與Server-side Tagging的核心差異
Google Tag Gateway主要解決的是：「如何讓資料透過第一方網域傳送給Google」
而Server-side Tagging 解決的是：「資料送到Google之前，是否先經過自己的伺服器進行處理」
因此：
- Google Tag Gateway：不需要 Server Container、不需要額外伺服器、僅改變資料傳輸路徑
- Server-side Tagging：需要 Server Container、需要雲端主機、可修改、過濾、匿名化資料、可建立FPID（First-Party Identifier）
總結
Google Tag Gateway是Google 推出的第一方資料傳輸方案，透過網站自己的網域載入Google Tag並傳送GA4資料，降低第三方追蹤被瀏覽器或廣告攔截工具封鎖的機率。
如果你的目標是：
- 提升GA4資料完整性
- 降低Ad Blocker影響
- 減少CSP限制
- 不想維護Server-side Tagging 架構
那麼Google Tag Gateway是值得優先評估的解決方案。
但如果你的需求包含：
- 隱私合規管理
- 敏感資料過濾
- 第一方識別碼（FPID）
- 完整掌控資料流向
則建議直接導入Server-side Tagging。