行銷人必看：掌握 Google 代碼閘道，提升數據力與行銷成效

發佈日期: 作者:

Google 近日已推出 Google 代碼閘道(Google tag gateway)，可以讓 Google 代碼改跑第一方通道，是我認為目前接替第三方 Cookie 的最佳解決方案。

Google 代碼閘道與 Facebook 的轉換 API (Conversion API) 或是 Google 先前推出的 Server-side GA (伺服器端 GTM/GA) 的做法不同，FB CAPI 與 Server-side GA 都必須在網站端部署程式碼，以便承做第一方的數據接收端的任務，但 Google 代碼閘道無需在網站端部署任何程式，而是透過 CDN (例如 Cloudflare)或反向代理伺服器，將第一方的指定路徑，轉送請求至 Google 廣告主代碼閘道端點的伺服器，來完成任務。

行銷人最常見的煩惱，不外乎網站追蹤與成效分析，以及第三方 Cookie 限制對數據分析帶來的影響與挑戰，Google 代碼閘道提供了一個全新的解決方案，能幫助提升數據的準確性、強化網站評估，並在重視隱私的網路環境中取得更全面的行銷洞察，那就是 Google 代碼閘道 (Google tag gateway)。

Google 代碼閘道就像一個更聰明、更有效率的數據收集與傳輸中樞，能避開第三方 Cookie 即將淘汰的各種影響，是一個屬於第一方的數據追蹤方案。

資料來源: 推出廣告主專用 Google 代碼閘道，提升轉換評估和廣告成效

為什麼行銷人需要了解 Google 代碼閘道？

在過去，我們通常依賴瀏覽器直接執行 GTM、Google Analytics (分析)、Google Ads 等平台的追蹤代碼。然而，隨著瀏覽器對第三方 Cookie 的限制日益嚴格，這種傳統的追蹤方式面臨越來越多的障礙，包括追蹤被阻擋攔截、數據傳輸過程遺失、歸因不準確等等，進而影響行銷報表及經營決策。

Google 代碼閘道的出現，正是為了排除這些障礙，為行銷人帶來以下關鍵優勢：

  • 提升網站評估的準確性： 透過將 Google 代碼的部署與執行轉移到您的第一方網域下，不再依賴第三方 Cookie，能有效減少因第三方 Cookie 限制而造成的數據遺漏，讓您的網站評估報告更加可靠。
  • 強化轉換追蹤： 優化廣告活動需要倚賴準確的流量轉換數據，代碼閘道能幫助您更完整地追蹤使用者行為，提升轉換追蹤的精準度，進而改善廣告成效。
  • 掌握更全面的行銷洞察： 透過更可靠的數據基礎，可以更深入地了解使用者的行為路徑、廣告活動的實際效益，以及不同行銷渠道的貢獻，進而制定更適切的行銷策略。
  • 為未來的隱私趨勢做好準備： Google 代碼閘道的設計考量了日益嚴格的隱私保護要求，未來，透過閘道設定的代碼將預設採用更注重隱私安全的技術，讓行銷策略更符合未來的發展趨勢。

Google 代碼閘道如何運作？對行銷人有什麼影響？

Google 代碼閘道像一個位於網站和 Google 行銷平台之間的數據通道，當使用者瀏覽您的網站時，追蹤代碼不再直接將數據傳送至 Google 的伺服器，而是先將數據傳送到您設定的閘道（位於您的網域下，所以是第一方），再由閘道將數據轉送到 Google 的平台。

對行銷人來說，這將帶來以下的改變：

  • 更可靠的第一方數據： 由於數據是透過第一方的網域傳輸，因此能規避瀏覽器對第三方 Cookie 的限制，提升數據的持久性和準確性。
  • 更精準的廣告再行銷： 更準確的網站行為數據，能幫助您更精準地劃分受眾，提升再行銷廣告的效果。
  • 更清晰的轉換歸因： 由於追蹤數據更加完整，可以更清晰地了解不同行銷觸點在使用者轉換過程中的作用，進而優化行銷預算分配。

如何開始使用 Google 代碼閘道？

