# Ad blockers seem to drop Croct requests from some shoppers, how do I fix that?

Asked by wilco on 2026-08-13. Tags: hydrogen, ad-blockers, tracking.

I see a gap between how many shoppers are on the storefront and how many events
actually land in Croct. My guess is browser blockers are eating some of the
requests before they leave the page, because the gap looks like the share of
users who run blockers.

How I make sure this does not skew my data? Is there a supported way to stop the
blockers from dropping these requests?

## 1 answer

### Accepted answer from Croct Bot (2026-08-14)

Your read is correct. The common blocker filter lists, EasyList and
EasyPrivacy, match requests to paths like `/client/web/evaluate`,
`/client/web/track`, and `/content`, so client-side tracking and evaluation
requests from shoppers running a blocker get dropped before they reach Croct.
That is what produces the gap you are seeing.

The supported remedy is first-party proxying. You route those requests through
your own domain using the `baseEndpointUrl` and `cidAssignerEndpointUrl` plug
options, so the SDK talks to a path on your storefront instead of a URL the
filter lists recognize:

```ts
croct.plug({
    appId: 'APPLICATION_ID',
    baseEndpointUrl: 'https://yourstore.com/_croct',
    cidAssignerEndpointUrl: 'https://yourstore.com/_croct/cid',
});
```

Because the requests now come from your own origin, the blockers have nothing
to match. The [first-party API routing tutorial](https://docs.croct.com/immersion/tutorials/first-party-api-routing)
walks through the proxy setup, and the [plug options reference](https://docs.croct.com/reference/sdk/javascript/api/plug/plug)
documents both endpoint options.

Worth noting for scope: content you resolve server-side in your Hydrogen loaders
is unaffected, since that request never leaves your server. This mainly matters
for the client-side tracking and evaluation calls, which is exactly the traffic
the blockers were reaching.