What is server-side tracking?
Server-side tracking sends analytics events from your backend, not the browser. What it fixes, how it differs from a first-party proxy, and when to use each.
What is server-side tracking?
Server-side tracking sends analytics events from your own backend rather than from the visitor's browser. Because the event does not depend on a client-side script, it cannot be blocked by an extension, it is not affected by browser storage limits, and you control exactly which fields leave your infrastructure.
A worked example.
The same purchase, measured two ways.
| Client-side | Browser fires a purchase event after the confirmation page renders |
|---|---|
| Blocked by an extension | Event never sent, purchase missing from analytics |
| Server-side | Your payment webhook fires the event when the charge succeeds |
| Blocked by an extension | Irrelevant, the browser was never involved |
Server-side records the purchase in cases where client-side loses it entirely
For revenue events specifically, the server already knows the truth. Asking the browser to report something your backend confirmed is adding a failure mode for no benefit.
What it fixes
Client-side tracking has four structural weaknesses, and server-side removes three of them.
- Blocking. Content blockers remove analytics requests from the browser. An event sent from your backend never passes through the browser at all.
- Reliability. A browser event can be lost to a closed tab, a flaky network or a script error mid-page. A backend call can be retried and logged.
- Data control. You decide exactly which fields are sent, so nothing unexpected leaves your infrastructure and personal data can be stripped before it goes anywhere.
- The one it does not fix is consent. Where the request originates has no bearing on whether you may store something on the device or profile a person.
That last point is the most commonly misrepresented thing about server-side tracking. Moving a tag to a server changes the network path, not the legal basis.
Server-side tracking against a first-party proxy
These solve overlapping problems and get confused constantly. A proxy keeps client-side collection and moves the hostname; server-side moves the collection itself.
| First-party proxy | Server-side tracking | |
|---|---|---|
| Where the event originates | The visitor's browser | Your backend |
| What it defeats | Hostname-based blocklists | All client-side blocking, plus lost requests |
| Client context available | Full: viewport, referrer, scroll, engagement | Only what you pass in explicitly |
| Setup effort | A DNS record | Code in your application, per event |
| Good for | Pageviews and engagement | Purchases, signups, subscription changes |
Most teams end up using both: a first-party proxy for browser-side pageviews and engagement, server-side calls for the revenue events that must never be lost.
See it on real data
The live demo is a fully populated dashboard with real demo traffic. No signup and no card required.
Open the live demo
What server-side cannot do
It does not create consent
If your setup stores an identifier on the device or profiles a person, consent is required whether the request came from a browser or a server.
It cannot see the page
Scroll depth, engagement time, viewport size, rage clicks and session replay are all browser-side phenomena. A backend cannot observe them.
It is not free of effort
Every event has to be written into application code, which means engineering time for each new measurement rather than a marketer adding a tag.
It can hide bot traffic badly
Without browser signals, distinguishing an automated request from a person is harder. Server-side data needs its own filtering discipline.
How Mrkr supports it
Mrkr accepts events over a plain HTTP API, so any backend that can make a POST request can send them: a payment webhook, a job runner, a mobile backend, a CLI.
That runs alongside the browser tracker rather than replacing it, which is the combination most teams want. The browser reports pageviews, engagement and session context; the backend reports the events that are financially important and must not be lost.
There is also the first-party proxy for the client side, which serves the tracker and the collection endpoint from a neutral subdomain of your own domain. Between the two, the amount of measurement lost to blocking gets small.
Questions, answered.
Related terms.
- What is first-party data?
First-party data is information you collect directly from your own audience on your own properties: site behaviour, purchases, support conversations, and anything customers tell you.
- What is cookieless tracking?
Cookieless tracking is any method of recognising visits without storing an identifier in the browser.
- What is tracking pixel?
A tracking pixel is a tiny, usually invisible image embedded in a web page or an email.
- What is event?
An event is any recorded action beyond loading a page: a button click, a form submitted, a video played, a subscription upgraded.
- What is cookie banner?
A cookie banner is the notice that asks a visitor's permission before storing or reading information on their device.
Where this shows up in Mrkr
- Send events from your backend with Mrkr server-side tracking
A plain HTTP API for the events that must never be lost.
- Serve the browser tracker from your own subdomain with the managed proxy
- Browse the full analytics glossary
Every metric, method and privacy term, defined in one place.
Your first visitor is already here.
Drop in the script and watch them land. It takes about a minute.