What the Intercom Messenger Collects

The Intercom Messenger script (loaded from widget.intercom.io or js.intercomcdn.com) initializes a global Intercom object and identifies visitors with the intercom-id-* and intercom-session-* cookies. From that moment it captures pageviews, time-on-page, scroll depth, and visitor-level metadata: user agent, OS, browser, IP-derived location, referrer, and any custom attributes the application passes via Intercom('boot', {...}) or Intercom('update', {...}). The Messenger's real-time presence feature also reports visitor activity back to Intercom's servers continuously while the page is open, generating one of the heavier streaming-data footprints among customer messaging tools.

Once a user is identified — typically by calling Intercom('boot', { user_id: ..., email: ... }) after authentication — the script links the visitor identity to a known Intercom contact. Conversation history, attributes, and segmentation membership all flow from this identification, and Intercom uses the link to drive automated message campaigns, lifecycle email, and in-app product tours.

Why "It is Just a Chat Widget" Does Not Get You Out of Consent

A common defensive framing from product teams is that Intercom is a customer service tool, not a marketing tracker, and that customer service activity sits closer to "necessary for contract performance" than to "marketing requiring consent". The framing has narrow truth but is broadly wrong in practice.

Pre-conversation tracking is not contract performance

Once a customer initiates a chat conversation, processing related to that specific conversation can reasonably be characterized as contract or pre-contract performance under GDPR Article 6(1)(b). Everything before that point — the pageview tracking, the presence reporting, the visitor identification, the segmentation-driven automated message — is not. It is analytics and marketing-purpose processing requiring its own lawful basis.

The Messenger fires before any conversation

The script's default behavior is to initialize on page load and start collecting data immediately, long before the visitor has clicked the chat bubble. Whatever lawful basis covers an active chat session does not cover the data collected in the pre-conversation period.

Automated outbound messages are marketing

Intercom's automated message campaigns, lifecycle email, and behavioral triggers are marketing communications. They require their own lawful basis under both the GDPR and, in the US, CAN-SPAM and the TCPA where applicable.

Native Intercom Privacy Controls

Intercom exposes a useful set of native privacy primitives. As with other major marketing platforms they assume that a consent decision exists upstream; they do not collect it themselves.

shutdown

The Intercom('shutdown') call terminates the active session, clears the local cookies, and stops further tracking. Pair it with Intercom('boot') when the user accepts the marketing category in your CMP.

The hide_default_launcher option

Setting hide_default_launcher: true hides the chat bubble entirely without unloading the script. Useful for pages where chat should not be offered, but not a substitute for actually preventing the script from loading.

Data retention controls

Intercom's admin settings include configurable retention windows for visitor data, conversation history, and event logs. Tightening these is a defense-in-depth measure on top of the CMP-level gating.

The EU Data Hosting option

Intercom offers EU data hosting for accounts that require it, keeping conversation and visitor data within EU infrastructure. This addresses a meaningful portion of the cross-border transfer concern but does not eliminate the consent requirement.

Step-by-Step CMP Integration

The reliable pattern is to defer Messenger initialization until the visitor accepts the marketing category, then boot the Messenger with the appropriate user context. Once initialized, the Messenger runs normally; if the user revokes consent, the Messenger shuts down cleanly.

1. Remove the default Messenger snippet from the head

Intercom provides an installation snippet that initializes the Messenger on page load. Remove the boot call from the document head. The script tag can remain (with type="text/plain" and data-category="marketing" if your CMP uses that pattern), but the Intercom('boot') invocation must be deferred.

2. Boot Messenger from the consent callback

When the CMP fires its marketing-accepted event, rewrite the script type back to text/javascript, let it load, and then call Intercom('boot', { app_id: ... }). If the user is authenticated, include the identifying parameters in the boot call.

3. Provide a manual chat trigger for unconsented users

A customer who has rejected marketing tracking still has a right to contact support. Offer an alternative chat path — a contact form, an email link, or an explicit "Start chat" button that loads the Messenger only when clicked. The latter is the cleanest pattern: the user's explicit click constitutes consent for the specific purpose of the chat conversation.

4. Handle revocation

When the user revokes marketing consent, call Intercom('shutdown'). This clears the local cookies and stops tracking. Persist the updated consent state so subsequent page loads honor it.

5. Use EU data hosting for EU accounts

For accounts where EU data residency matters, configure the Intercom workspace for EU hosting. Route EU traffic accordingly; if you operate separate workspaces for EU and non-EU customers, the integration must select the correct app ID at boot time.

Common Pitfalls

Four integration mistakes show up repeatedly in audits of Intercom deployments.

Booting before consent

The single most common defect. The default install boots the Messenger on page load, which fires the visitor identification and pageview tracking before any consent decision. The remediation is straightforward — defer the boot call to the consent callback — but the default integration documentation does not flag this clearly enough.

Treating shutdown as optional

If a user revokes consent and the Messenger is not explicitly shut down, the script continues running with its session cookies in place. The CMP has recorded the revocation but the underlying tracking continues. Always wire shutdown to consent revocation.

Bundling support and marketing

Some teams justify pre-consent Messenger loading by arguing it is "support, not marketing". If the same Messenger also runs automated outbound campaigns or in-app product tours, the line cannot be drawn. The conservative approach is to gate the Messenger entirely under marketing and provide a separate, unbundled support contact path for users who reject marketing.

Ignoring custom attribute payloads

The data passed in Intercom('update') calls — custom user attributes, subscription tier, account age, internal user identifiers — is personal data forwarded to Intercom. Review these payloads for over-sharing; many integrations pass more identifying data than the Messenger functionally needs.

Audit Checklist

Six concrete questions to answer for any Intercom deployment touching EU, UK, or California traffic.

• Does the Messenger wait for consent? Open the page in a private window with strict tracking protection and confirm no intercom.io or intercomcdn.com requests fire before banner acceptance.
• Is there a non-Messenger support path? For users who reject marketing, can they still contact support via a form, email, or explicit-click chat trigger?
• Does revocation shut down the Messenger? Confirm consent revocation calls Intercom('shutdown') and clears local cookies.
• Are custom attributes minimized? Review the payloads in Intercom('update') calls and remove any data not functionally required by the Messenger.
• Is EU data hosting configured where required? Confirm EU traffic routes to an EU-hosted workspace, with documentation of the routing decision.
• Are outbound campaigns gated on consent? Confirm automated message campaigns honor the contact's marketing-consent state and stop sending on revocation.

Where Intercom Fits in a Consent-First Stack

Live chat and customer messaging platforms occupy a regulatory grey zone that vendors have not been eager to highlight. The data flow looks like analytics and marketing tracking; the framing emphasizes customer service. Regulators have made clear that the data flow controls the analysis, not the framing. The right architecture treats the Intercom Messenger like any other identifying third-party script: gate it behind consent, provide an alternative support contact path for users who reject, use the platform's native shutdown primitive to honor revocations, and configure EU data hosting where residency matters. Done correctly, support teams keep the live chat and lifecycle automation that make Intercom valuable, while the underlying compliance posture stops being a quiet exposure waiting for an audit to surface it.