会话回放与GDPR：配置Hotjar、Clarity和FullStory

2026年11月5日，法国CNIL发布了其关于会话回放（session replay）和热力图工具的最终建议，该建议已于10月8日由CNIL全体会议通过。如果您的网站使用Hotjar、Microsoft Clarity、FullStory，或任何记录访客页面浏览行为的工具，这份建议回答了CRO和数据分析团队多年来一直争论的一个问题：观察访客如何使用您的网站，是否需要与追踪Cookie相同的同意？CNIL的答案是肯定的，没有例外，并且对您录制什么内容以及保留多长时间提出了具体要求。

会话回放与GDPR：配置Hotjar、Clarity和FullStory

CNIL建议的内容

会话回放工具会捕捉鼠标移动、点击、滚动和表单输入，然后将其重建为单次访问的类视频回放。热力图则将同样的信号聚合到许多会话中，形成单一视图。两者都需要读取并写入访客设备上的信息，这正是CNIL将其建议依据设定为《法国数据保护法》第82条的原因，该条款是欧盟ePrivacy指令第5.3条的法国国内转化条款，也正是用来规范普通追踪Cookie的同一条款。

第82条仅在追踪器对提供访客所请求的服务严格必要，或其唯一目的是传输电子通信时，才豁免同意要求。CNIL的建议将这一测试标准直接适用于会话回放：网站方完全可以在没有该工具的情况下运营网站，而且它与传输消息毫无关系，因此两项豁免均不适用。在工具开始捕捉数据之前，必须取得事先同意，这与在分析或广告Cookie触发前需要取得同意的要求完全相同。

由于重建后的会话也会直接或间接识别出个人身份，GDPR在同意要求之外同样适用，尤其是第6条规定的合法依据，适用于录制完成后的任何后续处理。

CNIL也对可接受的用途划定了界限。它列出了三项：检测并修复技术错误、识别用户体验中的摩擦点以改进体验，以及处理具体的客户支持请求。它指出会话回放不应用于广告再营销（retargeting），理由是存在侵入性更小的替代方案，例如购物车提醒Cookie，并且这种做法不符合数据最小化原则。

为什么「这只是分析工具」站不住脚

许多团队的本能反应是把会话回放的同意并入现有的分析类别开关中。CNIL的建议从两个方面否定了这种做法。首先，上述三项用途中的每一项，都需要在同意界面中拥有各自独立的简短标签和说明，而不是合并成一个笼统的「分析」勾选项。其次，这是本月发布的最终文本中的新内容：CNIL现在还建议在横幅的第一层展示一段简短、措辞清晰的说明，与这些用途标签分开呈现，明确指出正在使用的技术就是会话回放。其理由是，访客对会话回放的认知普遍很低：大多数在Cookie横幅上点击「接受」的人，完全不知道之后会有工具重建他们的鼠标移动轨迹和键盘输入。

这与CNIL在处理其他具体追踪技术时的做法一致，例如邮件追踪像素，CNIL同样将按用途单独取得同意设为标准，而不是接受一个合并的勾选项。关于这一原则如何在CMP中落地，请参见标准隐私框架之外的自定义用途（Custom Purposes）一文，其中已将session_recording列为IAB TCF范围之外的用途示例。

这也意味着需要重新审视在此建议发布之前就已搭建的配置。如果您网站上的Hotjar、Clarity或FullStory目前与Google Analytics等工具一同归入笼统的「性能/分析」类别，这在CNIL最终文本发布之前是合理的做法，但现在不再是了。请将会话回放重新标记为独立的用途，而不是继续让它混在其他类别中。

取得同意之后会发生什么变化

同意只是入场券：CNIL的建议大部分篇幅都在讲述取得同意之后要做什么，其内容围绕GDPR三项我们熟悉的原则展开。

在数据最小化方面，CNIL希望网站方首先限制所采集的会话范围，而不是默认录制每一次访问，具体方式包括随机抽样、仅在出现错误等预设触发事件时才录制，或者在确认某次会话并非必要后迅速删除。遮蔽（masking）与此相辅相成：表单字段、账户信息、文本输入和图片应默认被遮蔽，而最终文本新增了两类今年早些时候发布的草案中并不包含的内容：屏幕数字键盘上的鼠标移动和点击（可能泄露登录验证码），以及聊天机器人的对话内容，因为问答交流本身就可能泄露敏感数据。会话和用户标识符也应默认避免将某位访客的活动无限期地关联起来。

