GA4 Not Receiving Data: 9 Reasons and Check Order

3. Reason: Cookie Consent and Consent Mode v2 Not Counting Visitors Who Don’t Consent

If the cookie banner initializes analytics_storage consent as “denied” by default, GA4 does not perform cookie-based measurement for visitors who don’t consent; this is not a bug but the expected result of the consent mechanism. Google’s Consent Mode developer guide requires the default consent to be set on every page before commands that send measurement data, and states that defaults won’t work if commands are called in the wrong order. Consent Mode v2 added ad_user_data and ad_personalization parameters alongside ad_storage and analytics_storage.

The implementation type changes the outcome. According to Google’s GA4 Consent Mode page, there are two paths:

• Basic implementation: Google tags are blocked until consent is given; no data comes from visitors who don’t consent, and no modeled data fills the gaps.
• Advanced implementation: Tags load before the consent prompt; if consent is denied, a cookieless ping is sent and GA4 uses these pings for modeling.

Modeling does not activate on every site. Google’s behavioral modeling page requires the property to collect at least 1,000 events per day with analytics_storage=’denied’ for at least 7 days, and to have at least 1,000 daily users who consented in at least 7 of the previous 28 days; meeting these thresholds alone does not guarantee eligibility. On small sites with daily visitors below this level, the gap from visitors who reject remains as a blank in the report.

When a cookie banner is installed as a legal requirement, part of the drop in GA4 is permanent; hiding the reject option or setting the default to “granted” is not a solution. To see the real volume, compare with organic clicks in Search Console, because Search Console data comes from Search Console’s own records, not from the tag on the site. The same consent issue’s impact on the Meta side is covered in the Meta pixel not working article.

4. Reason: Report Delay; Present in Real-Time, Absent in Standard Reports

A visit visible in the real-time report but missing from standard reports is usually due to processing time. Google’s data freshness page gives typical times for standard properties as follows:

The same page also states that data processing can take 24–48 hours and that report numbers may change during this period. When today’s and yesterday’s numbers look incomplete, waiting two days before deciding reduces false alarms. If GA4 shows no data and the real-time report is also empty, delay is not the explanation; the issue is on the tag or blocking side.

5. Reason: Internal Traffic or Developer Traffic Filter Incorrectly Active

An active data filter permanently excludes matching events; an incorrectly defined IP rule can remove real visitors from reports as well. According to Google’s internal traffic filter page, the rule is created under Data stream > Configure tag settings > Define internal traffic; the filter itself is under Data collection and modification > Data filters. The filter has three states: Testing, Active, and Inactive.

Symptom: Traffic drops after the filter’s activation date. If a broad IP range was written, the excluded audience may be larger than expected. Check: The filter is first set to Testing; Google states that matches in this state are marked with the “Test data filter name” dimension so the effect can be seen in explorations.

Fix: The rule is narrowed. According to Google, an active filter’s effect is permanent, excluded data is never processed, and historical data is untouched; filter application can take 24–36 hours. The developer traffic filter excludes events in debug mode. If the debug_mode parameter is accidentally left on for all users on the live site and this filter is active, normal visits can also get caught; Google writes that setting the value to false is not enough to turn off debug_mode, the parameter must be removed.

6. Reason: Cache and JavaScript Defer Plugins Holding Back the Tag

JavaScript defer, combine, or minify settings in performance plugins can delay the GA4 tag until the visitor’s first interaction, or break the code’s execution; a visitor who leaves without interacting is then not counted at all. Google wants the Google tag immediately after the opening <head> tag, and the GTM code as high as possible in <head>. The defer setting effectively changes this order.

A typical sign of this issue is that the drop coincides with a plugin update or settings change. The check is done in this order:

1. The page is opened in an incognito window; the Network tab shows whether the collect request fires on page load or only after the first scroll or click.
2. If the request waits for interaction, googletagmanager.com and gtag phrases are added as exceptions to the cache plugin’s defer setting.
3. The plugin, server, and CDN cache (if any) are cleared; the test is repeated and the request is confirmed to fire at load time.

