This is usually not a bug. Consent Mode does not block requests — it changes what Google's tags are allowed to send, and it has no authority at all over tags that are not Google's. Requests you still see may be perfectly correct denied-state pings, or they may be a real gap. The parameter that tells you which is in the request URL.
The short answer
With advanced consent mode, Google's tags still load and still send a cookieless ping while consent is denied. The ping carries no identifiers and sets no cookies, and it exists so conversion modelling has something to work with. That is behaving as designed, and it is not the pattern a pre-consent claim is built on.
What is a real problem: a Meta, TikTok, LinkedIn, Klaviyo, or session-replay tag firing at the same moment. Consent Mode is a Google framework — those vendors never see it. If you configured Consent Mode and assumed the whole page was covered, the non-Google half of your stack is still ungated.
You set the defaults, wired the CMP, republished — and the network tab still shows traffic before the banner is answered. Look closely and it usually splits into two groups. Group one: requests to google-analytics.com/g/collect or googleads.g.doubleclick.net carrying a gcs= parameter. Group two: everything else — facebook.com/tr, analytics.tiktok.com, px.ads.linkedin.com, clarity.ms — with no consent parameter anywhere, because those vendors do not implement one.
Group one may be correct. Group two is the consent gap you still have.
The gcs parameter is the whole diagnostic. It is four characters that tell you what consent state Google's tag believed it was in when it sent the hit.
collect. Click any request and read the query string. Find the gcs parameter.G followed by three digits: a status digit, then ad_storage, then analytics_storage — 1 means granted, 0 denied. So gcs=G100 is both denied (correct before consent) and gcs=G111 is both granted (wrong, if you have not clicked anything).gcs=G111. If they never change, the CMP is not calling the consent update — the defaults are working but the accept path is broken.What a healthy result looks like: A correctly configured advanced setup shows gcs=G100 before consent and gcs=G111 after, and shows no non-Google vendor traffic at all until the visitor accepts.
In advanced mode the tags load and send cookieless pings while consent is denied. If you expected zero requests, use basic consent mode instead — the tags do not load until consent is granted — and accept the loss of modelled conversions.
Anything that runs after the tag library has already initialized cannot retroactively deny storage. If the default call is inside GTM rather than in the page source before gtm.js, the first hits can escape with granted state.
Meta, TikTok, LinkedIn, Klaviyo, Intercom, Hotjar and the rest have their own consent APIs or none at all. Consent Mode does not reach them. This is the single most common reason a "we did Consent Mode" site still shows pre-consent trackers.
Some CMP integrations record the choice internally and never call gtag('consent','update',…). The symptom is a gcs value that never changes after the visitor clicks Accept.
California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that tags transmitting visitor data with consent state granted, or with no consent signal at all, before the visitor has answered before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.
To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.
// Read the consent state a Google tag believed it had:
// gcs=G100 -> ad_storage denied, analytics_storage denied
// gcs=G101 -> ad_storage denied, analytics_storage granted
// gcs=G110 -> ad_storage granted, analytics_storage denied
// gcs=G111 -> both granted
// Before the visitor answers the banner you want G100.
// After Accept you want G111. A value that never changes = the
// CMP is not calling gtag('consent','update', ...).Read gcs from the query string of any /g/collect or doubleclick request in the network tab.
Terminology bridge
Google calls this consent mode, and the two flavours are basic (tags do not load until consent) and advanced (tags load, send cookieless pings, and upgrade on consent). The URL parameter is the gcs — Google consent state — signal, and the modelled-data feature it enables is conversion modelling. When a vendor is outside this system entirely, the industry phrase is that it is not consent-mode aware; your CMP's docs will call gating those scripts prior blocking or script blocking.
A scan — ours or anyone's — records what your site loaded and when. It cannot tell you whether a denied-state ping is acceptable under any particular statute, and it is not legal advice. What it can do is separate the two groups above for you: Google traffic carrying a consent signal, and everything else carrying none. The second group is where the work is.
RegSentry loads your site in a real browser, records when each third-party tracker first contacts its server, and flags everything that fires before consent — with the fix for each one. Continuous monitoring re-runs it and emails you when something new appears.
Free real-browser scan
See every pre-consent tracker on your site — free, 30 seconds, no signup.
Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.