GDPR：管理用戶同意

1）目的和領域

創建一個統一、可驗證且用戶友好的同意和通信偏好管理流程,兼容GDPR和ePrivacy,適用於所有曲面：Web 、移動應用程序/SDK 、電子郵件/SMS/推送、附屬登陸、流/社交網絡、供應商標簽。

2）基本原則

自由，特定，知情和明確的意誌表達（無新聞/訪問條件）。
目標分離：分析，個性化，營銷，地理定位，A/B測試，第三方標簽-單獨的撥號器。
召回就像同意一樣簡單。沒有「任務」可以拒絕。
沒有黑暗模式。沒有視覺扭曲/鎖定。
可證明性。徽標，文本版本，UI變體的截圖，策略哈希。
缺省最小化和私有化。

3）法律依據（簡稱）

Art.6（1） （a）同意：市場營銷,個性化,身份分析,非條件cookies/SDK。
Art.6（1） （b）合同：提供服務所需的業務（嚴格需要的cookies）。
Art.6（1） （f）法律利益（LIA）：在強有力保障和反對權的情況下有限的生產率計量。
Art.8兒童：兒童同意年齡----國家門檻；在未成年人中-禁止營銷。
Art.9特殊類別：生物識別/健康-非市場營銷；單獨的法律依據/禁令。
ePrivacy：存儲/訪問設備（cookies/local storage/SDK）-未經同意,只有「嚴格要求」。其余的是經同意的。

4）角色和RACI

DPO/合規之頭-政策，DPIA，投訴/風險控制。(A)

法律-文本，需求本地化，基礎矩陣。(R)

產品/UX-橫幅/偏好中心，反黑暗模式。(R)

工程/CMP所有者-CMP/SDK，API，版本，GPC/DNT集成。(R)

CRM/Marketing-按同意標誌進行細分，表示。(R)

Data/Analytics-識別模式,跟蹤限制。(C)

InfoSec-加密，密鑰，RBAC/ABAC到同意日誌。(C)

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

5）同意和偏好的分類法

功能（未經同意）：嚴格需要（認證、籃子、平衡、防凍）。

1.分析（標識符/跨字節）

2.個性化內容/遊戲

3.營銷（電子郵件/SMS/push/in-arr/telematics）-分開頻道

4.重新銷售/Ads（包括像素/第三方SDK）

5.地理位置不嚴格（城市/地區）

6.A/B測試（如果使用ID）

7.附屬標簽/附屬像素

6）CMP UX模式（Web/mobile）

第一層（橫幅）：簡要目標+接受全部、拒絕全部、自定義是相同的可見性。
第二層（面板）：按類別分解和反轉「閱讀更多」（供應商、目標、時間）。
優惠中心（帳戶）：營銷渠道（電子郵件/SMS/push/電話）-分開；提及「拒絕一切」。
召回/更改：從任何屏幕點擊1-2次；不會更改對強制性功能的訪問。
可用性：對比度、鍵盤、屏幕閱讀器、位置。
GPC/」Do Not Track」：全局信號被解釋為拒絕除嚴格要求以外的所有信息。
移動SDK：在應用程序中CMP+系統權限（OS prompts） →與服務器配置文件同步。

7) IAB TCF 2.2（實施框架）

支持目標/功能堆棧、供應商列表、客戶端TC字符串。
保留TC行，版本，供應商列表；在我們的旗幟上塗抹。
在接收TC （prior consent）之前鎖定tag/SDK。
尊重「Deny All」的地位和供應商的終結。
對於非TCF市場，「定制」CMP具有相同的UX和日誌記錄。

8）未成年人和弱勢群體

如果<市場閾值年齡-沒有營銷渠道和個性化；分析僅嚴格需要/PII。
在下載SDK/像素之前驗證您的年齡。
SE/RG標誌：在自我約定中-強制營銷支持，無論同意如何。

9）保密、保管及保密

最小化模型：存儲操作事實（accept/deny/withdraw）、文本版本、TC字符串/哈希而不是「原始」cookie。
Retence：只要目標/關系+市場時間表有效（通常≤ 24個月沒有營銷活動）。
訪問：RBAC，不變日誌（WORM），時間在UTC。
刪除：召回→立即停止處理；cron清潔未使用的id/SDK緩存。

10）數據和證據（最低模型）

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

工件：在同意時散列策略文本和橫幅，變體截圖，活動標簽/SDK列表。
鏈接：「consent_id」 ↔ CRM/Ads事件以實現可跟蹤性。

