You set up the new GA4 property, watched yourself show up in Realtime, and called it done. Next morning every report says "no data available." I get this exact panic message from store owners constantly, and most of the time nothing is broken. But sometimes it is. Here's how to tell the difference.
- Open Realtime and browse the site — Appearing within a minute means collection is healthy and you're waiting on processing
- Compare the measurement ID — The G-XXXXXXX in your tag against Admin > Data streams. Old test properties are common.
- Check the tag fired and shipped — GTM Preview's Tags Not Fired list, and confirm the container version is published
- Retest in incognito, extensions off — uBlock Origin and Brave shields block google-analytics.com on your own machine too
- Check consent and data filters — analytics_storage stuck denied, or an internal or developer filter left Active
- Set the range to yesterday — Today is incomplete by definition, and a new property needs a full 48 hours
Is data actually arriving in GA4 at all?
First question: are events reaching Google's servers? Open Reports → Realtime and browse your site in a second tab. If you appear within a minute, data is arriving and your problem is almost certainly processing lag, not a broken tag. For a sharper view, open DebugView with GTM Preview on (or debug_mode: true on the tag) to watch events stream in with their parameters.
If neither panel shows anything, work through these four in order:
- Measurement ID mismatch. The
G-XXXXXXXID in your tag has to match the property you're staring at. Compare it against Admin → Data streams. I've seen sites happily sending data to an old test property for months. - The tag isn't firing. If GTM Preview shows the GA4 tag under "Tags Not Fired," the trigger is wrong or the tag is paused. And confirm the container version is actually published, not just saved.
- Consent defaults are denying everything. With Consent Mode v2, if your defaults set
analytics_storagetodeniedand the banner never sends the update on accept, GA4 gets cookieless pings at best. Accept the banner and check whether consent flips in GTM Preview's Consent tab. - An ad blocker in your own browser. Embarrassing and common. uBlock Origin, Brave shields, and most privacy extensions block
google-analytics.comoutright, so you test your own site, see nothing, and conclude a working install is broken. Retest in incognito, extensions off.
Why is Realtime working but my standard reports are empty?
Because standard reports run on processed data, and processing takes 24–48 hours. That's not a bug. It's how GA4 works, and it's far and away the number-one thing people panic over that isn't a problem. Realtime reads a near-live stream; reports read a pipeline that aggregates, applies filters, and attaches attribution first. A property created yesterday showing empty reports today is behaving as designed.
The second half of this trap is the date range. Today's data in standard reports is incomplete by definition, so a report scoped to "Today" can look empty even after processing starts. Set the range to yesterday before you judge anything.
Why do my custom dimensions show "(not set)"?
Because sending a parameter and registering it are two different steps, and GA4 only reports on registered ones. Your event can carry membership_tier on every hit, and DebugView will proudly show it, but until you register it under Admin → Custom definitions, reports show "(not set)" or nothing at all.
The part that stings: registration is not retroactive. GA4 populates the dimension from the moment you register it and never backfills earlier events (BigQuery is your only way back). Register custom dimensions the same day you create the property.
Could filters or thresholding be hiding my data?
Yes, and this is where "empty reports" turns from a waiting problem into a config problem. Two things silently remove rows from GA4 reports:
The internal traffic filter — the office IP trap. GA4 lets you mark internal traffic by IP and filter it out. Useful, until the "internal" range covers the office network your whole team browses from, or the egress IP of a shared VPN. I've audited both. Everyone testing the site was invisible, so every check said "GA4 shows nothing." Look under Admin → Data settings → Data filters, including for a developer-traffic filter left active after the build. Active filters drop data permanently. No undo, no backfill.
Data thresholding. When Google signals is enabled, GA4 withholds rows with low user counts so individuals can't be identified. Small sites and tightly segmented reports get hit hardest: the data exists, but the row is suppressed. The data-quality icon at the top of the report will say thresholding is applied. Check that icon before assuming loss.
| Realtime | DebugView | Standard reports |
|---|---|---|
| Near-live stream, last 30 minutes | Only devices flagged debug_mode | Processed data, after filters |
| Latency: seconds | Latency: seconds | Latency: 24-48 hours |
| Proves hits reach Google at all | Proves names and parameters are right | Proves the whole pipeline works |
| Full here, empty reports = wait | Your device, not your customers' | Empty on day one is normal |
What does each GA4 panel actually prove?
Each panel reads a different pipeline with different latency, so each proves something different:
| Panel | What it reads | Latency | What it proves |
|---|---|---|---|
| Realtime | Near-live stream, last 30 minutes | Seconds to a minute | Hits are reaching Google at all |
| DebugView | Only events flagged with debug_mode, per device | Seconds | Your event names and parameters are structured right |
| Standard reports | Processed data, after filters and attribution | 24–48 hours | The full pipeline works end to end |
| Explorations | Processed data, limited by your retention window | 24–48 hours | Same as reports, but only as far back as retention allows |
Realtime full but reports empty means wait, or check filters and date range. Empty everywhere means collection is broken.
Why is only part of my data missing?
Partial gaps have three usual causes, worth separating from a fully dead setup.
Consent mode without modeling eligibility. Visitors who decline your banner send cookieless pings instead of full hits. GA4 can fill that gap with behavioral modeling, but only when the property qualifies — Google's documented bar is roughly 1,000 daily events with analytics_storage denied, sustained for at least seven days. Below that, declined users just aren't in your reports. A site with a 40% decline rate looks like it lost 40% of its traffic. It didn't. It lost consent, plus eligibility.
Region controls. GA4 can switch off granular data collection per region. If someone toggled these for EEA countries, European traffic thins out while everything else looks normal.
Data retention chopping explorations. Event data retention defaults to two months. Standard reports don't care, since they run on pre-aggregated tables, but explorations query event-level data and go blank past the retention window. Flip it to 14 months under Admin → Data settings → Data retention. Like custom dimensions, it isn't retroactive.
When is it genuinely broken, and when should you just wait?
It's genuinely broken when a clean-browser test puts nothing in Realtime. Fix collection first: measurement ID, tag firing, published container, consent update. Nothing downstream matters until Realtime moves.
Wait when Realtime works and the property is under 48 hours old. Seriously, just wait.
Investigate config when data flowed and then stopped, or when specific slices are missing. Sudden stops usually trace to a freshly published GTM container, a broken consent update, or a redesign that dropped the snippet. Missing slices trace to filters, thresholding, region controls, or retention.
Will first-party server-side tracking stop this from happening again?
It fixes the collection half of the problem, the half you can't get back later. Plain-language version, since most store owners have never heard the term: right now the visitor's browser sends events straight to google-analytics.com. With server-side tracking, the browser sends events to a subdomain you own, like track.yourstore.com, where a server container built on Google Tag Manager receives them and forwards clean copies to GA4, Meta, or wherever else.
Remember the ad-blocker test from step one, where your own browser was silently blocking GA4? That same blocker-shaped hole sits in your production data every day. Blockers and privacy browsers kill requests to Google's domains on your real customers too, and those sessions never reach Realtime or reports. Requests to your own subdomain don't match the blocklists the same way, so traffic GA4 never saw starts arriving. First-party cookies set server-side also outlive Safari's ITP limits, so returning visitors stop counting as "new" every week. And one server pipeline feeding GA4 and your ad platforms means consistent numbers and proper deduplication instead of three tags failing differently.
Processing lag still exists; that's on Google's side. But every "is data even arriving?" failure mode above shrinks dramatically once collection runs through infrastructure you control.
Frequently asked questions
How long does it take for GA4 to show data?
Realtime shows activity within about a minute. Standard reports take 24–48 hours, longer for brand-new properties. If Realtime works, the install is fine.
Why does GA4 Realtime show users but reports show nothing?
Realtime reads a near-live stream; standard reports read processed data with a 24–48 hour lag. Past two days, check date ranges, data filters, and consent settings.
Why does my GA4 custom dimension show "(not set)"?
The parameter is arriving but was never registered under Admin → Custom definitions, or was registered after the events came in. Registration isn't retroactive; only events collected afterward populate it.
Can an ad blocker stop GA4 from tracking?
Yes. Most ad blockers and privacy browsers block requests to google-analytics.com, so those sessions never reach GA4 at all. Serving tracking from your own subdomain via a server-side setup recovers much of that traffic.
What does "data threshold applied" mean in GA4?
GA4 is withholding low-volume rows to avoid identifying individual users, mainly when Google signals is enabled. The data was collected; it's just hidden in that view.
Can I recover data GA4 never collected?
No. Data dropped by an active filter, a broken tag, or a blocked request is gone permanently. GA4 has no backfill, which is why fixing collection matters more than any reporting setting.
Why did my GA4 data suddenly stop after working fine?
Usually a newly published GTM container, a cookie-banner update that broke the consent signal, or a site change that removed the snippet. Check Realtime to confirm collection actually stopped.
- ga4
- debugging
- fix it

