簡短概述

TCF v2.3係v2.2嘅演進，而唔係重新架構。TC String格式保持兼容，現有嘅目的同功能得以保留，大多數面向出版商嘅UI要求亦都原樣沿用。有意義嘅變化集中喺四個範疇：

• CMP必須點樣呈現供應商資訊同保留期嘅規則更加清晰。
• 對細粒度二層控件嘅新要求，正正係自從2022年比利時DPA裁決以來監管機構一直喺度要求嘅嘢。
• 圍繞dark pattern、同等顯著度同預先剔選選項嘅政策執行進一步收緊。
• 對全球供應商列表（GVL）架構同供應商披露流程嘅調整。

v2.3點解會出現

每一個TCF版本都係三方受眾之間嘅博弈：需要繼續變現嘅出版商、需要穩定技術介面嘅供應商，以及不斷發現具體合規漏洞嘅監管機構。v2.3係對以下三種壓力嘅直接回應：

1. v2.2下對"合法利益"濫用嘅執法行動。多個歐洲DPA認定太多供應商喺本應只可以以同意為依據嘅目的上聲稱LI。v2.3收緊咗供應商聲明嘅合法依據披露規則，並將其喺同意UI中更早噉呈現。
2. 對dark pattern持續嘅投訴。更新後嘅政策令同等顯著度規則更加明確，並堵住咗二層上預先剔好嘅開關嘅漏洞。
3. 來自大型CMP同出版商嘅運營反饋。v2.2引入嘅幾項必要披露喺手機同CTV上難以乾淨地實現。v2.3精簡咗強制披露集合，並容許更多內容存在於分層視圖中。

TC String兼容性

TC String本身保持向後兼容。v2.3嘅CMP所產生嘅字串可以畀v2.2嘅供應商讀取，而v2.3嘅供應商喺過渡期亦可以消費v2.2字串。字串核心段中嘅版本標識符標明CMP聲明遵從嘅政策版本，而GVL版本指標就獨立向前推進。

實際意味住：你唔需要同時升級所有供應商，亦都唔需要喺部署v2.3嗰一日對每一個用戶強制重新取得同意。分階段推出係被明確支援嘅。

關鍵技術變化

1. 供應商披露同保留期

v2.3要求CMP喺分層UI中呈現每個供應商所聲明嘅資料保留期，而唔單止係喺另外嘅供應商列表度。保留期一直都係GVL嘅一部分，但係v2.2並冇強制要求用戶喺睇目的嘅時候同時睇到佢。v2.3堵住咗呢個缺口，因為監管機構認為，用戶喺唔知道資料會保存幾耐嘅情況下，冇辦法做出知情選擇。

2. 更嚴格嘅二層控件

喺二層——即係"管理偏好"視圖——入面，v2.3明確規定非必要目的同供應商嘅開關必須預設關閉。即使用戶從未明確點擊"接受"，預先剔好嘅方格或者預先啟動嘅滑桿都屬於政策違規。之前依賴"軟選擇加入"模式嘅CMP都要重新渲染佢哋嘅二層介面。

3. 同等顯著度嘅執行

同等顯著度規則由v2.1起已經存在，但v2.3對佢嘅定義更加明確，解釋空間更細："全部拒絕"控件必須同"全部接受"處於同一層，具有相同嘅視覺份量、相同嘅色彩對比等級同相同嘅交互距離。將拒絕收埋喺連結、細掣或者次級畫面入面，而家已經係明確嘅合規失敗，而唔再係見仁見智嘅判斷。

4. 合法利益訊號傳遞

喺v2.3下聲明以合法利益作為合法依據嘅供應商，而家仲必須聲明佢哋已評估嘅目的，同埋其中邊啲已完成合法利益評估（LIA）。CMP要將呢啲聲明傳遞到用戶介面，令用戶喺掌握完整資訊下反對。實際上，呢個意味住"反對"流程現在會展示供應商特定嘅LIA狀態，而唔係一個一般性嘅開關。

5. GVL架構更新

