Cookie consent for online stores: doing it right in the EU
How consent actually works on a hosted store platform, what the built-in tools do, and how to make sure marketing pixels genuinely wait.
The short answer
An online store sets more identifiers than an ordinary website: the platform’s own cookies for the session, the cart and the checkout; analytics; and marketing pixels arriving through apps, sales channels and tags added over the years. The legal position is the same as anywhere in the European Union. Cookies strictly necessary for what the customer asked for, the session, the cart, checkout state, the consent record, need no consent. Analytics, advertising pixels, personalisation, recommendation engines and testing tools do. Hosted platforms provide a consent mechanism and a privacy framework that apps and pixels are expected to use, and the real work is verifying that everything on your store actually respects it. The common failure is not a missing banner but a pixel pasted into the theme years ago that fires on page load regardless of what the customer chooses. That is visible in the browser in five minutes, and it is the first thing to check.
What a store loads and when it may load
| Cookie or script | Purpose | Consent needed |
|---|---|---|
| Session and cart | Keeping the basket and the customer’s place | No |
| Checkout state | Completing the purchase | No |
| Fraud prevention essential to the transaction | Completing the purchase safely | Generally no; document the reasoning |
| Consent record | Remembering the choice | No |
| Store analytics | Understanding traffic and behaviour | Yes, unless genuinely cookieless and non-identifying |
| Advertising pixels from any channel | Measurement and audiences | Yes |
| Email and marketing app trackers | Attribution and personalisation | Yes |
| Reviews, chat, popup and upsell apps | Varies; often set identifiers | Usually yes |
| A/B testing tools | Assignment identifiers | Yes |
| Embedded video or maps on content pages | Third-party cookies | Usually yes; use click-to-load |
Verifying it properly
- Open the store in a private window with the browser’s storage and network panels visible.
- Load a product page without touching the banner and list every cookie set and every third-party request.
- Compare against the strictly necessary list; anything else at this point is a failure.
- Refuse consent and repeat; nothing non-essential should appear.
- Accept consent and repeat; now the analytics and marketing scripts should load.
- Find the offenders in the theme code, the app list and the sales channel settings.
- Move them into the privacy framework or remove them.
- Repeat on the cart and checkout, where different scripts run.
- Re-test after installing any app, because apps add scripts.
- Publish an accurate cookie page listing what the store actually sets.
The measurement consequence
When consent is properly enforced, measured conversions fall, because visitors who refuse are no longer tracked. That is the correct outcome, not a bug. Plan for it: compare periods honestly, use the platform’s own order data as the source of truth for sales, and consider consent-free aggregate analytics for the site-wide picture. Businesses that respond by looking for ways to track refusers anyway are taking on the exact risk the rules exist to address.
What this means for you
On a store, cart and checkout cookies need no consent and analytics and marketing pixels do. Use the platform’s privacy framework so apps and pixels respect the choice, then verify in the browser before consent, after refusal and after acceptance, including on cart and checkout. Hunt down tags pasted into the theme, retest after every app install, and publish a cookie page that matches reality. Expect measured conversions to fall, and treat that as correct. This is general information rather than legal advice.
Frequently asked questions
Does the platform's built-in banner make us compliant?
It gives you the mechanism; compliance depends on configuration and on whether every tracking script honours it. Platform-native pixels and apps built to use the consent API will wait; scripts pasted into the theme by a previous agency, or apps that ignore the API, will not. The compliant state is one you verify in the browser, not one the banner's presence implies.
Which cookies can we set before consent?
Those strictly necessary to provide what the customer asked for: the session, the cart, checkout state, fraud prevention essential to the transaction, and the record of the consent choice itself. Analytics, advertising pixels, personalisation, recommendation engines and A/B tests are not strictly necessary and must wait. If in doubt about a platform cookie, check the platform's own documentation of its cookie purposes.
What about marketing pixels for advertising channels?
They need consent, and configuring them through the platform's customer privacy framework rather than by pasting a tag into the theme is what makes them respect it. Expect to lose some measured conversions from visitors who refuse, which is the correct outcome rather than a problem to engineer around. Server-side approaches do not remove the consent requirement for the underlying processing.
Sources
- Autoriteit Persoonsgegevens: Cookies (accessed 2026-09-12)
- European Data Protection Board: Guidelines 05/2020 on consent (accessed 2026-09-12)