Should a Shopify store block scripts before consent or fix it after?
Block first, then release. Scripts that fire before the visitor chooses are the most common consent failure on Shopify stores, and no policy page or after-the-fact deletion fixes it. Prior blocking means optional scripts do not execute until consent state is known, which requires controlling the load order through the tag manager or the theme. It is more work up front and it is the only pattern that actually holds up under inspection.
Why after-the-fact fixes fail
The tempting shortcut is to let everything load and clean up afterward: fire the pixels, then delete the cookies if the visitor rejects. This fails on every level that matters. The data was already collected and transmitted, which is the violation, not the cookie sitting in the browser. Deleting a cookie does not un-send a network request. Regulators evaluate what happened, not what you tidied up.
The same logic defeats "we anonymize it" as a retroactive defense for pre-consent collection. If the collection itself lacked a legal basis, the processing pipeline does not cure it. The only compliant moment to decide is before the script runs.
What prior blocking actually requires
Prior blocking has three parts. First, inventory every script the store loads and classify each as strictly necessary or optional. Second, gate the optional ones: they do not execute until consent state is read, and a rejection or an unanswered banner keeps them blocked. Third, handle the tag manager, which is usually the biggest leak, by configuring it to respect consent state before firing any tag, not as an afterthought.
On Shopify this typically means working in the theme's script loading and the tag manager configuration together. Apps that inject their own scripts are the hard part; each one needs the same classification and gating, which is why the script inventory has to include app-injected code, not just theme code.
The consent-state race
The technical crux is timing. The banner needs to read or establish consent state before optional scripts execute, which means the consent logic must run early and synchronously enough to gate the rest. The common failure is a race: the banner script loads asynchronously, the pixels fire first, and consent arrives a second too late. From the visitor's perspective they never chose; from the network log, everything fired.
Solve it by making consent state the first thing that resolves. Store it in a first-party cookie or localStorage with a fast synchronous read, default to the most restrictive state when nothing is stored, and only release optional scripts after an explicit accept. A first-time visitor with no stored state is a "no" until they say "yes."
Test it like an inspector would
Verification is a fresh browser profile, not your own. Clear everything, load the store, make no choice, and record every network request for sixty seconds. Then accept and record again, then start over and reject and record a third time. The three traces should show three different script populations, with the no-choice and reject traces containing only strictly necessary requests.
Repeat the test after every theme change, app install, and tag manager publish. Consent gating is configuration, and configuration drifts. The stores that stay compliant are the ones that re-test on a schedule instead of assuming the setup still holds.
Document the pattern
Keep a record of the blocking implementation: which scripts are gated, where the gate lives, what the default state is, and the test traces proving it works. When a client, a partner, or a regulator asks how consent is enforced, this document is the answer. "We block first" is a claim. The traces are the proof.