Consent Mode 是什麼？2026 隱私追蹤與同意管理重點

Consent Mode 是什麼？

Consent Mode（同意模式）是把使用者同意狀態傳給 Google 標籤（Google tags）與軟體開發套件（SDK）的機制，讓 GA4、Google Ads、Floodlight 等工具依照同意狀態調整 Cookie、ID 與資料傳送行為。

Google 對 Consent Mode 的官方說明很清楚：它不提供同意橫幅，也不代替同意管理平台。它接收 Cookie Banner 或 CMP 傳來的選擇，再讓支援同意檢查的 Google tags 調整運作。對行銷團隊來說，Consent Mode 的角色不是「多裝一段追蹤碼」，而是把使用者選擇、廣告衡量與資料品質接在同一條流程上。

一句話摘要：Consent Mode 是同意訊號傳遞機制，核心任務是讓 Google 追蹤工具知道哪些資料可以用、哪些資料必須受限。

它和 Cookie Banner / CMP 有什麼不同？

項目	負責工作	常見誤解
同意橫幅（Cookie Banner）	把 Cookie、分析、行銷等選項呈現在畫面上，讓使用者做選擇。	以為畫面有按鈕就代表 Google 已收到正確同意狀態。
同意管理平台（Consent Management Platform, CMP）	管理同意選項、紀錄偏好，並把結果傳給網站或標籤系統。	以為安裝 CMP 就自動完成所有 Google 參數對應。
Consent Mode（同意模式）	把同意狀態傳給 Google tags / SDK，讓標籤依照 granted 或 denied 調整行為。	以為它可以取得同意、寫隱私權政策或保證合規。

實務上，最容易出錯的地方不是少了哪個工具，而是三者責任沒有接好。畫面有同意橫幅、後台有 CMP，不代表 ad_storage 或 analytics_storage 已在正確時間點送到 Google。

為什麼 2026 還需要談 Consent Mode？

2026 還需要談 Consent Mode，原因不只在法規，而是行銷追蹤本身已經進入「需要同意狀態才能判讀資料」的階段。第三方 Cookie 限制、瀏覽器隱私機制、Google Ads 與 GA4 的衡量需求，都讓追蹤不能只靠過去那種全站直接埋標籤的做法。

Google 在歐洲經濟區（EEA）相關政策中強調，若廣告主向 EEA 使用者投放廣告並使用特定受眾或衡量功能，需要傳送可驗證的同意訊號。這個背景不能被寫成「全球所有網站一律強制」，但對有跨境流量、Google Ads、再行銷或未來市場擴張的台灣網站，已經是該提前盤點的基礎設施。

Consent Mode 解決了什麼行銷追蹤問題？

Consent Mode 解決的是使用者同意、廣告追蹤、轉換衡量與隱私要求之間的衝突：當使用者同意狀態不同，Google tags 可以用不同方式處理 Cookie、事件與模型化資料。

沒有 Consent Mode 時，網站通常只剩兩種粗糙選擇：一種是標籤照常送出，增加隱私與政策風險；另一種是拒絕同意後全部封鎖，造成轉換追蹤、歸因與 ROAS（廣告投資報酬率）判讀出現資料缺口。兩種做法都讓行銷主管很難回答同一個問題：報表變差，到底是投放退步，還是追蹤少收？

導入 Consent Mode 後，Google tags 可以依照 granted 或 denied 狀態調整行為。使用者同意時，標籤能正常寫入或讀取相關 Cookie 與 ID；使用者拒絕時，Basic 與 Advanced 模式會有不同資料傳輸方式。判斷成效時，這會影響轉換模型、再行銷名單、受眾建立與個人化廣告可用性。

我的判斷是，Consent Mode 對台灣團隊最大的價值，不是讓報表變漂亮，而是讓「哪些資料是完整追蹤、哪些資料是受限或模型化」變得可管理。只看總轉換數，很容易誤判投放品質；把同意狀態納入追蹤架構，才比較有機會分清楚成效問題與資料問題。

使用者同意時，Google tags 如何運作？

當使用者授予同意，相關 consent type 會被設定為 granted。在這種狀態下，Google tags 通常可以寫入或讀取對應用途的 Cookie 或裝置識別資訊，並傳送較完整的衡量資料。例如 analytics_storage 為 granted 時，GA4 的分析 Cookie 可以支援工作階段與事件衡量；ad_storage 為 granted 時，Google Ads 相關 Cookie 與 ID 才能用於廣告衡量。

