# Ad blockers are eating a chunk of our Shopify tracking, any first-party option?

Asked by Grace Kimani on 2025-04-16. Tags: shopify, tracking, ad-blockers.

I have been comparing event counts from our Shopify storefront against the
server logs and there is a consistent gap, roughly 12 percent of sessions
produce no events at all. The pattern points to content blockers: the missing
sessions skew heavily toward desktop Firefox and Brave.

Before I dig further, could someone confirm whether the Croct tracking
endpoints are on the common blocklists, and whether there is a supported
first-party option to route around this? I would rather fix it properly than
accept the gap

## 2 answers

### Accepted answer from Tunde Adebayo (2025-04-16)

Your diagnosis is right. EasyList and EasyPrivacy block the
`/client/web/evaluate`, `/client/web/track`, and `/content` paths, so any
browser running a blocker with those lists will drop exactly the traffic you
are describing. Desktop Firefox and Brave skewing high matches the typical
blocker install base.

The supported remedy is first-party proxying. The plug configuration exposes
`baseEndpointUrl` and `cidAssignerEndpointUrl`, so you point both at a path on
your own domain and proxy the requests through it. Blockers filter by
third-party host, so requests to your own origin pass through.

Set up the proxy on your storefront domain, flip the two options, and your
gap should close to near zero within a day.

### Answer from phil_m (2025-04-17)

Worth stating the wider implication: this is not a Croct-specific problem, ad
blockers silently exclude traffic from any client-side tool, and the excluded
users are not a random sample. If you run experiments on the unproxied setup,
your results are skewed toward blocker-free browsers before you even start.
Proxying first-party fixes the measurement, not just the counts, so do it
before your next test rather than after.