The chat bubble is a third-party payload

A live chat widget looks like a small bubble in the corner. Behind it is a third-party script that loads on every page, opens a connection to the vendor, and writes storage before a visitor types a word. Intercom sets first-party cookies on your domain (intercom-id-*, intercom-session-*, intercom-device-id-*) to identify anonymous visitors and hold sessions. Drift and Crisp do the equivalent. The widget booting up is the moment storage gets written and data starts flowing to the vendor, and by default that moment is page load.

So the same question that applies to any embed applies here: does this need consent before it loads? The honest answer is that it depends on what your chat is for, and the reasoning matters more than the label.

Is chat "strictly necessary"? Usually not

The strictly-necessary exemption in ePrivacy is narrow. Storage is exempt only when it is essential to provide a service the user explicitly requested. A visitor landing on your marketing page did not request a chat session; the widget is a support and lead-capture tool you added. Intercom itself says its Messenger is not necessary for the operation of a website and that categorizing its cookies is a legal decision for you to make. For most marketing, SaaS, and ecommerce sites, chat is an enhancement, which puts it in the consent-required column.

There is a narrower case. If chat is genuinely core to the service (a support product where the user came specifically to talk to an agent, or a session the user themselves opened), a functional-necessity argument gets more defensible, and Crisp, for one, frames its cookies as functional session-restoration rather than tracking. Even then, the safe default is to treat the widget as functional (not strictly necessary), disclose it, and gate it. Categorize it honestly using the framework in our guide to cookie categories, and remember the categorization drives what has to happen before it loads.

Two ways to gate it

Route one: category consent. Treat the widget's loader script as a functional (or marketing) tag and hold it until the visitor grants that category, the same way you hold any other non-essential script. Your consent platform blocks widget.intercom.io, js.driftt.com, or client.crisp.chat from executing until consent lands. Simple, and it fits an existing banner.

Route two: load on click. Often the better experience. Render a lightweight static button that sets nothing, and only boot the real widget when the visitor clicks to open chat. The click is an unmistakable signal that the person wants chat, which doubles as a clean basis for loading it. Here is the pattern for Intercom:

<button id="open-chat" type="button">Chat with us</button>

let booted = false;
document.getElementById('open-chat').addEventListener('click', () => {
  if (booted) { window.Intercom('show'); return; }
  window.intercomSettings = { app_id: 'APP_ID' };
  const s = document.createElement('script');
  s.async = true;
  s.src = 'https://widget.intercom.io/widget/APP_ID';
  s.onload = () => window.Intercom('show');
  document.head.appendChild(s);
  booted = true;
});

Nothing from Intercom loads, and no cookie is set, until the visitor asks for chat. Drift and Crisp expose the same shape: keep their snippet out of the initial page, inject it on the click, then call the vendor's open method once it loads.

Don't forget the parts around the widget

Gating the load is the main event, but two things travel with it. First, withdrawal has to be as easy as granting: if a visitor turns off the functional category later, the widget should stop loading on subsequent pages, and you should not silently keep a booted instance running. Second, be transparent in your privacy notice about which chat vendor you use and what it collects. A hidden support tool that quietly profiles visitors is the fast route to a complaint.

Chat vendors can also carry behavioral features (visitor tracking, session context, bot analytics) that go well beyond restoring a conversation. If yours does, it belongs in the same higher-scrutiny bucket as the tools in our guide on session replay and heatmaps, and consent is clearly the right basis.

Read the vendor's cookie table before you categorize

Do not guess at what a chat widget stores. Each vendor publishes a cookie and data-processing description, and they differ. Intercom identifies anonymous visitors and can tie a conversation to a logged-in user, which is closer to marketing behavior than a pure support session. Crisp describes its cookies as session-binding for message continuity. Drift has historically leaned into account-based marketing signals. The category you assign should follow what the vendor actually does on your site, not a generic "chat equals functional" assumption.

Two practical steps make this concrete. Pull the vendor's current cookie list and check it against what your consent tool declares. Then confirm whether your configuration turns on visitor tracking or wires the chat into a marketing platform. If it does, treat it as marketing, gate it accordingly, and put a data processing agreement in place, because the vendor is a processor handling your visitors' personal data on your behalf.

Checklist

Decide honestly whether chat is strictly necessary. On a marketing or ecommerce site, it usually is not.
Keep the widget's loader out of the initial page. Load it on category consent, or on the click that opens chat.
Confirm with the network panel that no vendor connection and no chat cookie appears before that trigger.
Make withdrawal work: turning the category off stops future loads.
Name the vendor in your privacy notice and describe what it collects.

A consent platform like CookieBeam supports both routes: it blocks the chat loader until the matching consent category is granted, and its scanner detects the outbound connection to the chat vendor so you can see, per page, whether the widget is loading when it should not. Back category-driven gating with server-side enforcement if you want a hard stop that a client-side bypass cannot defeat.