Free scan
Chat widgets · troubleshooting

Your chat widget loads before consent

The chat bubble isn't just a bubble — most widgets open a connection, set an identity cookie, and start logging visitor activity the moment the page loads. Before anyone consents, and before anyone even opens the chat.

What it looks like

Fresh incognito window, DevTools → Network (include the WS tab), banner untouched, chat never opened. An ungated widget loads its script — widget.intercom.io, js.driftt.com, embed.tawk.to, client.crisp.chat, or similar — opens a WebSocket to the vendor, sets a visitor-ID cookie, and starts reporting page views and visitor metadata immediately. All of that happens whether or not the visitor ever clicks the bubble.

That's the part owners miss: modern chat widgets are behavioral-tracking tools with a chat feature attached. Idle on the page, they're still identifying the visitor and logging activity to a third party.

DevTools → Network — fresh incognito, banner untouched:
GET widget.intercom.io/widget/APP_ID ← widget script loads with the page
WS wss://…intercom.io/… (101 Switching Protocols) ← connection opens before any interaction
Cookie: intercom-id-… ← visitor identity set on first paint

Not sure what's firing on your site? See every pre-consent tracker — free, 30 seconds.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Why it happens

1. The embed is pasted site-wide by design

Vendor install instructions say to paste the embed in the site footer or theme so chat is available on every page — which also means the tracker component runs on every page load, ahead of any consent tool.

2. A helpdesk plugin injects it

A WordPress/Shopify helpdesk or support plugin injects the widget itself, outside the CMP's script management, so the consent platform never had a chance to gate it.

3. CMP classifies chat as strictly necessary

Consent platforms often file chat under "necessary" or "functional" by default. The widget then loads pre-consent even though it sets identity cookies and reports behavioral events — a categorization that's hard to defend for a marketing-oriented messenger.

4. The widget tracks even when idle

Teams assume tracking starts when a visitor opens a conversation. Most widgets (Intercom and Drift prominently) track page views and identity from the moment the script loads — the chat UI is irrelevant.

The risk context

California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that capturing a visitor's identity, pages viewed, and anything typed into chat via a third-party widget before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.

Chat tools have their own thread of the CIPA wave: § 631 claims have specifically targeted third-party chat vendors receiving the contents of visitor conversations, on the theory that the vendor — a party the visitor never knowingly addressed — is intercepting the exchange.

To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.

How to fix it

  1. Decide the loading strategy: the cleanest pattern is load on intent — render a static "Chat with us" button, and only inject the real widget when the visitor clicks it (which is itself a strong consent signal) or after CMP consent, whichever you prefer.
  2. Otherwise gate the embed behind your CMP: move the widget snippet into the CMP's script management (or GTM with a consent requirement) so it can't load pre-consent.
  3. Re-categorize chat correctly in your CMP — a messenger that sets identity cookies and reports behavioral events isn't "strictly necessary".
  4. Check the vendor's own privacy controls (identity verification, data-collection toggles) and turn off what you don't use.
  5. Re-scan to confirm no widget domains are contacted before consent or intent.

Verify the fix in 30 seconds — free re-scan, no signup.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Common questions

Does a chat widget really track visitors before they open the chat?

Most do. The widget script loads with the page, opens a connection to the vendor, sets a visitor-ID cookie, and reports page views and metadata immediately — whether or not the visitor ever clicks the bubble. The chat UI and the tracking are separate behaviors.

Is a pre-consent chat widget a CIPA problem?

Third-party chat vendors receiving visitor communications have been a specific target of CIPA § 631 claims. A widget loading before consent is a technical finding, not a legal conclusion — but it creates the timing pattern those claims are built on, so gating or load-on-intent is the prudent posture. Not legal advice.

How do I stop a chat widget loading before consent?

Either load on intent — a static chat button that injects the real widget only when clicked — or gate the embed behind your consent platform or a GTM tag with a consent requirement, and remove plugin-injected duplicates. Verify with a free re-scan that no widget domains are contacted pre-consent.

Related

Intercom compliance guideDrift compliance guideTawk.to compliance guideLiveChat compliance guideCrisp compliance guideSession replay & CIPA risk
Monitor my site ($99/mo) Estimate my exposure