Intercom Messenger 收集哪些数据

Intercom Messenger 脚本（从 widget.intercom.io 或 js.intercomcdn.com 加载）会初始化一个全局 Intercom 对象，并通过 intercom-id-* 与 intercom-session-* Cookie 标识访客。从那一刻起，它便开始捕获页面浏览、页面停留时长、滚动深度及访客级元数据：用户代理、操作系统、浏览器、基于 IP 的位置信息、来源页面，以及应用程序通过 Intercom('boot', {...}) 或 Intercom('update', {...}) 传入的任何自定义属性。Messenger 的实时在线功能还会在页面保持打开状态期间持续将访客活动上报至 Intercom 服务器，在客户消息工具中产生较重的流数据足迹。

一旦用户完成身份识别——通常是在认证完成后调用 Intercom('boot', { user_id: ..., email: ... })——脚本便会将访客身份与已知的 Intercom 联系人关联。对话历史、属性及细分组成员信息均由此身份识别流转，Intercom 也借助这一关联驱动自动化消息营销、生命周期邮件及页面内产品导览。

为何"只是个聊天 widget"无法豁免同意要求

产品团队常见的辩解是：Intercom 是客服工具而非营销追踪器，客服活动更接近于"履行合同所必要"而非"需要同意的营销行为"。这种说法有其狭义的正确性，但在实践中大体上是错误的。

对话前的追踪不属于合同履行

当客户发起聊天对话后，与该具体对话相关的处理行为在 GDPR Article 6(1)(b) 框架下可被合理定性为合同或预合同履行。而在此之前的一切——页面浏览追踪、在线状态上报、访客识别、基于细分驱动的自动化消息——均不属于此列。这些属于分析与营销目的的处理行为，需要各自独立的合法依据。

Messenger 在任何对话之前即已触发

脚本的默认行为是在页面加载时初始化，并立即开始收集数据，远早于访客点击聊天气泡。无论何种合法依据涵盖了活跃聊天会话，都不能涵盖对话前阶段收集的数据。

自动外发消息属于营销行为

Intercom 的自动化消息营销活动、生命周期邮件及行为触发器均属于营销通讯。在 GDPR 框架下以及在美国适用的 CAN-SPAM 和 TCPA 框架下，它们各自需要独立的合法依据。

Intercom 原生隐私控制

Intercom 提供了一套实用的原生隐私原语。与其他主流营销平台一样，这些原语假定上游已存在同意决策；它们本身并不负责收集同意。

shutdown

Intercom('shutdown') 调用会终止当前活跃会话、清除本地 Cookie 并停止进一步追踪。当用户在 CMP 中接受营销类别时，将其与 Intercom('boot') 配对使用。

hide_default_launcher 选项

设置 hide_default_launcher: true 可完全隐藏聊天气泡，而无需卸载脚本。适用于不应提供聊天功能的页面，但不能替代真正阻止脚本加载的措施。

数据留存控制

Intercom 管理设置包含访客数据、对话历史及事件日志的可配置留存窗口。收紧这些设置是在 CMP 层级管控之上的纵深防御措施。

EU 数据托管选项

Intercom 为有需求的账户提供 EU 数据托管服务，将对话及访客数据保留在 EU 基础设施之内。这在一定程度上解决了跨境传输问题，但并不消除同意要求。

CMP 集成分步指南

可靠的方案是将 Messenger 初始化推迟至访客接受营销类别后，再携带适当的用户上下文启动 Messenger。一旦初始化完成，Messenger 将正常运行；若用户撤回同意，Messenger 则会被完全关闭。

1. 从 head 中移除默认 Messenger 代码片段

Intercom 提供的安装代码片段会在页面加载时初始化 Messenger。将 boot 调用从文档 head 中移除。script 标签可保留（如果 CMP 支持该模式，可设置 type="text/plain" 及 data-category="marketing"），但 Intercom('boot') 调用必须延迟执行。

2. 从同意回调中启动 Messenger