使用者拒絕時，會完全沒有資料嗎？

使用者拒絕時，不一定代表所有情境都完全沒有資料，關鍵在 Basic Consent Mode 與 Advanced Consent Mode。Basic 模式下，若使用者未同意，Google tags 會被阻擋，連同意狀態本身也不送出。Advanced 模式下，Google tags 會先載入並依預設 denied 狀態運作，可能傳送不含 Cookie 的測量或 consent pings，用於支援隱私保護下的模型化。

這裡要保守理解：模型化不等於把所有流失資料補回來。Google 也說明，模型化需要符合一定資料門檻，帳戶不一定會看到明確的提升數字或完整補償。

誰需要導入 Google Consent Mode v2？

最需要導入 Google Consent Mode v2 的，是使用 Google Ads、再行銷、GA4 轉換衡量或 Google Marketing Platform 的網站；只做自然流量的網站需求較低，但仍應視市場、CMP 與未來廣告規劃評估。

網站情境	導入優先度	主要原因	建議判斷
有投放 Google Ads，並追蹤轉換	高	影響轉換衡量、模型化與廣告最佳化資料。	優先盤點 v2 參數與 CMP 對應。
有做再行銷、受眾或個人化廣告	高	ad_user_data 與 ad_personalization 會影響廣告資料用途。	確認同意選項是否能分別映射。
只裝 GA4，沒有廣告投放	中	主要影響分析 Cookie 與資料品質。	不必誇大為一定必裝，但應與 CMP 一起規劃。
只做自然流量，且沒有跨境廣告	低到中	短期商業壓力較小，但仍涉及同意與分析追蹤治理。	可先整理 Cookie 類別與隱私權政策。
服務台灣，也可能接觸 EEA 使用者	中到高	平台政策與地區法規需要分開判斷。	不要等廣告帳戶出現限制才補架構。

有投放 Google Ads 或做再行銷

只要網站有 Google Ads 轉換追蹤、再行銷名單、受眾匯入或個人化廣告，Consent Mode v2 就屬於高優先度。原因是廣告系統需要知道使用者是否同意廣告 Cookie、廣告使用者資料傳送與個人化用途。漏掉 v2 參數時，轉換衡量可能受限，再行銷與受眾使用也可能受到影響。

只裝 GA4、沒有廣告投放

只用 GA4 的網站，Consent Mode 的重點多半落在 analytics_storage。如果使用者拒絕分析 Cookie，GA4 衡量會受到限制；如果同意狀態沒有正確傳送，報表中的工作階段、事件與轉換可能更難解讀。這類網站不必把 Consent Mode 說成最高緊急事項，但不能完全當作廣告團隊才需要處理的事。

只服務台灣市場，需要嗎？

只服務台灣市場時，不能直接套用 EEA 的強制語境；法規要求、平台政策與企業內部風險標準要分開看。不過，如果網站使用 Google Ads、GA4、CMP，或未來可能取得海外流量，提前把同意狀態與追蹤架構整理好，會比日後補救更穩。

很多台灣網站真正的問題不是現在有沒有被要求導入，而是從來沒有盤點過 Cookie 類別、標籤觸發順序與隱私權政策描述是否一致。

Consent Mode v2 的四個核心參數

Google Consent Mode v2 的四個核心參數是 ad_storage、analytics_storage、ad_user_data、ad_personalization，分別控制廣告儲存、分析儲存、廣告使用者資料傳送與個人化廣告同意。

參數	控制範圍	granted 時	denied 時
ad_storage	廣告相關 Cookie 或 ID 儲存。	可支援 Google Ads 轉換追蹤、廣告點擊識別與相關衡量。	廣告 Cookie 或 ID 使用受限，可能影響轉換與再行銷。
analytics_storage	分析相關 Cookie 或 ID 儲存。	可支援 GA4 工作階段、事件與使用行為衡量。	分析 Cookie 使用受限，GA4 資料完整度下降。
ad_user_data	是否同意把使用者資料傳送給 Google 作線上廣告用途。	可依同意狀態支援廣告衡量與相關用途。	廣告用途的使用者資料傳送受限。
ad_personalization	是否同意個人化廣告。	可支援再行銷與個人化廣告用途。	個人化廣告、再行銷受眾使用會受限制。

ad_storage