由於 Google 代碼閘道才剛推出不久，設定操作不像埋設 GTM 或 GA4 的代碼那麼簡便，可能需要網站技術人員的協助，主要的步驟包括：

  1. 在 GTM 或 Google Analytics 4 (GA4) 或 Google Ads 中設定 Google 代碼閘道。
  2. 選擇您網站的一個子網域或子目錄作為閘道的端點（例如 tracking.yourdomain.com或 yourdomain.com/metrics）。
  3. 若採用子網域形式，則須設定 DNS CNAME 記錄，將該子網域指向 Google 提供的閘道目標。
  4. (強烈建議) 透過 CDN (例如 Cloudflare) 或伺服器設定反向代理，並進行相關的標頭設定。
  5. 更新您網站上的 Google 代碼，使其將數據發送到您設定的閘道子網域。
  6. 在 Google 平台中驗證您的設定。

雖然設定並不算簡單，過程可能需要一些技術操作，但其帶來的長期效益絕對值得投入，能更準確的數據將直接轉化為更有效的行銷策略和更高的投資回報率。

不過，由於 Google 為了推行代碼閘道，與 Cloudflare 進行了合作，目前不論是 GTM、GA4、Google Ads，都提供了快速的 Google 代碼閘道設定功能，只要在設定過程授權 Google 系統登入 Cloudflare，就能一鍵安裝好 Google 代碼閘道，請參考下圖。

影片逐步說明：廣告主專用 Google 代碼閘道的簡化設定程序，瞭解如何使用網站的內容傳遞網路轉送評估資料

以下是透過 GTM 的介面進行設定，GA4 和 Google Ads 的設定畫面看起來應該是長一樣的。

登入 CloudFlare 帳號之後，就會跳出如上面動畫中的畫面了。

自行從 Cloudflare 設定 Google 代碼閘道

既然 Google 提供了一鍵安裝的功能，為何還需要自行設定 Google 代碼閘道呢?

因為授權 Google 系統可取用你的 Cloudflare 帳號之後，我實在無法確定 Google 會拿來做什麼其他事，因為無法有效監督，所以我暫時不打算採取這種方式，改從 Cloudflare 端手動設定。

在 Cloudflare 的帳號管理介面，可以找到 標籤管理 > Google 標籤閘道 這個項目(如下圖)。

點擊要設定的網址，就會出現下方的設定畫面，其中 Google 標籤 ID 就貼入你的 Google 代碼，測量結果路徑請自行命名一個目前未使用的子目錄名，這是給 Google 代碼閘道專用的，不能與現有已使用中的目錄重複，也無須真的建立這個目錄，因為 Cloudflare 會幫它透過類似轉址的方式，把它對應到 Google 的伺服器，所以不會用到這個實體目錄。

設定標籤的動作，代表請 Cloudflare 幫我埋入新的追蹤代碼，這也代表你這個網站的 DNS 必須設定 通過 Proxy 處理，而不能設定 僅 DNS，因為這樣的設定代表訪客瀏覽網頁時，是透過 Cloudflare 抓取一份進行暫存之後再傳送給瀏覽者，Cloudflare 才有機會在這過程中，自動幫你的網頁嵌入新的 Google 追蹤碼。

新的代碼安裝之後，可以透過 Tag Assistant 來檢查是否有安裝成功，或透過 GTM 的預覽功能來檢查代碼是否能正常觸發運作，但這些檢查其實都無法幫你確認是不是已經是以第一方的模式運作，若要確認，你可以檢視你的網頁原始碼，參考下圖，找到 <head> 下方的區塊，由於代碼是透過 CloudFlare 進行安插，所以應該都會被安插在 <head> 區塊的最前頭，以便能優先被執行，通常在最上面就可以找到黃色區塊這一塊，其中有許多資源指定的路徑，可以看到都是第一方的 /metrics，也就是在上面 Cloudflare 上設定的代理路徑，已經看不到任何第三方 Google 伺服器的路徑了。

不透過 Cloudflare 也能設定 Google 代碼閘道嗎?

如果你不想透過 Cloudflare 或其他 CDN 來啟用 Google 代碼閘道，應該也是可以的，只不過必須做一些額外的設定，有些設定甚至可能需要有主機管理的權限，一般的虛擬主機使用者，必須透過主機商來設定，大致分享一下作法。

Google 代碼閘道的運作架構，主要是透過反向代理的機制，將客戶對第一方資源的要求轉送到第三方(Google 追蹤伺服器)，來達成目的，若不透過 Cloudflare 或其他 CDN，則必須在主機端設定啟用此代理的機制，包含(假設 Google 代碼是 G-12345):

