Skip to main content
How-To6 min read

GA4 installed but showing zero visitors? Read one URL parameter

A content site we run spent more than two months with Google Analytics telling us "No data received from your website yet." That message reads as a diagnosis: the tag is missing, or broken. Ours was neither. The GA4 snippet was installed correctly and firing on every page load, and I could prove that in a browser in under a minute.

The fix ended up being a handful of lines in a consent configuration, but finding it meant ignoring every green checkmark GA4 offers and going straight to the request the tag itself sends to Google. Here is exactly what I found, in the order I found it.

The healthy 204 that hid the real problem

Here is the check I now run first whenever a GA4 property looks empty, and it takes about a minute. Open the site in a private browser window, so there is no stored consent cookie left over from an earlier visit skewing the result. Open DevTools, switch to the Network tab, and filter for "collect". Load any page. You will see a request to google-analytics.com/g/collect come back with a 204 status, which normally reads as "request succeeded, nothing more to say." Click that request and read the gcs= parameter in the query string.

On our site it read gcs=G100. That single parameter told me more than every check GA4's own interface had run for two months, all of which said healthy.

What gcs=G100 actually means

gcs=G100 marks a cookieless, consent-denied ping. Google accepts these requests, which is why the network tab shows a clean 204 and every standard health check passes. But a ping carrying that flag never shows up in standard GA4 reports. The tag is fine, the network call is fine, and the data is thrown away by design, because the visitor is being tracked in a mode that explicitly tells Google not to attribute anything to them. A real, reportable hit carries gcs=G111instead. Same request shape, same 204, completely different fate once it reaches Google's side.

Why a small site never notices the gap

Google can partially paper over consent-denied traffic with behavioral modeling, filling in estimated numbers based on the visitors who did consent. That modeling only switches on once a property sustains roughly 1,000 consented events a day for seven days straight. A small or mid-size content site rarely gets there, so instead of a modeled estimate you get nothing. No error, no warning banner inside GA4, just a permanently empty report that looks exactly like a site with no traffic at all.

The root cause: a global deny-by-default

Working backward from gcs=G100, the cause turned out to be Consent Mode v2, configured to deny analytics storage by default for every visitor on the site, worldwide, regardless of where they were browsing from. It had been added while wiring up a cookie consent banner during ad-network compliance work, which is exactly the moment this mistake tends to sneak in. Someone reasonably decides to default to denied until the visitor agrees, ships it as one global setting, and never revisits it once the banner itself looks like it works. The banner rendered correctly. The site looked compliant. It was also throwing away nearly all of its own analytics.

The fix: region-scope the defaults instead of denying everyone

The fix is not to remove the deny-by-default behavior, it is to scope it to the regions that actually require opt-in consent. That means two consecutive gtag('consent', 'default', ...) calls instead of one. The first call sets consent to granted with no region specified, which becomes the worldwide default. The second call sets consent to denied, scoped to a region array covering the EEA countries, the UK, and a handful of others where opt-in consent is a legal requirement.

Two details bit us here and are easy to get wrong. First, the ISO code for the United Kingdom is GB, not UK. Write it wrong and your rule meant to deny by default in the UK silently does nothing. Second, when two consent defaults overlap, the more specific region declaration wins, regardless of which call appears first or second in your code. You do not need to order the two calls a particular way, you need to make sure the region arrays themselves are correct.

The banner also has to actually revoke consent

One change people forget once the worldwide default flips to granted: the banner's Decline button has to do real work again. Before this fix, denying by default meant clicking Decline changed nothing, because everyone was already denied. After the fix, a visitor outside the opt-in regions starts out granted, so Decline now needs to fire a gtag('consent', 'update', ...) call that actively revokes it. Skip that step and the consent banner becomes decorative for most of the world.

A word on the legal side, stated carefully

This is analytics configuration, not legal advice, so treat it as a starting point rather than a ruling. In Malaysia, the PDPA does not require opt-in consent for analytics cookies, which means a global EU-style deny-by-default on a Malaysian site was discarding data that no law required us to discard. If your audience is meaningfully European or UK based, keep their default denied exactly as it was. This fix restores measurement for the rest of the world, it does not loosen anything for the regions that actually require opt-in consent. If your traffic mix leans European, talk to someone qualified before changing any of this.

What we verified after shipping

After deploying the region-scoped defaults, I opened the site again in a fresh private window with no stored consent, loaded a page, and checked the same Network tab filter. The first request came back as gcs=G111, the banner still rendered normally, and the console showed zero errors. Reports began populating shortly after. The whole fix was a handful of lines in a consent configuration, and the two months of missing data before it were never a GA4 problem at all.

The bottom line

If your GA4 property says "no data" but every installation checklist says the tag is fine, stop trusting the checklist and go read gcs= on the actual collect request. It is the one signal that tells you whether Google is throwing your traffic away on purpose. If you want a second pair of eyes on your own consent setup, or you are not sure whether your banner is quietly costing you your own analytics, send me a brief and I will walk through it with you.

More questions?

Easier on a call than in a blog post.

Replying within 4 hours during working hours