FullStory 数字体验与会话回放Cookie同意集成指南：2026年操作手册
FullStory 在数字体验分析领域占据主导地位，原因只有一个：它默认采集一切。传统分析工具只记录开发者埋点的离散事件，产品分析平台记录交互行为及自动采集的补充数据，而 FullStory 采集完整渲染的 DOM、光标轨迹、按键时序、滚动行为、愤怒点击、无效点击、网络请求和 JavaScript 错误，将其合成为分析师可逐帧查看的会话录像。这种覆盖能力就是产品本身。这也是 FullStory 处于每个现代隐私制度中最严格同意规则交汇点的原因。EDPB 2023年会话回放指引和2026年工作组优先事项将会话回放视为独立的、更严格的同意类别。CNIL是该议题上公开表态最多的监管机构，但并非唯一——Garante、ICO、西班牙AEPD和荷兰AP均发布了立场一致的意见。经过正确配置、具备恰当遮蔽、正确门控和完整审计轨迹的 FullStory 部署，是发布者可以运营的最有力工具之一；未作适当配置的部署则是监管机构最容易发现的合规目标。
FullStory 为何属于最严格的同意类别
默认的 FullStory 初始化所做的事情比任何会话回放工具都多。它在 fs_uid 和 fs_lua 命名空间下设置含持久访客标识符和最近活跃时间戳的第一方Cookie，在 fs_session 下生成会话标识符，并在页面加载后数毫秒内开始将渲染的 DOM 流式传输至 rs.fullstory.com。数据流包含每个输入事件、每次鼠标移动、每个滚动位置、每次页面跳转，以及在网络采集模块启用时页面发出的每个 XHR 和 fetch 响应（含响应体，除非运营者配置了抑制）。
上述每项采集各自触发独立的同意门控。保存访客标识符属于 ePrivacy 指令 Article 5(3) 下的存储和访问操作，在整个 EEA、英国及任何采纳同等标准的司法管辖区均须事先获得自由、具体、知情且明确的同意。记录渲染的 DOM 是 GDPR 下的个人数据处理，因为视觉记录足以识别用户身份并揭示其实质性内容。采集按键流有特殊的敏感性：用户在表单字段中输入的任何内容都会逐帧被采集，若字段未遮蔽，录像将包含所键入的内容。EDPB 明确指出，会话回放采集属于需要独立于通用分析同意的明确、细粒度同意的类别。
FullStory 在同意前写入什么——以及必须抑制什么
标准 FullStory 快速启动将跟踪代码直接安装在页面 <head> 中。这在技术上可行，也是最常见合规失败的根源：代码在Cookie横幅渲染前运行，fs_uid 和 fs_session Cookie在数毫秒内写入，会话回放流随即流向 rs.fullstory.com，无论用户后续如何选择。每位就此模式作出裁决的欧洲监管机构结论相同：同意前设置的 Cookie 违法，同意前采集的录像属违法处理，发布者承担相应责任。
合规集成必须阻止 FullStory 代码在相关同意类别获批前初始化。在生产环境中有效的模式是将 FS.consent() API 与延迟录制相结合：代码以 FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) 加载并立即调用 FS.shutdown()，此后仅在 CMP 发出会话回放类别已获批的信号后才调用 FS.restart() 和 FS.consent(true)。
FullStory 写入的 Cookie 和存储
FullStory 代码初始化时写入以下标识符，均属非必要且需要同意：含持久访客标识符、多年有效期的 fs_uid；含最近用户活跃时间戳的 fs_lua；含会话标识符的 fs_session；以及 FullStory 内部使用的录制状态标记。撤销同意必须同时使上述 Cookie 过期，并调用 FS.consent(false) 和 FS.shutdown() 停止进一步采集，发布者还须通过 FullStory 隐私端点发送针对用户此前录像的删除请求。
将 FullStory 映射至同意框架
FullStory 不原生实现 IAB TCF 或 IAB Global Privacy Platform——它是第一方数字体验平台，而非广告技术供应商。它提供原生同意 API，并支持不论同意状态如何均生效的默认私密遮蔽模型。能通过监管审查的模式将每个 FullStory 模块视为绑定至特定 CMP 信号的独立门控。
- 会话回放和完整 DOM 流绑定至独立于通用分析的专属会话回放或研究类别。EDPB 指引在此点明确：回放同意必须独立且细粒度，不得与分析或营销捆绑。
- 网络采集置于同一类别内更严格的子门控之后，因为它采集的 HTTP 响应体可能包含与可见界面无关的个人数据。
- 通过 FS.identify() 实现的身份拼接在用户匿名时可基于合法权益使用临时会话标识符运行，但跨会话将身份绑定至持久第一方标识符须获得与会话回放相同的同意。
- 热图和转化分析衍生自会话回放流，继承上游流的门控——它们不是独立的同意界面，而是同一采集数据的下游产物。
有效的集成模式
参考部署有四个组成部分：暴露实时同意变更事件的 CMP；通过 FS.shutdown() 以采集抑制状态初始化 FullStory 的延迟引导程序；在会话回放门控开启时调用 FS.consent(true) 和 FS.restart() 的同意监听器；以及在未明确选择加入时对所有输入字段强制抑制的默认私密遮蔽配置。
默认私密遮蔽
FullStory 遮蔽层独立于同意运作，即便已获同意也应积极配置。任何元素上的 fs-mask CSS 类将该元素内容从录制中抑制；fs-exclude CSS 类将元素完全从 DOM 流中排除；fs-block 类同时屏蔽内容和结构。根据 GDPR 特殊类别规则和 CCPA 敏感个人信息定义，任何可能采集健康信息、金融细节、政府标识符、生物特征数据、精确地理位置或私人通讯内容的字段，无论用户同意状态如何，均须使用遮蔽属性。推荐做法是在表单级别而非字段级别应用 fs-mask。
地区选择与数据存储位置
FullStory 为美国和欧盟分别运营独立的数据摄入端点。对于 EEA 和英国流量，欧盟端点是正确的默认选择——它将摄入、处理和存储保持在 EEA 内部，并降低任何美国地区会话回放部署所带来的 Schrems II 风险。端点按 FullStory 组织配置且无法追溯变更，因此地区选择必须在扩展之前完成，并记录在隐私声明中，以确保从采集到存储的合法性链条清晰。
验证集成与审计轨迹
验证步骤是监管机构会检查、而发布者最常在会话回放工具上跳过的环节。正确集成的 FullStory 部署必须依次通过四项测试。其一，展示横幅但未作任何选择的全新浏览器会话，除 SDK 文件获取外，应对 rs.fullstory.com 产生零请求，document.cookie 中亦应有零个 fs_ Cookie。其二，拒绝会话回放同意须保持该状态——无采集、无标识符、无录像。其三，接受会话回放同意须产生预期的 fs_uid Cookie、单次 FS.consent(true) 事件，以及流向配置地区端点的 DOM 流，并确认遮蔽字段仅采集遮蔽占位符。其四，撤销同意须立即停止进一步采集，使 fs_ Cookie 过期，并通过 FullStory 隐私端点触发针对用户此前录像的删除请求。
审计轨迹预期是会话回放工具面临最严格审查之处。EDPB 2023年Cookie横幅指引和2026年工作组更新优先事项明确指出，发布者必须能够针对 FullStory 项目中任意特定会话录像证明：生成该录像的用户在采集时已给予有效的会话回放同意。标准做法是通过 FS.setUserVars({ consent_version: 'v3', consent_ts: ts }) 在 FullStory 标识符上设置同意版本和时间戳作为用户变量，使任意单条录像均可追溯至特定同意日志条目。正确门控的部署，配合默认私密的遮蔽属性以及在撤销时触发的删除路径，是将 FullStory 的覆盖能力从监管集中风险转变为发布者数字体验技术栈可防御组成部分的关键所在。