設定反向代理規則

對於 Apache HTTP Server： 需要啟用 mod_proxy 和 mod_proxy_http 模組，並在你的虛擬主機 (Virtual Host) 配置中加入 ProxyPass 和 ProxyPassReverse 指令。

<VirtualHost *:443>
ServerName tracking.yourdomain.com
ProxyPass / https://G-12345.fps.goog/
ProxyPassReverse / https://G-12345.fps.goog/
# … 其他 SSL 設定 …
</VirtualHost>

對於 Nginx： 你需要在你的伺服器區塊 (Server Block) 配置中使用 proxy_pass 指令。

server {
listen 443 ssl;
server_name tracking.yourdomain.com;

location / {
proxy_pass https://G-12345.fps.goog;
# … 其他 SSL 設定 …
}
}

覆寫「主機」標頭，允許轉送所有 Cookie 和查詢字串。

在反向代理配置中，你需要確保在將請求轉發到 G-12345.fps.goog 時，將原始請求的 Host 標頭覆寫為 G-12345.fps.goog。同時，你需要配置伺服器以轉發所有的 Cookie 和查詢字串。

升級 Google 代碼閘道後，排除網站流量的關鍵步驟

隨著追蹤碼的埋設方式從過去的直接嵌入，轉變為透過 Google 代碼閘道進行統一管理，有可能會造成原本該被排除的流量，重新開始被 GA4 或相關分析工具收錄了，例如網站管理者後台的操作。

這是因為 Google 代碼閘道會監控所有通過其傳輸的數據，而後台操作同樣會觸發追蹤碼，然而對於行銷分析而言，後台流量通常屬於內部操作，並非真實的使用者行為，若將其納入分析，可能會造成數據的混淆，影響您對使用者行為和行銷成效的判斷。

這個問題可以透過 Google Tag Manager (GTM) 解決，如果你現在不是採用 GTM，例如直接嵌入 GA4 追蹤碼，我會建議你改用 GTM。 GTM 是一個強大的代碼管理工具，能協助您精細地控制哪些流量需要被追蹤，透過設定特定的觸發條件，可以指示 GA4 或其他分析代碼，在使用者瀏覽網站後台的特定網址時，不要觸發追蹤行為，從而有效地排除這部分內部流量。

以下是您需要了解的關鍵步驟：

識別後台網址的規則：

通常網站後台會有特定的網址結構，例如 WordPress 的 /wp-admin/，或其他 CMS 或自訂後台的路徑。您需要明確知道您想要排除的網址模式。

在 GTM 中建立排除觸發條件：

前往您的 Google Tag Manager 帳戶。
進入「觸發條件」選單，並新增一個觸發條件。
選擇觸發條件類型為「網頁檢視」。
設定觸發條件在「部分網頁檢視」時觸發。
建立排除規則：當「Page Path」（頁面路徑）「包含」（contains）您後台的網址模式（例如 /wp-admin/）時觸發。


將排除觸發條件應用到您的 GA4 設定代碼：

前往「代碼」選單，找到您的 GA4 設定代碼。
在該代碼的「觸發條件」設定中，新增一個「排除觸發條件」。
選擇您剛才建立的「排除後台流量」觸發條件。
預覽與測試： 在 GTM 中開啟「預覽」模式，實際瀏覽您的網站後台頁面，確認 GA4 設定代碼沒有觸發，同時，瀏覽前台頁面，確認追蹤代碼正常運作。

發布變更： 測試無誤後，請記得提交並發布您的 GTM 容器，使設定生效。

透過以上簡單的步驟，您就能有效地將網站後台的流量從您的 GA4 或其他分析數據中排除，確保您的行銷分析基於更準確、更具參考價值的真實使用者行為數據，在升級 Google 代碼閘道後，持續優化您的行銷策略，達成更好的成效。

結論

Google 代碼閘道是行銷人在面對日益複雜的網路追蹤環境時，必須掌握的重要工具，它不僅能提升數據的準確性，強化網站評估，更能為您的行銷決策提供更堅實的基礎，建議盡早採用 Google 代碼閘道，提早享受 Google 代碼閘道所帶來的優勢，帶動更卓越的行銷成效！