Server-side tracking
Server-side tracking, minus the hand-waving.
Server-side tracking means the record is made by a server rather than by a script in somebody’s browser. That one difference decides how much of your data survives ad blockers, browser restrictions and closed tabs.
Browser tracking has been getting less reliable every year, and not by accident. Blockers remove scripts, browsers cap how long a cookie set by script survives, and privacy settings hide the rest. None of that is coming back, so the sensible response is to move the parts that matter off the browser.
A redirect is already server-side. The visitor asks a server for your tracking link, the server records the click and answers with where to go next. There is no script to block, and the record exists before your landing page has loaded a single byte.
Postbacks are server-side too: the network calls you when the sale is real. So are conversion APIs, which send that sale to Google, Meta or TikTok from your server rather than from the visitor’s browser. Put together, the money path never touches a script.
What server-side tracking does not fix is honesty about people. It does not let you follow somebody across devices without them being identifiable, and it does not exempt anyone from privacy law. Whatever is collected still needs a reason, a retention period and a way out.
How it works
The mechanism, not the marketing.
- 01
The redirect records the click
Server-side by definition. Nothing in the browser has to cooperate.
- 02
Your lander reports, if you want it to
One tag for page views and goals, using a first-party cookie and falling back to the click id in the URL.
- 03
The network calls your server
A postback on the sale, carrying the click id — days later if that is when it is approved.
- 04
Your server tells the ad platform
Through the platform’s own API, matched on its click id, so bidding learns from real revenue.
What to check tonight
You can do all of this without us.
None of it needs an account anywhere. If it turns out your tracking is fine, you have lost twenty minutes and learned something.
Turn on an ad blocker and buy something
Run your own funnel with a blocker enabled. Whatever still records is your server-side data; whatever disappears was browser data all along.
Look for the click id at every hop
Ad, tracking link, landing page, offer. If it survives all four, server-side attribution will work. If it is dropped at a hop, that is the thing to fix first.
Check what your ad platform is being told
In Google Ads or Meta, look at whether conversions arrive from the browser or from an API. The second is more of them, and sooner.
Read your own privacy page
If it was written for a pixel and you now hold click-level records on your own server, it needs updating. That is a ten-minute job that avoids a bad conversation later.
How UTMCAP does it
What you would get here.
The redirect is the record
Answered at the edge in about 300 cities, written before the visitor sees your page.
Postbacks in, from 39 networks
With mappings already written, a shared secret, and duplicate handling.
Conversion APIs out
Google Ads, Microsoft, Meta and TikTok, from our server to theirs.
A tag only where it helps
Page views, goals and lander clicks. The money path does not depend on it.
Signed server orders
For shops, so a conversion cannot be faked from a browser console.
Retention you control
Old clicks are anonymised rather than deleted, so reports survive and people do not.
Questions
The ones people ask next.
Read next
- Is server-side tracking legal?
- Moving the collection to a server changes nothing about consent or lawful basis; it changes where the data is. You still need a reason to hold it, a retention period and a way for someone to be removed. Our privacy policy and DPA set out how we handle that half.
- Do I still need a pixel on my landing page?
- Only for what a server cannot see: page views, scrolls, clicks on your own buttons. The click and the conversion do not need it.
- Does this work with iOS and ad blockers?
- The redirect and the postback do, because neither runs in the browser. Anything script-based is affected on iOS as everywhere else, which is the argument for keeping the money path off scripts.
Point a domain at us and run a click through it.
The free plan takes a hundred thousand clicks a month and no card. If it does not do what you need, you have lost twenty minutes.