How consent settings work
Every tag in a container carries a consent configuration. Google’s own tags declare their requirements themselves — an advertising conversion tag knows it depends on ad storage — and for any other tag you state the requirement yourself under the additional consent checks. When the trigger fires, Tag Manager compares the tag’s requirement against the current consent state. If a required type has not been granted, the tag is held back instead of firing.
The consent state does not come from these settings. It arrives from a banner or a consent management platform, which updates it as the visitor chooses. The settings only decide what each tag does with that state, and a tag with no requirement declared fires regardless of what the visitor said.
Why consent settings matter
They are what turns a banner from decoration into a control. A site can display a perfectly worded cookie notice and still fire every marketing tag the moment the page loads, which is what I find on a great many sites I audit. Consent settings are the point where the promise on the banner becomes something the container actually enforces.
They also keep behaviour predictable in a container several people edit. Once a requirement is declared on a tag it travels with that tag, rather than depending on someone remembering to attach an exception trigger every time.
Where consent settings go wrong
The first failure is a banner with nothing behind it. Nothing on screen gives this away: the notice appears, the visitor declines, and the tags fire anyway. Only preview mode or a tag inspection tool exposes it.
The second is the opposite — requirements drawn so broadly that basic first-party reporting is blocked alongside the advertising tags. The reporting gap that follows usually gets blamed on the analytics setup rather than on the consent configuration that caused it.
The third is assuming the settings satisfy a legal obligation. They are a technical control and nothing more. What consent you must collect, and how, depends on where your visitors are, and that is a question for a legal adviser rather than for a configuration screen.
How to act on it
Go through every tag in the container and decide what each genuinely requires; a tag whose requirement nobody can articulate probably should not be there at all. Then test both paths in preview, consent granted and consent declined, and confirm the blocked tags really are blocked. A declared requirement that was never tested is only an intention.
If you sell to visitors in the EU or the UK, build consent into the tracking setup from the start rather than bolting it on at the end, and expect reported conversions to sit lower than an unconsented setup showed. If you do not know what your container currently does when someone declines, a tracking audit settles it in an afternoon.