How to know if a tag is really setting cookies before consent
Open the page in a private window with developer tools already running, and do not touch the banner. Whatever appears under Application, Cookies, and whatever leaves under Network, happened before consent. Then attribute each one: pause the tag you suspect, reload, and see whether it comes back anyway. A container audit answers a different question, which tags are ungated rather than which of them did anything.
What an audit list is actually telling you
A consent audit, whether it comes from a scanner or from someone reading a container export, answers one question: which tags have no consent condition attached to them. That is a fair question. It is not the same question as whether anything left the browser before the visitor chose.
On a live estate this year the client side handed us a findings list of eleven ungated tags, with a complaint attached and a deadline. Measured against a single clean page load, three of the eleven were vendor tags that read the consent state themselves and did nothing with it, two were dataLayer listeners that set no cookie and made no network call, and six were real leaks. Five of eleven findings were configuration hygiene. Worth fixing, and not what anyone was complaining about.
The finding that explained the complaint was not on the list at all.
How to check whether a tag is really setting cookies
Start from a profile that remembers nothing
A private window, extensions off, developer tools open before the page loads, with Preserve log switched on. If the profile already holds a consent record the page treats you as a returning visitor and the load proves nothing at all.
Read what happened before you touch the banner
Application, then Cookies, for every domain listed. Network, filtered to hosts that are not yours. Write both lists down before you accept or reject anything. That record is the finding. Everything after this step is matching, not discovering.
Give every flagged tag one of three verdicts
Leaking: it wrote a cookie or sent a request. Inert: it fired and did neither. Self gating: it fired, read the consent state itself, and stopped. Only the first verdict is a leak, and the other two are worth writing down so nobody raises them again next quarter.
Confirm each suspected leak by pausing one thing at a time
Pause the tag, reload the private window, and look for the same cookie or request again. If it is still there, that tag was never the source, and the next place to look is the page source itself: a snippet pasted into the head is isolated exactly the same way, by removing it and reloading.
Trace the cookies nobody flagged back to what loaded them
For every cookie or request on your list that no tag explains, read the initiator column. A request whose initiator is another vendor's script came in downstream, is not in your container, and will survive every change you make there.
Rank by what actually left the browser
A cross site request carrying an advertising identifier is a different order of finding from a first party cookie holding a session id. Fix in that order, and put the ranking in the reply rather than the raw count of eleven.
Steps one and two are the whole method. The rest is bookkeeping, and it is bookkeeping that answers the question a client actually asked, which is not how many tags are ungated but which of them is doing something.
Why a container audit cannot produce this list
Two structural reasons, and neither is a flaw in the tooling.
A container knows its own tags, and nothing else. It does not know what a script does once it has loaded, and it cannot see anything pasted straight into the site head, which is where the oldest and least reviewed vendor snippets tend to live. Whether a given snippet can be moved into the container in the first place is a decision worth making one script at a time.
Ungated and leaking are different properties. More vendor tags now read the Consent Mode state themselves and hold back on their own, so a tag can carry no condition in the container and still behave correctly. The inverse is also true, and worse: a tag can carry a perfect condition and still leak, because the thing setting the cookie is downstream of it. Assigning the right category to each script is its own exercise, and the decision test for that is here.
The finding that will not be on any list
In that audit, the cookie that mattered was set by a third party pixel that no tag in the container references. Another vendor's script had requested it after loading, which is a chain a container export cannot show and a scanner reading tag configuration will not report.
The Network panel's initiator column is what finds it. Follow the request back to the script that asked for it, and you usually land on a tool that was approved years ago for something unrelated. Pausing tags does nothing here, because the tag was never the source. The mechanism behind that pattern is worth reading in full, since once you have seen it once you check for it every time.
What to send back
Reply with verdicts rather than a count. Six leaking, ranked by what left the browser. Five ungated and inert, with the evidence that they are inert. One leak that was not on your list, with the script that loaded it named. That reply is shorter than the original list and it is the one that can be acted on.
The reason to be strict about this is that both errors cost real money in opposite directions. Gating a tag that was never leaking removes measurement for nothing. Missing a tag that is leaking leaves the complaint unanswered. Across Amplio Data client implementations we have measured 34% of sessions hidden by consent, and, as a separate figure, 20% to 40% of lost conversions recovered once the wiring is correct. Those are measured ranges across Amplio Data client implementations, not a guarantee, and they depend on your traffic mix, your regions and how your tags are configured.
Run the same clean load again after every fix, because that is the only thing that proves the fix. The full pre launch sequence is here, and it is the same discipline applied earlier. Velo blocks by category before a tag can run and records what was granted at the moment it happened, which shortens this exercise considerably. It does not remove it: the scripts your vendors load are still yours to find.
Common questions
What people ask about this topic.
How do I know if a tag is really setting cookies before consent?
Open the page in a private window with developer tools already running and do not touch the banner. Read the cookies that were written and the network requests that were sent. Then attribute each one by pausing the tag you suspect and reloading: if the cookie comes back anyway, that tag was never the source. Your container tells you what is configured, never what happened.
Does a tag with no consent condition always mean a leak?
No. On one audit of eleven flagged tags, three were vendor tags that read the consent state themselves and did nothing, and two were dataLayer listeners that set no cookie and made no call. Five of the eleven were configuration hygiene rather than leaks. Ungated and leaking are different properties, and only a live load separates them.
What if a cookie appears before consent but nothing in my container set it?
Then it was injected downstream: another vendor's script requested it after loading, so it is not in your container and pausing tags will never stop it. The Network panel's initiator column names the script that asked for it. This is the finding an audit tool cannot list, and it is often the one that explains the complaint.
Why does a consent audit list tags that are not actually leaking?
Because it reads configuration. An audit enumerates tags with no consent condition attached, which is a real question but a different one from whether anything left the browser. It also cannot see scripts pasted straight into the site head, or the requests a loaded script makes on its own.
Your banner, your consent,
your data, all in one place.