ad_storage 控制廣告用途的 Cookie 或裝置 ID 儲存。對 Google Ads 來說，它會影響廣告點擊後的轉換追蹤、Conversion Linker 與再行銷相關能力。若設定為 denied，廣告 Cookie 不應照常寫入或讀取，報表中的轉換歸因也可能出現缺口。

analytics_storage

analytics_storage 控制分析用途的 Cookie 或 ID 儲存，最常見影響對象是 GA4。當它為 granted，GA4 可以較完整地衡量工作階段、頁面瀏覽、事件與使用者互動；當它為 denied，分析資料會受到限制，Advanced 模式下則可能以不含 Cookie 的方式傳送受限測量訊號。

ad_user_data

ad_user_data 是 v2 的新增重點之一，用來表示使用者是否同意將資料傳送給 Google 作線上廣告用途。它不是單純的 Cookie 開關，而是資料用途層級的同意訊號。舊版只處理 ad_storage 與 analytics_storage 的網站，常見風險就是漏掉這個參數。

ad_personalization

ad_personalization 控制個人化廣告同意，會直接影響再行銷與受眾用途。當使用者拒絕個人化廣告時，即使某些衡量資料仍可在受限條件下處理，也不能把它解讀成可以照常用於個人化投放。這是行銷與法遵溝通時最該講清楚的一個參數。

Basic Consent Mode vs Advanced Consent Mode

Basic Consent Mode 與 Advanced Consent Mode 的差異在於 Google tags 何時載入、拒絕同意時是否傳送受限訊號，以及可支援的轉換模型細緻度；Advanced 不一定比較適合所有網站。

比較項目	Basic Consent Mode	Advanced Consent Mode
標籤載入	使用者與同意橫幅互動前，阻擋 Google tags 載入。	網站開啟時載入 Google tags，先套用預設同意狀態。
使用者拒絕時	Google 不會收到資料，連同意狀態也不送。	可能傳送 consent pings 或不含 Cookie 的測量訊號。
使用者同意時	標籤載入後送出 default 與 update consent states。	更新為 granted 後，才傳送完整衡量資料。
轉換模型	較依賴一般模型。	可能支援更細緻的廣告主層級模型。
實作風險	難點在阻擋標籤太早觸發。	難點在預設狀態、更新順序、CMP 非同步與隱私邊界。

選擇模式時，不應只問哪一種「比較強」。Basic 適合希望在使用者互動前完全不讓 Google tags 傳送資料的網站，但工程上要確保標籤真的被阻擋。Advanced 適合需要較完整衡量與模型化能力的廣告主，但前提是 CMP、default consent、update consent 與區域設定都能正確處理。

Basic 不等於比較簡單

Basic 名稱容易讓人誤會成「比較容易裝」。實際上，Basic 的重點是使用者互動前不能讓 Google tags 載入並送資料，這對 Google Tag Manager（GTM）、第三方外掛與既有追蹤碼很多的網站並不輕鬆。如果頁面一開就觸發 GA4 或 Google Ads 事件，Basic 的精神就已經被破壞。

Advanced 的好處與風險

Advanced 的好處是拒絕同意時仍可在受限條件下傳送訊號，支援更細緻的轉換模型與行為模型。不過，它也更依賴正確的預設狀態與更新流程。若預設誤設為 granted，或 CMP 還沒回傳選擇就讓標籤送出完整資料，風險會比 Basic 更難排查。

CMP 類別如何對應 Consent Mode 參數？

CMP 類別要對應 Consent Mode 參數時，通常會把分析類 Cookie 對應 analytics_storage，把行銷類 Cookie 對應 ad_storage、ad_user_data 與 ad_personalization。

CMP 常見類別	可能對應參數	判斷重點
必要 Cookie	通常不對應四個核心廣告與分析參數，可能涉及 security_storage。	只限網站運作、安全、登入或防詐等必要功能。
分析 Cookie	analytics_storage	是否允許 GA4 或其他分析工具儲存分析用途 Cookie。
行銷 Cookie	ad_storage	是否允許廣告 Cookie 或廣告 ID 用於衡量與再行銷。
廣告資料用途	ad_user_data	是否同意把使用者資料傳送給 Google 作線上廣告用途。
個人化廣告	ad_personalization	是否允許再行銷、受眾與個人化廣告。
功能或個人化體驗	functionality_storage、personalization_storage	語言設定、偏好設定、內容推薦等，不要和廣告個人化混在一起。

分析類 Cookie 對應 analytics_storage

