Cookie Consent for Headless & Composable Commerce

What changed, and what didn't

Composable commerce splits the monolith apart. Instead of one platform rendering your store, you have a Jamstack frontend (often a Next.js or Remix app on Vercel or Netlify) talking to a commerce API like Shopify Hydrogen, commercetools, or BigCommerce, following MACH principles: microservices, API-first, cloud-native, headless. You gained control and speed. You also gained responsibility for things the old platform did quietly, and consent is one of them.

What didn't change: the cookie rule. Article 5(3) of the ePrivacy Directive applies to storage on the visitor's device no matter where your frontend is hosted or how your backend is assembled. Your GTM container, your Meta Pixel, your analytics still execute in the browser. So a headless store needs the same consent gating a monolith needs. The difference is that nobody hands it to you anymore.

Where the CMP lives now

On a packaged platform, the consent banner was often a plugin. On a headless frontend, you own the load order, and that's the whole game. The CMP belongs in the root layout or app shell, loading once, before any third-party tag, and surviving client-side route changes so it doesn't re-initialize on every navigation. The framework mechanics are the same ones covered in our single-page app consent guide and, for App Router specifically, the Next.js consent guide.

The build step is the trap unique to Jamstack. If an analytics or pixel snippet is baked into the static bundle or a shared layout component, it can execute the instant the page hydrates, before consent resolves. Keep third-party tags out of the build output and inject them at runtime behind the consent signal, using dynamic imports so the code isn't even fetched until it's allowed to run.

Edge middleware helps with geo, not with consent

Composable stacks lean on edge functions (Vercel Edge Middleware, Netlify Edge Functions) that run close to the user. They're good at reading the request's country and deciding which banner or legal framework to serve, GDPR in the EEA versus a US opt-out experience in California. That's a real use: pick the right regional treatment at the edge, as covered in running one banner globally.

What the edge can't do is make the consent decision. Consent is chosen in the browser by a human and stored client-side; the edge function ran before that and doesn't know the answer. Use the edge to select the experience and to gate server-rendered personalization by region, but keep the actual accept-or-reject where it belongs, in the browser, readable by everything downstream.

Caching is the related gotcha

A Jamstack site caches aggressively at the CDN, and that collides with consent in a specific way: any response whose content depends on consent or region has to vary its cache key accordingly, or you'll serve one visitor's consent-shaped page to the next person who hits the same edge node. Vary on the geo signal you gate the banner with, and never cache a fully rendered page that already has tags injected. The safe shape is a cacheable shell plus consent-aware tag loading that happens per visitor in the browser, so the cached HTML is identical for everyone and the personalization layer is the only thing that reacts to a given person's choice.

Server-side tagging doesn't remove the obligation

Moving tags into a server-side GTM container is a common composable pattern, and it's worth doing, but it's often misunderstood as a consent workaround. It isn't. The browser still sends the first event to your server-side endpoint, and that hop is storage-and-access on the device just like a client-side tag. Consent Mode v2 signals still have to travel to the server container so it knows whether it may forward data to Google or Meta. Our guides on server-side GTM and server-side tagging consent on Shopify cover the wiring.

If you're on Shopify Hydrogen, the platform exposes a Customer Privacy API your frontend should read before firing marketing and analytics, described in our guide to the Shopify Customer Privacy API. Respecting it is part of staying in Shopify's own consent contract, not a substitute for your banner.

Composable means more processors, and more edge personalization

Two second-order problems come with the architecture. The first is contractual. A composable stack replaces one platform with a dozen microservices (search, reviews, recommendations, a customer data platform, an analytics API), and each vendor that touches personal data is a processor you need an agreement with. The tidy single-vendor relationship becomes a list, and your records of processing have to reflect it. See our guide to data processing agreements.

The second is edge personalization. Rendering a personalized page at the edge or on the server can mean reading a profile or an identifier before the visitor has consented to anything. If a returning shopper gets a personalized hero driven by past behavior, that processing needs a basis just like a client-side pixel does. Gate server-rendered personalization on the same consent state as your tags. Don't let the fact that it runs on your own infrastructure disguise that it's still profiling.

A checklist for a headless build

1. Load the CMP once in the root layout, before third-party tags, and keep it stable across client-side navigation.
2. Keep analytics and pixel snippets out of the static bundle; inject them at runtime behind the consent signal with dynamic imports.
3. Use edge middleware to pick the regional experience, not to decide consent.
4. Pass Consent Mode v2 state through to your server-side container; don't assume moving tags server-side ends the obligation.
5. Read the commerce platform's privacy API (Shopify Customer Privacy API and equivalents) where one exists.
6. Scan the deployed frontend URL, not localhost, since edge and CDN behavior only appears in production.

CookieBeam drops in as a framework-agnostic script that suits any Jamstack frontend, and its scanner crawls the deployed store to show which tags fire before consent across your real routes. The broader tag-gating and conversion trade-offs for a store live in our ecommerce consent and conversion guide.