全球供應商列表架構新增咗用嚟描述保留期粒度、LIA狀態，同埋指向每個供應商針對所聲明目的嘅私隱政策部分嘅機器可讀連結嘅欄位。緩存GVL嘅CMP，要喺指向v2.3 GVL之前更新其架構解析器，先至可以理解呢啲新欄位。

影響UX嘅政策變化

TCF既係一份技術規範，亦係一套政策。v2.3嘅幾項政策變化直接落喺同意UI上：

• 唔再允許"唔接受繼續"作為拒絕嘅等效操作，除非佢喺視覺上同接受掣相符，並且產生同完全拒絕相同嘅TC String。
• 語言平等——同意告知必須提供網站本身支援嘅每一種語言，而唔單止係用戶瀏覽器嘅語言。CMP必須支援區域設定覆寫。
• 持續可訪問——用戶必須可以由網站每一頁到達偏好中心，而唔只係落地頁，而且連結標籤要令非專家用戶都能識別出佢同同意有關。

出版商必須做嘅嘢

1. 確認你CMP供應商對v2.3嘅支援。問佢哋通過v2.3認證嘅構建確切可用日期同上報嘅版本字串。
2. 刷新你嘅GVL緩存邏輯。如果你自己托管任何GVL鏡像，喺v2.3 GVL推出之前更新架構解析器，否則你嘅CMP會無法驗證新供應商。
3. 重寫你嘅二層UI，令每個開關預設關閉、視覺上強制執行同等顯著度，並喺目的旁邊展示保留期。
4. 重新進行一次合規審核。最容易拎嘅監管勝利就係v2.3而家明確指出嘅dark pattern違規。趕喺下次執法審查之前修正佢哋。
5. 規劃重新提示策略。雖然TC String向後兼容，但政策鼓勵出版商喺處理範圍或披露發生實質變化時重新徵求同意。判斷你嘅v2.3推出對你嘅受眾嚟講係咪"實質性變化"。

供應商必須做嘅嘢

1. 對每一個聲明LI嘅目的完成合法利益評估，並將結果提交到GVL。
2. 用v2.3架構欄位更新你嘅GVL條目：保留期粒度、LIA聲明同私隱政策深層連結。
3. 用IAB Europe提供嘅v2.3參考字串驗證你嘅TC String解析器。
4. 同你嘅CMP夥伴協調一個共同嘅切換日期，以免首個攜帶v2.3字串嘅買方請求落到一個只支援v2.2嘅供應商度。

常見嘅遷移陷阱

• 將v2.3當成UI重設計嘅機會。將品牌更新同v2.3推出捆綁一齊好有誘惑力，但咁做會令合規測試變得複雜。先發一個僅做合規嘅v2.3版本，然後再迭代設計。
• 漏咗保留期展示要求。團隊經常更新咗供應商列表視圖，但忘記保留期而家必須出現喺逐個目的嘅分層視圖入面。
• 以為TC String本身已經夠。由一個不合規嘅UI所產生嘅合規字串依然係不合規嘅。監管機構已經多次對字串睇落冇問題但橫額卻收埋拒絕掣嘅營運商罰款。
• 將CTV同手機排除出範圍。v2.3適用於每一個產生TCF信號嘅介面。只更新網頁而忽略CTV或手機應用嘅出版商，會製造出一個混合型不合規環境。

結語

TCF v2.3並唔係同v2.2嘅顛覆性決裂，但就係對支撐歐洲程序化生態嘅規則一次有意義嘅收緊。方向好清楚：更高透明度、更少dark pattern、更細粒度嘅用戶控制、以及對以往蒙混過關嘅邊緣情況更低嘅容忍度。將v2.3當成快速補丁嘅CMP同出版商，好快就會再次去到監管機構面前。將呢次遷移用嚟清理二層UX、揚棄合法利益捷徑、重建真正嘅同等顯著度同意流程嗰批人，就會帶住真正喺v2.3時代能夠順利出清嘅庫存走出另一邊——以及一個唔論v2.4帶嚟乜嘢都能捱得住嘅同意姿態。