· askVela-Team
GDPR Live Chat Cookie Consent for Ecommerce: Test Your Widget Before Launch
Does your chat widget access browser storage before a shopper chooses? Test the published storefront across consent states and document what you find.
A chat widget does not automatically require cookie consent. Nor does a provider’s “GDPR-compliant” label settle what happens on your storefront. Before launching to shoppers in Europe, test whether your Shopify or WooCommerce site stores information on, or accesses information from, their devices before a choice, after refusal, after acceptance and after withdrawal. Your goal is evidence about the installed widget—not a legal conclusion based on its name.
Cookie consent and chatbot disclosure are separate checks
These checks answer different questions. One concerns what shoppers are told when they interact with AI. The other concerns device storage and access, including cookies and similar technologies. Completing one does not complete the other.
| Check | Question | Evidence |
|---|---|---|
| Chatbot disclosure | Does the interface make the AI interaction clear? | What appears before and during the conversation. |
| Device storage and access | What does the widget store or access, when, and why? | Consent state, browser storage, request details and likely initiating code. |
Use the EU AI Act chatbot disclosure guide for the first check. The procedure below addresses the second. It helps you identify questions for your developer or privacy adviser; it cannot determine whether a particular operation needs consent or qualifies for an exemption.
Map how the widget loads on your storefront
Test the published store with its real consent banner, not only a theme preview or plugin settings page. A chat button may appear before the full widget loads, and the same script may be inserted in more than one place.
If you are evaluating the askVela live-chat widget, its one-script-snippet setup gives you a place to start tracing the installation. It does not tell you what your installed storefront does before consent; test that directly.
Run a clean before-consent browser test
Use a desktop browser with DevTools and extensions disabled. Keep the browser, page type and widget configuration the same when you compare consent states. Browser menus differ, but the evidence to collect does not.
- Start clean. Use a fresh browser profile, or clear site data for the shop and relevant widget origins. Close other shop tabs. Open DevTools before navigation, select Network and enable Preserve log if available. Clear the Network log at the start of each run.
- Load without choosing. Visit the page and leave the banner untouched. Note whether the button appears, whether chat is usable and the time of the observation. Do not open chat yet.
- Inspect storage. In Application or Storage, check cookies for the shop and relevant third-party origins, plus localStorage and sessionStorage. Check frames separately where DevTools exposes them. Record the key, origin, visible expiry and whether an item was present after loading. Redact identifier values in anything you share.
- Inspect requests. In Network, search for the known widget script URL and its related domains. Open relevant requests and check the initiator or call stack. Where available, inspect request Cookie headers and response Set-Cookie headers: these can show cookie access or setting that a storage snapshot alone may miss. Record what you actually see; a request to a domain alone is not proof of device storage.
- Check attribution. Compare the domains and initiators with your script inventory. If the source remains unclear, ask a developer to compare runs on a safe staging copy with the widget disabled and enabled while other scripts stay unchanged. Do not switch off live payment or consent code to make a result look cleaner.
- Repeat by page. Run the untouched-banner check on the product and cart pages. Start clean again when an earlier page visit has already established a session or stored a banner choice.
A storage snapshot shows that an item exists, not necessarily which script read it. An empty cookie list does not rule out localStorage, sessionStorage or other device access. If DevTools cannot establish whether a read occurred, mark it as unconfirmed rather than writing “no access.”
Repeat after refusal, acceptance and withdrawal
Run refusal and acceptance from separate clean starts. Otherwise, an identifier created during acceptance could contaminate your refusal result. Use the same page types on Shopify or WooCommerce, and save each path’s Network log separately.
| Path | Action | Compare with the untouched run |
|---|---|---|
| Fresh visit | Load with no saved choice; leave chat closed. | Widget requests, storage items, cookie headers and initiators. |
| Refusal | From a clean start, refuse optional storage, reload and navigate to another test page. | Whether widget activity starts, stops or continues after refusal. |
| Open after refusal | If chat is available, open it without sending personal information. | Storage or requests triggered only by opening chat. |
| Acceptance | Start clean, accept the relevant choice, reload and navigate. | New activity relative to the fresh and refused paths. |
| Open after acceptance | Open chat on the same type of page used for the refusal path. | Session-related items and requests triggered by opening. |
| Withdrawal | From the accepted path, withdraw through banner settings; reload and navigate. | Whether existing items remain, are sent or apparently accessed again, or are replaced. |
Refusal and withdrawal are different tests. After refusal, a widget may never have created an identifier. After withdrawal, one may already exist. Record its continued presence separately from evidence that it is used again. If chat cannot open in a state, write “not available in this state”; do not silently skip the check.
Record evidence for your developer or privacy adviser
Make one entry per observation. Keep observed facts separate from suspected purpose, and link each entry to a screenshot or saved DevTools capture. Avoid sharing full cookie or storage values if a redacted value will do.
Illustrative entry—not a finding about any product: “WooCommerce; product page; consent untouched; page load; localStorage key example_chat_session on the shop origin; request to chat.example.test; initiator appears to be the inserted chat script; suspected purpose: retain a chat session; capture: product-untouched-storage.png; developer to confirm which code creates or reads the key.” Replace every detail with your own evidence.
A key containing “session” does not prove technical necessity. A chat-domain request does not prove device storage. You can review askVela security and privacy controls when assessing a provider, but provider privacy information does not substitute for testing device access on your storefront.
Decide what to change before launch
Use the observations to assign a next action, not to apply a blanket rule to every widget.
Before launch, you should be able to show what happened in each consent state, what storage or access you observed, which code likely caused it and which questions remain open. That is a useful basis for a technical fix or legal decision—not a generic claim about “chat cookies.”