Amplitude为何需要同意

默认的Amplitude浏览器SDK和Amplitude移动SDK的功能远不止记录页面浏览量。在初始化时，它们会在第一方存储中设置设备标识符、生成会话标识符、捕获引荐来源、从URL解析UTM和点击标识符，并开始将自动捕获的事件加入队列：页面浏览、元素点击、表单交互、文件下载，以及在最新版本中的会话回放。它们还会用IP派生的地理位置、用户代理派生的设备数据丰富这些事件，如已配置，还会使用数据合作伙伴的第三方数据进行丰富。

上述每个步骤都涉及不同的同意法律依据。存储设备标识符是ePrivacy指令第5(3)条下的存储和访问操作，在欧洲经济区、英国以及任何采用相同标准的司法管辖区，这需要事先、自由给予、具体、知情且明确的同意。捕获与该标识符相关联的行为事件是GDPR下的个人数据处理。使用第三方数据进行丰富引入了第二个控制者关系。CCPA和CPRA将相同的处理定性为出售或共享，除非发布商与Amplitude签订了适当范围的服务提供商合同——该合同是可以获得的，但前提是集成配置为禁用广告功能。

Amplitude在同意前收集的内容——以及您必须抑制的内容

最常见的实现错误是将Amplitude视为可以与cookie横幅同时运行的轻量级分析工具。这是不可能的。在默认的amplitude.init()调用中，SDK将在页面首次渲染时写入至少一个cookie或本地存储条目，发送一个identify调用，并开始缓冲事件。在用户明确接受相关同意类别之前，这些操作均不被允许。

因此，合规集成必须将amplitude.init()延迟至CMP发出分析同意类别已获批准的信号之后。SDK完全不应从依赖CMP目的8（分析）或目的1（存储和访问）信号的同意门控<script>标签中加载。如果SDK必须更早加载——例如因为它被打包到应用程序代码中无法延迟获取——初始化调用应传入defaultTracking: false和optOut: true，以便在记录同意之前不发送任何事件，然后延迟的选择加入事件应翻转这些标志。

Amplitude写入的Cookie和存储

浏览器SDK 2.x默认写入一个名为AMP_{apiKey}的第一方cookie，有效期一年，包含设备标识符和会话元数据。旧版本还写入amplitude_id_{apiKey}。移动SDK将相同标识符保存在应用程序的沙盒存储中。会话回放会添加第二个cookie，即AMP_MKTG_{apiKey}，如果启用了实验定向或受众模块，Amplitude的丰富合作伙伴可能会设置其他第三方cookie。所有这些都是非必要的，需要同意。

将Amplitude映射到同意框架

Amplitude本身并不实现Google同意模式v2、IAB TCF或IAB全球隐私平台。这不是缺陷——Amplitude是第一方分析平台，而非广告技术供应商——但这确实意味着集成责任由发布商承担。在实践中有效的模式是将每个Amplitude模块视为单独的同意门，并将其绑定到CMP已公开的特定信号。

• 核心分析事件绑定到分析目的。在TCF术语中，这通常是目的8（衡量内容效果）与目的1（存储和/或访问信息）的组合。对于Google同意模式，这对应analytics_storage。
• 会话回放应置于更严格的信号之后。回放捕获渲染的DOM，包括表单值（除非明确屏蔽），因此需要单独的preferences或functional选择加入，即使授予了分析权限，回放也应默认关闭。
• 受众、群组和第三方丰富绑定到营销目的。在TCF术语中，这是目的7（衡量广告效果）或目的9（应用市场研究）。对于Google同意模式，这对应ad_storage和ad_user_data。
• 实验——Amplitude Experiment可以在合法利益基础上使用匿名、临时分配运行，但与用户标识符相关联的持久分配需要与核心分析相同的同意。

有效的集成模式

