Digital Marketing
Server-Side Tracking
Genuinely valuable at volume, and an expensive way to recover a rounding error below it.
Server-side tracking moves data collection out of the browser and onto a server you control, so measurement survives ad blockers, Safari’s ITP and shortened cookie lifetimes. The Nexclick builds it where the recovered data justifies the monthly running cost, and says plainly when it does not.
Is this you?
What usually prompts the call
- A large share of your traffic is on Safari or running an ad blocker, and the numbers show it.
- Reported conversions have drifted steadily downwards while actual sales have not.
- Your conversion data is thin enough that automated bidding has stopped performing.
- Someone has told you server-side tracking will fix attribution and you want to know whether that is true.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Establish whether it is worth doing at all
- Consent decline rate, blocked requests, Safari share and the resulting conversion gap, modelled against the monthly cost. The output is a number, and sometimes that number says no.
- Deploy a server container on infrastructure you own
- Cloud Run or a managed equivalent, billed to your own account. Cost scales with request volume, which is precisely why the viability assessment comes first.
- First-party subdomain and cookie handling
- Collection served from your own domain, so identifiers are set server-side and are not capped at seven days by Safari’s intelligent tracking prevention.
- Conversions API integrations
- Meta CAPI, Google Ads enhanced conversions and the equivalents on TikTok and LinkedIn, fed from the server rather than the browser.
- Deduplication, verified rather than assumed
- Shared event IDs between browser and server so one conversion is counted once. This is the single most common fault in an inherited server-side setup and it inflates everything.
- Consent enforced server-side too
- A visitor who declined must not have data forwarded from the server either. Moving collection to your infrastructure does not move it outside UK GDPR, whatever the vendor marketing implies.
- Data minimisation and hashing
- Only what each platform needs, hashed where required, with a written record of exactly what leaves your servers and where it goes. That record is a compliance artefact, not a nicety.
- Monitoring and alerting
- Server-side failures are silent — no console error, no broken page, just a container quietly refusing events. Alerting on error rates and volume drops is part of the build.
Decision tree
Do you actually need server-side tracking?
The honest version. Work down until one matches. Several branches end in no, and this is currently sold to a great many businesses sitting squarely in those branches.
01You take fewer than about 100 conversions a month
No. The recovery will be a handful of conversions and the cost is permanent. Fix consent mode and offline conversion import instead — cheaper, and they close more of the same gap.
02You take several hundred conversions a month and rely on automated bidding
Probably yes. Thin conversion data is what degrades automated bidding, and feeding the platforms reliably from the server is the most direct fix available.
03Ad spend is meaningful and Safari is a large share of your traffic
Yes. ITP caps client-set cookies at seven days, so returning visitors are counted as new. First-party server-side cookies are the only real remedy.
04You want it because attribution "does not add up"
No, not on its own. Platforms disagree by design. This improves data quality; it does not make three systems agree, and anyone promising that is selling you something else.
05Your consent decline rate is very high
It will not help. Declined visitors must not be tracked server-side either. That gap is a legal boundary rather than a technical one, and no architecture removes it.
06You are an ecommerce business with genuine volume
Yes. Purchase data reaching the conversions APIs reliably is worth the running cost several times over once transaction volume is real.
07Someone has quoted you a large monthly retainer for it
Ask what happens each month. The build is a project, the hosting is your cloud bill, and ongoing work is monitoring plus the occasional fix. A permanent four-figure fee needs explaining.
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1
Viability assessment
Measure what you are actually losing today and price the recovery against the running cost. Ends in a recommendation, which is negative more often than the industry admits.
- 02Week 2
Provision and configure
Server container, subdomain, certificates, and the client-side changes needed to feed it. Provisioning is quick; the domain and DNS work is usually what waits.
- 03Week 2–3
Platform integrations and deduplication
Conversions APIs connected and event IDs matched, then tested against real conversions until duplicate counts are zero rather than nearly zero.
- 04Week 3–4
Verify, document and monitor
Side-by-side comparison against the previous setup, written documentation of what data leaves and to whom, and alerting configured before handover.
What you get
Reporting and ownership
- A measured before-and-after, so the recovery is a figure rather than a claim.
- A server container on infrastructure you own and are billed for directly.
- Event deduplication verified against real conversions, not assumed from documentation.
- A written record of what data leaves your servers, in what form, and to which platform.
- Alerting, because a broken server container fails without any visible symptom.
Tools and platforms
- Server-side Google Tag Manager
- Google Cloud Run or equivalent hosting
- Meta Conversions API
- Google Ads enhanced conversions
- Uptime and error alerting
Timeline
How long this actually takes
Three to four weeks. The uncomfortable part is the first one: we measure what you are losing before recommending anything, and on plenty of sites the answer does not justify the work. Server-side tracking carries a permanent monthly cost — hosting billed per request, plus the maintenance of one more system that can break — and on a site taking forty conversions a month it recovers a handful. Recovering four conversions a month for a hundred pounds a month plus a build fee is not an improvement, it is a subscription to slightly better reporting. At real volume the arithmetic reverses entirely, and that is the whole reason the assessment comes before the proposal.
Pricing model
Fixed-price project
Fixed price for the build, plus your own cloud hosting billed directly to you rather than marked up through us. If the viability assessment concludes no, you pay for the assessment and nothing further.
Questions
Server-Side Tracking questions
Does server-side tracking get around cookie consent?
No, and any vendor implying otherwise is describing a compliance problem as a feature. Consent applies to the processing, not to where the code runs. A visitor who declines must not have their data forwarded from your server any more than from their browser.
What does a server container cost to run each month?
It scales with request volume. A modest site runs for a few pounds; a high-traffic ecommerce site can run into the hundreds. It is billed to your own cloud account, which we set up in your name so you see the real figure rather than a marked-up line on an invoice.
Will this make our platforms report the same numbers?
No. Attribution windows, view-through counting and modelling still differ by design, and they always will. What improves is the completeness of the data each platform receives, which makes each one more accurate on its own terms. Convergence is not the goal and is not achievable.
What is event deduplication and why does it matter so much?
When the same conversion is sent from both the browser and the server, a shared event ID lets the platform recognise them as one. Without it every conversion counts twice, cost per acquisition halves on paper, and budget gets allocated on a number that is exactly double reality.
Do we still need client-side tracking as well?
Usually yes, running alongside. The browser sees things the server cannot — scroll behaviour, clicks, the front end generally. Most sound setups are hybrid, sending important conversions both ways with deduplication, rather than moving everything server-side as a matter of principle.
How much data does it actually recover?
It varies enormously with audience. A B2B site with a technical readership loses a great deal to ad blockers and recovers correspondingly more. A consumer site on mostly Android and Chrome may recover very little. That is exactly what the first week measures rather than estimates.
What happens if the server container goes down?
Events stop being recorded and nothing on the site looks wrong, which is why alerting is part of the build rather than an extra. Without monitoring, the usual discovery route is somebody noticing a strange-looking month three weeks after it started.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.