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 from your own domain. To the browser — and the ad blocker — it's ordinary first-party traffic. Nothing to block.
There are two ways, and they don't cover the same ground:
- DNS path — add one CNAME, change nothing else. Your event collection goes first-party automatically; the tag you already pasted picks it up with no edit. The script file itself still loads from our CDN. Easiest, and it keeps your geo data accurate with zero config.
- Framework path — rewrite one path prefix on your own server. Now the script and the collector load from your domain — the complete bypass, and the tightest CSP. It costs you a config change (and forwarding the visitor's IP).
Start with whichever fits. You can move from one to the other later.
Best for: any stack, no redeploy, no code — you just need access to your DNS. Moves your event collection first-party, the part ad blockers drop most aggressively.
How it works
The tag the dashboard gave you already carries your own domain:
<script defer src="https://cdn.datalook.app/s.js" data-site="YOUR_SITE_ID" data-domain="you.com"></script>data-domain is inert until you add the DNS record below. The moment metrics.you.com resolves, the same already-installed tag detects it and starts posting events to https://metrics.you.com/collect — first-party, unblockable. No reinstall, no edit, no redeploy.
Add a CNAME
In your DNS provider, point a subdomain at our proxy edge:
Type Name Value
CNAME metrics.you.com -> proxy.datalook.appAny DNS provider can host this subdomain CNAME (Cloudflare, Vercel DNS, Route 53, and the rest) — it's an ordinary record, nothing special to enable. Propagation is usually under five minutes.
Nothing to reinstall
That's the whole change. Your existing tag has data-domain baked in, so once metrics.you.com is live it routes your events there on its own. You don't touch the snippet again.
Confirm it's live
Open your site with an ad blocker on and watch the Network tab: the collect beacon now posts to metrics.you.com and returns 204. The dashboard's "Become invisible to ad blockers" step verifies the same thing for you.
The DNS path keeps event collection on our edge, so the visitor's IP reaches us directly — your country breakdown stays accurate with zero extra config. The trade-off: s.js itself still loads from cdn.datalook.app. That defeats blockers that drop the beacon (most of them), but not one that blocks our script domain outright — for that, use the framework path, which serves the script first-party too.
Best for: when you want the complete bypass — script and collector both first-party — or you're on a platform where a rewrite is one line (Vercel, Netlify, Next.js, …).
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 you only 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/collectThen point the tag at your own prefix — no data-domain here, since nothing loads from our domain anymore:
<script defer src="/_axis/s.js" data-site="YOUR_SITE_ID"></script>Every stack is slightly different, so each has its own copy-paste guide:
Your proxy must forward the visitor's IP (X-Forwarded-For) or every visit looks like it came from your server's location — the guides that need it call this out. The DNS path sidesteps this entirely; the framework path doesn't.
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. It takes precedence over both the relative default and data-domain:
<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
DNS path: the collect beacon still posts to cdn.datalook.app.
metrics.you.com isn't serving yet. Either it hasn't propagated (give it up to your TTL), the CNAME points somewhere other than proxy.datalook.app, or the tag is missing its data-domain. Re-run the dashboard's verify step once the record is live. (The first pageview of each visit may still hit our CDN for a beat while the SDK probes your subdomain — that's expected; subsequent events go first-party.)
Framework path: all my visitors show up from one country (or as my server's location).
Your 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.
Framework path: 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.
Everything's blocked, even the script.
An ad blocker is blocking cdn.datalook.app/s.js at the source, so nothing runs. The DNS path can't fix this (the script loads from our CDN there) — use the framework path, which serves the script from your own domain.
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.