Server-Side GTM 與 Consent Mode 搭配：合規追蹤的實作流程

Server-Side GTM 與 Consent Mode 搭配的核心架構

Server-Side GTM 與 Consent Mode 的整合，是以雙層容器架構爲核心：客戶端容器負責收集使用者 consent 信號，服務端容器接收這些信號後，在決定是否放行 tag 前進行處理。這個架構改變了傳統的追蹤方式，讓發佈者能更全面地掌握資料流，而不只是依賴瀏覽器端的判斷。

要理解這個架構，可以把追蹤流程拆成兩個階段。第一階段是資料收集，發生在使用者瀏覽器中；第二階段是資料決策與轉發，發生在伺服器端。這種拆分方式讓 consent 判斷從一個「前端事件」變成「後端流程」，不僅提升控制的精確度，也降低了前端腳本被幹擾的風險。

客戶端與服務端容器的資料流傳遞

在標準的 Server-Side GTM 部署中，客戶端容器（Web Container）與服​​務端容器（Server Container）各司其職。客戶端容器內會整合 Consent Management Platform（CMP），當使用者進入網站並做出同意選擇後，CMP 會把 consent 狀態寫入資料層（dataLayer）。

此時客戶端容器不會立刻決定是否觸發所有 tag，而是將包含 consent 信號的請求傳送到服務端容器。服務端容器接收請求後，會解析其中的 consent 資訊，再依據該使用者的同意狀態，決定要放行、修改或阻止後續的 tag 觸發。

這個流程的關鍵優勢在於：決策點從瀏覽器移到了伺服器。當請求進入服務端容器時，發佈者可以在轉發到 Google Ads、GA4 或其他終點之前，對 payload 進行檢查與修改。以資料正確性的角度來看，這樣的設計讓追蹤流程多了一層治理機制，而不是依賴 client-side 腳本的完整執行。

關於 Server-Side GTM 的基礎資料流架構，可以參考 Server-Side GTM 是什麼？從資料流看伺服器端追蹤架構，這篇文章從資料層傳遞的角度說明瞭客戶端與服務端容器的協作關係。

Consent Mode V2 在 Server-Side GTM 的運作機制

Consent Mode V2 相較 V1 新增了 ad_user_data 與 ad_personalization 兩個 consent 類型，進一步區隔廣告資料使用與個人化廣告的同意程度。在 Server-Side GTM 環境中，這些信號同樣會被傳遞到服務端容器，成爲 tag 放行與否的判斷依據。

V1 時代的 consent 信號主要涵蓋 analytics_storage 與 ad_storage，分別對應分析 cookie 與廣告 cookie 的儲存與讀取。V2 將廣告相關的 consent 拆得更細：ad_user_data 涉及的是「是否允許將使用者資料用於廣告目的」，而 ad_personalization 則針對「是否允許使用這些資料進行個人化廣告投放」。

這個拆分的意義在於，使用者可能願意讓網站收集資料用於成效衡量，但不希望這些資料被用於建立個人化廣告檔案。透過 V2 的機制，網站可以更精確地反映使用者意願，同時仍能在合規框架內取得一定程度的量測資料。

Consent Mode V2 的兩個新增信號

ad_user_data 的用途是控管資料是否可用於廣告相關處理，包括受衆建立、轉換比對等；ad_personalization 則控管資料是否可用於個人化廣告的投放與優化。兩者在 Google Ads 與 GA4 的喫使用邏輯上有所區隔：前者影響的是廣告系統的資料處理權限，後者影響的是廣告內容的個人化程度。

在 Server-Side GTM 的整合流程中，這些信號會隨請求參數傳遞到服務端容器。服務端容器內的 Google tag 會讀取這些 consent 狀態，若使用者拒絕特定類型的 consent，對應的 tag 就不會觸發，或只會觸發部分功能。

Cookieless pings 與轉換建模機制

Advanced Consent Mode 的運作方式與 Basic Consent Mode 有根本差異。在Basic Consent Mode下，若使用者拒絕 consent，Google tags 完全不會被觸發，網站等於喪失了該使用者的量測資料。而在Advanced Consent Mode下，即使使用者拒絕 consent，Google tags 仍會發送 cookieless pings，也就是不含 cookie 識別碼的請求。

這些 cookieless pings 雖然不包含可識別使用者的 cookie 資訊，但仍能攜帶匿名化的行爲信號，例如頁面瀏覽、點擊事件、轉換行爲等。Google Ads 與 GA4 收到這些匿名信號後，會結合過去已同意使用者的行爲模式，透過 consent mode modeling 進行轉換與行爲建模，估算被阻擋的資料中可能包含的轉換量。

這套機制對資料品質的影響有兩個層面。正面來看，Advanced Consent Mode 讓網站在合規前提下仍能保留相當程度的行爲資料；反面來看，建模終究是估算，與完整量測之間存在一定誤差。這也是爲什麼在設定時，需要明確區分 Basic 與 Advanced 兩種模式，並依據網站的合規需求選擇合適的方案。

