Consent, tracking and a marketing stack that still works

The first thing worth fixing is the mental model. 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 behaviour 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 behaviours 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 honoured 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.

In practice 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.

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 doing, and 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 more robust 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 genuinely 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.

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 actually 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.

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