如果 CMP 中有「分析」或「統計」類別，通常會對應 analytics_storage。這會影響 GA4 是否能使用分析 Cookie 來辨識工作階段、事件與回訪。行銷主管不需要看懂每一段程式碼，但至少要知道：分析同意被拒絕時，GA4 報表品質不會和全同意狀態一樣。

行銷類 Cookie 對應廣告相關參數

行銷類 Cookie 不應只對應 ad_storage 就結束。v2 還要看 ad_user_data 與 ad_personalization，因為一個控制廣告資料傳送，一個控制個人化廣告用途。這裡是很多舊 CMP 設定最容易漏的地方，也是再行銷與受眾功能受影響的常見來源。

必要與安全類 Cookie 不要混淆

必要與安全類 Cookie 通常用於登入、身份驗證、防詐、安全保護或記住網站基本設定。Google 的 consent types 也包含 security_storage、functionality_storage、personalization_storage 等延伸類型，但本文主軸仍是廣告與分析同意。把所有 Cookie 都塞進「必要」類別，短期看起來方便，長期會讓法遵、產品與行銷都很難交代。

Consent Mode 對廣告成效與資料判讀的影響

Consent Mode 會影響 Google Ads 轉換模型、再行銷名單、個人化廣告、受眾使用與 ROAS 判讀；它不保證補回所有資料，但能讓資料缺口更有規則可循。

影響層級	受影響項目	判讀方式
高	再行銷、個人化廣告、受眾名單。	拒絕 ad_personalization 或 ad_user_data 時，廣告用途會直接受限。
中到高	Google Ads 轉換追蹤與歸因。	同意缺口可能透過模型化處理，但需符合資料門檻。
中	GA4 事件、工作階段與轉換報表。	analytics_storage denied 時，分析資料完整度下降。
中	ROAS 與投放最佳化判讀。	報表變動可能同時來自投放表現與追蹤限制。

比較成熟的做法，是把 Consent Mode 導入視為資料治理的一部分。廣告成效下滑時，先確認同意率、標籤觸發、v2 參數、CMP 對應與模型化狀態，再去判斷素材、出價或受眾是否真的失效。

轉換不一定消失，但會變成模型化與門檻問題

在 Advanced 模式下，使用者拒絕 Cookie 時，Google 仍可能收到不含 Cookie 的測量訊號，用於支援轉換模型與行為模型。這不代表每筆轉換都能被還原，也不代表所有帳戶都會看到 uplift。Google Ads 與 GA4 的模型化需要一定資料條件，門檻沒達到時，報表可能看不到明顯補償。

再行銷與個人化廣告會更直接受影響

再行銷與個人化廣告比一般衡量更直接受同意影響。當使用者拒絕 ad_personalization 或相關廣告用途，網站不能把該選擇解讀成仍可照常建立受眾或投放個人化廣告。對投放負責人來說，這會影響名單規模、受眾品質與再行銷覆蓋率。

導入時要先檢查哪些事？

導入 Consent Mode 前，要先檢查 CMP 類別、Google tags 觸發順序、default consent、update consent、區域設定、GTM Consent Overview 與 Tag Assistant 驗證結果。

• 確認網站使用的是 GTM、gtag.js、CMP 外掛，或多種方式混用。
• 盤點 GA4、Google Ads、Floodlight、Conversion Linker 是否已存在。
• 確認同意橫幅的分析、行銷、個人化選項能對應 v2 參數。
• 確認預設同意狀態早於任何 measurement 指令。
• 確認使用者接受、拒絕、變更偏好時，都會送出 update。
• 確認 CMP 非同步載入時，是否需要 wait_for_update。
• 用 Tag Assistant 或 GTM Consent Overview 檢查標籤是否依同意狀態運作。

預設同意狀態必須早於 measurement 指令

Google Developers 的 Consent Mode 設定指南要求，在任何會送出 measurement data 的指令之前，先設定 default consent。這包含 GA4 config、event、Google Ads 轉換事件等。若順序錯了，標籤可能在同意狀態尚未建立前就送出資料。

使用者互動後必須送出 update

Consent Mode 不會替網站保存同意選擇。使用者按下接受、拒絕或調整偏好後，網站或 CMP 必須盡快送出 update，並把選擇保存到後續頁面可讀的位置。若只在第一頁更新，換頁後又回到空白或錯誤狀態，報表與隱私行為都會不穩。

GTM、gtag.js、CMP 的責任分工

