Most Shopify stores fail the reject all test: click reject, and tracking scripts keep firing anyway. Peer reviewed research found 65.4 percent of sites offering a rejection option still collect data after refusal. The test takes ten minutes to run yourself.
A banner is a user interface. Compliance is a network behavior. The gap between the two is where every recent enforcement action has landed, and it is invisible from the front end.
The reject all test is a two minute check of whether clicking the reject button on your cookie banner actually stops third party tracking, and it is the specific behavior that regulators and plaintiffs’ attorneys examine first. Everything else about your consent setup, the wording, the button colors, the privacy policy, the vendor you pay, is secondary to this one question: after a visitor says no, does anything still fire?
The reason it decides your exposure is that a failed reject all test is not a paperwork gap. It is a misrepresentation. Your banner told the visitor their choice would be honored. The network traffic says otherwise. Odia Kagan, who chairs the data privacy compliance group at Fox Rothschild, framed the risk to Bloomberg Law in its analysis of the surge in cookie banner litigation: when the banner does not do what it says it will do, that is a misrepresentation, and misrepresentation opens the door to several different causes of action at once.
The volume is moving in one direction. Bloomberg Law’s docket analysis found four federal suits targeting failure to honor opt-out requests filed in late 2024, 40 across 2025, and 49 in the first months of 2026. That is not a plateau.
What makes this the right diagnostic for an operator rather than a lawyer is that you can run it yourself, today, on your own store, without buying anything or asking permission. It requires no admin access, no developer, and no vendor. It produces a binary answer. And in my experience the operators most confident that they will pass are the ones most likely to fail, because confidence usually traces back to having installed a reputable consent platform two years ago and never looked since.
The best available measurement found that 65.4 percent of websites offering a cookie rejection option likely collect user data anyway, despite the visitor’s explicit refusal. That figure comes from Bouhoula and colleagues at ETH Zurich, whose automated large scale analysis of cookie notice compliance examined roughly 97,000 websites popular in the EU and, critically, interacted with the notices rather than just looking at them.
Independent work points the same direction. Research led by Amit Zac at the University of Amsterdam found that roughly 65 percent of testable websites ignore user rejection choices, and the team’s characterization of the pattern is the part operators should sit with. Popular websites scored well on the obvious, visible violations and worse on the back end ones. They ask for consent, which makes visitors feel protected, and then override the answer. Zac’s team called it a facade of compliance.
Two thirds is not an outlier population of bad actors. Two thirds is the norm, which means the base rate assumption for your own store should be failure until you have evidence otherwise. That inverts how most teams approach this. The default assumption in nearly every operator conversation I have is that the banner works because it is there and it was expensive.
Regulators have moved to testing rather than reviewing. The UK’s Information Commissioner’s Office reviewed the top 100 UK websites and issued formal warnings to 53 of them, then extended the review to the top 1,000. The relevant detail is not the count. It is that a regulator with limited resources chose to spend them running exactly this test at scale, because it is cheap to run and it separates real compliance from declared compliance in a single pass.
Open a private browsing window, open developer tools to the Network tab, load your storefront, click reject on the banner, and watch what continues to fire. That is the whole method, and the reason it works is that it observes actual browser behavior rather than reading a configuration file.
The sequence matters, so run it exactly this way. Open a private or incognito window so no prior consent cookie is present. Open developer tools before you navigate, because requests that fire during initial page load are the ones that matter most and you will miss them if the panel opens late. Switch to the Network tab and make sure the preserve log option is checked, so navigating between pages does not wipe your record. Now load your homepage.
Before touching the banner, scan the request list for third party domains. Anything you see at this point fired before consent, which is a separate failure from the one you are testing and worth noting on its own. Now click reject all. Clear the network log. Then navigate to a product page and to your cart.
What you are watching for after rejection is any request going to an advertising or analytics domain. Common ones on a Shopify store include connect.facebook.net, google-analytics.com, googletagmanager.com, analytics.tiktok.com, doubleclick.net, and whatever domains your review, chat, or heat mapping apps use. Strictly necessary requests to your own domain and to Shopify’s infrastructure are expected and fine.
Run it on at least three page types. Homepage, product page, and cart behave differently because tag configurations frequently differ by template, and I have seen stores pass cleanly on the homepage and leak on the cart, which is the worst possible place to leak because that is where purchase intent data lives. Then take a screenshot of the network panel with the timestamp visible. That screenshot is the entire point of the exercise.
After a rejection, the only requests you should see are ones serving your own domain, Shopify’s platform infrastructure, your CDN, and your consent platform itself. Everything else is a finding. The distinction that trips people up is between strictly necessary and merely useful, so here is the line: strictly necessary means the store breaks without it. Session management, cart state, authentication, load balancing, fraud prevention, and payment processing all qualify. Analytics does not, no matter how much you rely on it. Advertising pixels never do.
Three specific patterns come up often enough to name. First, a tag that fires once on load and never again, which usually means a script was hardcoded into your theme rather than routed through your consent platform. Second, a tag that fires only after a delay of several seconds, which typically means a lazy loaded script or an iframe that the consent platform never saw because it did not exist at scan time. Third, a tag that respects the homepage rules but ignores them on the cart, which means someone added a template specific snippet during a conversion optimization sprint and it never entered the tag governance process.
You should also check the reverse case, because passing the reject test while failing the accept test is possible and creates a different problem. Click accept in a fresh session and confirm your tags actually fire. Stores occasionally over block, and the operator discovers months later that their conversion data has a hole in it because the consent platform was silently suppressing a tag that had permission to run.
Cookies persisting after rejection is the fourth thing to check. In developer tools, open the Application tab and look at the cookie list. Existing non-essential cookies should be deleted on rejection, not merely stopped from being written. The Shein decision turned partly on cookies that continued to be read after the visitor clicked refuse, and reading a cookie you were told to stop reading is its own violation.
Nearly every failed test on a Shopify store traces to one of four causes, and three of them are organizational rather than technical. This is the pattern I have watched repeat across merchant conversations since my Shopify days, and it has not changed as the tooling has improved.
The first cause is theme level hardcoding. Somebody pasted a Meta pixel or a GA4 snippet directly into theme.liquid, usually years ago, usually because a marketing agency needed it live that afternoon. Your consent platform cannot block what it does not wrap. The fix is finding it and routing it through Google Tag Manager or your platform’s blocking mechanism, which takes twenty minutes once you know it exists.
The second cause is app injected scripts nobody catalogued. An app adds reviews or a chat widget or an upsell engine, and it brings its own third party calls with it. Twenty apps become several dozen network destinations that no single person on the team can enumerate. This is the same accumulation that shows up as page speed decay and checkout friction, and the remedy is the same one I have argued for in the context of clearing app bloat and operational drift: stop adding and start subtracting.
The third cause is uninstalled apps that left their scripts behind. Removing an app from your Shopify admin does not reliably remove every snippet it added to your theme. Orphaned code keeps calling home to a vendor you stopped paying, which is both a compliance finding and a slightly absurd one.
The fourth cause is drift after a passing test. Consent setups do not stay correct. A developer adds a tag, a vendor updates a script, a marketer installs a trial app on a Thursday. This is why the test belongs on a quarterly calendar rather than in a one time project plan, and why the merchants who install Shopify apps that touch protected customer data should treat every new install as a trigger to retest rather than an event to log.
A scan report from your consent management platform tells you what its crawler found, which is a different question from whether rejection is honored at runtime. This distinction is worth being blunt about, because it is the single most common reason an operator believes they are compliant when they are not.
Scanners work by crawling your pages and cataloguing the cookies and trackers present. That is genuinely useful, and it is how you build the category map you need. But a crawler observes what loads during its crawl. Scripts that set cookies conditionally, only after a user interaction, or through a lazy loaded iframe frequently go undetected. Pages added since the last scan are not in the report at all. And a scan cannot, by construction, tell you what happens after a rejection, because the crawler is not clicking reject and then watching.
There is also a structural point that applies to every vendor in this category including the ones I recommend. The platform selling you the banner is not the ideal party to certify the banner works. That is not an accusation of bad faith, it is just how incentives and instrumentation work. Your own browser is the neutral instrument.
Cookiebot by Usercentrics offers a free cookie checker that will inventory what is running on your domain without a signup, and running it alongside your manual test is a reasonable pairing: the scan gives you the catalogue, your browser gives you the runtime truth. Its patented scanner simulates real user sessions and picks up more than ten tracking types, including local storage, pixel tags, and web beacons that a simple cookie list would miss. OneTrust, Didomi, and iubenda all offer comparable discovery, and the discovery layer is not where these tools meaningfully differ. Whichever you use, the scan is the input. The reject test is the verification.
Remediation is a category mapping exercise followed by a retest, and the proof you generate at the end is worth more than the fix itself. Take the list of domains that fired after your rejection and assign each one to strictly necessary, analytics, or marketing. Anything not strictly necessary goes behind your consent platform’s blocking mechanism, and if you do not have one yet, a platform with automatic blocking such as Cookiebot by Usercentrics handles the category enforcement without a developer. For hardcoded theme scripts, that means moving them into a tag manager or wrapping them in your platform’s blocking attribute. For app scripts, it means checking whether the app supports consent integration natively and escalating to the vendor if it does not.
Then retest. Same private window, same three page types, same screenshot. The retest is not optional, because roughly a third of the remediations I have seen produce a partial fix: the homepage clears, the cart still leaks.
Now the part almost nobody does. Save the evidence with a date on it. A screenshot of the network panel after rejection, a note of which pages you tested, and your consent platform’s log export. Plaintiffs’ attorneys build these cases from a HAR file, a browser capture showing exactly what fired and when. You can export a HAR from the same Network tab: right click, save all as HAR. If a demand letter ever arrives, the difference between having a dated capture showing clean behavior and having nothing at all is the difference between a conversation and a settlement.
Store it somewhere your team will find it in eighteen months, alongside the record of what your stack actually contains. If you are building that record from scratch, the discipline is the same one behind keeping a data inventory of what you collect and where it lives, and the two documents want to live in the same folder.
Every stage runs the same ten minute test; what changes is what you build on top of it. Do not let the size of your store become a reason to skip the diagnostic, because the diagnostic costs nothing and the exposure it detects has no revenue floor.
Under $500K, run the test and fix what it finds. That is the whole assignment. If you have no consent platform at all and the test shows trackers firing, install one, categorize your scripts, and retest. Do not build a governance process, do not write policy documents, do not hire anyone. A store at this stage that knows what fires and blocks what should not is in better shape than most $10M brands.
Between $500K and $5M, add cadence and ownership. Put the test on a quarterly calendar, name one person accountable for it, and add a retest trigger to your app installation process. This is the stage where drift starts winning, because you now have enough people touching the site that nobody has the full picture. Save the evidence each time.
Above $5M, move from periodic to continuous. Quarterly manual testing is a floor, not a ceiling, and at this spend level automated monitoring that alerts on consent regressions pays for itself the first time a vendor script update slips through. This is also the stage where the reject test should extend to your logged in experience and your subscription flows, which crawlers rarely reach and which carry your most sensitive data. Pair it with the broader move toward zero party and first party data you actually own, because the durable answer to signal loss is collecting less from more willing people rather than collecting more from everyone.
Whatever your stage, the useful reframe is this. You are not testing your vendor. You are testing your store, which is an assembly of decisions made by many people over several years, most of whom have left. The banner is the only part of that assembly your visitors can see, and it is the only part currently making them a promise.
Open your site in a private browsing window, open your browser’s developer tools to the Network tab with preserve log enabled, load the page, and click reject on the banner. Clear the log, then browse to a product page and your cart. Any request to an advertising or analytics domain that appears after your rejection means the banner is not blocking. Repeat on at least three page types, because tag configurations often differ by template. Also check the Application tab to confirm existing non-essential cookies were deleted rather than just stopped. Screenshot the results with the timestamp visible.
The most common causes are scripts hardcoded directly into your theme rather than routed through your consent platform, scripts injected by apps that were never catalogued, and orphaned code left behind by apps you uninstalled. Your consent platform can only block what it wraps, so a Meta pixel pasted into theme.liquid three years ago will keep firing regardless of what your banner says. Lazy loaded scripts and content inside iframes also frequently escape blocking because they did not exist when the platform scanned your site. Each of these is fixable in under an hour once you know it is there.
No, a scan report tells you what a crawler found, not whether rejection is honored at runtime. Scanners catalogue cookies and trackers present during the crawl, which is genuinely useful for building your category map. But they miss scripts that set cookies only after user interaction, content loaded in lazy loaded iframes, and pages added since the last scan. More fundamentally, a scan does not click reject and then observe what happens next, which is the actual question. Use the scan for discovery and your own browser for verification. The two answer different questions and you need both.
Peer reviewed research from ETH Zurich analyzing roughly 97,000 websites popular in the EU found that 65.4 percent of sites offering a rejection option likely collect user data despite explicit refusal. Separate research from the University of Amsterdam reached a similar figure, around 65 percent, and noted that popular websites performed worse on these back end violations than smaller ones while performing better on visible ones. The practical implication is that failure should be your default assumption about your own store until you have run the test and kept the evidence.
Keep a timestamped screenshot of your browser’s Network tab after rejection, a HAR file export from the same session, a note of which page types you tested, and your consent platform’s log export. Export the HAR by right clicking in the Network panel and choosing save all as HAR. This matters because plaintiffs’ attorneys build tracking claims from exactly this kind of capture, and a dated record showing clean behavior materially changes your position if a demand letter arrives. Store it where your team will find it in eighteen months, and regenerate it each time you retest.
