Cookie和CMP系統政策

1）目的和領域

在Web、iOS/Android、e-mail/SMS/Push、附屬登陸、流等所有曲面上建立合法存儲/讀取ID （cookies, local storage, SDK）和通過CMP管理同意的統一規則。該文件補充說：「GDPR：同意管理」，「年齡驗證」，「廣告標準」。

2）法律框架（簡述）

ePrivacy：任何非嚴格必需的cookies/SDK-僅在獲得同意後。「嚴格必需」（身份驗證、籃子/平衡、安全/防凍）-未經同意允許。
GDPR：同意作為合法的處理基礎（Art。6(1)(a));對於服務運營-合同需求（Art。6(1)(b));合法利益-有限且具有反對權。
兒童/弱勢群體：市場營銷/個性化標識符-禁止使用。

3）原則

1.Prior Consent：在CMP中選擇之前沒有必要的標簽。
2.目標分離：分析，個性化，營銷，重新銷售，地理定位，A/B-單獨的撥號器。
3.召回=點擊：就像同意一樣簡單；立即停止處理。
4.沒有黑暗模式：「接受全部」/「拒絕全部」/「自定義」的同等可見性。
5.可證明性：文本版本，哈希，UI截圖，firing規則日誌。
6.最小化/本地化：只在允許的區域放置和存儲所需的內容。

4）角色和RACI

DPO/Compliance（所有者）-政策，DPIA，對投訴的回應。(A)

法律-文本、本地要求和保留時間。(R)

產品/UX-橫幅/面板，可用性和位置。(R)

工程/CMP所有者-標簽鎖，SDK，API和版本。(R)

Data/Analytics-基於同意的識別模式。(C)

CRM/Ads-根據撤回的同意書進行補充。(R)

InfoSec-加密、密鑰、訪問同意日誌。(C)

內部審計-證據樣本，CAPA。(C)

5） Cookie 分類法/SDK

• 會議/身份驗證，平衡/籃子，防凍和負載分配，保持隱私選擇。

• 分析（用戶級別，跨設備ID）。
• 個性化（內容/遊戲、建議）。
• 營銷（電子郵件/SMS/push-單獨的渠道）。
• 重新營銷/Ads（第三方像素/SDK）。
• A/B測試（如果使用ID）。
• 地理位置「城市/地區」（非嚴格性）。

6） CMP： UX模式和文本

第一層（橫幅）：簡要目標,3個等效按鈕：拒絕全部/設置/接受全部。
第二層（面板）：目標撥號器、供應商和保留期限列表、策略鏈接。
首選中心：在玩家的個人資料中-渠道營銷標誌（電子郵件/SMS/push/電話），「拒絕一切」。
可用性：AA+對比，焦點陷阱，屏幕閱讀器，本地化，移動適應。
GPC/Do Not Track：全局信號=拒絕所有（嚴格要求除外）。
Apps： in-app CMP+系統OS-prompts；與服務器配置文件同步。

7) IAB TCF 2.2（框架）

生成和存儲TC字符串、供應商列表版本、目標映射↔我們的標誌。
在收到TC （prior consent）之前鎖定第三個標簽。
尊重每個供應商和目標的許可/禁令。
對於TCF以外的市場，是具有類似日誌的定制CMP。

8）標簽、Tag Manager和Server side

Deny by default：在同意之前,TM中的規則會阻止所有非必需的標簽。
Server side tagging：在沒有同意的情況下,使用無效/身份掩蔽的代理環路；配置存儲在允許的區域中。
SDK門：僅在目標的true標誌下初始化營銷/分析SDK。
Firing logs：誰/什麼/什麼時候「射擊」，同意的狀態。

9）數據，工件和修飾（最低模型）

consent_id, user_id/device_id, market, locale,
ui_variant_id, policy_version, tcf_string, vendors[],
purpose_id, status{accept    deny    withdraw}, source{web    app    sdk    api},
captured_at_utc, ip_hash, ua_hash, gpc{true    false},
evidence{banner_screenshot_id, copy_hash}, expires_at

WORM同意/評論日誌，文本版本，UI變體截圖。
Retentia：只要目標/關系有效+本地時間表；市場營銷-有限（通常≤ 24個非活動時間）。