GTM 負責標籤管理與 consent checks，gtag.js 是直接向 Google tag 傳送 consent command 的方式，CMP 則負責取得與管理使用者選擇。三者可以合作，但不能互相代替。工程端要處理順序，行銷端要確認追蹤需求，法遵或產品窗口要確認同意文案、隱私權政策與合法基礎判斷。

常見錯誤與排查方向

Consent Mode 常見錯誤包含標籤太早觸發、沒有 default、沒有 update、CMP 非同步延遲、區域設定錯誤，以及只設定舊版參數卻漏掉 v2 廣告參數。

錯誤	症狀	檢查點
Google tag 太早觸發	使用者還沒看到同意橫幅，GA4 或 Ads 事件已送出。	檢查 GTM 觸發條件、Consent Initialization 與 Tag Assistant 時序。
沒有 default consent	同意狀態空白，標籤行為不可預期。	確認每頁都在 measurement 指令前設定 default。
沒有 update consent	使用者按下同意後，Google tags 仍停留在 denied 或空白狀態。	檢查 CMP 回呼、dataLayer 事件與 update command。
CMP 非同步太慢	標籤先跑，CMP 後回傳。	評估 wait_for_update 與 CMP 載入順序。
漏掉 v2 參數	舊版同意設定存在，但 Google Ads 受眾或廣告用途仍受限。	確認 ad_user_data 與 ad_personalization 是否已設定。
區域設定錯誤	不該顯示橫幅的地區也被限制，或該限制的地區沒有套用。	檢查 CMP 地區規則與 Google consent region 設定。

同意橫幅還沒出現，Google tag 已經送出事件

這是最常見也最嚴重的實作問題。若採 Basic 模式，標籤應在使用者互動前被阻擋；若採 Advanced 模式，標籤可以載入，但必須先有正確的 default consent。排查時不要只看畫面上有沒有橫幅，要看 Tag Assistant 的時間序與每個事件當下的 consent state。

只設定 v1，漏掉 v2 兩個廣告參數

許多舊設定只處理 ad_storage 與 analytics_storage，但 v2 還需要 ad_user_data 與 ad_personalization。若漏掉這兩個參數，Google Ads 的廣告資料用途、再行銷與個人化廣告可能受影響。這不是小命名差異，而是用途同意層級的缺口。

Consent Mode 不能取代什麼？

Consent Mode 不能取代 CMP、Cookie Banner、隱私權政策、法律判斷或合法基礎評估，也不保證網站導入後就合規或資料品質自動恢復。

不能取代的項目	原因	應由誰處理
同意橫幅	Consent Mode 不提供使用者選擇介面。	產品、網站、CMP 或設計實作。
CMP	Consent Mode 不管理同意紀錄與偏好中心。	CMP 供應商、網站管理員、工程團隊。
隱私權政策	Consent Mode 不撰寫資料使用說明。	法遵、產品、法律或隱私顧問。
法律判斷	不同市場、資料用途與合法基礎需要個案判斷。	法律或隱私專業人員。
資料品質保證	拒絕同意、模型門檻與標籤錯誤仍會造成缺口。	行銷、分析與工程共同檢查。

它不是 Cookie Banner

Consent Mode 不會跳出視窗、提供按鈕或替使用者做選擇。它需要從同意橫幅或 CMP 接收結果，再把結果傳給 Google。若網站只有 Consent Mode，卻沒有可靠的同意取得流程，就只是把中間管線接起來，前端的同意來源仍然缺失。

它不是 GDPR 合規保證

導入 Consent Mode 不等於 GDPR、ePrivacy 或其他隱私要求自動合規。只要談到法規，就仍需 CMP、隱私權政策與合法基礎判斷。比較負責任的做法，是讓行銷、工程、產品與法律或隱私顧問一起確認資料用途，而不是把所有責任交給一段標籤設定。

結論：Consent Mode 是隱私優先追蹤的基礎設施

Consent Mode v2 是現代 Google 行銷追蹤的基礎設施：它讓同意狀態進入 GA4、Google Ads 與 Google tags 的運作邏輯，並影響轉換衡量、再行銷、受眾與資料判讀。

• 第一，先把 Consent Mode 理解成同意訊號管線，不要把它當成 Cookie Banner 或合規保證。
• 第二，有 Google Ads、再行銷或跨境流量的網站，應優先檢查 v2 四個核心參數。
• 第三，導入前先處理 CMP 對應、default / update 順序與驗證流程，否則報表問題會很難追。

