【提升數據傳輸品質】Google 代碼閘道（GTG）最新更新內容與可能潛在問題（截止至 2026/05 月）
【提升數據傳輸品質】Google 代碼閘道（GTG）最新更新內容與可能潛在問題（截止至 2026/05 月）
（本篇文章最後更新時間 2026/05/07）從 Google 官方開始推廣 GTG 這項服務也已經經過半年了，對於廠商而言，導入 GTG 之後，確實可以讓原本收集到的數據更完整與精準，不過 GTG 也並非是完全的神仙丹，在技術支援不夠ˇ的情況之下，還是有可能在導入之後產生其他問題，這邊文章將會持續更新我們或是其他外部團隊導入 GTG 之後所碰到的問題，幫助大家盡量少走冤望路。
文章目錄
一、Google 代碼閘道最新官方更新
１. 使用 Fastly 設定廣告主專用 Google 代碼閘道（2026/05）
２. 使用 Akamai 設定廣告主專用 Google 代碼閘道（2026/03）
二、Google 代碼閘道的局限性和注意事項
１. 可以改善資料收集的問題，但並非完全解決
２. 無法延長 Cookie 的使用效期
３. 透過 CDN 導入會強制註入到網站的所有頁面
三、Google 代碼閘道碰到的潛在問題
１. 如果網站的資訊結構不完整，可能會導致直接流量升高（2026/02/23）
２. 歐盟地區的網站目前暫時沒有辦法將 GTG 的效能最大化（2026/03/03）
四、總結
一、Google 代碼閘道最新官方更新
１. 使用 Fastly 設定廣告主專用 Google 代碼閘道
以下為官方文件的重點節錄
透過手動設定或使用 Fastly，在 Google 代碼中成功設定廣告主專用 Google 代碼閘道後，畫面會顯示代碼閘道處於「有效」狀態。有廣告主專用 Google 代碼閘道在網站網域中運作時，網域旁會出現這項指標。
啟用廣告主專用 Google 代碼閘道後，即可管理網域，方法是在 Google 代碼閘道設定畫面中，點按「管理網域」按鈕。所有網域都會歸入下列 3 個部分：
- 已安插代碼的網域：這個部分會顯示安插目前這組代碼的網域。
- 未安插代碼的網域：這個部分會顯示尚未加入代碼的網域。如果選擇為這裡的網域啟用廣告主專用 Google 代碼閘道，網域會自動安插缺少的代碼。
- 其他有效網域：這個部分的網域已透過 Fastly 或手動操作，啟用廣告主專用 Google 代碼閘道，但使用別的代碼。
也可以點按右上角的「設定」，接著選取「在 Fastly 中查看」。如果設定時發生問題，畫面會顯示重試的選項。若一再出現錯誤訊息，請改為在 Fastly 介面設定廣告主專用 Google 代碼閘道，不要在 Google 代碼介面進行這項作業。
２. 使用 Akamai 設定廣告主專用 Google 代碼閘道
以下為官方文件的重點節錄
在 Akamai 中，廣告主專用 Google 代碼閘道僅支援一個 Google 代碼設定。直接設定多個代碼可能導致閘道無法正常運作，且可能容易受到指令碼注入式攻擊。如要設定多個代碼，您可以在 Google 代碼管理工具中，將網站代碼整合至單一容器，並在該容器中設定廣告主專用 Google 代碼閘道。進一步瞭解如何整理容器。
使用 Akamai 透過 Google 代碼成功設定廣告主專用 Google 代碼閘道後，正在執行廣告主專用 Google 代碼閘道的各網站網域旁都會顯示「有效」狀態。
如果設定時發生問題，系統會顯示重試的選項。如果持續收到錯誤訊息，請改從 Akamai 介面設定廣告主專用 Google 代碼閘道 (而非 Google 代碼管理工具介面)。
二、Google 代碼閘道的局限性和注意事項
１. 可以改善資料收集的問題，但並非完全解決
此方法可以降低部分瀏覽器擴充套件的影響，但無法完全避免所有情況。對於較為進階的擴充套件，例如：Ghostery，即使將 Google Analytics（或其他廠商）的請求改為透過你的網域轉送，它們仍然可能有能力辨識並加以封鎖。
２. 無法延長 Cookie 的使用效期
當 Google Tag Gateway 以標準的用戶端（client-side）部署方式使用時，它不會改變 Apple 的 Intelligent Tracking Prevention（ITP）對 Cookie 存活時間的限制。如果希望延長 Cookie 的有效期限，仍然需要採用完整的 Server-Side Google Tag Manager（GTM）架構來實現。
３. 透過 CDN 導入會強制註入到網站的所有頁面
當你的 CDN 在網站中注入 GTM／GTAG 程式碼片段時（至少 Cloudflare 的整合方式是這樣運作的），它會將該程式碼注入到整個網站的所有頁面上（包括後台管理頁面）。所以如果您有些子網域或是部分頁面的數據不想要配收集，目前的 GTG 方案可能不適合您。但是圖靈數位有研究出了突破這個問題的方法，有興趣的客戶歡迎直接與我們聯繫。
三、Google 代碼閘道目前碰到的潛在問題
１. 如果網站的資訊結構不完整，可能會導致直接流量升高
若網站在來源資訊的傳遞過程中出現缺口，GA4 可能無法辨識使用者的實際來源，進而將流量歸類為 Direct。因此，當 Direct 流量異常升高時，建議優先檢查以下幾個可能影響資訊結構完整性的面向。
【 Cloudflare 是否完整轉送 Referer 與 Request Header 】
在使用 Tag Gateway 的架構下，Cloudflare 需要完整保留並轉送原始請求標頭，否則來源資訊可能在傳遞過程中遺失。
建議確認：
・Referer header 有被完整保留，未被移除或清空
・Origin header 有正常傳遞，未被改寫
若 Referer 資訊在請求過程中遺失，GA4 將無法辨識使用者的上一個來源頁面，可能導致：
・Direct 流量比例上升
・source / medium 出現 (not set) 或 direct / none
【 Tag Gateway 是否被誤判為新的流量來源 】
在某些設定情況下，Google Tag Gateway 的端點網域可能被視為新的流量節點，導致原始來源被覆蓋或中斷。
建議確認：
・Google Tag Gateway 的 endpoint domain 未被 GA4 視為 referral source
・GA4 中未誤排除或改寫 Tag Gateway 網域
・Gateway 未造成來源資訊重新初始化
若中間節點被誤當作來源，會造成原始來源資訊斷裂，使 GA4 無法追溯到真正的流量來源。
【 GA4 Google Tag 設定是否一致 】
若頁面同時存在多個 Google Tag，但設定或觸發順序不一致，也可能造成會話來源被重新判定。
建議確認：
・只有一個 Tag 負責 session 初始化
・多個 Tag 使用相同設定參數
・未覆寫以下欄位：
> page_referrer
> page_location
・Tag 在相同的頁面生命週期中正常觸發
若多個 Tag 在錯誤順序下觸發，即使 client ID / session ID 沒有改變，仍可能導致 GA4 重設歸因。
導入 GTG 之後，Direct 流量異常升高，未必代表真的有更多使用者直接輸入網址進站。更常見的原因是：
・Referer header 遺失
・Google Tag Gateway 介入造成來源斷裂
・多個 Tag 導致會話重新初始化
・GA4 request 參數在傳遞過程中被改寫或遺失
２. 歐盟地區的網站目前暫時沒有辦法將 GTG 的效能最大化
假如您看到 GA 標籤仍然會向 Google 的端點發送請求（例如 region1.google-analytics.com，或在啟用 Google Signals 時出現的 region1.analytics.google.com），這其實是預期中的行為。在某些情況下，系統仍會直接將資料傳送到 Google 的端點，其目的是為了最大化轉換資料的完整性，或符合特定地區的法規要求。
例如：在歐盟（EU）地區，Google Analytics 對於請求的處理方式有非常明確的規範。相關文件說明，在這些情況下，所有流量必須只傳送到該地區的 Google 伺服器，以符合當地的資料處理與隱私法規。
因此，如果您位於 EU 地區，並且預期 Google Tag Gateway 會將所有 ga / gtm 請求都轉送到自己的端點，那麼實際結果可能會讓人有些失望。目前的運作方式並不是如此，未來是否會調整仍不確定。
四、總結
簡而言之，Google 推出的 GTG 服務，目的就是為了解決廣告主在資料收集上所碰到的問題，整體的方向是希望在符合法規與隱私權政策的情況之下，盡可能收集用戶的數據，但是仍有部分的外部因素短期之內較難被解決。
假如您在導入 GTG 的過程之中有碰到任何的問題，都歡迎隨時聯繫我們，我們會安排專員與您進行接洽。假如您發現自家的網站無法直接透過 Cloudflare 導入 GTG，我們也提供了特製化的服務方案，能夠做到跟 GTG 一樣的效果。
若想獲得更多 GA4 最新資訊與教學文章，歡迎填寫以下表單，訂閱【 圖靈數位 】電子報
