Privacy Sandbox 退場，第三方 Cookie 沒有被淘汰
Search Engine Land 在 2025 年 10 月 20 日報導，Privacy Sandbox 副總裁 Anthony Chavez 確認 Google 將退場 10 個剩餘的 Sandbox API，包括 Chrome 與 Android 上的 Attribution Reporting、Topics 與 Protected Audience。
同一篇報導指出，這距離 Google 放棄淘汰第三方 Cookie 的計畫已經超過一年。
依 Search Engine Land 的報導，CHIPS（Cookies Having Independent Partitioned State）、FedCM（Federated Credential Management）與 Private State Tokens 三項保留下來。
我們的判斷是，原本依賴 Attribution Reporting API 做歸因的設定，需要另找做法。
Meta Conversions API 怎麼補訊號，Event Match Quality 看什麼
Business of Apps 指出，Apple 的 App Tracking Transparency（ATT）在 2020 年推出，自 iOS 14.5 更新起對所有蒐集資料的 App 強制實施；iOS App 使用者中，選擇同意追蹤的不到一半。
Facebook 廣告的轉換追蹤，過去靠的是裝在網站上的 Pixel。DinMo 的 Meta Conversions API 指南寫到，iOS14 推出後，Meta 開放廣告主從自己的伺服器直接上傳轉換事件。想看這個名詞的完整定義，可以讀 Facebook 廣告術語頁。
DinMo 是提供 Composable CDP 方案的業者，它在 2026 年 9 月 11 日更新的指南中說明，Conversions API 讓企業不依賴第三方 Cookie，把轉換事件從自己的伺服器直接送到 Meta Ads，繞過使用者的瀏覽器。
opting for tracking via the Conversions API enables more precise and reliable tracking on your website, overcoming technological and regulatory constraints
中譯：DinMo 稱，透過 Conversions API 追蹤，可以在網站上取得更精確、更可靠的追蹤，克服技術與法規上的限制。
DinMo 也寫到，Meta 建議同時做瀏覽器端（Pixel）與伺服器端追蹤，該指南稱主要原因是部分比對鍵還無法從伺服器端收集，例如 fbp（Browser ID）與 fbc（Click ID）。
同一份指南把 Event Match Quality 定義為送出的轉換與 Facebook 使用者之間的比對率，送出越多完成事件的顧客個人資訊，分數越高。分數可以在 Facebook 事件管理工具裡點選事件分數查看。想看完整定義，可以讀 Event Match Quality 術語頁。
網頁事件同時經由 Pixel 與 Conversions API 送出時，Meta 可能從瀏覽器和伺服器各收到一次同樣的事件；DinMo 寫到，Meta 判定事件相同而重複時，會保留一筆、忽略其他，也就是去重。
DinMo 稱，為了驗證整體實作品質，Facebook 會顯示每個事件歸因到 Conversions API 的額外轉換數；該指南另稱，Purchase 事件平均多出約 20%，這是業者自己的說法，沒有列出處。
整合方式方面，該指南列出 Shopify、GTM Server Side 與 CAPI Gateway 等選項，並稱這類工具適合顧客路徑單純、轉換全在線上的公司。
同意模式的建模門檻：每 7 天 700 次廣告點擊
同意管理平台業者 Secure Privacy 在 2026 年 5 月 11 日的文章稱，使用者拒絕同意時，Advanced 同意模式會送出不含 Cookie 的 ping 校準 Google 的轉換建模，可補回 30% 到 70% 遺失的歸因；Basic 模式在取得同意前封鎖所有 Google 標籤，補不回任何歸因。
| 項目 | Basic 同意模式 | Advanced 同意模式 |
|---|---|---|
| 拒絕同意時的標籤行為 | 取得同意前封鎖所有 Google 標籤 | 以受限狀態載入，送出不含 Cookie 的 ping |
| 拒絕同意者的歸因補回 | 補不回 | Secure Privacy 稱 30% 到 70% |
同一篇文章提到兩組門檻，適用的系統不同。Secure Privacy 寫到，Google Ads 的建模需要每個國家與網域組合在 7 天內至少 700 次廣告點擊；GA4 的行為建模則要網站達到每日 1,000 名同意使用者的門檻，否則不論設定多正確都不會啟動。
但這篇文章的摘要段落，把每日 1,000 名以上 analytics_storage=granted 使用者（過去 28 天中有 7 天），以及同期間每日 1,000 次以上 analytics_storage=denied 的事件，寫成轉換建模的啟動條件，和後文 Google Ads 每 7 天 700 次點擊的說法不同，兩種寫法並列在此。
依 Secure Privacy，Google Ads 建模的門檻是每 7 天 700 次廣告點擊，以國家與網域的組合分開計算。
該文也提到，在 EEA 與英國的典型市場，廣告 Cookie 的同意率平均約 45%。
Secure Privacy 稱，同意訊號出錯時，Google 的工具不會馬上發現：
Google’s Tag Diagnostics system has a 48 to 72-hour detection latency for consent signal problems
中譯：Google 的 Tag Diagnostics 對同意訊號問題有 48 到 72 小時的偵測延遲；文章接著說，一個實作錯誤可能跑上三天，Google 自己的工具才登記得到。
文中轉引 Harvest Digital 的 Mike Teasdale 在 2026 年 4 月發表的案例：一個 Google Ads 帳號一夜之間失去 90% 的已測量轉換，最後透過行為建模補回 40% 的歸因資料，其餘 60% 永久流失。Secure Privacy 也寫到，設定錯誤期間的歷史資料無法從 Google 系統找回。
伺服器端追蹤修不了前端的同意訊號錯誤
Secure Privacy 寫到，透過第一方網域做伺服器端標記，可以繞過多數廣告攔截器，但它無法修正源自瀏覽器端的同意訊號錯誤；前端競態問題產生的錯誤同意狀態，會連同事件資料一起傳到伺服器容器。
在伺服器端 GTM 的架構裡，伺服器容器無法自行取得瀏覽器端的同意狀態；該文指出，網頁容器必須把同意狀態作為事件參數，一起送到伺服器容器。
依 Secure Privacy 的說法，沒有轉送同意狀態的伺服器容器，可能蒐集了不該蒐集的資料，也可能漏送該送的資料，造成歸因流失。
同一篇文章也提到，標籤若在同意狀態建立前就觸發，Google 會把未定義的狀態視為拒絕，並丟棄蒐集到的可識別資料。
Secure Privacy 列出的排查方式包括：用 Tag Assistant 檢查 Consent Initialization 事件，確認 ad_storage、analytics_storage、ad_user_data、ad_personalization 四個參數都有設定、預設為 denied，並在使用者操作後即時更新。
另一步是比較同期間 Google Ads 與 GA4 的轉換量；該文稱，考量歸因窗口差異後，若 Google Ads 低了超過 20%，同意訊號鏈多半在 GA4 與 Google Ads 之間斷掉。
TCF v2.3 時程：2026 年 2 月 28 日
同意管理業者 Clym 在 2026 年 2 月 18 日的文章指出，Google 自 2026 年 2 月 28 日起，要求所有新產生的 TC 字串符合 IAB TCF v2.3。
該文說明，這個期限直接影響在 EEA、英國或瑞士營運，並使用 Google Ad Manager、AdSense 或 AdMob 的出版商。
依 Clym 的說法，TCF v2.3 最主要的更新，是在 TC 字串中新增必要的 disclosedVendors 段落，它用 1 或 0 的二進位指示，確認某個廠商是否真的在同意管理平台（CMP）介面上揭露過。
期限過後，缺少必要段落的 TC 字串可能被視為無效，受影響的廣告請求可能退回 Limited Ads，也就是不使用個人化 Cookie、沒有完整鎖定能力的廣告。該文也寫到，期限前產生的字串可能仍然有效，一般不需要只因這次框架更新而重新取得同意。
Clym 建議使用 Google Ad Manager、AdSense 或 AdMob 的出版商，確認自己的 CMP 已取得 Google 的 TCF v2.3 認證。
中國 2026 年個資專項行動：互聯網廣告列為重點領域
安全內參轉載賽博研究院劉境棠的解讀文章指出，2026 年 4 月 2 日，中央網信辦、工業和信息化部、公安部發布《關於開展 2026 年個人信息保護系列專項行動的公告》，將互聯網廣告、教育、交通、衛生健康、金融列為重點治理領域。
依該文整理，廣告相關的要求包括：個人資料處理規則要載明將蒐集的個人資料用於廣告、使用者畫像等功能的情況，並列明向第三方提供個人資料的種類、目的、方式，以及接收方名稱與聯絡方式。
以自動化決策方式推送廣告的，要提供便於訪問和操作的關閉選項；使用者關閉個性化推薦後，不得繼續基於該目的蒐集相關個人資料，並應提供刪除個人特徵標籤等功能。
我們的判斷是，這份要求和歐洲的 TCF v2.3 屬於不同市場、不同機制，稽核清單需要分開準備。
銷波快觀點：靜默失敗不會報錯，只會安靜地印出 0
先講一個我們自己講錯的地方。2024 年我們在節目上談 Cookieless，判斷是第三方 Cookie 會全面停用，廣告追蹤能力大幅下降，市場會被推向自然流量。後來 Google 放棄了淘汰第三方 Cookie 的計畫，Privacy Sandbox 反而退場。預測的對象錯了。
但操作上的結論撐住了。我們當時說的是提早評估第一方數據，把收集能力建起來，降低對平台 Cookie 的依賴。路徑變了，施力點沒變。
再行銷這條線的變化最直接。我們的看法是，Conversions API 已經從進階選項變成基礎建設。Pixel 從瀏覽器端捕捉，API 從伺服器端補上顧客識別資料，兩條軌一起跑。三層受眾分層能不能做得細，看的就是訊號完整性。
最想提醒的是失敗的形狀。我們查一個客戶的廣告帳號，底下撈出兩顆同名像素。活動實際掛的那顆 2016 年建立、當天還在觸發、Purchase 事件的比對分數 9.2；另一顆是 2026 年 9 月新建的，最後觸發時間顯示 1969 年 12 月 31 日，也就是從來沒收過任何事件。這次掛對了，但那是運氣。
這種錯不在程式層也不在資料層，它在選單裡。兩個選項長得一模一樣，選錯不會警告、不會報錯、不會中斷，報表只會安靜地印出一整排 0。而 0 在轉換廣告的前幾天看起來完全正常。防法只有一條：改動轉換活動之後，回讀廣告組的 pixel_id 確認掛的是哪一顆。
同樣的形狀在別的地方也出現過。一個帳號資金正常、政策審核通過、素材全數過審，介面上全部綠燈，曝光是零。查到最後發現是系統層級的投遞限制在作用，不通知、不拒登、資格狀態照樣顯示符合。診斷的終點不是找到紅字。全綠燈卻不跑，本身就是證據。
把這兩件事和同意建模的門檻放在一起看，會發現同一個模式：平台的降級越來越傾向沉默，沒有錯誤訊息，只有慢慢消蝕的數字。能抵抗這件事的只有主動回讀：讀 ad_storage 的實際值、讀 pixel_id、讀比對分數、讀 Google Ads 與 GA4 轉換量的差距。Secure Privacy 提到的 48 到 72 小時偵測延遲，就是等系統發現之前，錯誤可能先跑掉的時間。
結論：先把同意訊號接對，再談伺服器端追蹤
DinMo 稱 Conversions API 可以繞過瀏覽器送出事件；Secure Privacy 則寫到，伺服器端標記修不了源自瀏覽器端的同意訊號錯誤。
依 Secure Privacy，Basic 模式補不回拒絕同意者的歸因，Advanced 模式可補回一部分；Google Ads 建模需要每個國家與網域組合 7 天累積 700 次廣告點擊。
在 EEA、英國或瑞士使用 Google 廣告服務的出版商，Clym 建議確認 CMP 已取得 TCF v2.3 認證。Meta 這一側，依 DinMo 的說法，送出的顧客資訊越完整，Event Match Quality 分數越高。
還有一件事現在就能做：挑一個轉換活動，回讀它掛的像素識別碼，確認是你以為的那一顆。
喜歡這篇？讓行銷變好懂，訂閱銷波快。
資料來源
- Google officially shuts down Privacy Sandboxsearchengineland.com
- iOS ATT opt-in ratesbusinessofapps.com
- Meta Conversions API: 2026 guidedinmo.com
- Consent Mode 轉換數據流失分析secureprivacy.ai
- TCF v2.3 deadline: what publishers must do before February 28, 2026clym.io
- 2026 年中國個人信息保護專項行動解讀secrss.com
