Ad blockers seem to drop Croct requests from some shoppers, how do I fix that?
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
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:
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 walks through the proxy setup, and the plug options reference 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.