Test the Denied State. That Is Where Consent Actually Lives.
Consent does not travel between domains on its own. A choice made on the shop subdomain is invisible to the support subdomain unless the consent tool is deliberately configured to share it, and trackers on the second domain will treat the visitor as undecided, banner them again, or worse, default to firing.
The denied state test is simple: reject all consent, then load the site with the tag manager in preview mode and the browser network panel open. No analytics, advertising, or personalization tags should fire, and no non essential cookies should be set. If anything fires, the tag conditions and the consent platform disagree, and the consent record is describing a state the site does not honor.
Why the accepted state tells you nothing
In the accepted state, every tag fires and every cookie sets, which is what the site is supposed to do. A test that only checks the accepted state confirms the site works when the visitor says yes, and says nothing about what happens when they say no. The denied state is the only state that tests the consent logic.
The most common denied state failure is a tag that fires on a page view trigger with no consent condition at all. The consent platform records a refusal, the tag manager never asks about it, and the tag fires. The second failure is a condition that checks the wrong variable: the platform writes consent_analytics and the tag checks analytics_consent, so the condition never matches and the tag fires by default.
Running the test properly
Reject all on the banner, then clear the site data and reload with preview mode on. Walk the homepage, a content page, the cart, and checkout, watching the tags that fire and the cookies that appear. Write down every tag and cookie, with the trigger that fired it, and compare the list against the consent record for the same visit.
Repeat the test on a phone, where the banner layout differs and the reject option is sometimes harder to reach. A denied state that works on desktop and fails on mobile is still a failure, because most visitors arrive on mobile.
Fixing what the test finds
Fix the tag conditions first, not the banner copy. Every non essential tag needs a consent condition that matches the variable the consent platform actually writes, and the condition has to be tested in the denied state after the fix, not assumed. The consent platform and the tag manager are configured separately and changed on different schedules, which is why they drift apart.
Put the denied state test into the release check. Every release that touches tags, embeds, or vendors runs the test before it ships, because new cookies arrive through routine marketing changes far more often than through deliberate privacy decisions.
Keep reading: One Brand, Several Domains: Keeping Consent State Coherent Across Subdomains, Prior Blocking: The Tags That Must Not Fire Before a Choice Exists, and Consent State Across Subdomains: Where the Shop, Blog, and Support Site Disagree cover the nearby cases in this series.
Frequently asked questions
What is the denied state?
The state after a visitor rejects non essential consent. Analytics, advertising, and personalization tags must not fire, and no non essential cookies should be set, until the visitor changes that choice.
Why does my tag fire after I reject all?
Usually because the tag has no consent condition, or the condition checks a variable the consent platform does not write. Check the tag trigger and the consent variable name in preview mode; the mismatch is usually visible in one screen.
Should I test the denied state on every page?
Test the homepage, a content page, and the checkout path at minimum. Checkout loads payment, fraud, chat, and media scripts that other pages do not, and those are the scripts most often missed.
How often should the denied state be tested?
After every release that touches tags, embeds, or vendors, and monthly otherwise. Consent breaks through routine changes, so the test belongs in the release check, not in an annual audit.