← Back to Blog

You Set Up GA4 and Got Less Data Than Before — You’re Not Imagining It

GA4 typically counts 10–20% fewer sessions than Universal Analytics due to different session definitions, stricter bot filtering, and privacy-driven thresholding. But the gap doesn’t stop there. Ad blockers strip another 20–30% of visitors before GA4’s JavaScript even fires. Consent rejection removes another 15–55% in regulated markets. And GA4’s own thresholding hides entire report rows when audience sizes are small. The result is that many WooCommerce stores see 30–50% less data in GA4 than they saw in Universal Analytics — and it’s not a bug. The proven workaround is BigQuery export for unsampled data and server-side tracking for the visitors GA4 never sees.

The Session Counting Changed — That’s the First 10–20%

GA4 measures sessions differently than Universal Analytics — and the new rules consistently produce lower numbers.

If you migrated from Universal Analytics to GA4 and immediately noticed lower traffic numbers, you weren’t looking at a broken installation. You were looking at a different counting system that genuinely reports fewer sessions for the same website traffic.

GA4 typically counts 10–20% fewer sessions than Universal Analytics, according to industry benchmarks. The range varies by site, but the direction is consistent — GA4 numbers are lower. Three structural changes drive the gap.

First, Universal Analytics started a new session at midnight. A visitor browsing your store at 11:58 PM and still browsing at 12:02 AM counted as two sessions in UA. GA4 counts it as one. Second, UA started a new session whenever campaign parameters changed mid-visit — clicking from an email link to a Google ad within 30 minutes created two sessions. GA4 keeps the original session running. Third, GA4 automatically filters bot traffic that UA only excluded when you manually checked a box most people never found.

GA4 typically counts 10–20% fewer sessions than Universal Analytics due to stricter session definitions, automatic bot filtering, and event-based measurement that doesn’t restart sessions at midnight.

Each of these changes individually makes GA4’s count more accurate. A visitor browsing across midnight isn’t two people. A user clicking two ads in one sitting isn’t two visits. Bot traffic isn’t real traffic. The problem isn’t that GA4 is wrong — it’s that your year-over-year comparisons are comparing two different measurement systems, and nobody warned you the baseline would shift.

You may be interested in: Your Smart Bidding Is Training on Biased Data — Safari Made Sure of It

Thresholding Hides Data You Already Collected

GA4 collected the data and then decided not to show it to you — that’s thresholding, and it’s by design.

The session counting gap is visible and explainable. Thresholding is neither. It happens silently inside GA4’s reporting interface, hiding entire rows from your reports without telling you how much data is missing or why.

GA4’s thresholding is a privacy mechanism. When the number of users in a report segment is small enough that individual behaviour might be identifiable, GA4 blanks the row entirely. You don’t get an estimate. You don’t get a warning with a number. You get nothing — a gap in your report where data should be.

Google Signals is the most common trigger. When you enable Google Signals to see demographic and cross-device data, GA4 starts applying thresholds to any report that combines Signals data with small audience sizes. The catch: thresholding can persist even after you disable Google Signals, according to OptimizeSmart’s 2026 analysis. The privacy flag stays active in historical data.

GA4 applies data thresholding that hides entire report rows when user counts are too small — you get blanks, not estimates, with no warning about how much data is missing.

For WooCommerce stores with moderate traffic, thresholding hits harder than expected. Your top-level traffic report might look fine, but drill into a specific campaign, a specific product category, or a specific geographic region and the data disappears. The smaller the slice, the more likely thresholding removes it — which means the detailed analysis that actually drives decisions is exactly where GA4 gives you the least data.

On top of thresholding, GA4 applies sampling to Exploration reports when queries exceed 10 million events. The GA4 UI also caps Explorations at 100,000 rows per report. And GA4’s 14-month retention limit means historical data in Explorations expires — a WooCommerce store looking at last year’s Black Friday in Explorations has exactly one year-over-year comparison before the data vanishes.

