Context first, since this board asks for it. I build a cookie consent app
that’s live on the App Store, and the thing I keep seeing in merchant
threads here is that Shopify’s built-in banner does not stop tracking
scripts sitting in your theme or in other apps — a visitor declines and
those scripts still load.
Before anything paid: here’s how to check that on your own store in two
minutes, plus two fixes that don’t involve me at all —
If you’d rather not maintain that wiring yourself, I do the setup as a
service. Fees, in full:
$35 — banner installed and matched to your theme, up to 3 tools blocked
until consent, verification report
$95 — the above, up to 6 tools, Google Consent Mode v2 and a cookie
policy draft
$180 — the above, unlimited tools, banner in 5 languages, consent log
walkthrough
Two things you should know before deciding. The app’s free plan covers the
banner and real script blocking, so there’s no monthly software cost for
the basic setup; Consent Mode v2, the consent log and the policy generator
are on its paid Complete plan, billed by Shopify, not by me. And I can
configure a different CMP instead — Cookiebot, Pandectes, Consentmo or
whatever you already run.
I don’t give legal advice and won’t tell anyone this makes them compliant.
The policy output is a draft; have it reviewed before you publish it.
Hi @novece
This is a useful thing to check, especially because a banner appearing correctly doesn’t necessarily mean the underlying scripts are actually being blocked.
Do you recommend merchants test this after every new app or theme change? It seems like adding a new tracking/review/marketing app could potentially reintroduce scripts that weren’t being blocked before.
Yes — and you’ve picked the two moments that actually matter, so let me be
specific about why each one breaks differently.
Theme change: this is the one that bites hardest. The banner runs as a theme
app embed, and embeds are per-theme. Publish a new theme and the banner is
silently off — the store looks fine, nothing errors, and no scripts are held
back. Any time you publish or duplicate a theme, load the storefront once
and confirm the banner still appears.
New app: the risk here isn’t that your existing blocking breaks, it’s scope.
An app I don’t know about can inject its own tags at runtime, and no consent
banner intercepts those — rewriting arbitrary third-party tags on the fly
breaks apps in ways their developers never tested for. What saves you is
that apps following Shopify’s rules read the Customer Privacy API, so they
respect the visitor’s choice on their own. The residual risk is a
badly-behaved app that sets cookies while ignoring that API.
So the honest cadence isn’t “test after every change”, it’s: after a theme
publish, check the banner is there; after installing anything that tracks,
measures or personalises, spend two minutes in DevTools — Application →
Cookies, on a fresh visit, before consenting. Anything sitting there that
isn’t strictly necessary tells you which app to talk to. Marketing, reviews
and analytics apps are worth checking; a shipping-rates or inventory app
almost never is.
One more thing worth knowing: a script that has already loaded can’t be
unloaded. If a visitor withdraws consent, the new choice applies from their
next page view onward, not retroactively.
That makes sense, especially the distinction between a theme publish and installing a new tracking app. I like the idea of checking the storefront rather than assuming the consent banner is still working just because it’s enabled in the admin.
For the DevTools check, would you also recommend testing the same flow in a fresh/incognito session both before and after giving consent? That seems like a good way to verify that non-essential cookies/scripts are actually behaving differently based on the visitor’s consent.
Yes — incognito is the right way to do it, and the reason is that consent
is stored in a cookie. Once you’ve accepted on a store, your own browser
looks nothing like a first-time visitor’s, so testing in your normal window
mostly tells you what your past self clicked.
The flow I’d use is a single incognito session, kept open:
Open the store fresh. Before touching the banner, check Application →
Cookies. Strictly necessary items are expected; anything analytics or
advertising sitting there already is the finding.
Switch to the Network tab, clear it, then accept. You should see the
previously-held requests fire at that moment — that’s the positive proof
the blocking was actually doing something rather than the tags simply
being absent.
Open a second incognito window and repeat, but decline instead. Same
checks. This is the half people skip, and it’s the half that matters:
accepting proves the tags exist, declining proves they stay held.
One caveat worth knowing: don’t reuse the same incognito window between
runs. Closing every incognito window clears the session; a new tab in the
same window keeps the consent cookie, and you’ll get a false pass.
And a browser-level one: some ad and tracking blockers stay active in
incognito. If a vendor is missing from the Network tab entirely, confirm
your extensions are off before concluding the store is clean.