10）集成： CRM/Ads/附屬公司

支持：召回→即時停用頻道和重新銷售（近實時+夜間擊球）。
E-mail/SMS：僅在通道明確為真時發送（按市場雙操作）。
附屬機構：沒有CMR/有效同意狀態的線索-不合格；version/hash條件-必須。

11）區域簡介（模板）

Market: ______
Required banner elements:...
Retention and localization:...
Requirements for TCF/vendor lists:...
GPC/DNT status:...
Documents/mandatory links:...

12）控制、測試和審計

CI-linter：檢查是否存在「拒絕一切」、GPC處理、鎖定標簽,直至獲得同意。
E2E測試：accept/deny/withdraw腳本→在CRM中驗證防火日誌和支持。
樣本：對UI同意記錄和截圖的季度審計；文本版本核對。
事件：任何未經同意的標簽啟動→立即取回，原因/虛構，CAPA。

13） KPI/KRI和dashboard

按目標/市場/設備分列的Opt-in Rate。
Withdraw率和Time-to-Apply（中位）。
GPC榮譽率（正確處理。信號）。
Tag Firing Violations（在1k下載中）。
Suppression Integrity（召回時營銷=0）。

Complaint Rate / Reg Findings.

Auditability Score（包含完整工件包的條目的百分比）。

14）支票單

發射前

• 標語為「拒絕所有人」，本地化，AA+可用性。
• 目標類別和供應商列表（Legal/DPO）是一致的。

[] Tag Manager: deny-by-default;SDK門。

• GPC被識別和應用。
• 帶有運河旗和「從一切中脫穎而出」的偏愛中心。
• WORM證據庫已啟用。

在操作中

• 監控火災違規和GPC。
• 在CRM/Ads中驗證支持。
• DSAR返回當前狀態和日誌。

審計/改進

• 季度同意和UI截圖樣本。
• 沒有黑暗模式的A/B橫幅。
• 更新區域簡介和文本。

15）模板（快速插入）

A）橫幅（第一層）

B）面板（重新銷售/廣告目標）

C）撤銷同意（確認）

D）對投訴的回應「不可能拒絕」

16）技術框架和事件

События: `cmp_banner_shown`, `consent_given/denied/withdrawn`, `gpc_detected`, `tag_fired_blocked`, `sdk_initialized/blocked`, `marketing_unsubscribed`, `dsar_fulfilled`.

API:

`GET /consents?user_id=…`

`POST /consents` (create/withdraw/update)

`POST /marketing/preferences`

`POST /gpc/signal`

基礎架構：服務器同意緩存,地域日誌綁定,deny時的ID掩碼。

17）風險與預防

在同意之前啟動標簽。→ Deny-by-default，E2E測試，警報。
橫幅中的深色模式。→設計評論，等同於按鈕的可見度。
CRM/Ads中的狀態不匹配。→單一支持服務和每日對賬。
收集多余的標識符.→最小化、掩蔽、區域配置文件。
缺乏證據。在WORM中→截圖/散列/記錄。

18）30天實施計劃

第一周

1.批準Cookie/目標分類法和文本（locali）；DPIA.

2.選擇/自定義CMP （TCF 2.2+定制目標），包括GPC。
3.專門化數據/工件模型，WORM存儲。

第二周

4）在Tag Manager、服務器同意緩存、SDK門中實現deny-by-default。
5）建立優先中心（運河標誌，「從一切中脫穎而出」）。
6）在CRM/Ads和附屬支線中設置支持。

第3周

7）10-20％流量的飛行員：Opt-in/Withdraw/GPC榮譽，Firing Logs測試。
8）關於支架和事件的UX/copiright/TM規則更正。

第四周

9）完整發布；啟用KPI/KRI和Alerta dashboard。
10）季度審計計劃和CAPA。

11）計劃v1。1： 服務器端標簽適用於所有市場,自動報告同意.

• GDPR：管理用戶同意
• 年齡檢查和年齡過濾器
• 廣告標準和禁令/Disclamers和廣告真實性
• 獎勵條款的透明度
• 跨轄區數據本地化
• 編譯和監視/內部和外部審計