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和广告真实性
• 奖励条款的透明度
• 跨辖区数据本地化
• 编译和监视/内部和外部审计