同意管理

1）責任條款及界限

同意（接受）：自願、知情、具體和明確的意願；可以召回。
法律依據：同意只是一種選擇（合同、合法依據、合法利益等）。模型必須同時存儲基礎和目標。
處理目標（purpose）：原子原因：分析、個性化、ads、email_marketing、data_sharing_vendor_X。
粒度：同意按目標、渠道、供應商、地區、數據類別進行存儲。
受試者的個人資料：人，設備，家庭，孩子的帳戶（未成年人的特殊規則）。

2）同意生命周期

1.收集：橫幅/SMR、配置文件設置、API/SDK、離線通道（聯系中心）。
2.驗證：年齡，地區，替代品的可用性（沒有「黑暗模式」）。
3.註冊：為目的創建同意事件和當前狀態快照。
4.分發：發布到事件總線,將緩存升級到邊緣,與供應商同步。
5.執行：在實時（網關/像素/SDK），batch（ETL/analytics）和ML pipline中應用。
6.更改/撤回：立即禁止新的收集/激活，隨後對歷史政策數據進行「清理」。
7.審計/報告：處理時同意的可證明性（誰、何時、文本版本）。

3）建築組件

CMP（同意管理平臺）：UI/SDK+API，在UX/轄區下格式化同意選項；文本和版本中的真相來源。
Consent Registry（註冊表）：一個可靠的狀態和同意事件存儲庫（僅限日誌+當前投影）。
Consent PDP/PEP: Policy Decision/Enforcement Point.PDP決定"可以嗎？"，PEP將解決方案應用於API網關，ETL，SDK等。
同意的邊緣緩存：周邊檢查的潛在性低。
合作夥伴/GPP/IAB網關：將本地目標轉換為合作夥伴信號並返回。
Data Lineage&Tagging：在整個鏈條上用同意/基礎標誌標記數據。

4）數據模型（電路）

json
{
"subject_id": "usr_123",
"subject_scope": "user",
"region": "EU",
"legal_basis": {
"analytics": "consent",
"personalization": "consent",
"security": "legitimate_interest",
"contract_core": "contract"
},
"purposes": {
"analytics": {"status": "granted", "version": "v5", "updated_at": "2025-10-31T13:20:10Z"},
"personalization": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"ads": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"email_marketing": {"status": "granted", "channel":"email","updated_at":"2025-10-31T13:22:05Z"}
},
"text_bundle": {"locale":"uk-UA","policy_version":"2025-09"},
"evidence": {"capture_ip":"203. 0. 113. 5","capture_ua":"Chrome/142"}
}

json
{
"event_id": "cse_987",
"subject_id": "usr_123",
"purpose": "personalization",
"previous": "denied",
"current": "granted",
"legal_basis": "consent",
"policy_version": "2025-09",
"captured_at": "2025-10-31T13:21:31Z",
"channel": "web",
"evidence": {
"banner_id": "cmp_v3",
"text_hash": "sha256:...",
"ip": "203. 0. 113. 5",
"ua": "Chrome/142",
"locale": "uk-UA"
}
}

5）信號協議和傳播

Web/App/SDK：存儲同意標記（cookie/local storage/secure store）+簽名/完整性檢查；登錄時的自動重新定位。
服務器側：「X-Consent-Token」/「X-Purposes」頭,SSR/邊緣渲染雙向交換。
合作夥伴/供應商：轉換為其格式（例如，目標矢量，通用信號「GPP/TCF」）；故障時為零信號/限制模式。
離線通道：操作員記錄音頻同意/checkbox，然後進行驗證並綁定到「主語_id」。

6）執行： 交通在何處和如何「切斷」

• 未經同意（/profile/enrich,/ads/,/events/track）鎖定端口/字段。
• 突變響應/查詢：切斷跟蹤器、個性化字段、標識符。
• 將同意上下文分配給後端查詢（JWT標題或單個標題）。

• 事件變形金剛通過同意標誌刪除/掩蓋字段。
• Dataset標記：'dataset。consent_scope=analytics:granted;ads:denied`.
• 在ML管道中，沒有適當的同意就排除了記錄；禁用用於禁止目的的培訓/激活。

7）偽代碼： 網關上的解決方案

