谁拥有同意？面向发布商团队的简明归属模型
问题：人人触碰同意，却无人负责
在典型的广告支持型发布商那里问“谁负责同意”，你会听到好几种答案。法务写了cookie政策。广告运营添加了供应商。工程部署了横幅。产品上个季度改了设计。营销上周新增了一个像素。每一项变更单独看都合理，但没有人负责它们如何协同——这就是网站最终出现同意之前就触发的标签、横幅中缺失的供应商，或悄悄拉低同意率的改版的原因。
本文提出一个简单的归属模型，让同意相关的决策有明确的负责人、明确的批准人和明确的流程。
为什么归属不仅关乎风险，也关乎收入
同意处于两个方向相反的目标之间。法务和隐私团队关注设置是否尊重用户的选择和适用的规则。广告运营和收入团队关注有多少库存能以完整价值变现。双方关心都是对的。没有明确的负责人，分歧就会由最后改动配置的人来了结，而不是由事后任何人都能解释的决定来了结。
角色
大多数发布商可以把同意工作对应到五个角色，即使一个人身兼数职：
- 隐私或法务 — 解读规则，批准目的、法律依据和横幅措辞，并负责cookie政策。
- 广告运营或收入 — 管理需求合作伙伴和供应商列表，监控与同意相关的收入，并提出会影响变现的变更请求。
- 工程 — 实现CMP，控制标签加载，并确保脚本遵守同意信号。
- 产品与设计 — 在法务设定的范围内负责横幅体验，并开展布局和文案测试。
- 营销与分析 — 提出新标签和衡量工具的请求，并依赖同意信号进行报告。
针对反复出现的决策的RACI
RACI列出谁负责执行（Responsible）（做事）、谁最终负责（Accountable）（做最终决定）、谁被咨询（Consulted）以及谁被知会（Informed）。以下是一个起点：
添加新的供应商或标签
- 执行：广告运营或营销（提出请求的一方）。
- 最终负责：隐私或法务。
- 咨询：工程，关于如何对其进行门控。
- 知会：产品。
更改横幅设计或文案
- 执行：产品与设计。
- 最终负责：隐私或法务。
- 咨询：广告运营，关于预期的收入影响。
- 知会：工程和营销。
更改目的或法律依据
- 执行并最终负责：隐私或法务。
- 咨询：广告运营和工程。
- 知会：所有依赖同意数据的人。
CMP配置与发布
- 执行：工程。
- 最终负责：指定的同意负责人（见下文）。
- 咨询：隐私和广告运营。
- 知会：产品和营销。
监控同意与收入指标
- 执行：广告运营。
- 最终负责：同意负责人。
- 咨询：产品。
- 知会：隐私或法务，尤其是有关异常情况。
指定唯一的同意负责人
当有一个人对整体同意设置负最终责任时，RACI的效果最好。这不一定是资历最高的人；而是让供应商列表、横幅配置、标签清单和cookie政策保持同步，并在有变化时召集相关人员的人。在小团队中，这通常是广告运营或工程部门中与法务有直接联系的人。
让模型运转起来的流程
- 新标签的申请渠道。每一个新的像素、SDK或合作伙伴都通过同一个入口，并填写一份简短表单：它做什么、收集什么数据、需要哪些目的、由谁提出。
- 变更日志。记录对供应商、目的、横幅文本和设计的每一次变更，附上日期和批准人。当某项指标出现变动，或合作伙伴或监管机构来函询问时，这非常宝贵。
- 发布检查。凡涉及标签或横幅的发布，未经在干净浏览器中的同意测试，不得上线。
- 定期审查。每季度一次，负责人对照实际标签审查供应商列表，对照收入审查同意指标，并对照两者审查cookie政策。
- 升级路径。当法务与收入部门意见不一时，决定交由指定人员作出，并将理由写下来。
缺少归属模型的迹象
- 没有人能说出供应商列表上次审查是什么时候。
- 网站上出现了CMP中没有的标签。
- 横幅变更上线后，没有人检查同意率。
- 不同团队对哪些合作伙伴会收到TC string给出不同的答案。
- 合作伙伴关于同意信号的问题需要几天才能回复。
核心要点
- 同意涉及法务、广告运营、工程、产品和营销；它需要一位负最终责任的负责人。
- 简单的RACI能把反复出现的决策变成可预测的流程。
- 让每个新标签都通过单一入口并接受同意审查。
- 保留变更日志，并每季度审查设置。
- 写下收入与隐私之间的分歧如何解决。