Hotjar热图与会话录制Cookie同意集成指南：2026年发布者操作手册
Hotjar在工具栈中占据独特地位。它既不是像Google Analytics那样的网络分析平台，也不是像Amplitude或Mixpanel那样的产品分析平台，更不是标签管理器。它是一款用户体验研究工具，专门用于记录单个用户在页面上的行为——鼠标移动轨迹、点击位置、滚动位置、停顿位置，以及在会话录制情况下用户输入和看到的内容。这种粒度就是产品本身，也正因如此，监管机构将会话重放列为行为处理风险最高的类别之一。CNIL、Garante和EDPB均已发布专门针对会话重放行为的指南，2026年EDPB Cookie横幅工作组将其列为优先类别。好消息是，Hotjar在该类别中是工程设计较好的工具之一，支持以同意为先的部署——前提是发布者实际使用了已有的控制机制。
为何Hotjar需要明确同意
Hotjar的数据采集范围触发了各主要框架的同意义务。在默认初始化时，Hotjar跟踪脚本会在页面加载后数毫秒内向浏览器写入至少三个第一方Cookie——_hjSessionUser_{siteId}、_hjSession_{siteId}以及一系列压制和来源Cookie。随后脚本开始持续流传输光标坐标、点击坐标、滚动位置、视口大小，以及在启用会话录制时完整渲染的DOM差异数据。
根据ePrivacy指令第5(3)条，上述每个Cookie都是需要在EEA、英国、瑞士及采用同等标准的司法管辖区事先获得自由给予、特定、知情且明确同意的存储和访问操作。根据GDPR，行为数据流构成个人数据处理，因为光标轨迹、IP地址、设备指纹和会话标识符的组合足以识别特定个人。根据CCPA和CPRA，相同的数据采集构成销售或共享，除非发布者与Hotjar签订了相关服务提供商合同——Hotjar通过其符合CCPA的DPA提供此服务，但仅在正确配置集成后才生效。根据EDPB会话重放指南，要求更为严格：重放必须与特定的合法用户体验研究目的相关联，保留期必须最短必要，且数据主体不仅须被告知录制存在，还须被告知其本人的会话可能被分析师回放。
Hotjar在同意前收集的数据——以及必须压制的内容
最常见的实施错误正是Hotjar自身快速入门所附带的：将跟踪脚本直接粘贴到页面<head>中。这种方式可行，但会在Cookie横幅渲染之前加载Hotjar，这意味着Cookie已被设置、行为录制已在第一次页面浏览时开始——无论用户之后如何决策。每个就此模式作出裁决的欧盟监管机构都给出了相同的裁决：在同意前设置的Cookie是违法的，发布者须承担责任。
因此，合规集成必须完全阻止Hotjar脚本在相关同意类别获批前加载。最简洁的方式是将Hotjar代码片段包裹在一个同意门控的<script>标签中，仅在用户选择加入分析或产品研究类别后由CMP注入。如果脚本通过标签管理器加载，等效做法是将触发器设置为同意授予事件，而非All Pages。Hotjar自身文档现已明确推荐此模式，并暴露了hj('consent', 'grant') API，适用于脚本必须存在但在记录同意前应保持休眠的情况。
Hotjar写入的Cookie和存储
Hotjar跟踪代码6.x写入以下标识符，均为非必要且需要同意：_hjSessionUser_{siteId}（365天有效期，包含用户标识符）、_hjSession_{siteId}（30分钟有效期，包含会话标识符）、_hjFirstSeen、_hjIncludedInSessionSample_{siteId}、_hjAbsoluteSessionInProgress，以及在调查或反馈组件激活时的若干活动归因Cookie。会话录制本身存储在Hotjar服务器上并与会话标识符关联——撤回同意因此还必须通过Hotjar的API或产品内用户删除流程发送删除请求。
将Hotjar映射到同意框架
Hotjar不原生集成IAB TCF或IAB全球隐私平台。它不是广告技术供应商，也从未被设计为此类用途。但它通过analytics_storage信号与Google同意模式v2集成，并暴露了任何CMP均可绑定的原生同意API。能够通过监管审查的模式将每项Hotjar功能视为独立的同意门。
- 热图和点击图绑定到分析或产品研究目的。在TCF术语中，这通常是目的8（衡量内容表现）与目的1（存储和/或访问信息）的组合。对于同意模式，这是analytics_storage。
- 会话录制应位于更严格的独立信号之后。录制捕获渲染的DOM及任何未屏蔽字段，明确的偏好级别选择加入——而非笼统的分析同意——是在EDPB会话重放指南下可辩护的立场。
- 调查和反馈组件在收集自由文本输入时可在与会话录制相同的同意门下运行，在仅收集评分数据时可在分析门下运行。
- 漏斗和转化跟踪绑定到分析门；如果任何用户标识符被传播到CRM或广告平台，则营销门也适用。
有效的集成模式
参考部署包含四个部分：暴露实时同意变更事件的CMP、仅在分析同意触发后注入Hotjar代码片段的延迟脚本加载器、默认关闭录制直至独立门开放的会话录制压制层，以及即使在同意已授予时也强制压制监管机构认为敏感的任何字段的输入屏蔽配置。第四点常被忽视：输入屏蔽不能替代同意，但在同意已为合法研究目的授予、用户恰好在自由文本字段粘贴敏感数据时，它可以替代灾难性后果。
Web实现
在Web端，最简洁的模式是订阅CMP的同意变更事件，然后在分析目的从false变为true时有条件地注入Hotjar代码片段。使用document.createElement('script')以设置async属性的方式注入跟踪代码，并附加一个onload处理程序，仅在存在服务器验证的用户标识符时调用hj('identify', userId, properties)。当同意被撤回时，调用hj('consent', 'revoke')，通过document.cookie使所有_hj Cookie过期，并通过Hotjar数据API为用户之前的会话录制发送删除请求。不要在与横幅相同的渲染过程中懒初始化Hotjar——脚本必须等待明确的授权，且授权必须在脚本触发前以时间戳和同意字符串记录。
输入屏蔽和敏感数据压制
Hotjar会话记录器附带三种屏蔽模式：Suppress mode，这是密码字段和任何标记了data-hj-suppress属性的元素的默认模式；Whitelist mode，仅明确选择加入的输入被录制；以及Mask mode，按键以星号记录。根据GDPR特殊类别规则和CCPA敏感个人信息定义，任何可能捕获健康信息、财务详情、政府标识符、生物特征数据、精确地理位置或私人通信内容的字段，无论用户同意状态如何，均必须使用Suppress mode。在表单级别而非字段级别设置data-hj-suppress是最安全的模式——即使开发人员后来添加了忘记单独标记的新字段，也能压制整个表单。
单页应用和路由变更
对于SPA（React、Vue、Angular、Svelte），Hotjar代码片段默认仅绑定到初始页面加载。要跟踪虚拟页面转换，引导程序必须在每次路由变更时调用hj('stateChange', newPath)。此调用遵循Hotjar当时持有的任何同意状态，因此CMP门控逻辑无需重复——但如果在页面浏览之间同意已被撤回，路由变更本身不得触发新的脚本加载。
验证集成
验证步骤是监管机构检查而发布者最常跳过的部分。正确集成的Hotjar部署必须按顺序通过四项测试。第一，显示了横幅但未作出选择的全新浏览器会话应向static.hotjar.com、script.hotjar.com或vars.hotjar.com产生零请求，且document.cookie中零个_hj Cookie。第二，拒绝分析应保持该状态——无脚本加载、无录制、无Cookie。第三，接受分析应产生脚本加载，以及具有正确SameSite属性的预期_hjSessionUser和_hjSession Cookie，且热图录制应在五分钟内出现在Hotjar仪表板中。第四，事后撤回同意应立即停止进一步录制、使Cookie过期并触发删除请求——延迟清理是一个发现。
审计记录另有其用。监管机构期望发布者能够证明，对于Hotjar账户中的任何特定录制，生成该录制的用户在捕获时已给予有效同意。标准模式是通过hj('identify', userId, { consent_version: 'v3', consent_ts: ts })将同意版本和时间戳作为自定义属性嵌入Hotjar用户记录。这使任何特定录制都可追溯到特定的同意日志条目，这是EDPB设定的标准，也是发布者无论在哪里运营都应采用的标准。正确门控的部署，加上默认压制的输入屏蔽和在撤回时激活的删除路径，使Hotjar成为研究栈中可辩护的组成部分，而非合规负担。