python def enforce_consent(request, consent_snapshot):
purpose = map_endpoint_to_purpose(request. path) # /ads/ -> "ads"
basis  = consent_snapshot. legal_basis. get(purpose)
status = consent_snapshot. purposes. get(purpose, {}). get("status", "denied")

if basis! = "consent": # e.g. security/contract - allowed without return ALLOW banner

if status!= "granted":
return DENY # or ALLOW with redaction if degradation is allowed

return ALLOW

8）驗證和可證明性

同意文本版本：存儲「policy_version」、「text_hash」、「banner_id」。
本地和區域：顯示的確切文本和語言。

處理時的快照： 回答的機會"為什麼廣告在09：03播出2025-10-15？».

不變日誌：WORM/append-only with密碼事件子項。

9）特殊案例

未成年人：年齡驗證，父母同意，單獨目標和時間表。
來賓→登錄：匿名標記與帳戶的合並；沖突中的規則（最嚴格的勝利）。
多重結構：一致性再平衡；當召回時-在所有設備上推入致殘令牌。
區域模式：「嚴格」（EU）vs 「opt-out」（某些市場）-切換CMP預設。
A/B測試：數據實驗-實驗的獨立目標；沒有它-只有功能測試沒有個人數據。
刪除權：召回可以觸發按目的刪除/匿名歷史數據（「purge on revoke」策略）。

10）反模式

一個「共享」的支票盒。
缺乏文本版本和顯示的可證明性。
僅存儲沒有服務器註冊表的Cookie標誌。
僅在UI中但在ETL/ML/出口中不適用同意。
沖突真相來源（SDK ≠後端）。
黑暗模式，強加同意：法律和聲譽風險。

11）可觀察性和指標

覆蓋：具有有效同意標記的流量份額。
Latency PDP：周邊決策時間。
漂移：SDK和服務器快照之間的不匹配。
Revoke SLA：召回時間→完全停用/清理的時間。
Vendor Compliance：使用正確信號的合作夥伴呼叫百分比。
事件：未經同意的處理嘗試,阻止呼叫。

Dashbords：「同意漏鬥」，區域/通道地圖，熱故障圖。

12）測試和驗證

PDP/PEP合同測試：目標/區域組合的真實性表。
混亂/漂移測試：非同步SDK狀態↔服務器；TTL緩存到期。
CMP發行版：A/B驗證文本和UX中性（無深色模式）。
E2E跟蹤：用戶反向事件→沒有發送到夥伴像素和管道。

13）相互關聯的能力

匿名/別名化：在非個人化之前和之後執行故障。
加密和KMS：標記/日誌保護。
Geo路由：選擇區域文本/規則。
可觀察性：沒有PDn的私人行星；僅與令牌相關。
Data Lineage：在每個dataset中都是同意的印記。

14）迷你食譜

yaml purposes:
analytics:
legal_basis: consent enforcement: redact_fields: [ad_id, gaid, idfa]
personalization:
legal_basis: consent enforcement: deny_endpoints: [/recs/, /profile/enrich]
security:
legal_basis: legitimate_interest enforcement: allow email_marketing:
legal_basis: consent channel: email

event. meta. consent. analytics = granted    denied event. meta. consent. ads    = denied event. meta. legal_basis    = consent    contract    li

on user_revoke(purpose):
mark subject_id + purpose as "purge_pending"
schedule purge jobs over datasets with lineage(purpose)
emit audit_event("purge_started", scope=purpose)

15）建築師支票清單

1.是否有一個單一的註冊表和不變的同意日誌？
2.到處都有原子靶和旋轉靶嗎？
3.執行是在外圍，在線程，在分析和ML？

4.是否實施了歷史數據的召回和清除政策?

5.UI/SDK/服務器快照和松弛機制是否一致?

6.是否配置了Coverage/Drift/Revoke SLA和報告指標?

7.有關於事件（違規行為，投訴，監管機構）的運行簿嗎？
8.支持特殊制度（兒童、地區、B2B合作夥伴）？

二.結論

同意管理不是模態窗口，而是端到端架構功能：從目標聲明和文本驗證到實時機器執行和後續報告。嚴格的數據模型、統一註冊表、PDP/PEP、完整的遙測和清潔程序將合規性轉化為競爭優勢--一個值得信賴的平臺。