Before thresholding can hide your data, ad blockers and consent banners prevent GA4 from collecting it.

Everything we’ve discussed so far happens to data GA4 has already collected. Ad blockers and consent rejection operate upstream — they prevent the data from reaching GA4 at all.

An estimated 1.77 billion internet users now use ad blockers, according to Backlinko’s analysis of GWI data. That’s roughly 29.5% of all internet users. Tools like uBlock Origin, Brave Shields, and DuckDuckGo block google-analytics.com by default. When a visitor runs one of these tools, GA4’s JavaScript tag never fires. No page view, no event, no session. That visitor doesn’t exist in your reports.

Ad blockers affect roughly 30% of web sessions globally, and tools like uBlock Origin block google-analytics.com by default — meaning GA4 never sees those visitors at all.

Consent rejection compounds the loss. In European markets, consent banner denial rates range from 15–55% depending on banner design and region, according to Clickport’s data loss analysis drawing on Didomi’s 2026 benchmark data. Google’s own Consent Mode v2 promises to model the denied traffic, but it requires at least 1,000 denied and 1,000 granted events per day for seven consecutive days before modelling activates — a threshold most small WooCommerce stores don’t reach.

Safari’s Intelligent Tracking Prevention adds another layer. It caps first-party cookies at seven days, which means returning visitors who come back after a week are counted as entirely new users. Your customer retention metrics, your returning visitor segments, your attribution windows longer than seven days — all of them are systematically wrong for every Safari visitor.

You may be interested in: Google Made Your CMP the Single Point of Failure for WooCommerce Conversions

The Cumulative Gap: Where Your Data Actually Went

Each data loss layer operates independently — and they stack.

Here’s where it gets uncomfortable. These aren’t alternative explanations for the same missing data. They’re independent layers that compound on top of each other.

Data Loss Layer What Happens Approximate Impact
Session counting changes GA4 counts fewer sessions than UA for the same traffic 10–20% fewer sessions
Ad blockers GA4 JavaScript never fires for blocked visitors 20–30% of visitors invisible
Consent rejection Visitors who deny cookies are not tracked 15–55% in regulated markets
Safari ITP Cookies capped at 7 days — returning visitors counted as new Inflated new-user count, broken attribution
Thresholding Small-audience rows hidden from reports Variable — worst in detailed breakdowns
Sampling Explorations estimated above 10M events Accuracy degrades with data volume

The cumulative effect is that many WooCommerce stores are making business decisions based on a data set that represents 50–70% of actual visitor activity. The missing 30–50% isn’t random noise. It’s systematically biased — privacy-conscious visitors, mobile users, returning customers, and small-segment behaviour are disproportionately underrepresented.

The combination of session counting changes, thresholding, ad blocking, and consent rejection means many stores see 30–50% less data in GA4 than they recorded in Universal Analytics.

Translation: you’re not imagining it. The data genuinely went somewhere. But it didn’t disappear — it was blocked, denied, hidden, or counted differently. And every one of those gaps has a fix.

BigQuery Export: The Free Fix Most Teams Never Enable

GA4 gives you a free path to unsampled, unthresholded data — and most WooCommerce stores don’t know it exists.

BigQuery export is the single most underused feature in GA4. It streams every raw event from your GA4 property into a Google Cloud data warehouse — unsampled, uncapped by the 14-month retention limit, and free to enable for standard GA4 properties.

BigQuery export gives standard GA4 properties free access to every raw event, unsampled and uncapped by the 14-month UI retention limit — but most teams never turn it on.

What BigQuery export fixes: it eliminates sampling, bypasses thresholding, removes the 100,000-row report cap, and keeps your data indefinitely. Every event GA4 collects lands in BigQuery as a raw row you can query with SQL. No estimates, no hidden rows, no data expiration.

