An ad blocker is software, usually a browser extension or a built-in browser setting, that stops adverts loading on the pages someone visits. Most ad blockers also stop tracking, which means the scripts behind Google Analytics, Google Tag Manager, the Meta Pixel and similar tags never run.
How an ad blocker works
Ad blockers work from filter lists: shared, community-maintained lists of web addresses and page patterns known to serve ads or tracking. Each time a page asks the browser to fetch something, the blocker checks the request against its lists and quietly cancels any match. The main lists cover ad networks, and companion privacy lists cover analytics and tracking services, including Google’s and Meta’s.
Some blocking happens without any extension. Brave blocks trackers by default, Firefox blocks a range of known trackers and more in its strict mode, and Safari’s Intelligent Tracking Prevention limits how long tracking cookies last. Privacy-focused DNS services and some workplace networks block tracking domains for every device on the connection.
From the visitor’s side the page loads as normal. What changes is that the tags never fire, so the visit, the form submission or the purchase never reaches your analytics or your ad accounts.
Why it matters
Every report built on browser tags undercounts the people who block them. GA4 shows fewer sessions than really happened, Google Ads and Meta see fewer conversions, and retargeting audiences are smaller than your real visitor numbers. Blocking is not spread evenly either. It varies by audience and device, and a software company with a technical readership is likely to lose more of its data than a local café.
The effect stacks on top of consent. On a UK site, analytics and advertising tags should only run for people who accept them under PECR. Ad blockers then remove a further slice of the people who did accept, and the two losses together explain much of the gap between platform reports and the orders or enquiries in your own systems. I walk through reading that gap in why GA4 and Facebook conversion numbers do not match.
Blockers can also break things. If a form, booking widget or chat tool loads from a domain on a filter list, some visitors cannot use it, and they will not tell you why they left.
Common mistakes
- Treating GA4 as a complete record of visits or sales. It is a record of the people whose browsers allowed it to run.
- Using server-side tracking or a disguised first-party domain to measure people who refused consent. Getting past a blocker does not get you past PECR, and the ICO’s guidance applies to any technique that stores or reads information on a visitor’s device, not only cookies.
- Asking visitors to switch off their blocker before they can use the site, which loses enquiries from people who simply leave.
- Deciding a campaign is failing because its reported conversions dropped, without first checking whether the tracking changed.
- Never testing the site with a blocker switched on, so a broken enquiry form goes unnoticed for months.
How to act on it
Measure the gap on your own site rather than guessing at it. Compare a month of GA4 key events with the enquiries in your inbox or CRM, or with orders in your shop platform, and note the difference. That figure is the one to plan around.
Make your own records the source of truth for leads and sales, and use platform data to compare campaigns rather than to count results. Where a platform accepts conversion data from your server or CRM, such as Meta’s Conversions API or Google Ads offline conversion imports, sending data for consenting customers that way gives the bidding systems a fuller picture without overriding anyone’s choice.
Then open your key pages with a mainstream blocker switched on and complete every form and checkout step. I run checks like this on measurement and forms before managing any budget in performance marketing, because spend cannot be judged on numbers nobody has tested.