Do ad blockers block the Meta pixel?

Many ad blockers and privacy browsers block it. When the script is blocked, no browser events reach Meta from that visitor, but purchases sent server-side from your order data still arrive.

How many shoppers use ad blockers?

It depends on your audience, devices and countries, so a general figure tells you little about your store. Measure your own gap by comparing web orders with the Purchase events your pixel sent in the same period.

Can ad blockers block server-side tracking?

Not the purchase sent from order data, because that request goes from a server to the platform's API. A blocker can stop the browser script that saves the click id, which is why first-party collection matters.

Is an ad blocker the same as declining consent?

No. Declining consent is a choice in your cookie banner that your tracking must follow. An ad blocker is a tool in the browser. Both reduce pixel events, so measure them separately.

Do I still need the pixel if I send purchases server-side?

Yes, for the visitors without a blocker. The pixel adds browsing events and browser cookies, and with the same event id the platform keeps one copy of each purchase.

Ad blockers and tracking: what your store loses

Key takeaways

Ad blockers use filter lists to stop pixel scripts and their requests, so the ad platform receives no event at all from that browser.
A blocked pixel loses page views, add-to-cart events and purchases, and the purchase matters most because it drives reported ROAS and bidding.
Purchases sent server-side from your order data are not affected, because the shopper's browser does not send them.
Measure your own gap by comparing web orders in your shop with the Purchase events the browser pixel sent, not with attributed conversions.
Server-side tracking cannot bring back browsing events or click ids that were never saved, and first-party collection reduces that loss.

Ad blockers stop tracking by preventing the ad platform's pixel script, or the requests it sends, from loading in the shopper's browser. When that happens, the platform never hears about the page view, the add to cart or the purchase, even though the order is in your shop. Purchases sent server-side from your order data are not affected, because the shopper's browser is not involved in sending them.

This guide explains how ad blockers and browser privacy features work, which events your store loses, what server-side tracking recovers and what it cannot. It ends with a simple way to measure the gap in your own store.

How do ad blockers stop tracking pixels?

Most ad blockers work with filter lists. A filter list is a long list of rules that match web addresses: domains, paths and file names of known ad and tracking scripts. When a page asks the browser to load something that matches a rule, the blocker cancels the request.

The best-known lists are EasyList, for ads, and EasyPrivacy, for tracking. They work with extensions such as Adblock Plus, AdBlock, uBlock Origin and AdGuard. The pixel of a large ad platform is an easy target for these lists, because it loads the same script from the same domain on many different sites.

Page loadsYour theme includes the pixel script of the ad platform.

Blocker checks the addressThe script address matches a rule in a filter list.

Request cancelledThe script never runs, so no event is created.

Ad platformReceives nothing from this visit.

A blocked pixel does not send a weaker event. It sends no event at all.

Browsers with built-in protection

Some browsers block trackers without an extension. Brave turns on its Shields for every site by default, and Shields block third-party ads, trackers and cross-site cookies. Firefox blocks content from known cross-site tracking domains in private windows, and people can choose stricter settings that apply to all windows. Safari's Intelligent Tracking Prevention blocks all third-party cookies and shortens the life of cookies that scripts set. Our guide to Safari ITP and ad tracking explains those limits.

Network-wide blockers

Some people block trackers for a whole device or home network, with a DNS-based blocker or a VPN with a tracker filter. These stop requests to tracking domains in every browser and app on that network. Switching browsers does not change the result.

Which events does your store lose?

When the pixel is blocked, every event it would have sent from that browser is lost. The damage is not the same for each event.

Event	What it is used for	Lost when the pixel is blocked?	Can order data replace it?
PageView, ViewContent	Audiences of site visitors, product retargeting	Yes	No
AddToCart, InitiateCheckout	Optimization toward shoppers who start a purchase, cart retargeting	Yes	No
Purchase	Reported conversions, ROAS, purchase optimization, value-based bidding	Yes	Yes
Click id on landing	Linking the purchase to the exact ad click	Yes, when the tracking script is also blocked	No, it must be saved in the browser

The purchase is the most valuable event, and it is the one that order data can always replace.

Lost browsing events make your retargeting audiences smaller. Lost purchases do more damage. The platform reports fewer conversions, the ROAS in the ads report drops, and the bidding algorithm learns from fewer buyers. A profitable campaign can then look unprofitable, and you may cut it.

Why server-side events from order data are not blocked

An ad blocker runs inside the shopper's browser. It can only stop requests that the browser makes. When the purchase is sent from your shop's order data, the request goes from a server to the ad platform's API. The shopper's browser is not part of that path, so there is nothing for the blocker to cancel.

14:02:11 PageView pixelBlocked by a filter list in the browser

14:09:47 Purchase pixel order-1042Never sent, because the pixel script did not load

14:09:52 webhook order-1042 paidThe shop reports the paid order to the server

14:10:12 Purchase server order-1042Sent to the Conversions API with hashed email and phone

Example: one visit with an ad blocker. The browser sends nothing, but the purchase still reaches the platform from the order.

The platform then matches the purchase to a person with the data in the event: the hashed email and phone from the order, the IP address and user agent, and the click id if one was saved. None of this passes through the blocker. For the full data path, read what server-side tracking is.

What can server-side tracking not recover?

The click id needs the browser