對台灣行銷團隊來說，Consent Mode 最實際的價值，是把隱私要求和成效衡量放進同一個可檢查的架構裡。它不是萬靈丹，但已經是 Google 追蹤系統中很難忽略的底層設定。

Consent Mode 是什麼？

Consent Mode（同意模式）是 Google 提供的同意訊號傳遞機制，用來把使用者對 Cookie、廣告與分析用途的同意狀態傳給 Google tags / SDK。Google tags 會依照 granted 或 denied 狀態調整 Cookie、ID 與資料傳送行為。

Consent Mode 跟 Cookie Banner 有什麼不同？

Cookie Banner 是使用者看到的同意選擇介面，CMP 負責管理與紀錄同意，Consent Mode 則負責把同意狀態傳給 Google。三者常一起使用，但責任不同。

Google Consent Mode v2 一定要導入嗎？

不應寫成全球所有網站一律強制。若網站使用 Google Ads、再行銷、Google Marketing Platform，或會向 EEA 使用者投放廣告，導入優先度很高。只做台灣自然流量的網站，可依 CMP、分析需求與未來廣告規劃評估。

只用 GA4、沒有投 Google Ads，也需要 Consent Mode 嗎？

需求通常較 Google Ads 網站低，但仍有價值。只用 GA4 時，重點是 analytics_storage 與分析資料品質。若網站已有 CMP 或同意橫幅，建議一併規劃 GA4 的同意狀態，而不是讓分析標籤和同意選擇脫鉤。

Basic Consent Mode 和 Advanced Consent Mode 差在哪？

Basic 會在使用者與同意橫幅互動前阻擋 Google tags，拒絕時不傳送資料。Advanced 會先載入 Google tags 並套用預設同意狀態，拒絕時可能傳送不含 Cookie 的受限訊號，支援更細緻的模型化。Advanced 功能較完整，但也更要求設定正確。

ad_storage、analytics_storage、ad_user_data、ad_personalization 分別代表什麼？

ad_storage 控制廣告 Cookie 或 ID 儲存，analytics_storage 控制分析 Cookie 或 ID 儲存，ad_user_data 表示是否同意把使用者資料傳送給 Google 作線上廣告用途，ad_personalization 表示是否同意個人化廣告與再行銷用途。

使用者拒絕 Cookie 時，Google 還會收到資料嗎？

要看模式。Basic 模式下，使用者拒絕時 Google tags 被阻擋，通常不會收到資料。Advanced 模式下，Google 可能收到不含 Cookie 的 consent pings 或受限測量訊號，用於隱私保護下的模型化。

Consent Mode 可以取代 CMP 或隱私權政策嗎？

不可以。Consent Mode 不負責取得同意、不管理同意紀錄，也不撰寫隱私權政策。只要涉及法規與資料用途，仍需 CMP、隱私權政策與合法基礎判斷。

要怎麼初步確認 Consent Mode 有沒有設定成功？

可以用 Google Tag Assistant、GTM Consent Overview 與瀏覽器開發者工具初步檢查。重點看 default consent 是否早於 measurement 指令、使用者互動後是否送出 update、四個 v2 核心參數是否都有正確狀態，以及拒絕同意時標籤行為是否符合預期。

可以關掉 Google Consent Mode 嗎？關掉會影響什麼？

技術上可以不導入或移除，但影響取決於網站使用的 Google 產品與市場。若有 Google Ads、再行銷、轉換追蹤或 EEA 廣告流量，關掉可能影響衡量、受眾、個人化廣告與平台政策要求。關掉前應先確認 CMP、法規責任與廣告帳戶需求。

functionality_storage、personalization_storage、security_storage 需要一起設定嗎？

這些是延伸 consent types，是否需要設定取決於網站功能與資料用途。functionality_storage 常見於語言或功能設定，personalization_storage 常見於內容或體驗個人化，security_storage 常見於安全與身份驗證。不要把它們和 Google Ads 的四個核心參數混為一談。

Consent Mode 會讓轉換資料變準，還是只是符合法規？

兩者都不該講得太滿。Consent Mode 可以讓同意狀態下的追蹤更有規則，並在部分情境支援轉換模型與資料缺口判讀；但它不保證轉換資料一定變準，也不等於符合法規。資料品質仍取決於 CMP、標籤設定、同意率、模型門檻與合法基礎判斷。