What server-side tracking is
Server-side tracking routes your analytics through a subdomain of your own site — for example analytics.yoursite.com — instead of sending events straight to a third-party endpoint from the browser. The subdomain is a CNAME that points at datakant, so every request counts as first-party.
Because the browser sees a same-site request, privacy browsers and ad blockers treat it like any other call to your own domain. Events that would otherwise be dropped get through, and session cookies survive far longer than the seven-day cap Safari's ITP applies to third-party scripts.
How an event travels
Every tracked event follows the same path from the visitor's browser to your dashboard. Each hop has a clear job.
Visitor's browser
Tracker fires a pageview or event
Your subdomain
First-party CNAME (same-site)
datakant edge
Strips IP, drops UA, checks consent
Your dashboard
Real-time analytics in datakant
Destinations
Optional forwarding to GA4, Meta
- The tracker on your site fires an event and sends it to your first-party subdomain, not to a third-party domain.
- The subdomain
analytics.yoursite.comis a CNAME that resolves to datakant's EU edge, so the request never leaves a same-site context in the browser. - At the edge, datakant minimises the payload — the raw IP is truncated, the user-agent is reduced to a device class, and consent rules are applied before anything is written.
- The cleaned event is stored for your dashboard and, if you have connected a destination, forwarded server-side to GA4 or Meta.
Client-side vs server-side
Standard browser tracking and first-party server-side tracking collect the same events — the difference is how reliably they arrive and how long sessions stay intact.
Client-side (standard)
Browser → third-party endpoint
- Blocked by many ad blockers and tracking-prevention lists
- Safari ITP caps script-set cookies at 7 days
- No setup — works the moment the snippet is installed
Server-side (first-party)
Browser → your subdomain → datakant
- Same-site requests survive most blockers and ITP
- Longer, more stable sessions and cleaner counts
- Needs a one-time CNAME and snippet swap
What happens at the edge
Before an event is stored or forwarded, datakant's EU edge applies a fixed minimisation policy. None of it is optional — it runs on every server-side event.
Raw IP stripped
The visitor IP is truncated to /24 (IPv4) or /48 (IPv6) before it leaves the edge — enough for coarse geo, never the full address.
User-agent dropped
The user-agent string is replaced with a coarse device class — mobile, tablet, desktop, or bot.
Consent applied
Events and fields are kept or dropped according to the consent mapping configured for the property.
Server-side forwarding
If a destination is connected, the minimised event is relayed to GA4 or Meta from the edge — not from the browser.
Setting it up
Switching a property to server-side tracking is a one-time change you make once per domain.
- Open Settings → Server-side for the property and copy the subdomain datakant suggests.
- Add a CNAME record at your DNS provider that points
analytics(or the subdomain you chose) atingest.datakant.app. Propagation usually takes a few minutes. - Back in datakant, click Verify — once the CNAME resolves, the panel confirms the first-party domain is live.
- Replace your existing snippet with the first-party snippet shown in the Tracking code tab, then deploy. Events now flow over your own domain.
Consent and privacy
Server-side tracking does not change how consent works. The tracker still reads consent signals from your CMP or dataLayer in the browser, and the edge enforces the same per-system mapping you configure under Mode & consent.
Because IP truncation and user-agent reduction happen before storage, server-side tracking generally lowers the amount of personal data that ever reaches datakant — and, when forwarding is enabled, the amount that reaches GA4 or Meta.