当 CMP 触发营销已接受事件时，将 script 类型改回 text/javascript，等待脚本加载，然后调用 Intercom('boot', { app_id: ... })。若用户已完成身份验证，在 boot 调用中加入识别参数。

3. 为未同意用户提供手动聊天触发方式

已拒绝营销追踪的客户仍有权联系客服。提供替代聊天路径——联系表单、邮件链接，或仅在点击时加载 Messenger 的显式"开始聊天"按钮。后者是最简洁的方案：用户的明确点击即构成针对该聊天对话特定目的的同意。

4. 处理撤回操作

当用户撤回营销同意时，调用 Intercom('shutdown')。这将清除本地 Cookie 并停止追踪。持久化更新后的同意状态，以便后续页面加载时予以遵守。

5. 为 EU 账户使用 EU 数据托管

对于 EU 数据驻留有要求的账户，将 Intercom 工作区配置为 EU 托管。相应地路由 EU 流量；若您为 EU 与非 EU 客户分别运营独立工作区，集成方案必须在启动时选择正确的 app ID。

常见陷阱

在 Intercom 部署审计中，四类集成错误反复出现。

在取得同意前启动

最常见的缺陷。默认安装会在页面加载时启动 Messenger，在任何同意决策作出之前便触发访客识别与页面浏览追踪。修复方案直截了当——将 boot 调用推迟至同意回调——但默认集成文档对此提示不够清晰。

将 shutdown 视为可选操作

若用户撤回同意但 Messenger 未被显式关闭，脚本将携带其会话 Cookie 继续运行。CMP 已记录撤回操作，但底层追踪仍在持续。务必将 shutdown 与同意撤回关联绑定。

将客服与营销捆绑

部分团队以"客服而非营销"为由，主张在取得同意前加载 Messenger。若同一 Messenger 还运行自动外发营销活动或页面内产品导览，则无法划清界限。保守的做法是将 Messenger 完全置于营销管控之下，并为拒绝营销的用户提供独立、解绑的客服联系路径。

忽视自定义属性负载

Intercom('update') 调用中传入的数据——自定义用户属性、订阅层级、账户年龄、内部用户标识符——均属于被转发至 Intercom 的个人数据。审查这些负载是否存在过度共享；许多集成传入的识别数据远超 Messenger 功能所实际需要的范围。

审计核查清单

针对任何涉及 EU、英国或加州流量的 Intercom 部署，需回答以下六个具体问题。

• Messenger 是否等待同意后再触发？在开启严格追踪保护的隐私窗口中打开页面，确认在横幅被接受之前不存在 intercom.io 或 intercomcdn.com 请求。
• 是否存在非 Messenger 的客服路径？对于拒绝营销的用户，是否仍可通过表单、邮件或显式点击聊天触发方式联系客服？
• 撤回同意是否会关闭 Messenger？确认同意撤回操作会调用 Intercom('shutdown') 并清除本地 Cookie。
• 自定义属性是否已最小化？审查 Intercom('update') 调用中的负载，移除 Messenger 功能不需要的任何数据。
• EU 数据托管是否已在需要的地方配置？确认 EU 流量路由至 EU 托管工作区，并留存路由决策的文档记录。
• 外发营销活动是否已基于同意进行管控？确认自动化消息营销活动遵守联系人的营销同意状态，并在撤回时停止发送。

Intercom 在以同意为先的技术栈中的定位

在线客服与客户消息平台所处的监管灰色地带是供应商不愿主动揭示的。其数据流看似分析与营销追踪，但定性框架强调的是客服。监管机构已明确指出：数据流决定分析结论，而非定性框架。正确的架构是将 Intercom Messenger 视同其他任何具有识别性的第三方脚本：将其置于同意管控之后，为拒绝的用户提供替代客服联系路径，使用平台原生 shutdown 原语遵守撤回操作，并在数据驻留有要求的地方配置 EU 数据托管。做到这些，客服团队可以保留使 Intercom 具有价值的在线客服与生命周期自动化功能，而合规态势也不再是等待审计触发的潜在敞口。