The order itself is safe, but the link to the ad click is made in the browser. A script has to read the click id from the landing URL and save it. If an ad blocker also blocks that script, the order arrives without a click id. The platform can still match the purchase through hashed customer data, but the match is less certain.

Two things reduce this loss. First, collect events first-party: serve the tracking script and its requests from your own domain, for example through a Shopify app proxy or a subdomain of your site. Filter lists target known third-party tracking addresses, so a first-party path is much harder to block, though not impossible. Second, use the landing page that some webshops, such as Shopify, store with each order. If that URL still contains the click id or UTMs, the order can be attributed without any browser event.

Browsing events are still lost

Order data contains orders, not page views. Sending purchases from orders does not bring back the page views and add-to-cart events of a visitor whose browser blocked everything. A first-party collector can forward these events from the server when its own requests get through.

Declined consent is not blocking

A visitor who declines marketing cookies in your cookie banner is not the same as a visitor with an ad blocker. The first visitor made a choice that your tracking must follow. With Respect visitor consent on, ROASaurus sets no visitor id for that visitor, so their ad clicks and visits are not linked to them. Their browser events are kept without a visitor id, IP address or browser details, and are not sent to ad platforms. The paid order is still sent server-side, with hashed customer data from the order and the order's IP address and user agent. Keep the two groups apart when you measure your loss, and see consent and privacy for the details.

How to estimate your own loss

You do not need industry averages, which depend on audience, device and country. You can measure your own gap by comparing the orders in your shop with the purchases the browser pixel reported for the same period.

Pick a period and one platform
Use 14 or 30 days and one platform, for example Meta. Use the same time zone in both systems.
Count web orders in your shop
Start with all orders. Remove the orders that never pass through your online checkout: point-of-sale, manual and draft orders, subscription renewals and test orders.
Count Purchase events from the browser
In the platform's events tool, count the Purchase events that the browser pixel sent. This is easiest before you add server events. If server events already run, use the platform's view by connection method where it offers one. Meta Events Manager shows the connection method of each event and counts events there before deduplication. Do not use attributed purchases from the ads report.
Divide
Browser purchases ÷ web orders is the share that the pixel saw. The rest is your gap.
Separate consent from blocking
Estimate the orders from visitors who declined marketing cookies, with the decline rate from your consent tool. What remains is mostly ad blockers, privacy settings and pages that did not load.

Example store, 30 days	Orders	Share of web orders
All orders in the shop	1,240
Point-of-sale, manual and renewal orders	−90
Web orders	1,150	100%
Purchase events from the browser pixel	874	76%
Gap	276	24%
Estimated orders from visitors who declined consent (10% decline rate)	115	10%
Remaining: ad blockers, privacy settings, pages that did not load	161	14%

In this example store, the pixel misses about 1 in 4 web orders. About 1 in 7 is lost to blocking and browser failures, not to consent.

The gap also changes ROAS. Suppose Meta reports a ROAS of 2.0 for this store and its break-even ROAS is 2.3. On pixel data, the campaigns lose money. If ad-driven orders were missed at the same 24% rate as all web orders, the pixel saw only 76% of the ad revenue. The real ROAS would then be about 2.0 ÷ 0.76 = 2.6, above break-even. This is an upper estimate, because not every missing order came from an ad. Our guide to break-even ROAS explains how to set that threshold.

How to reduce what you lose

The fixes are the same for every webshop platform. They work best together.

Send purchases from order data. This closes the purchase gap for every platform you connect, whatever the visitor's browser blocks.
Keep the pixel, with a shared event id. Visitors without a blocker still send browser events with cookies and page context. The same event id on both copies lets the platform keep one. See preventing double counting.
Collect first-party. Serve the tracking script and its events from your own domain, so click ids are saved for more visitors.
Send hashed customer data. Email and phone from the order let the platform match purchases that have no click id.
Measure again. Repeat the comparison a month later. The Purchase events the platform receives should now match your web orders.

Example store: Purchase events Meta received in 30 days

Pixel onlyPixel + server, deduplicated

Purchase events

874

1,150

After purchases are sent from order data, all 1,150 web orders reach the platform. The pixel still adds browser data for the 874 orders it saw.

How ROASaurus handles ad blockers

ROASaurus sends every paid order server-side to the ad platforms you add under Tracking & platforms, so an ad blocker in the shopper's browser does not stop the purchase. On Shopify, storefront events go through Shopify's app proxy on your own store domain. You can also serve the script and its events from a CNAME subdomain of your site. When a visitor has no browser touch, ROASaurus attribution falls back to the click ids and UTMs in the order's landing URL, when the shop records one, as Shopify does.

Every delivery and the platform's response are listed in the Event log, so you can check that each order reached each platform. See server-side tracking and the Shopify integration for the setup.

Sources

In ROASaurus

Keep reading

TrackingConsent Mode v2 and GDPR: what a webshop may sendConsent Mode v2 for webshops: the four Google consent signals, what EU law asks, and what server-side tracking may still send. General information only.TrackingDuplicate purchase events: why sales are counted twiceDuplicate purchase events inflate conversions and ROAS. See the causes, how Meta, TikTok, Snapchat, Pinterest and Reddit deduplicate, and how to fix it.TrackingSafari ITP and ad tracking: what still worksSafari ITP caps cookies set by scripts at 7 days, or 24 hours after some ad clicks. See what it does to attribution and which tracking still works.