ERR_BLOCKED_BY_CLIENT on a GA4 request means the browser reported a client-side block. It is a clue about that request, not a measurement of all lost traffic. Find out whether the blocked request loads your tag or sends an event, then compare the same action with blocking off and on.
This is an actual Chromium network error, not a GA4-specific diagnostic. Chromium defines BLOCKED_BY_CLIENT as error -20, meaning the client chose to block the request. The code alone does not identify the blocker or prove that Introtrace supports the affected resource.
1. Identify which request is blocked
Open developer tools before reloading. In Network, enable Preserve log if your action navigates, clear old entries, and filter for gtag or collect. Inspect the full request URL and error, rather than relying on the Console message alone.
A blocked gtag/js request can prevent the Google tag from initialising. A blocked /g/collect request means an attempted measurement request was stopped. If GA4 runs through GTM, check gtm.js too: a blocked container can prevent the GA4 tag from running at all.
Use the free ad blocker scanner for an initial check of a public page. It tests one uBlock Origin configuration; it does not reproduce your logged-in session, consent choice, or checkout actions.
2. Compare one action with blocking off and on
- Use a test page and test property where possible. Note the page, browser version, blocker settings, consent choice, and event you expect.
- With the blocker disabled for your own test page, accept analytics consent and trigger the action once. Record script loading and the event request.
- Enable the blocker, keep consent and the page configuration unchanged, reload, and repeat the same action.
- Compare the two runs. Save the failed request URL and whether the script initialised. Restore your normal browser settings afterwards.
If the baseline fails too, fix the installation first. If both runs succeed, this test has not reproduced blocking for the event in question. Change one variable at a time; disabling several extensions and changing consent together makes the result hard to interpret.
3. Check consent and configuration separately
Missing events without a blocked request can have another cause. Confirm the destination measurement ID, event trigger, published container version, and any JavaScript errors. Check whether the action happens on a page that actually includes the tag.
A visitor declining analytics consent is different from an extension blocking a permitted request. Preserve the intended consent behavior while debugging. If the browser sends events but the report is empty, check the selected property, report filters, and processing delays. Google’s GA4 setup troubleshooting guide covers these checks.
For a broader investigation, follow the GTM blocking diagnostic when your container fails, or the missing WooCommerce purchases guide when only checkout measurement is affected.
4. Verify the event in GA4
Enable debug mode for your test device through Tag Assistant or GTM Preview, then choose that device in GA4 DebugView. Trigger one identifiable event and inspect its name and parameters. A successful request response alone is not proof that the intended event is in the intended property.
Google notes that DebugView can be empty when analytics consent has not been given. Use Network and consent-state checks alongside it. Remove temporary debug settings after testing. Google’s DebugView instructions
Record the result for each run: request outcome, event receipt, and relevant parameter values. Do not infer correct attribution or duplicate handling from a single received event.
5. Test recovery only after reproducing a block
If blocking is confirmed, GA4 ad blocker recovery can be tested on the same page. Introtrace serves blocked scripts and relays supported blocked event requests. Its default host is cdn.introtrace.com; a custom CNAME subdomain requires a paid plan.
Keep the blocker enabled, enable recovery, and repeat the same action. Check both request transport and GA4 receipt. Repeat with consent declined to verify that your installation preserves its intended consent behavior.
Our recorded Brave test includes browser observations and GA4 verification from October 3, 2026. It covers accepted analytics consent and one test configuration; it is not a guarantee for every blocker. Use the three-run recovery checklist to document your own result.
Recovery does not necessarily remove the original error from DevTools. In our recorded Brave run, the direct GA4 request still failed with ERR_BLOCKED_BY_CLIENT while Introtrace used a relay route; separate DebugView evidence verified recovery-run parameters. Introtrace can recover supported analytics requests, but this evidence does not establish a fix for every resource or browser policy that produces this error.