11） API/SDK和標簽鎖定

Edge/CMP-SDK：在選擇之前-我們只裝載嚴格需要的腳本。

Server-Side API:

`GET /consents?user_id=...`

`POST /consents` (create/withdraw)

「POST/marketing/preferences」（通道標誌）

`POST /gpc/signal`

Tag Manager Guards： "fire if consent規則。purpose.marketing == true».

電子郵件/短信：僅通過'營銷'發送郵件。電子郵件==true'和「double opt-in」（如果需要市場）。

12）與CRM/Ads/關聯公司的兼容性

Suppression流：在CRM、Ads、附屬支線（batch+near-real-time）中召回→更新支持。
UTM/後背：僅傳輸技術參數；在沒有單獨法律框架的情況下，同意不會&quot；偏離&quot；夥伴。
附屬機構：必須顯示相同的SMR/Disclamer；沒有這個線索，就沒有資格了。

13）流程和案例

通過電子郵件進行反饋：在每封電子郵件中,「Unsubscribe all」和「Configure」。退出-立即在頁面/信中確認。
DSAR/呼籲：顯示當前的同意標誌，行動記錄；沒有第三方PII的出口。
改變目標：新目標→新的同意請求（不是&quot；追溯性&quot；）。
A/B測試：更改UI CMP-版本/屏幕到偽影中，對沒有暗模式進行審核。
事件：未經同意而錯誤加載標簽→立即加載，Logo審計，CAPA。

14） KPI/KRI和dashboard

按目標/市場/設備分列的Opt-in Rate

Withdraw/Change Rate和「Withdraw-Apply」中位數"

GPC榮譽率（正確處理的GPC信號比例）

Tag Firing Violations（未經同意發射）

Suppression Integrity（召回時營銷=0）

Complaint Rate и Regulatory Findings

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

15）支票單

發射前

• 基礎和目標矩陣已商定（法律/DPO）。
• CMP支持「拒絕一切」，GPC，本地。
• 在同意之前,Tag Manager會阻止所有非必需的標簽。
• 帶有頻道的偏好中心（電子郵件/SMS/push/電話）。
• 與CRM/Ads/附屬機構的聯系，以提供支持。
• WORM中的文本/截圖版本。

在操作中

• 監控違反消防規則和GPC的行為。
• DSAR以當前標誌和日誌進行響應。
• 投訴和事件-SLA和CAPA。

審計/改進

• 按證據完整性分列的季度抽樣。
• CMP的深色模式的A/B評論。
• 更新區域/法律文本。

16）模板（快速插入）

17）技術框架和事件

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

Fichi： GPC自動讀取；SDK門；server-side consent cache;Tag Manager的完整性驗證；用於分析的「PII自由」出口。
CI/CD中的測試：標簽鎖定linter，版本方案遷移，CMP屏幕測試。

18）風險與預防

標簽鎖定不完整.→ Tag Manager中的「deny by default」規則。
對供應商的依賴。→供應商/目標/司法管轄區列表，DPA和審計。
深色模式。→設計和按鈕等價控制。
缺乏證據.→截圖、文本哈希、WORM雜誌。
CRM/Ads中的狀態不匹配。→單一支持服務+每日對賬。

19）30天實施計劃

第一周

1.批準目標/基礎矩陣和文本（lokali）。
2.選擇/自定義CMP （TCF 2.2+定制目標）。
3.專門化數據和工件模型,啟用WORM。

第二周

4.集成CMP/SDK, Tag Manager 「deny by default」, GPC。
5.為CRM/Ads構建優先中心和API支持。
6.準備橫幅的A/B變體，屏幕修復。

第3周

7.10-20％的交通量飛行員：Opt-in/Withdraw/GPC榮譽測量。
8.關於投訴/事件的復古；UX/文本編輯。
9.將關聯連接至強制性CMP層。

第四周

10.完整發行；啟用KPI/KRI和Alerta dashboard。
11.季度審計計劃和CAPA。
12.計劃v1。1： Server consent cache,自動市場報告。

20）相關部分

年齡檢查和年齡過濾器

廣告標準和禁令/Disclamers和廣告真實性

獎勵條款的透明度

附屬機構和合作夥伴的合規性

跨轄區數據本地化

負責任的遊戲和限制/自我體驗/現實檢查

監管報告和數據格式/內部和外部審計