2026年Microsoft Clarity会话录制Cookie同意集成指南
Microsoft Clarity 于2020年推出，是一款免费、无配额的会话录制、热力图及交互分析工具，可替代 Hotjar 和 Smartlook。五年来，它已被全球大量中小型企业网站广泛采用，一方面得益于其确实实用的功能，另一方面则在于安装只需一行 JavaScript，大多数运营者未加思索便直接粘贴部署。从隐私角度来看，这种便利恰恰是问题的根源。Clarity 记录鼠标移动、滚动行为、点击操作、按键输入、表单交互以及完整的页面 DOM 快照——在所有常见分析工具中，其行为数据捕获密度最高——脚本一旦加载便立即将全部数据上传至 Microsoft 的服务器。对于涉及欧盟、英国、EEA、巴西或加州流量的部署，默认安装方式不符合合规要求。在会话录制执法领域最为活跃的监管机构——CNIL、意大利 Garante 以及英国 ICO——均已明确表示，相关规定适用于所有定价层级和供应商的工具。本指南将逐一介绍 Clarity 的录制内容、同意边界的运作机制，以及能够通过审计的集成架构。
Clarity 实际录制的内容
Clarity SDK（从 www.clarity.ms/tag/{project_id} 加载）初始化后会创建一个全局 clarity 对象，并通过 Microsoft 专属 Cookie _clck 识别访客，同时设置会话 Cookie _clsk。自此，脚本开始采集密集的行为数据流：
- 鼠标与触控输入——每次移动、点击、轻触、滚动及手势操作均以时间戳和坐标形式完整记录。
- 表单交互——每个表单字段的焦点、失焦及输入事件，以及在未配置掩码的情况下非敏感字段所输入的文本。
- DOM 快照——定期对页面 DOM 进行完整快照，使会话回放能在任意时刻精确还原页面的视觉状态。
- 自定义事件——应用程序通过 clarity("event", "name") 调用显式发送的任意事件。
- 性能与错误数据——JavaScript 错误、网络故障及核心网页指标时序。
- 标识符数据——Clarity 专属 Cookie，以及基于 IP 的地理位置信息和用户代理指纹。
上述数据的组合——尤其是 DOM 快照与表单字段捕获——使 Clarity 在功能上等同于对访客会话进行视频录制。依据 GDPR 的合规分类，这属于个人数据处理：相关 Cookie 为非必要 Cookie，数据需跨境传输至 Microsoft 的美国基础设施，所需的合法依据为同意。CNIL 于2024年发布的会话录制指南在这一点上措辞明确，并点名了 Clarity 所属工具类别。
敏感数据风险
会话录制工具存在其他分析工具所没有的特定隐私风险：可能意外捕获敏感个人数据。若字段未经显式掩码处理，用户在任意表单字段中输入的信用卡号、健康状况、宗教信仰或国家标识符都会被 Clarity 记录。根据 GDPR，这属于 Article 9 敏感个人数据的处理，需要明确的选择性同意，通常无法由通用的营销同意决策所涵盖。
Clarity 支持内容掩码配置，可将特定字段从录制中排除，但默认行为会捕获所有内容。经得起审计的做法是积极使用掩码——在未经证明之前，将每个表单字段均视为敏感字段——并明确记录相关掩码决策。
Clarity 原生隐私控制
过去两年，Microsoft 持续投入改进 Clarity 的隐私控制功能。该平台现已提供若干基础原语，可供 CMP 集成使用。
掩码属性
向 DOM 元素添加 data-clarity-mask="true"，可将其内容从会话录制中隐藏。向子元素添加 data-clarity-unmask="true"，可覆盖该子树的掩码设置。对于任何可能包含个人数据的表单字段，正确的默认策略是启用掩码，并对已知安全的元素（页面标题、导航标签、公开内容块）显式例外取消掩码。
同意 API
Clarity 提供 clarity("consent") 调用，调用后表示已授予同意，SDK 可继续运行。若不调用此接口，SDK 可被配置为在初始加载后停止运行。这是 CMP 在激活侧进行集成的正确原语。
IP 掩码与标识符处理
Clarity 项目设置中提供了 IP 截断和标识符掩码选项。启用这些选项是在 CMP 门控基础上的纵深防御手段，不能替代同意机制本身。
敏感内容自动掩码
最新版本的 Clarity 尝试自动检测敏感字段（信用卡格式、密码字段、命名为"ssn"或类似名称的字段）并默认进行掩码。该检测机制基于启发式算法，存在遗漏；请勿将其作为唯一的防线。
逐步 CMP 集成
可靠的架构是将 Clarity SDK 完全推迟到同意获得授予之后再加载，然后通过同意 API 显式激活。
1. 从文档头部移除默认标签
Clarity 安装代码片段是一段单行内联脚本，会在页面加载时初始化 SDK。将其替换为占位符脚本元素，将 type 设置为 text/plain，根据 CMP 对会话录制工具的分类，将 data-category 设置为 analytics 或 marketing。
2. 确定类别映射
会话录制属于存在争议的类别。CNIL 曾将其视为分析类（当数据用于内部用户体验研究时）和营销类（当数据用于个性化决策或对外共享时）。保守的做法是归入营销类；经得起审计的立场要求明确说明录制数据的实际使用方式。
3. 在激活前配置积极掩码
向所有表单元素、所有输入字段以及所有可能存储个人数据的容器添加 data-clarity-mask="true"。默认策略为全量掩码，仅对已知安全的元素（页面标题、导航标签、公开内容块）显式设置例外取消掩码。
4. 从同意回调中激活 Clarity
当 CMP 触发相关类别接受事件时，重写占位符脚本标签，并调用 clarity("consent") 授予 SDK 运行权限。在同意授予前缓冲的排队事件随后将被刷新。
5. 明确处理撤回操作
若用户撤回同意，Clarity SDK 没有与激活 API 等效的"停止录制"调用。实际处理模式是：在 SDK 版本支持的情况下调用 clarity("consent", false)，同时在客户端清除 Clarity Cookie。如需完全删除历史录制，请使用 Clarity 管理界面的数据删除工作流或删除 API。
常见陷阱
四类集成错误占 Clarity 部署审计发现问题的大多数。
以"只是看看访客行为"为由安装 Clarity
最常见的情形：产品经理安装 Clarity 以研究用户体验问题，从未启用同意门控，从未配置掩码，随后便遗忘了这段脚本。录制数据持续累积。解决方案是彻底移除 Clarity，或将其纳入与其他追踪工具相同的同意架构中。
信任自动掩码
Clarity 的启发式敏感字段检测能捕获明显情况，但会遗漏特定领域的情况——例如医疗网站的"症状"文本框、金融网站中名称不规范的"账户号码"字段。应进行显式掩码，而不是依赖自动检测。
将会话录制归类为分析类
CNIL 已明确指出，从同意角度来看，会话录制类别更接近于营销类，而非第一方分析类。仅在分析类同意下对 Clarity 设置门控，只有在录制数据仅用于内部用户体验研究且从不在组织外部共享的情况下才具有可辩护性。
忽视自定义事件载荷
调用 clarity("event", "name", customProperties) 的应用程序代码可能通过 customProperties 载荷将个人数据泄露至 Clarity 数据流。请审计每个调用点，避免在事件属性中传递用户标识符、电子邮件地址或任何个人数据。
审计检查清单
针对涉及欧盟、英国、巴西或加州流量的 Clarity 部署，需回答以下六个具体问题。
- Clarity 是否等待同意？ 在隐私窗口中打开页面，确认在接受横幅之前没有 clarity.ms 请求触发。
- 掩码是否足够积极？ 确认每个表单字段及所有可能包含个人数据的容器均已应用 data-clarity-mask。
- 类别映射是否有文档记录？ 确认有书面记录说明 Clarity 在分析类还是营销类同意下进行门控，以及相应的理由。
- 同意 API 是否已接入？ 确认 CMP 回调在授予时调用 clarity("consent")，在撤回时调用等效接口。
- 自定义事件是否经过审计？ 确认 clarity("event", ...) 调用未在事件属性载荷中传递识别性或敏感数据。
- 删除是否已自动化？ 确认 DSAR 请求会触发 Clarity 的删除工作流，而非依赖人工支持工单。
Clarity 在以同意为核心的技术栈中的定位
会话录制是常见部署中信息密度最高的行为追踪方式，而 Clarity 是将其普及化推进最为积极的工具。免费的定价层级和无摩擦的安装方式，使其成为任何希望洞察用户体验行为的团队的最小阻力选择。然而，正是这种无摩擦的安装方式，导致 Clarity 成为2026年审计中配置最不规范的分析工具。正确的架构是将 Clarity 与其他识别性追踪工具一视同仁：在明确同意的前提下启用，默认对表单字段进行积极掩码，记录类别映射，并接入同意 API，使 SDK 自身的原语来执行 CMP 所记录的内容。正确实施后，工具所带来的用户体验研究价值得以保留，同时监管风险也降至默认安装情形下的极小部分。