EU Cookie Consent

Vwam can hold back cookies, local storage, and any third-party scripts (like BlueConic) for visitors in the EU/EEA until the visitor has given consent. This is a setting you switch on, and it is off by default. This article explains what the setting does, why it is off until you turn it on, and how to wire it up to your existing cookie banner.

Turning it on

The setting lives in Settings → Consent, under "Require consent before tracking EEA shoppers". It applies to every agent in your organization.

The gate covers the EU-27 plus Iceland, Liechtenstein, and Norway. It does not cover the United Kingdom. A UK visitor is treated as un-gated even with the setting on.

Wire up your cookie banner first. The gated state only lifts when your consent management platform (CMP) tells Vwam that the visitor accepted — see Connecting your cookie banner below. If you switch the setting on before that call is in place, every EU/EEA visitor stays gated for their entire visit, and you will not capture any leads from them. That is why the setting is off by default rather than on: an assistant that silently drops your EU leads is worse than one you switch on deliberately once the plumbing is ready.

What happens once it is on

For a visitor Vwam detects as being in the EU or EEA, a new conversation starts in a pending state:

• No cookies are read or written by the assistant.
• Nothing is saved to the browser's local storage, so nothing about the conversation is carried over to the visitor's next page load. The conversation is still recorded on our side — that's what lets the assistant follow the thread — and a conversation that never receives consent is deleted within 24 hours.
• Third-party scripts the assistant would otherwise load (like BlueConic) are held back.
• Lead-capture forms in the chat can't be submitted yet — a visitor who tries sees an inline message asking them to accept cookies first, instead of a generic error.

The assistant still works normally in every other way: visitors can chat, get recommendations, and use the widget exactly as they would anywhere else. Answering still means sending the conversation to the AI providers that power the assistant — that isn't held back, because it's what produces the reply (see AI providers & how prompts are handled). What the pending state holds back is everything around it: writes to the visitor's browser, our own analytics events (including the identity signals they normally carry, such as a Klaviyo cookie), any read from or write back to a connected customer data platform (BlueConic), lead-capture submissions, and the profile-property extraction that normally runs after a reply.

Visitors outside the EU/EEA are unaffected — this pending state never applies to them. Neither is anyone affected while the setting is off: with it off, every visitor is treated as un-gated, exactly as before.

If Vwam is ever unable to determine a visitor's region (for example, a brief outage on our side), it defaults to the same pending, cookie-free behavior rather than risk showing an EU visitor as un-gated. The assistant still loads and works normally in this case — nothing is broken, it just stays cautious until the check succeeds.

Connecting your cookie banner (OneTrust, Cookiebot, or similar)

Once your cookie consent management platform (CMP) records that a visitor has accepted cookies, tell Vwam by calling:

<script>
  window.vwam.consent({ granted: true });
</script>

Call this from your CMP's own "on consent accepted" callback — the exact hook depends on which CMP you use:

• OneTrust — call it from the OneTrust.OnConsentChanged() callback, or from your OptanonWrapper() function after checking the relevant consent category.
• Cookiebot — call it from a CookiebotOnAccept event listener (window.addEventListener('CookiebotOnAccept', ...)).
• Any other CMP — call it wherever your CMP tells your page that consent was granted.

Once called, the conversation on the current page keeps going — nothing is lost or restarted for that pageload — and from that point on cookies, local storage, and any third-party scripts resume normally.

A few things to know about what "resume" does and doesn't cover today:

• Resuming only applies for the rest of the current pageload. If a pending visitor accepts consent and then reloads the page or navigates elsewhere, the assistant starts a brand-new conversation on the next page — it does not pick back up the earlier (pending) conversation. Persisting a pending conversation across pageloads is on our roadmap but isn't built yet.
• Identity (BlueConic, Klaviyo, and similar) attaches starting with the conversation created after consent, not retroactively. Anything the visitor did while pending isn't linked to their profile after the fact — profile linking picks up cleanly from that point forward.
• Every pageload starts pending again for an EU visitor until your CMP calls vwam.consent({ granted: true }) on that page — this call needs to happen on each page where the assistant is embedded, the same way your CMP re-applies consent state on every page today.

Calling vwam.consent({ granted: true }) again after consent was already granted is safe — it's a harmless no-op.

Withdrawing consent

If a visitor changes their mind — switches your CMP's toggle back off, or uses a "withdraw consent" control — tell Vwam the same way, with granted: false:

<script>
  window.vwam.consent({ granted: false });
</script>

The assistant goes back to the cookie-free behavior described at the top of this article: local storage it wrote is cleared, third-party scripts stop, analytics stop, and lead-capture submission is blocked again. The conversation itself keeps working — the visitor can carry on chatting and nothing is restarted.

A few things to know:

• Withdrawal applies to the visitor's whole session, not just the current conversation. If they have the assistant open in another tab, or start a new conversation, those stop too.
• Nothing already collected is deleted by this call. Withdrawing stops further processing from that point on; removing existing data is a separate data-deletion request.
• Re-granting later works and starts a clean slate. Calling { granted: true } again resumes normally, with a fresh analytics session — activity from before and after a withdrawal is never stitched together into one.
• granted must be an actual true or false. A call with anything else — vwam.consent() with no argument, vwam.consent({}), or a non-boolean value — is ignored and logs a warning to the browser console instead of guessing. An absent flag does not withdraw, so a CMP callback that fires without a payload can't accidentally revoke a visitor's consent.

If your CMP gates script loading itself

Some CMPs are configured to block the Vwam embed script entirely until consent is granted, rather than letting the script load and calling vwam.consent(...) afterward. If that's how your site is set up, add data-vwam-consent="granted" to your embed element:

<div data-vwam-config="YOUR_CONFIG_ID" data-vwam-consent="granted"></div>

This tells Vwam to skip the pending state entirely for that embed — appropriate here because your CMP already prevented the script from loading before consent existed, so there's no risk of an unconsented visitor being tracked.

Use one approach or the other, not both: either let the script load and call vwam.consent(...) once accepted, or gate the script itself and set data-vwam-consent="granted".

Troubleshooting

• EU visitors are not being gated at all — check that Settings → Consent is switched on. With it off, no visitor is gated, whatever their region.
• The assistant seems "stuck" for EU visitors — this is expected. It's in the pending state, not broken. Chat still works; it's just not saving anything to the visitor's browser or sending anything to your connected tools yet. Once consent is called, it resumes.
• Lead-capture forms show a consent message instead of submitting — the conversation hasn't received a consent signal yet. Confirm your CMP is actually calling vwam.consent({ granted: true }) (check your browser's console/network tab for the call, or add a temporary console.log inside your CMP's callback).
• Consent is being called but nothing changes — make sure window.vwam exists at the time you call consent(...) (the Vwam embed script must have loaded first).