为何 PostHog 需要同意——以及不同模块的答案各不相同

PostHog 的 Web SDK 并非被动的页面标签。默认初始化时，SDK 会设置一个或多个第一方持久化条目——默认以 ph_{projectKey}_posthog 为键，采用 Cookie 加 localStorage 的组合方案——生成稳定的唯一标识符，捕获包含来源、UTM 参数和点击标识符的初始页面浏览事件，并向配置的采集主机打开长连接事件通道。若在项目级别启用了会话回放，SDK 还会开始流式传输渲染后的 DOM、鼠标坐标及输入事件的连续记录。若配置了功能标志，SDK 会针对唯一标识符进行评估，将决策持久化至当前会话，并为每次评估发送 $feature_flag_called 事件。

每项活动对应不同的同意门槛。根据 ePrivacy 指令第 Article 5(3) 条，持久化唯一标识符属于存储与访问操作，在 EEA、UK 及采用相同标准的司法管辖区需要事先、自由给予、具体、知情且明确的同意。根据 GDPR，捕获行为事件属于个人数据处理，因为标识符、IP 地址与行为轨迹的组合足以识别个人。会话回放在 EDPB 会话回放指引下属于更严格的独立类别——回放捕获渲染后的 DOM 及任何未遮蔽的输入字段，需要与通用分析同意有所区别的明确、细粒度同意。功能标志评估较为微妙：返回布尔值的标志检查本身不需要同意，但将用户的标志分配持久化至跨会话的稳定标识符则需要，因为这正是基于标志的实验创建可追溯用户级数据的方式。

PostHog 在同意前写入的内容——以及必须抑制的内容

默认 PostHog 浏览器 SDK 在初始化时写入以下内容：一个以 ph_{projectKey}_posthog 为键的 Cookie 和 localStorage 组合条目，包含唯一标识符、会话标识符和功能标志决策；若启用会话回放，还有一个每隔几秒向采集端点刷新的内存录制缓冲区。SDK 还会立即发送 $pageview 事件，若开启自动捕获，则捕获页面上所有后续点击、表单交互和连点行为。

推荐模式是使用 opt_out_capturing_by_default: true 和 disable_session_recording: true 初始化 PostHog，然后在同意横幅返回肯定信号后切换这两个标志。这是 PostHog 文档目前推荐的集成姿态，也是能经受监管审查的姿态，因为它颠覆了默认行为：在记录同意之前不捕获任何内容，SDK 提供的是干净的过渡而非有状态的补救。

PostHog 持久化的 Cookie、localStorage 条目和标识符

浏览器 SDK 1.x 默认以 ph_{projectKey}_posthog 为键、365 天有效期写入每个项目的持久化条目。persistence 初始化选项控制底层机制：仅 cookie、仅 localStorage、localStorage+cookie（默认）、sessionStorage 或 memory。对于同意优先的部署，在尚未授予同意时，memory 持久化是正确默认值——确保标识符不会超过页面会话的生命周期——在同意切换后转为 localStorage+cookie。SDK 还以 __ph_opt_in_out_{projectKey} 为键写入选择加入或退出的标记，以在访问间记住用户的选择；该标记本身是严格必要的 Cookie，因为它持久化了同意决策。

将 PostHog 模块映射到同意框架

PostHog 并不原生实现 IAB TCF 或 IAB 全球隐私平台，也不是作为广告技术供应商构建的。但它通过发布者侧桥接与 Google Consent Mode v2 集成，提供原生选择加入和退出 API，并通过 respect_dnt 初始化选项遵循"请勿追踪"头。在生产环境中行之有效的模式是将每个 PostHog 模块视为绑定到特定 CMP 信号的独立门。

• 产品分析事件绑定到分析目的。在 TCF 术语中，这通常是目的 8（衡量内容效果）结合目的 1（存储和/或访问信息）。对于 Consent Mode，映射到 analytics_storage。
• 会话回放设有更严格的门槛。PostHog 的会话回放捕获渲染后的 DOM 及任何未遮蔽的输入字段，因此在 EDPB 指引下，区别于分析的偏好级或研究级选择加入是可辩护的定位。
• 功能标志和实验测试在目标仅为变换渲染页面时，可基于合法利益以临时内存评估方式运行。将标志分配持久化至跨会话的稳定标识符则需要与分析相同的同意，因为此时标志成为可追溯的用户级数据点。
• 问卷和反馈在收集自由文本输入时绑定到与会话回放相同的门槛，仅收集评分或单选响应时绑定到分析门槛。

