GA4 Not Showing Data? Every Fix (and Why It Keeps Happening)
You opened GA4 and saw nothing. No visitors, no pageviews, no data. Or worse: real-time shows visitors right now, but yesterday's reports are completely empty.
You are not alone. "GA4 not showing data" is one of the most searched analytics queries on the internet. The causes range from a typo in your measurement ID (fixable in 30 seconds) to architectural decisions in GA4 that permanently delete your data with no recovery option.
This guide covers every scenario. The quick fixes come first. The deeper problems come after.
Check if your tag is actually firing
Before debugging anything else, confirm GA4 is receiving data from your site.
Step 1: View your page source. On your website, press Ctrl+U (Windows) or Cmd+Option+U (Mac). Search for G- to find your measurement ID. If it is not there, your tracking code is missing entirely. Install it via Google Tag Manager, a code snippets plugin like WPCode, or directly in your theme's <head> tag.
Step 2: Check the network requests. Open Chrome DevTools (F12), go to the Network tab, and filter for collect. Reload the page. You should see requests to google-analytics.com/g/collect with status 200 or 204. No requests means the script is blocked or broken. Failed requests point to ad blockers, Content Security Policy headers, or firewall issues.
Step 3: Check GA4 real-time. In GA4, go to Reports > Real-time. Open your website in an incognito window (no extensions) and visit a few pages. Within 60 seconds, you should see yourself in the real-time report. If you do: your tag works. If standard reports are still empty, it is a processing delay (see next section).
Step 4: Verify the measurement ID. Go to Admin > Data Streams, click your web stream, and copy the measurement ID. Compare it character by character with what is in your page source or GTM tag. A single wrong character sends data to a different property. This is one of the most common causes.
Other common causes: GTM changes saved but not published (click Submit > Publish). Internal traffic filter set to "Active" with an overly broad IP range (Admin > Data Filters, switch to Testing). Enhanced Measurement disabled (Admin > Data Streams > toggle it on). WordPress caching plugins minifying or deferring the GA script (exclude gtag.js and googletagmanager.com from JavaScript optimization in WP Rocket, LiteSpeed Cache, or Autoptimize).
The 24-48 hour wait is real
GA4 uses two completely separate data pipelines. Real-time reports show raw events within seconds. Standard reports (Traffic Acquisition, Engagement, Pages) use a batch processing pipeline that takes 24-48 hours to complete.
This is not a bug. Google processes data in batches to run attribution modeling, bot filtering, session stitching, and behavioral modeling for consent mode. A visit that appears in real-time right now will not show up in your Acquisition report until tomorrow or the day after.
Attribution credit for conversions can change for up to 12 days after the event as Google retroactively adjusts its data-driven attribution model. And late-arriving events (from mobile apps or offline scenarios) are accepted within a 72-hour window. Events arriving after 72 hours are ignored and never appear in reports.
There is no way to speed up standard report processing on free GA4. GA4 360 ($50,000+/year) reduces intraday processing to under an hour.
Your consent banner is hiding your visitors
If you have EU traffic and a cookie consent banner, this may be the real reason your numbers look wrong.
GA4 sets cookies (_ga, _ga_<container-id>) on every visitor. Under GDPR, these require explicit opt-in consent before they can be placed. When a visitor denies consent (or ignores the banner), GA4 in Basic Consent Mode collects zero data from that visitor. Not reduced data. Zero.
In Germany and France, fewer than half of visitors consent to tracking cookies. Advanced Consent Mode sends cookieless pings for denied visitors, which feed Google's behavioral modeling. But modeling requires at least 1,000 daily users with consent granted and 1,000 daily events with consent denied, each sustained for 7 consecutive days. Most small-to-medium sites never meet these thresholds.
The most common WordPress scenario is worse: the consent plugin shows a banner but never transmits consent signals to Google tags. The banner looks compliant. The tracking integration does not exist. GA4 sees no consent state and blocks all EEA/UK data collection. After Google's July 2025 enforcement, sites with this misconfiguration lost visibility into most of their European traffic overnight. That missing data is permanently gone.
Ad blockers are hiding the rest
42.7% of internet users run ad-blocking tools. uBlock Origin, Brave, and Ghostery all block GA4 by default. The script either fails to load or its outbound requests are intercepted. The visitor is completely invisible across every GA4 report, including real-time.
The data loss varies by audience:
GA4 provides no warning, no estimate, and no indication in any report that these visitors exist. The data gap is invisible from inside GA4 itself. If your audience skews technical and you are wondering why GA4 numbers feel low, this is likely why.
GA4 is hiding data on purpose
Even when GA4 is working correctly, four separate mechanisms silently reduce what you see.
Thresholding. When Google Signals is enabled (cross-device tracking), GA4 hides rows in reports where user counts fall below approximately 35-50 users. The data exists but GA4 refuses to show it. An orange warning icon appears, but clicking it just says "thresholding applied" with no specifics about what was removed. You can reduce this by switching to device-based reporting identity (Admin > Reporting Identity), but you cannot disable thresholding entirely.
Sampling. When an Exploration query covers more than 10 million events, GA4 analyzes a subset and extrapolates. A yellow shield icon appears showing the sample percentage. At low sample rates, error margins can reach 38%. Standard reports avoid sampling by using pre-aggregated tables, but this means standard reports and Explorations can show different numbers for the same date range.
Cardinality limits. GA4 classifies any dimension with more than 500 unique values per day as "high-cardinality." When reports hit their row limits, the lowest-traffic values are grouped into an "(other)" row. If your site has thousands of unique page URLs, you see the top ones. The rest disappear into "(other)" with no way to query individual values.
Data retention. GA4 defaults to retaining event-level data for 2 months. Most site owners never change this setting. After 2 months, Exploration reports lose their data. Standard aggregated reports survive, but any custom analysis on older data returns empty results. The maximum for free GA4 is 14 months (Admin > Data Retention).
The fixes that actually work
For tag issues, the diagnostic flowchart above covers everything. Fix the measurement ID, publish your GTM container, check your CSP headers, exclude analytics scripts from caching plugin optimization.
For internal traffic filters, go to Admin > Data Filters. If any filter is "Active," verify the IP rules are not too broad. Switch to "Testing" for 48 hours to check.
For thresholding, switch reporting identity to "Device-based." For sampling, narrow your date range or remove secondary dimensions. For data retention, change it to 14 months now (not retroactive).
For consent mode data loss and ad blocker data loss, there is no fix within GA4's architecture. These are not configuration problems. They are consequences of how cookie-based, client-side JavaScript analytics works. The tracking script needs to load in the visitor's browser, set cookies, and send data to Google's servers. When any step in that chain is blocked, the data does not exist.
Or skip all of this
Every problem described in this article comes from the same architecture: a client-side JavaScript snippet that sends data to a third-party server, processes it in batches, requires cookies, depends on consent, and is targeted by every major ad blocker.
Clickport is built differently. One script tag in your HTML. Data flows directly to a ClickHouse database with no batch queue, no processing delay, and no middleman. The Realtime view updates every 30 seconds.
Script sets cookies
Consent check (blocks 50%+ in EU)
Ad blocker check (blocks 15-40%)
Data sent to Google servers
24-48 hour batch processing
Thresholding hides small rows
Sampling estimates large reports
Data available (maybe)
Script runs (no cookies)
No consent needed
First-party script (not ad-blocked)
Data inserted directly to ClickHouse
Available in next 30-second refresh
No thresholding, ever
No sampling, ever
Data available (always)
No cookies means no consent banner. No consent banner means no EU data loss from cookie rejection. No Google dependency means no "(not set)," no "(other)," no 14-month retention limit. Clickport retains data forever. It never samples. It never hides rows behind thresholding. Every number in the dashboard is real, observed data.
It tracks scroll depth, clicks, form submissions, file downloads, outbound links, 404 errors, internal search terms, and copy detection automatically. It has session-level drill-down, goal tracking with revenue attribution, cross-filtering, a world map, annotations, PDF reports, and CSV exports. It classifies traffic into 16 channels including AI Search.
The entire setup takes under 2 minutes: paste one script tag, open the dashboard, see your data.
Start your free 30-day trial. No credit card required.
Comments
Loading comments...
Leave a comment