My GA4 tag is installed but I am seeing no data

By Idea to Traffic Editorial Team · Published September 27, 2026 · Last updated September 27, 2026

A tag on every page and an empty Realtime report

A GA4 property and web stream for ideatotraffic.com were created on 2026-09-07 with measurement ID G-6BMJJ9F9ZV. The tag went into the site's shared head template, the build shipped, and the GA4 reports showed nothing. No sessions, no pageviews, no users. The obvious conclusion is that the tag is broken. It was not broken, and the process of establishing that is the whole point of this guide.

The reason the empty report proved nothing is arithmetic. ideatotraffic.com recorded 4 pageviews from 5 sessions in the seven days to 2026-09-27. A working tag on a site with almost no traffic produces a report that is visually identical to a broken tag on a site with plenty. Both show zero. The report cannot tell you which situation you are in, so reading harder does not help.

We resolved it by verifying the tag end to end against the GA4 Realtime report rather than confirming the snippet was present in the page HTML. Those are different claims. The snippet being in the source proves the file was deployed. Only a hit arriving in Realtime proves the script loaded, executed and reached Google's collection endpoint.

Four causes, and the likeliest is no visitors yet

Four causes produce an empty GA4 report, and they are not equally likely on a new site.

The first is that there is genuinely nobody there. On a domain a few weeks old this is the default explanation and the one people skip. Four pageviews in a week is not a reporting failure.

The second is processing delay. Standard GA4 reports can lag by many hours. An empty standard report on the day you install a tag is expected behaviour and carries no information either way. Realtime is the only view with no processing delay, which makes it the only view usable as a test instrument.

The third is the wrong identifier in the tag. Three IDs get confused constantly, and putting the wrong one in the page produces silence rather than an error message:

A publisher ID pasted where a measurement ID belongs does not throw a visible error. The page loads, the script runs, and the hits go nowhere useful. Nothing on screen tells you, which is why the failure survives casual inspection.

The fourth is your own browser. Ad blockers and privacy browsers block the GA4 script outright. Testing a tag from a browser with an ad blocker running produces an empty Realtime report on a perfectly good tag, and it produces it instantly and convincingly.

Watch your own visit arrive

The reliable method takes two minutes and needs two windows. Open the site in one browser and watch the GA4 Realtime report in another. Realtime has no processing delay, so a working tag shows your own visit within seconds. If it appears, the tag works and the empty standard report is either lag or an absence of visitors. If it does not appear, you have a real problem and can start narrowing it.

Two conditions make that test meaningful. Use a browser with no ad blocker and no tracking protection, otherwise you are testing your blocker. And load a real page on the live domain, because a local preview may carry a different head template.

Before that, confirm the snippet is actually in the served HTML and carries the right ID:

curl -s https://ideatotraffic.com/ | grep -o 'G-[A-Z0-9]*' | sort -u
curl -s https://ideatotraffic.com/guides/ | grep -c 'gtag/js'

The first command should print your measurement ID and nothing else. If it prints a second, different ID, you have two tags and a reporting mess. If it prints nothing, the deploy did not include the tag. The second command should return a non zero count on every page you check, not only the homepage.

If the snippet is present with the right ID and Realtime still shows nothing from a clean browser, check the network request itself in browser developer tools. A collection request to Google's endpoint that returns a response confirms the hit left the page. A request that never appears points at a blocker, a content security policy or a script error earlier in the page that stopped execution before the tag ran.

One tag in one shared template

1. Put the tag in a shared head template in the site build, not on individual pages. Ours lives in one template, so it cannot drift page to page and every page carries it by construction. A tag pasted per page will drift, and the drift shows up as pages that silently report nothing.
2. Confirm which identifier you are holding before you paste it. A measurement ID of the form G-XXXXXXX goes in the page. A numeric property ID goes to the reporting API. A ca-pub- value belongs to AdSense and never appears in a GA4 tag.
3. Deploy, then curl the served HTML on at least three different pages and confirm the same single measurement ID appears on each. This catches a template that did not rebuild and a page type that bypasses the shared head.
4. Open GA4 Realtime in one browser. In a second browser with no ad blocker, load the live site and click through two or three pages.
5. Watch for your visit in Realtime. Confirmed there, the tag is verified end to end and you never have to relitigate it.
6. Only after that, look at standard reports, and give them a full day before reading anything into them. An empty standard report on install day is not evidence.
7. Record the measured traffic alongside the verification so the next empty report is interpretable. Ours reads 4 pageviews from 5 sessions in the seven days to 2026-09-27, against a stream created 2026-09-07. Track your own equivalent: .

Check Realtime before you call it installed

Verify against Realtime as part of the install, not as a later debugging exercise. A tag is not installed when the snippet is committed. It is installed when a hit has been observed arriving.

Keep one tag in one template and treat any per page analytics snippet as a defect. The whole class of "it works on some pages" failures disappears when there is only one place the tag can live.

Keep a browser profile with no extensions for testing anything an ad blocker touches, meaning analytics, ad tags and much embedded content.

Write the three IDs down once where your deploy configuration lives, each labelled with what consumes it. The confusion between them is a labelling gap rather than a knowledge gap, and labelling fixes it permanently.

An accurate count is not more traffic

A verified tag does not produce traffic. It produces an accurate count of a small number, and on a new site the accurate number is small. Verification changes what you know, not what you have.

It also does not recover data from before the tag fired. GA4 has no backfill. Whatever happened between the site going live and the tag being verified is gone, which is a reason to verify on launch day rather than a month later.

Realtime confirmation says nothing about visitors who block the script. Those sessions are absent by design, so GA4 is a floor on your traffic rather than a census, and edge request logs will never match it.

A working tag also validates nothing downstream of collection. Conversion definitions, audience configuration and any link to another Google product are separate settings with their own failure modes.

Questions about an empty GA4 report