Old HTML in the cache can continue serving the old tag even after the ID is changed; a test taken without clearing the cache gives a misleading result.

7. Reason: Content Security Policy (CSP) Blocking Google Domains

The server or a security plugin sends a Content-Security-Policy header that does not include Google’s domains, so the browser blocks the tag or the measurement request. The symptom appears in the browser console: a content security policy violation error mentioning googletagmanager.com or google-analytics.com appears, and the collect request shows as blocked in the Network tab.

Google’s CSP guide lists the following for a GA4 setup without advertising features: add https://www.googletagmanager.com to script-src-elem, add https://www.googletagmanager.com and https://*.google-analytics.com to img-src, and add those plus https://*.google.com to connect-src. If advertising features are on, the list expands and Google’s country-specific domains must be written one by one, because CSP does not allow wildcards on the right side of the domain.

Fix: The header is edited. On WordPress sites, this header can come from a security plugin, server configuration, or .htaccess file. After the change, it is verified that the console error is gone and the collect request returns 200.

8. Reason: GA4 Event Not Showing; GTM Not Published or Key Event Waiting

When pageviews arrive but a specific event like form submission doesn’t appear, it’s usually due to a missing GTM publish or the reporting latency. In GTM, changes to tags, triggers, and variables stay in the workspace; according to Google’s container publishing page, the Submit button in the top right must be pressed, followed by Publish, for changes to take effect on the site. A tag working in Preview but not live suggests this step was skipped. GTM’s basic structure is explained in the What Is Google Tag Manager article.

The second check is timing. Google writes that data for an event appears in the Events report within 24 hours after it fires. When an event is marked as a key event, it can take 24 hours to reflect in standard reports, while real-time reports update within a few minutes. Marking is done in Admin > Data display > Events by clicking the star next to the event, and it does not change historical data.

An event that has never arrived can also be pre-marked as a key event; the limit in standard properties is 30 events. If a key event is being sent to Google Ads but shows zero in Ads, a separate chain applies: that scenario is covered in the Google Ads not recording conversions guide, and a from-scratch setup in the conversion tracking setup article.

9. Reason: Ad Blockers and Browser Protections

Ad blockers and privacy extensions can stop the GA4 script from running; this loss appears in a portion of traffic, not all of it. Google’s developer troubleshooting guide notes that some browser extensions can block Google Analytics scripts and recommends testing in an incognito window with extensions off or in a different browser. Browsers with built-in tracking protection can cause similar loss; Google has not published a specific rate for this loss.

A typical symptom: the tester’s own browser shows an empty real-time report, but the same visit appears in another browser without extensions. This reason does not produce zero data site-wide; if traffic is completely zero, the problem is almost certainly one of the first seven reasons.

What Does It Mean If GA4 Dropped but Search Console Clicks Are Rising?

If organic traffic in GA4 drops while Search Console clicks stay flat or rise, the drop is most likely a measurement change, not a real visitor loss. The two tools get data from different places: Search Console records clicks in search results on its own side, while GA4 relies on events sent by the tag running on the site. When the tag, consent setting, or filter changes, only GA4 is affected.

• GA4 dropped, Search Console rose or flat: Measurement changed. Look for a cookie banner added on that date, duplicate tag removed, filter activated, or plugin update.
• Both dropped together: High probability of real visibility loss; check indexing, rankings, and technical issues. First checkpoint is the pages not indexed guide.
• GA4 organic sessions spiked, Search Console flat: Duplicate tag possibility (reason 2) is examined.

In the comparison, the two tools’ numbers are not expected to match exactly; what matters is whether the direction and the break date align. According to Google’s Search Console linking page, Search Console data becomes available in both Search Console and Analytics 48 hours after collection; therefore, a comparison including the last two days will be incomplete.