Consent 模式	同意狀態	資料傳輸行爲	轉換建模支援
Basic Consent Mode	拒絕	Google tags 完全不觸發，無資料傳輸	不支援
Advanced Consent Mode	拒絕	發送 cookieless pings，不包含 cookie 識別碼	支援，依 Google 的建模機制估算
Advanced Consent Mode	同意	正常觸發完整 tag，包含 cookie 識別碼	不適用，以實際量測資料爲準

需要強調的是，表格中的行爲差異是依據 Consent Mode 的設計邏輯整理，實際部署時仍應參考 Google 官方文件，確認當前版本的詳細規格。

Server-Side GTM 處理 Consent 的設定流程

在 Server-Side GTM 中設定 Consent Mode，需要在客戶端與服務端兩個容器中分別進行設定。客戶端的任務是收集 consent 信號並傳遞到服務端，服務端的任務則是讀取這些信號並據此決定 tag 的放行。以下依序說明兩個容器的設定重點。

Web Container 端的 CMP 整合步驟

第一步是在網站上安裝 CMP，並確認 CMP 能將 consent 狀態寫入 dataLayer。常見的 CMP 解決方案如 Google 認證的 Consent Management Providers，均可輸出標準的 consent 參數。

第二步是在 Web Container 中建立 consent 相關變量。GTM 提供「Consent 狀態」變量類型，可讀取 ad_storage、analytics_storage、ad_user_data、ad_personalization 等信號。建立這些變量後，才能讓後續的 tag 觸發邏輯引用。

第三步是調整 tag 的觸發條件。在 Web Container 中，可以針對每個 tag 設定「需要額外的 consent 檢查」規則，確保當特定 consent 類型被拒絕時，tag 不會被觸發。同時，也要確認 Web Container 中用於傳送資料到服務端容器的請求，會一併附上當前的 consent 狀態。

Server Container 端的 Consent 信號接收與處理

服務端容器的設定重點在於：確認接收到的請求中包含 consent 參數，並確保服務端內的 Google Tags 能正確讀取。如果不做特殊處理，服務端容器的 tag 可能只會看到「有一個請求進來」，而不會自動判斷請求背後的 consent 狀態。

實務上，需要將客戶端傳來的 consent 參數解析爲服務端可讀取的變量。做法是在 Server Container 中建立對應的「事件資料」變量，然後再將這個變量與 service 端的 Google tag 建立關聯。

服務端容器的常見架構之一，是在客戶端使用「Google 標籤」這種 tag 類型，讓請求直接由服務端容器內的 Google 端點處理。這個端點本身具備解析標準 consent 參數的能力，只要客戶端請求有帶上正確的參數名稱，服務端就能正確判斷。

完整的部署流程牽涉到容器建立、自訂網域設定與 tag 配置，如果是初次接觸這項技術，可以參考 GTM Server-Side 設定教學：從建立容器到自訂網域部署，這篇文章可以幫你建立基礎的環境設定概念。

Server-Side GTM 對資料控制與合規追蹤的優勢

Server-Side GTM 與傳統 Web GTM 在 consent 處理上的最大差異，在於追蹤腳本的執行環境與資料的控制能力。傳統 Web GTM 的所有 tag 都在瀏覽器中執行，容易受到廣告阻擋器的幹擾，也較難在資料送出的過程中進行額外的檢查或修改；而 Server-Side GTM 將執行環節轉移到伺服器，提供了更多控制彈性。

sGTM 與傳統 Web GTM 的 Consent 處理差異

傳統 Web GTM 的流程是：使用者進入網頁 → tag 管理器讀取 consent 狀態 → 決定是否觸發 tag → 資料直接從瀏覽器發送到 Google 或其他終點。在這樣的流程中，廣告阻擋器可以輕易攔截第三方請求，導致資料丟失。即使 consent 狀態正確，被攔截的請求依然無法到達終點。

Server-Side GTM 的流程則是：使用者進入網頁 → Web Container 收集 consent 狀態 → 將請求傳送到自訂網域（通常是第一方網域）→ Server Container 接收後決定如何處理 → 轉發到終點。由於請求發往的是第一方網域，廣告阻擋器較難識別並攔截這些流量，因爲看起來就像一般的第一方請求。

此外，Server-Side GTM 也允許在資料轉發前檢查或修改 payload。例如，可以在服務端容器中設定邏輯，檢查某些請求是否符合預期的參數格式，或根據特定條件增加額外參數。這種「伺服器端的資料治理」能力，在傳統 Web GTM 中是不存在的。

對於廣告阻擋器常造成的資料流失問題，若想進一步瞭解 Server-Side GTM 在這方面的防護機制，可以參考 Server-Side GTM 如何解決廣告阻擋器導致的流量流失問題？。這篇文章從量測資料完整性的角度，分析了伺服器端追蹤如何降低阻斷風險。