能通过监管机构审查的参考实现有四个关键部分：一个在用户更改同意时公开实时事件的CMP、一个仅在该事件针对相关类别触发后才获取Amplitude的延迟SDK加载器、一个在法律允许的情况下不丢失用户先前匿名设备标识符同时尊重选择退出的会话级守卫，以及一个用于真正需要不论同意状态都收集的事件的服务器端桥接——例如安全遥测或欺诈检测——通过具有自身法律依据的独立端点路由。

Web实现

在Web端，最简洁的模式是通过window.__cmp_consent对象或标准__tcfapi回调公开CMP的同意状态，然后用一个小型引导脚本订阅同意变更。当分析同意从false变为true时，引导程序从CMP管理的CDN获取Amplitude SDK，调用amplitude.init(apiKey, undefined, { defaultTracking: true })，并重放等待同意期间在内存中排队的所有事件。当同意变回false时，引导程序调用amplitude.setOptOut(true)，通过document.cookie过期清除AMP_ cookie，并删除任何内存中的状态。关键是，引导程序绝不能在横幅渲染的同一请求流中延迟初始化Amplitude——SDK必须等待明确的授权。

移动端实现

在iOS上，等效方法是保持Amplitude框架已导入，但将Amplitude.instance().initialize(apiKey: apiKey)推迟到应用内同意流程返回正面分析信号之后。ATT提示是一个独立的问题：ATT管理IDFA，而Amplitude的标识符是SDK自己存储在应用沙盒中的UUID。两者在EEA都需要同意，但法律依据和提示是不同的。在Android上，同样的逻辑适用于Amplitude.getInstance().initializeApolloClient()或根据SDK版本的等效方法。

服务器端模式

Amplitude通过HTTP V2 API支持服务器端摄入。服务器端事件不豁免于同意——法律依据跟随数据，而非传输方式——但服务器端摄入确实给了发布商对发送哪些字段的完全控制，这使得遵守部分同意变得更容易。一种常见模式是在合法利益下服务器端捕获最小的仅必要事件集，并仅在用户在客户端授予分析同意后才用行为细节丰富这些事件。

验证集成

验证步骤是发布商最常跳过而监管机构最常检查的环节。正确集成的Amplitude部署应通过四项检查。第一，显示同意横幅但尚未做出选择的浏览器应对api.amplitude.com或api.eu.amplitude.com产生零请求，document.cookie中零个AMP_ cookie。第二，拒绝分析类别应保持该状态——没有事件、没有cookie、没有带AMP_前缀的本地存储条目。第三，接受分析应产生单个identify后跟事件流量，且AMP_ cookie应出现带有与发布商CMP政策一致的SameSite属性。第四，事后撤回同意应立即停止进一步的事件并清除存储的标识符——延迟清理是一个发现。

审计追踪单独很重要。根据EDPB 2023年cookie横幅指南和2026年更新的专责小组优先事项，监管机构期望发布商能够证明，对于Amplitude项目中的任何给定事件，生成该事件的用户在捕获时已给予有效同意。这要求CMP的同意日志可通过设备标识符或会话标识符查询，且Amplitude事件载荷携带一个同意版本字段，与该日志相关联。在每个事件上将同意字符串存储为自定义用户属性是使该链接可审计的最简单方式。

选择正确的地区和数据存储位置

Amplitude运营两个生产区域：美国（api.amplitude.com）和欧盟（api.eu.amplitude.com）。对于EEA和英国流量，欧盟区域是正确的默认选择——它将数据保留在EEA内，并降低了Schrems II裁决和欧美数据隐私框架（DPF）使之成为任何分析审查核心的传输风险面。切换区域不具有溯及力：现有数据保留在首次摄入的位置。对于计划CMP推出的发布商，因此值得在扩展之前确认区域，并在隐私声明中记录该选择，以便从收集到存储的合法依据链清晰。正确选择的区域，加上正确门控的SDK和可查询的同意日志，将使Amplitude部署从监管风险转变为分析栈中可辩护的组成部分。