行之有效的集成模式

参考部署包含四个部分：一个暴露实时同意变更事件的 CMP、一个以禁用捕获和回放初始化 PostHog 的延迟引导、一个在相关门开启时切换 opt_in_capturing 和录制开关的同意监听器，以及一个调用 opt_out_capturing、停止回放缓冲并通过 SDK 重置 API 清除持久化标识符的撤回路径。

Web 实现

最简洁的模式是在每个页面加载 PostHog SDK，但将 posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) 作为初始引导调用。订阅 CMP 的同意变更事件。当分析类别切换为 true 时，调用 posthog.set_config({ persistence: 'localStorage+cookie' })，随后调用 posthog.opt_in_capturing()；这将重新启用事件捕获，持久化过渡开始写入唯一标识符。当会话回放类别切换为 true 时，调用 posthog.startSessionRecording()。当任一门关闭时，对分析门调用 posthog.opt_out_capturing()，对回放门调用 posthog.stopSessionRecording()，通过 posthog.reset() 使持久化标识符过期，若用户行使了删除权，则通过 PostHog 的 GDPR API 发送删除请求。

区域选择：PostHog Cloud 美国 vs 欧盟 vs 自托管

PostHog 运营两个云区域——美国（us.posthog.com）和欧盟（eu.posthog.com）——并支持在客户自有基础设施上自托管。对于 EEA 和 UK 流量，欧盟云是正确的默认选择；它将采集、处理和存储保留在 EEA 内，降低了任何美国区域分析部署所带来的 Schrems II 风险。api_host 初始化选项固定区域。自托管 PostHog 将整个技术栈迁移至发布者自有基础设施，这是最强的数据驻留姿态，但不会消除同意义务——法律依据跟随数据而非运营商。无论选择哪种方案，都必须在隐私声明和控制者的处理记录中加以体现。

服务端捕获

PostHog 通过 Python、Node、Go、Ruby 和 PHP SDK 支持服务端事件采集。服务端事件并不豁免于同意——法律依据跟随数据——但服务端采集赋予发布者对发送字段和发送时机的完全控制。常见模式是在合法利益依据下通过服务端仅捕获最小必要事件集，然后仅在用户授予分析同意后，用客户端的行为详情丰富这些事件。在同意切换后，服务端和客户端事件基于同一唯一标识符关联；在同意之前，服务端事件使用每个会话重置的匿名临时标识符发送。

验证集成与审计轨迹

验证步骤是监管机构审查的内容，也是发布者最常跳过的环节。正确集成的 PostHog 部署必须按顺序通过四项测试。第一，显示横幅但尚未做出选择的全新浏览器会话，除 SDK 文件获取外，对配置的 api_host 的请求数为零，document.cookie 中的 ph_ Cookie 数为零，localStorage 中的 ph_ 条目数为零。第二，拒绝分析必须保持该状态——无捕获、无录制、无持久化标识符。第三，接受分析必须立即产生 $opt_in 事件、具有正确 SameSite 属性的预期 ph_{projectKey}_posthog 持久化条目，以及流向配置主机的事件流量。第四，事后撤回同意必须立即停止进一步捕获和回放、使持久化标识符过期，并在用户行使删除权时通过 PostHog 的 GDPR API 触发删除请求。

根据 EDPB 2023 年 Cookie 横幅指南和 2026 年更新的任务组优先事项，审计轨迹的期望是：发布者能够证明，PostHog 项目中任何给定事件的生成用户在捕获时已给予有效同意。标准模式是通过 posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) 将同意版本和时间戳设置为唯一 ID 的人员属性，使任何单个事件都可追溯至特定同意日志条目。正确门控的部署，结合与受众匹配的区域选择、默认内存持久化以及撤回时激活的删除路径，才能将 PostHog 从监管集中风险转变为产品分析栈中可辩护的核心。