第三方 Cookie 退場後，廣告追蹤要分兩層處理：Consent Mode 傳遞使用者同意狀態，伺服器端追蹤接收事件並在伺服器處理。兩者可以一起用，但不是同一項功能；關鍵是把「使用者同意什麼、網站產生什麼事件、哪些資料送到哪裡」拆開管理。
Chrome 對第三方 Cookie 的安排也不是一條固定的全面關閉時間表。Google 在 2025 年 4 月表示，Chrome 會維持讓使用者在隱私與安全設定中選擇第三方 Cookie 的做法，無痕模式仍預設封鎖第三方 Cookie。Google Privacy Sandbox 的公告。
因此，網站現在該做的是建立可取得同意、可驗證事件、可處理缺口的追蹤架構。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →第三方 Cookie 改變了什麼
第三方 Cookie 是由不同於使用者正在瀏覽之網站的網域寫入或讀取的 Cookie。
Google Privacy Sandbox 的Related Website Sets 說明也以目前網站以外來源的 Cookie 說明這個分類。廣告系統過去可用它把跨網站瀏覽訊號串起來；當瀏覽器限制這類儲存方式，跨網站識別、再行銷名單與轉換歸因都會受到瀏覽器、裝置和使用者設定影響。
這不代表第一方資料、網站事件和廣告點擊資訊全部失效。第一方資料是組織直接向使用者取得，或在使用者與組織互動時取得的資料。
事件則是「查看商品頁」「送出表單」「完成訂單」這類可定義的行為。Google Analytics 的說明也把同意狀態與標記行為分開處理。追蹤設計要先把事件定義清楚，再決定每個事件需要哪些同意與傳送方式。
也要把「瀏覽器限制」和「使用者不同意」分開看。前者可能使某種 Cookie 讀不到，後者則是網站收到的選擇。Google 的 Consent Mode 讓標記依照同意狀態調整行為；它不是 Cookie 同意橫幅，也不會替網站決定法律上的同意條件。
Google Analytics 的 Consent Mode 說明指出，Consent Mode 要和網站的同意管理介面互相傳遞選擇。
Consent Mode 到底在做什麼
Consent Mode 可以理解成「標記的行為開關」。網站先設定預設同意狀態，使用者在同意介面做出選擇後，網站再更新狀態。
Google 標記會依照廣告儲存、分析儲存、廣告使用者資料與廣告個人化等同意項目，決定是否寫入 Cookie、是否送出特定資料。Google Analytics 的 Consent Mode 說明列出這個流程。
其中，analytics_storage 關係到分析用途的儲存；ad_storage 關係到廣告用途的 Cookie 與識別資訊。
ad_user_data 與傳送給 Google 的廣告用途使用者資料有關；ad_personalization 則控制個人化廣告。各項狀態的定義可對照 Consent Mode reference。
Google 把網站做法分成 basic 與 advanced 兩種。Basic 做法是在使用者與同意介面互動前阻止 Google 標記載入；使用者拒絕時，不把資料送到 Google。
Advanced 做法讓標記載入，在拒絕狀態下送出不使用 Cookie 的訊號，等使用者選擇後再更新狀態。兩者的資料流、隱私評估與網站法遵條件不同，需依網站資料政策評估。
拒絕狀態下的 cookieless ping 可能包含時間、瀏覽器 user agent、來源頁和同意狀態等資訊；它不是完整使用者追蹤。
Google 的說明指出，這些訊號可用於行為與轉換模擬，模型會依資料門檻與資格條件補足量測缺口，結果不等於每位使用者的完整已觀測行為。參數參考與Google Ads 模型說明提供依據。
Consent Mode 說明、參數參考與Google Ads 模型說明都提醒，訊號內容和模型結果要依設定及資格條件判讀。
伺服器端追蹤不是把同意拿掉
伺服器端追蹤的核心是改變資料處理位置。Google Tag Manager 的說明是：瀏覽器或應用程式把請求送到你控制的伺服器容器，伺服器再依事件、觸發條件和標記設定處理，最後才把資料送往指定服務。Google 的伺服器端標記介紹把它和完全在瀏覽器執行的網頁容器分開說明。
它能解決的是資料路徑與控管問題，例如把不需要送出的欄位先刪除、統一事件格式、控制哪些目的地收到哪些事件，或讓部分資料處理邏輯移到伺服器；瀏覽器仍可能看見請求與其中部分資料。
它不能解決使用者沒有同意、網站沒有定義事件、訂單資料不完整或目的地拒收資料等問題。
伺服器端也不是「一上線就更安全」。伺服器環境的權限、日誌、憑證、資料保留期限、事件重送與個人資料欄位，都需要由網站管理。Google 的手動設定文件也提醒，伺服器環境的擁有者可能接觸資料，部署時要看該環境的條款與權限設計。伺服器端設定指南可作為基礎檢查清單。
| 問題 | Consent Mode | 伺服器端追蹤 |
|---|---|---|
| 主要處理 | 傳遞同意狀態，調整標記行為 | 接收、整理並轉送事件 |
| 主要位置 | 網站標記的同意狀態設定與更新流程 | 你控制的伺服器容器 |
| 不能單獨解決 | 同意條件與事件定義 | 同意問題與資料目的限制 |
| 適合先問 | 使用者選了什麼？ | 這筆事件要送去哪裡？ |
一個可維護的追蹤架構
第一層是同意層。網站要知道使用者選擇的是分析、廣告儲存、廣告資料或個人化中的哪一項，並把狀態傳給相關標記。Consent Mode 參數參考列出各項狀態。這一層要記錄預設狀態、更新時機與不同地區的規則，避免橫幅顯示了選項，標記卻沒有跟著改變。
第二層是事件層。先用商業流程寫事件名稱，例如 view_item、generate_lead、purchase，再列出每個事件的必要欄位、觸發時機和去重鍵。事件名稱不是目的地名稱；同一筆「送出表單」事件可以依同意狀態和資料政策，送往不同分析或廣告服務。
第三層是傳輸層。網站端可以送到伺服器容器，也可以直接送到 Google Analytics 或 Google Ads 等目的地的收集端點。
採用伺服器端時，先定義接收網址、請求格式、錯誤重試、事件去重和資料刪除流程，並記錄事件名稱、事件 ID、時間、同意狀態、必要參數、個人資料欄位與目的地。Google 的伺服器端標記介紹說明 client、event、tag、trigger 與 variable 的資料流。
第四層是目的地層。每個目的地都要有資料用途、欄位清單、同意條件與失敗回應。不要把所有欄位原封不動廣播給所有服務；例如訂單識別碼可能用於去重，但不代表姓名、電話或備註也應該跟著傳送。
第五層是驗證層。測試至少要涵蓋允許分析、拒絕分析、允許廣告、拒絕廣告、撤回同意、重整頁面與重複送出事件。Google 的 Consent Mode 說明要求確認標記是否遵守同意選項。每個情境都看三件事：瀏覽器是否寫入不該寫的 Cookie、伺服器是否收到正確的同意狀態、目的地是否收到符合政策的欄位。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →導入順序：先把量測做對，再談替代方案
第一步是盤點。把網站上的分析、廣告、客服、熱點圖和第三方嵌入逐一列出，參照伺服器端設定指南整理權限與資料接觸範圍，記下它們讀寫的儲存方式、觸發頁面、資料欄位和目的地。這個清單不是為了增加標記，而是為了找出沒有同意狀態、重複送出或用途不清楚的標記。
第二步是定義事件。把「看過頁面」和「完成重要行為」分開；前者可用於內容分析；頁面瀏覽、表單送出或訂單等事件，都可依商業目的納入轉換檢查。每個事件指定一個事件 ID 或去重規則，並寫清楚缺少必要欄位時要怎麼處理。事件規格穩定後，才有辦法比較瀏覽器端與伺服器端收到的資料。
第三步是接上同意管理。設定預設狀態、使用者更新狀態與撤回流程，依Consent Mode 導入說明檢查狀態傳遞。
先設定預設狀態，使用者選擇後立即更新並傳遞同意狀態，再確認標記遵守狀態；這三段要分開測，不要只看橫幅畫面有沒有出現。官方導入順序可作為驗收框架。
第四步才評估伺服器端。若瀏覽器端已有正確事件，但需要欄位清理、路由控制或集中管理，再設計伺服器容器。先在測試環境確認事件進得來、同意狀態傳得進來、目的地收到的欄位正確，再進入正式環境。不要用伺服器端追蹤掩蓋前端事件本身錯誤。
第五步是建立異常處理。記錄事件被拒收、欄位缺失、請求逾時、同一事件重送和同意狀態改變的情境。監控資料量時，要同時看原始事件、轉換事件和目的地回應；只看廣告報表的一個數字，無法知道缺口出在網站、伺服器還是目的地。
四個容易混淆的地方
第一，把 Consent Mode 當成同意橫幅。橫幅負責讓使用者作選擇，Consent Mode 負責讓標記知道選擇；若介面選擇未正確同步，資料流可能和使用者選擇不一致。
第二，把 cookieless ping 當成完整轉換資料。拒絕狀態下的訊號可能支援模型估算，但它不等於取得了完整識別資訊，也不能把模型欄位當成每一位使用者的已觀測行為。
第三，把伺服器端當成免同意通道。資料從瀏覽器先送到自己的伺服器，仍然是資料處理；同意狀態、用途、欄位和目的地都要一起設計。
第四，只測「允許」情境。拒絕、撤回、跨頁、重整和重送也可能讓錯誤浮現。測試報告要保存事件名稱、時間、同意狀態、欄位摘要和目的地回應，方便日後追查。
小型網站可以從哪裡開始
先把網站現有標記列成一張表，再挑一個重要事件做完整驗證。你可以先參考GA4 報表與事件的基礎文章，用UTM 參數文章整理來源欄位，再回頭檢查廣告標記；這和單一平台像素或轉換 API 的設定教學不同，重點是跨工具的資料分工。
若網站已經能穩定產生事件，再把同意狀態加入測試矩陣，最後才判斷是否需要伺服器端處理。若要設定單一平台的像素與轉換 API，應另查該平台的最新官方文件；焦點放在第三方 Cookie 變化下的共同架構。
工具介面與平台政策會更新，定期檢查標記文件、同意狀態、伺服器容器版本與目的地欄位。Google 也會調整 Consent Mode、模型與伺服器端文件，正式上線前應回看對應官方文件。
最後更新：2026-09
常見問題
第三方 Cookie 沒有全面消失，網站還需要準備 cookieless 追蹤嗎？
需要先準備能在不同瀏覽器與同意選擇下運作的事件架構。Chrome 的第三方 Cookie 選擇仍會由使用者在隱私與安全設定中管理，其他瀏覽器也可能採用不同限制；事件定義與同意狀態不應綁定單一 Cookie 行為。
Consent Mode basic 和 advanced 該怎麼選？
先看網站的同意設計與資料政策，再由法務或隱私負責人確認允許的資料流。Basic 在互動前阻止 Google 標記載入；advanced 會在拒絕狀態下傳送不使用 Cookie 的訊號，兩者不是只差一個設定值。Google 的說明列出這兩種資料流。
伺服器端追蹤需要把所有事件都搬過去嗎？
不需要。先選一個事件做欄位、同意、去重與目的地驗證；只有當伺服器端的路由或欄位控管能解決明確問題，再擴大事件範圍。
怎麼知道 Consent Mode 真的依照使用者選擇運作？
用允許、拒絕、撤回和重整等情境逐一測試，確認瀏覽器儲存、事件請求、同意參數和目的地回應彼此一致。只看到同意橫幅或報表有數字，不能代表整條資料流已驗證。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →