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 datataste, 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 — more events get through. Safari's ITP still limits script-stored identifiers regardless of the request route.
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)
datataste edge
Strips IP, derives device class, checks consent
Your dashboard
Real-time analytics in datataste
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 datataste's EU edge, so the request never leaves a same-site context in the browser. - At the edge, datataste minimises the payload — the raw IP is truncated, the device class is derived from the user-agent, 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 → datataste
- 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, datataste'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.
Device class derived
The user-agent is classified into a coarse device class — mobile, tablet, desktop, or bot — for device reporting.
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. Server-side tracking is a paid per-property add-on (included in some plans) — see the Billing tab.
- Open Settings → Server-side for the property and copy the subdomain datataste suggests.
- Add a CNAME record at your DNS provider that points
analytics(or the subdomain you chose) attracking.datataste.ai. Propagation usually takes a few minutes. - Back in datataste, 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 the IP is truncated before storage, server-side tracking generally lowers the amount of personal data that ever reaches datataste — and, when forwarding is enabled, the amount that reaches GA4 or Meta.