Consent, tracking and a marketing stack that still works

What consent actually gates

Fix the mental model first. Consent is not one switch, and a visitor who has not answered is not the same as a visitor who has said no.

Shopify's Customer Privacy API works in four categories: preferences (language, currency), analytics (how people use the storefront), marketing (targeting and promotion), and sale of data (sharing with third parties). A visitor can grant some and refuse others, and plenty will. Reading currentVisitorConsent() gives you 'yes', 'no' or an empty string per category, and that empty string is the state most implementations get wrong: it means undecided, and the correct behavior for it depends on where the visitor is. Code written as if (consent.analytics) collapses three states into two and will fire tags for undecided visitors in a region where that is not acceptable.

Two more documented behaviors matter for the build. getRegion() returns an ISO 3166-2 code, which is how the same storefront applies different defaults to a visitor in the EU and a visitor in a US state with an opt-out regime rather than a consent regime. And Global Privacy Control signals are honored automatically in configured regions: a browser-level signal your banner never sees, which means some visitors arrive already opted out and no amount of banner design changes that.

One more rule from the documentation that reads like a detail and is not: consent should only be recorded in response to a visitor interaction. Calling setTrackingConsent() on page load to "default everyone to yes" is not a shortcut with a compliance risk attached. It is the thing the API tells you not to do, and it is the single most common finding when we audit an inherited storefront.

Where the stack actually breaks

The banner is rarely the problem. Four other things are, in roughly this order of frequency.

Tags that were never in the tag system. A Google Tag Manager container pasted into theme.liquid three years ago does not know your consent state exists. Everything routed through it fires regardless of what the banner says. The first job of a consent project is almost always an inventory: every script in the theme, every app that injects one, and every tag inside the container, mapped to a consent category. It is dull, it takes a day, and it is the whole job.

Apps that inject rather than register. Shopify's Web Pixels API exists so marketing tags run in a sandbox (strict for app pixels, lax for custom pixels) with controlled access to cookies and storage rather than free run of your page. An app that instead drops a script tag into the theme is outside that system entirely. When you audit, sort your apps into the ones that use the pixel system and the ones that do not, because the second group is where both your consent exposure and your page-speed problem live.

Half-granted consent treated as full denial. Google's consent mode has separate parameters for ad_storage, analytics_storage, ad_user_data and ad_personalization. A visitor who accepts analytics and refuses marketing should still be counted in your analytics. Stacks that map a single banner button onto a single flag throw away the measurement they were legitimately given.

Checkout and the storefront disagreeing. Consent is a browser-side state that has to be consistent across the storefront and checkout. On a custom storefront in particular, Shopify documents that the API needs a Storefront API token and has to be coordinated across those surfaces. A storefront that respects consent and a checkout that does not is worse than neither, because it looks compliant in the place people test it.

Rebuilding reporting around what you own

The strategic answer to less browser data is not to reconstruct it. It is to move the numbers you run the business on off the browser entirely.

You own your orders. You own your customer records, your email engagement, your on-site search queries, your returns and your repeat rate. None of that depends on a third-party cookie or a consent state, and all of it is closer to the actual business question than a click-path report ever was. A merchant who knows their repeat purchase rate by acquisition month is better informed than one who knows which of nine touchpoints to credit for a sale, and only one of those two numbers is getting less reliable every year.

• Move the source of truth to orders and customers in your warehouse, and treat browser analytics as directional rather than authoritative.
• Ask for a post-purchase "how did you hear about us" answer. It is self-reported and imperfect, and it is unaffected by consent, ad blockers or browser policy.
• Use holdouts and geo tests for channels you cannot attribute. A channel that cannot be switched off for a fortnight to see what happens is a channel nobody is measuring.
• Report in cohorts, not in sessions. Cohort behavior survives sampling; individual journeys do not.
• Agree in advance which numbers are decisions and which are curiosities, and stop paying for precision in the second group.

Server-side is a tool, not an escape hatch

Server-side tagging and conversions APIs come up in every one of these conversations, usually framed as a way to get the data back. They are worth building, but that framing is wrong in a way that gets merchants into trouble.

Moving a tag server-side changes where a request originates, not whether you were permitted to send it. A visitor who refused marketing consent has refused it regardless of which machine makes the call, and a server-side setup that ignores the consent state is not a better implementation. It is the same non-compliance with a longer deployment pipeline. Build the consent check into the server-side path explicitly, and be able to show it.

What server-side buys you is reliability for the events you are allowed to send: fewer losses to ad blockers and browser restrictions, first-party context, and one place where deduplication happens. That is a real improvement in data quality. It is not a route around a "no".

If you are building the integration as a Shopify app rather than buying one, the compliance surface is concrete and documented: three mandatory webhooks, customers/data_request, customers/redact and shop/redact, each answered with a 200-series response and actioned within 30 days, with shop redaction arriving 48 hours after uninstall. Those are not optional extras on the backlog; they are conditions of the app existing.

The honest position

We are not lawyers and this is not legal advice. Your jurisdictions, your policy, your counsel. What we can say from doing the engineering is that most of the money spent on this is spent in the wrong place. Merchants buy a consent management platform, configure it in an afternoon, and never inventory the eleven scripts that bypass it. The platform is the cheap part. The audit is the work, and the audit is what would stand up to a question.

The second thing we would say is that the measurement loss is permanent and fighting it is expensive. The stacks that came through the last few years in good shape are the ones that got smaller: fewer tags, one tag system, consent read in one place, and a reporting layer built on orders rather than on events. That stack is cheaper to run, faster for buyers, and easier to explain to a regulator, and it makes better decisions than the one it replaced, which is the part nobody expects.

Questions this raises

Read next

• Shopify integrations and data
• Attribution models: what to believe after the cookie
• CDPs, ESPs and the customer record nobody owns