但需要注意的是，Server-Side GTM 並非「繞過」consent 的工具。它改變的是資料的傳輸路徑與控制方式，而非使用者同意與否的事實。若使用者拒絕 consent，正確的作法是仍然不發送可識別資料，而不是利用服務端「隱藏」追蹤行爲。

Consent Mode 在 Server-Side GTM 的常見陷阱與排解

Consent Mode 在 Server-Side GTM 環境中最常見的陷阱，是誤以爲服務端容器會自動處理 consent 判斷。事實上，Server-Side GTM 目前尚未有內建的 Consent Mode 功能，必須透官方提供的 template 進行明確的整合，否則 consent 信號很容易在兩層容器之間遺失。

以下是設定時的檢查清單，建議逐項確認：

第一，確認 Web Container 中的 CMP 正確寫入 consent 信號。ad_storage、analytics_storage、ad_user_data、ad_personalization 四個參數都應出現在 dataLayer 中，且值符合預期格式。若 CMP 沒有輸出 ad_user_data 或 ad_personalization，則需要升級 CMP 版本或調整設定。

第二，確認 Web Container 傳送給 Server Container 的請求中，確實包含 consent 參數。可以透過 GTM 預覽模式檢查客戶端發出的請求，查看 URL 參數或 request body 中是否有 ad_storage 等字段。

第三，確認 Server Container 接收到請求後，能正確解析 consent 參數並在 tag 觸發邏輯中使用。可以在 Server Container 中建立「Consent 檢查」的變量，並用預覽模式驗證不同 consent 組合下，tag 的觸發行爲是否符合預期。

第四，確認使用的是官方提供的 Consent Mode template。由於 sGTM 沒有內建 Consent Mode，必須使用 Google 或 Microsoft 提供的官方 template 來建立 consent 與 tag 的關聯。使用非官方的自訂 template 可能造成行爲不一致，也難以確保後續更新維護。

第五，測試實際使用者流程。分別模擬「全部同意」「全部拒絕」「部分同意」三種情境，確認資料接收端（GA4、Google Ads）收到的事件數量與內容符合預期。在 Advanced Consent Mode 下，拒絕同意的情境仍應收到 cookieless pings，若沒有收到，說明服務端容器的設定可能遺漏了 cookieless 請求的轉發邏輯。

第六，定期檢驗容器發佈後的行爲。Consent Mode 的機制與各瀏覽器對 cookie 的政策都會隨時間調整，建議在瀏覽器版本更新或 CMP 升級之後，重新執行上述檢查。

最後要提醒的是，將 Conssent Mode 部署到 Server-Side GTM 並不等於「自動化」了合規流程。它提供的是更精確的控制工具，但如何定義同意狀態、如何在資料處理流程中落實這些狀態，仍然是發佈者需要自行規劃與管理的責任。

若想在 Server-Side 與 Client-Side 架構之間做出選擇，瞭解兩者的差異會有幫助。GTM Server-Side 與 Client-Side 架構差異：2026 年 SEO 如何選擇最佳標記管理方案 整理了兩種架構在追蹤能力與部署考量上的異同，可作爲評估時的參考。

Server-Side GTM 有內建 Consent Mode 嗎？

目前 Server-Side GTM 尚未有內建的 Consent Mode，需要透過 Google 或 Microsoft Consent Mode 官方 template 進行明確整合，才能正確處理 consent 信號。若沒有使用官方 template，服務端容器無法自動判斷請求背後的 consent 狀態。

Consent Mode V2 新增了哪些 consent 信號？

Consent Mode V2 相較 V1 新增了 ad_user_data 與 ad_personalization 兩個 consent 類型。前者控管資料是否可用於廣告相關處理，後者控管資料是否可用於個人化廣告投放，進一步區隔廣告資料使用與個人化程度。

當使用者拒絕 consent 時，Server-Side GTM 還能收集資料嗎？

在 Advanced Consent Mode 下，即使使用者拒絕 consent，Google tags 仍會發送 cookieless pings，也就是不含 cookie 識別碼的匿名信號。Google Ads 與 GA4 可藉此進行轉換與行爲建模，但無法辨識個別使用者。

客戶端與服務端容器在 Consent Mode 中分別扮演什麼角色？

客戶端容器負責收集使用者的 consent 信號，並將這些信號附加在傳送至服務端的請求中。服務端容器接收這些信號後，在決定是否放行 tag 前進行處理，形成雙層控制架構。兩者缺一不可：少了客戶端的收集，服務端無從取得 consent 資訊；少了服務端的判斷，資料流就缺少了後端治理的環節。

Server-Side GTM 如何降低廣告阻擋器對 Consent 追蹤的幹擾？

Server-Side GTM 將追蹤腳本移至伺服器端執行，請求發往自訂的第一方網域，廣告阻擋器較難識別並攔截這些流量，因此能降低對 client-side 腳本的阻擋，減少資料丟失。同時，服務端容器也允許在資料轉發前檢查或修改 payload，提供額外一層控制。