First-party proxy
Serve our SDK and collector from your own domain so ad blockers can't strip your analytics.
By default the SDK loads from cdn.datalook.app and posts events to /collect there. Ad blockers (uBlock Origin, AdGuard, Brave Shields) match on domain, recognize ours, and drop the requests — so 15–40% of privacy-minded visitors go uncounted.
The fix: serve s.js and the collector from your own domain. To the browser — and the ad blocker — it's ordinary first-party traffic. Nothing to block.
There are two ways. Both end with data flowing from traffic you were silently losing.
How it works (30 seconds)
The SDK resolves its collector as collect relative to its own script URL. A script loaded from https://you.com/_axis/s.js posts to https://you.com/_axis/collect — automatically. So a proxy only has to forward one path prefix to our CDN and both files ride along:
/_axis/s.js -> https://cdn.datalook.app/s.js
/_axis/collect -> https://cdn.datalook.app/collectNo second endpoint to configure, no data-domain, no per-file rules.
Best for: any stack, no redeploy, no code. You just need access to your DNS.
Add a CNAME
In your DNS provider, point a subdomain at our proxy edge:
Type Name Value
CNAME metrics.you.com -> proxy.datalook.appMost providers (Cloudflare, Vercel DNS, Route 53) flatten this automatically. Propagation is usually under five minutes.
Point your script at the subdomain
<script defer src="https://metrics.you.com/s.js" data-site="YOUR_SITE_ID"></script>The collector follows to https://metrics.you.com/collect on its own — nothing else to set.
Verify
Deploy, then open your site with an ad blocker on and watch the Network tab: s.js returns 200, collect returns 204, both on metrics.you.com. Your pageview lands in the dashboard within seconds.
The DNS path keeps the request path on our edge, so the visitor's IP reaches us directly — your country breakdown stays accurate with zero extra config. That's the main reason to prefer it over the framework path.
Best for: when you'd rather not touch DNS, or you're on a platform where a rewrite is one line (Vercel, Netlify, Next.js, …).
You add a reverse-proxy rule for one prefix (we use /_axis/) that forwards to https://cdn.datalook.app, then point the script at the prefix. Every stack is slightly different, so each has its own copy-paste guide:
The script tag in every framework guide's proxy tab is the same shape:
<script defer src="/_axis/s.js" data-site="YOUR_SITE_ID"></script>The data-api escape hatch
If your proxy can't put the collector next to the script (rare), set data-api to the collector path explicitly:
<script defer src="/assets/s.js" data-site="YOUR_SITE_ID" data-api="/_axis/collect"></script>You won't need this for any of the framework guides — they all keep the two files under one prefix.
Troubleshooting
All my visitors show up from one country (or as my server's location).
Your framework proxy isn't forwarding the visitor IP. Make sure the rule passes X-Forwarded-For (the guides that need it call this out), or switch to the DNS path, which sidesteps the problem entirely.
s.js returns my app's HTML, not JavaScript.
The prefix is being handled by your app router before the proxy rule. Pick a prefix that can't collide with your routes, and make sure the rule is registered before your catch-all.
Works without an ad blocker, blocked with one.
You're still loading from cdn.datalook.app. Re-check that the script src points at your own domain/prefix.
What's next
- All set? You're done — the dashboard starts counting traffic you were losing.
- Want server-side certainty for conversions too? See Server events.