在存储限制方面，CNIL自己的附录表格给出了「不超过必要期限」按用途划分的具体参考：支持类场景为会话结束后的几个小时，而错误检测和用户体验改进类场景则为几个月。网站方需要具备按单个访客逐一删除会话记录的能力，而不能仅依赖一个笼统的保留期限，这既是为了响应GDPR下的访问或删除请求，也是因为撤回同意后，除非有其他法律依据支持保留，否则必须删除已经采集的数据。

在安全性方面，密码和支付信息无论是否被遮蔽都不应进入录制内容，而对已录制内容的访问应通过定期审查的权限控制来进行，这与CNIL对任何处理个人数据的内部系统所期望的基线要求一致。

配置Hotjar、Clarity和FullStory

这三款工具处理同意的方式各不相同，但目标对三者而言是一致的：在访客同意之前，任何内容都不应被捕捉；一旦访客撤回同意，捕捉也应随之停止。

Microsoft Clarity

Clarity是三者中最简单的一个，因为它内置了双向的同意信号，UniConsent会自动与其对接。在Clarity项目设置中关闭「默认设置Cookie」选项，UniConsent便会根据您为会话回放指定的用途或类别，告知Clarity启动或停止。完整配置步骤见Microsoft Clarity同意模式教程。Clarity还自带遮蔽选项，可以将账户信息等字段从录制内容中隐藏。

Hotjar

Hotjar无法自行识别CMP信号，因此需要使用UniConsent的自定义用途（Custom Purposes）功能来显式启动它：创建一个专门用于会话回放的用途，撰写CNIL所要求的第一层说明文字，并将该用途与Hotjar关联，使其在访客同意后开始录制。Hotjar同样支持默认遮蔽特定的表单字段和账户信息，而无需逐一屏蔽每个敏感字段。

FullStory

FullStory的工作方式与Hotjar相同：默认处于关闭状态，一个专门用于会话回放的用途会在同意被授予后告知它开始捕捉。FullStory自带的遮蔽控件可以让您在录制页面的同时排除特定字段，使其永远不会传送到其服务器。

将自定义用途接入第三方脚本的具体配置步骤，详见自定义用途教程和UnicScript教程。

设置保留期限与删除机制

按请求删除单个访客的会话，需要通过各供应商自身的删除工具、API或支持渠道来完成，您与供应商签订的数据处理协议应明确说明处理速度。UniConsent能够直接提供的，是CNIL建议所默认应当存在的证据链：会话回放用途的每一次授予和撤回都会带时间戳记录在Consent DB中，因此当访客询问自己当初同意了什么、何时同意时，您拥有的答案不依赖于会话回放供应商自身的记录。

这对营销和CRO团队意味着什么

这一切都不意味着要放弃会话回放。CNIL明确接受将其用于技术调试、用户体验改进和客户支持，这几乎覆盖了CRO团队实际使用它的绝大多数场景。真正发生变化的是：录制不能再是每次访问的默认状态，将行为画像挪用于再营销的做法不再可行，而同意环节必须在捕捉第一帧画面之前完成，而不能从Cookie横幅上一个笼统的「接受」操作中被默认推定出来。

已经采用分层、按用途划分的同意横幅的团队，走的是更轻松的一条路：新增一个独立的会话回放用途，将三款工具与之关联，开启默认遮蔽设置，建议中的大部分要求便已满足。而依赖单一「全部接受」按钮的团队则面临更多工作，首先要做的就是把会话回放从它目前隐藏其中的用途里分离出来。

UniConsent如何提供支持

UniConsent既支持将会话回放设为独立的自定义用途，也支持将其映射到某个同意类别，支持您在第一层自行撰写会话回放说明，并提供向Microsoft Clarity原生同意API的自动信号转发，以及针对Hotjar和FullStory的自定义用途控制，确保录制只有在访客真正同意后才会开始，并在访客撤回同意时随之停止。

立即注册，几分钟内即可为您的同意横幅添加会话回放用途。