What BigQuery export doesn’t fix: ad blockers, consent rejection, and Safari ITP. If GA4 never collected the event, BigQuery can’t export what doesn’t exist. BigQuery gives you the complete version of what GA4 captured — but it can’t give you what GA4 never saw.

The setup is a one-time link in GA4’s admin panel under Product Links. There’s no backfill — export starts from the day you enable it. If you haven’t enabled BigQuery export yet, every day you wait is a day of raw event data you’ll never get back. For WooCommerce stores hitting GA4’s free-tier limit of approximately 1 million events per day, the export pauses entirely and creates permanent data gaps.

Server-Side Tracking: Capturing What GA4 Cannot

BigQuery fixes the reporting layer. Server-side tracking fixes the collection layer.

The data that ad blockers, consent rejection, and Safari ITP strip away never reaches GA4 — so no amount of BigQuery querying can recover it. To capture that missing 20–40%, you need to collect data before the browser has a chance to block it.

Server-side tracking captures visitor interactions at the HTTP level — at the server, before the page renders in the browser. Ad blockers can’t block a server-side request because it doesn’t run in the browser. Cookie restrictions can’t strip a server-side identifier because it’s not a browser cookie. The data that GA4’s client-side tag loses, a server-side implementation captures.

The architecture combines both approaches. BigQuery export gives you the full, unsampled version of everything GA4 collects. Server-side tracking gives you the events GA4 never sees. Together, they close the gap between the 50–70% you’re currently working with and the near-complete picture enterprise teams take for granted.

Transmute Engine™ handles both — capturing server-side events from WooCommerce stores and routing them directly to BigQuery, bypassing GA4’s collection limitations and reporting restrictions entirely.

Key Takeaways

  • GA4’s lower numbers are real, not a bug: Session counting changes, automatic bot filtering, and event-based measurement account for 10–20% fewer sessions compared to Universal Analytics.
  • Thresholding silently hides collected data: GA4 blanks entire report rows when audience sizes are small — the data exists but the interface won’t show it, especially in detailed breakdowns.
  • Ad blockers and consent remove data before collection: Roughly 30% of visitors run ad blockers that prevent GA4 from firing, and consent denial rates add another 15–55% loss in regulated markets.
  • BigQuery export fixes the reporting gap for free: Enable it once in GA4 admin to get every raw event, unsampled and without retention limits — but it can’t recover data GA4 never collected.
  • Server-side tracking fixes the collection gap: It captures visitor data at the HTTP level before browsers can block it, recovering the 20–40% that client-side GA4 misses entirely.
Why does GA4 show less data than Universal Analytics did?

GA4 counts sessions differently — it doesn’t restart sessions at midnight or when campaign parameters change mid-visit. It also filters bot traffic automatically, which UA only did when manually configured. These changes alone account for 10–20% fewer sessions. On top of that, GA4’s thresholding hides report rows for privacy, and ad blockers prevent GA4’s JavaScript from firing for roughly 30% of visitors.

What is GA4 data thresholding?

Thresholding is GA4’s privacy mechanism that hides entire rows from reports when user counts are too small to safely display without risking individual identification. It’s triggered by Google Signals and demographic data. Unlike sampling, thresholding gives you blanks rather than estimates — the data exists but GA4 won’t show it to you in the interface.

How do I get unsampled GA4 data?

Enable the BigQuery export in GA4’s admin settings under Product Links. This streams every raw event into a BigQuery dataset — unsampled, with no row limits, and free for standard GA4 properties. You can then query the full dataset with SQL instead of relying on GA4’s sampled interface reports.

Should I connect GA4 to BigQuery for my WooCommerce store?

Yes. BigQuery export eliminates sampling, bypasses thresholding, removes the 14-month retention limit, and lets you join analytics data with CRM, ad spend, and order data. For WooCommerce stores making decisions based on GA4 reports, BigQuery is the difference between working with partial data and working with complete data.

References

Ready to see the data GA4 is hiding? Discover how Seresa closes the collection and reporting gap for WooCommerce stores.