A user consents to analytics, but their ad blocker still blocks GA4. What can you do?
A visitor accepts analytics in your consent banner. Your consent platform records that choice correctly. GA4 is now allowed to run. And the visitor’s ad blocker blocks it anyway.
This is not unusual. Consent systems and ad blockers solve different problems, and they usually do not communicate with each other. Your consent platform knows the visitor has allowed analytics. The ad blocker usually just sees a request to a known Google tracking domain and blocks it according to its filter rules. So yes: a visitor can explicitly consent to analytics and still never appear in GA4.
If that missing data matters, one option is to route the analytics requests through your own domain instead of sending them directly to Google’s normal analytics domains. That sounds simple, but there is an important catch: proxying the GA4 script alone is not enough.
Why consent does not override an ad blocker
A consent platform is deciding whether your website is allowed to load analytics under the visitor’s selected preferences. An ad blocker is making a separate decision at browser level. It may block known domains such as Google Analytics or Tag Manager regardless of what happened in the consent banner. So the sequence can look like this:
Visitor accepts analytics
↓
Consent platform allows GA4
↓
Website tries to load GA4
↓
Ad blocker blocks the request
↓
Visitor never appears in GA4
From the website’s perspective, the visitor said yes. From the ad blocker’s perspective, the request still matches a tracking rule. Those systems do not normally reconcile those two decisions.
Can you make GA4 less likely to be blocked?
One approach is first-party proxying. Instead of the browser requesting the analytics resources directly from Google, it requests them through a URL on your own website. Conceptually:
example.com/analytics/...
↓
your server
↓
Google Analytics
To the browser, the request starts on the same domain as the website. This can reduce blocking that is based mainly on known third-party analytics domains. It is not guaranteed to bypass every blocker, and it should not be presented as “ad-block-proof”. Blockers can also detect first-party tracking patterns. But it can improve measurement reliability.
The obvious mistake: proxying only gtag.js
This is where many implementations stop too early. GA4 does not consist of one JavaScript file. The browser first loads Google’s tracking code, but that code then sends page views and events to Google’s measurement infrastructure. Those are separate requests. A simplified version looks like:
Load GA4 script
↓
Run GA4
↓
Send pageview/event
If you proxy only the first step, you may successfully load gtag.js through your own domain while the actual event still goes directly to Google and gets blocked. The result is confusing because the tracker appears to load correctly. You may see no obvious JavaScript error, but GA4 still receives nothing from that visitor. So if the goal is to improve collection, you have to account for both:
- loading the analytics code;
- sending the analytics data.
Why Umami is easier
Umami is comparatively simple in this respect. It supports configuring where its tracking requests are sent, and self-hosted installations can keep both the script and collection endpoint under infrastructure you control. That makes it relatively straightforward to route the full analytics flow through a first-party domain. GA4 is more complicated because the script and the measurement traffic do not necessarily use the same Google host. That distinction matters a lot.
GA4 needs the collection path configured too
With GA4, you need to tell the Google tag where the measurement traffic should go. Loading gtag.js from a first-party URL does not automatically redirect the subsequent analytics events. This is the technical detail that makes many “just proxy GA4” examples incomplete. The full flow needs to become something closer to:
example.com/analytics/script
↓
Google's script infrastructure
example.com/analytics/collect
↓
Google's measurement infrastructure
The exact implementation depends on the setup, but the important point is simple: The script URL and the measurement destination are separate concerns. If you only solve one of them, the tracking can still be blocked.
Will this recover every missing GA4 visitor?
No. Ad blockers are only one reason analytics data is incomplete. You can also lose measurements because of:
- visitors rejecting analytics consent;
- browser privacy features;
- failed scripts;
- network problems;
- incorrect event configuration;
- navigation happening before a request completes;
- attribution differences.
First-party proxying only addresses part of the problem. It can make GA4 more resilient to some blocking rules, but it does not turn GA4 into a complete record of reality. Your CRM, ecommerce platform or booking system should still be the source of truth for actual leads, orders and bookings.
One reason I started looking more closely at this is that I run my own custom consent management plugin on some projects. That gives me control over the point where consent state, tag loading and the analytics transport meet, so first-party routing can be added as part of the same implementation rather than bolted on afterwards.
Is this worth doing?
That depends on how important the missing measurements are. For a small company website with limited traffic, it may not be worth adding extra infrastructure just to recover a small percentage of analytics events. For a business spending significantly on Google Ads, optimising landing pages, or relying on conversion attribution, the calculation can be different.
If missing events affect decisions about campaign spend or conversion performance, improving collection quality may be useful. I would first establish whether ad blocking is actually a meaningful source of measurement loss before building additional infrastructure.
How to check whether this is your problem
A simple test is:
- Open the site without an ad blocker.
- Accept analytics consent.
- Confirm the GA4 pageview or event appears.
- Repeat with the blocker enabled.
- Accept analytics again.
- Check whether the GA4 script and collection requests are being blocked.
Do not only check whether gtag.js loads. Look for the actual request that sends the event. If the script loads but the event request is blocked, you have found the important part of the problem.
Consent still has to control the setup
Routing analytics through your own domain does not remove the need to respect consent. If the visitor has rejected analytics, the first-party endpoint should not become a workaround that continues collecting data anyway. The questions are separate:
Is analytics allowed to run? That is controlled by consent.
If it is allowed to run, how does the event reach the analytics platform reliably? That is a technical implementation problem.
Keeping those two things separate makes the architecture much easier to reason about.
Why the implementation is more involved than it sounds
Once you go beyond the basic idea, the proxy has to account for details that are easy to miss. Different parts of the analytics platform may use different hosts. Query parameters have to survive the proxy correctly. Compressed responses have to be relayed properly. The proxy should only be allowed to connect to known analytics destinations rather than becoming a generic open proxy. These are implementation details, but they explain why a feature that sounds like:
“Just send GA4 through our domain”
can take more engineering work than expected. The conceptual fix is small. Making it reliable end to end is the real job.
The practical answer
If a visitor consents to analytics but their ad blocker still blocks GA4, you have three realistic options:
- accept that some analytics data will be missing;
- ask users to disable their blocker, which is rarely a great user experience;
- route permitted analytics traffic through a first-party endpoint to make it less likely to be filtered.
The third option can work well, but only if the complete measurement flow is proxied rather than just the visible JavaScript file. That means treating analytics as an integration, not as a single script tag.
