Server-Side Tagging for the Person Paying for It
04 Sept 2026
Server-Side Tagging for the Person Paying for It
At some point in the last year somebody has told you the tracking needs to move server-side. It was probably your agency, possibly your developer, and the explanation involved cookies, Safari and a diagram. You nodded, because the alternative was a longer meeting.
This is the version for the person who signs the invoice. No diagram.
What a tag does today
When a customer buys something on your site, a small script in their browser sends a message straight to Meta, another to Google, another to whichever other platforms you advertise on. Each message says, in effect, "this person just bought, here is roughly who they are". The platforms use those messages to work out which ads produced sales and to find more people like the buyers.
That has worked for fifteen years and it is now failing, for four reasons that arrived at about the same time.
Browsers limit it. Safari, and increasingly others, restrict how long the identifiers those scripts rely on can live. A customer who clicked your ad on Monday and bought the following week may look like a stranger by the time they buy.
Ad blockers stop it. A meaningful share of your visitors run one, and it blocks the scripts entirely. Their purchases happen. The platforms never hear about them.
Consent removes it. When a visitor declines cookies, the scripts do not run. Again, the sale happens and the ad platforms do not see it.
Phones changed the rules. Apple's app tracking changes cut off a large part of what Meta used to see on iOS.
The result is that the ad platforms are now optimising your budget against a slice of what happened, and the slice is not random. It under-represents Safari users, privacy-conscious people and anyone on an iPhone, which in most categories is your higher-value end.
What server-side means
Instead of the customer's browser sending a message to every platform, it sends one message to a server you control, on your own domain. That server then forwards what is needed to each platform.
Think of it as the difference between a visitor posting a letter to each of your vendors directly, and the visitor handing one note to your own post room, which copies it to whoever should receive it. The post room is the server. You own it, you decide what goes in each envelope, and the visitor only ever dealt with you.
What that changes
More of what happened reaches the platforms. A first-party server on your own domain is treated far more kindly by browsers and blockers than a third-party script. Purchases that were invisible become visible. Bidding improves because the platform is learning from more of your real customers.
You decide what leaves. A browser script takes what it likes. A server sends what you configured it to send, field by field. That is a control question as much as a measurement one, and it is the reason regulated businesses often prefer it.
The site gets lighter. One script talking to one endpoint replaces a dozen talking to a dozen. Pages load faster, which matters for both conversion and search ranking.
Your identifiers last longer. A cookie set by your own domain survives where a third-party one is cut short, so the customer who clicked on Monday and bought next week is recognised as the same person.
What it does not do
It is worth being clear about this, because the claims made for server-side are sometimes larger than the thing.
It does not bypass consent. If a visitor declines tracking, a server-side setup honours that exactly as a browser one should. Anyone telling you it lets you track people who said no is describing a compliance breach, not a feature.
It does not fix a bad data layer. If the purchase event fires twice, or carries gross revenue where it should carry net, or is missing the order ID, moving it server-side moves the fault to a more expensive place. Get the events right first.
It does not solve attribution. The platforms still each claim the sales they touched. Server-side gives them a more complete picture to claim from. It does not make them agree with each other, or with your finance team.
What it involves
A server endpoint, either Google's server-side Tag Manager on cloud infrastructure you pay for, or a dedicated collection platform, such as our own Datafly Signal. The purchase and other events remapped to send through it. Deduplication keys so that a sale seen by both the browser and the server counts once. A consent mechanism that the server respects. And somebody to run it afterwards, because it is infrastructure now, not a snippet.
Set-up is a defined project. The running cost is modest and continuous. The mistake is treating it as a one-off.
Five questions to ask whoever is proposing it
Which fields go to which platform? Ask for the list. If there is no list, nobody has decided.
How is consent honoured on the server? A specific answer, not "it is handled".
How is a sale prevented from counting twice? The word you want to hear is deduplication, with a key.
What will we reconcile against, and to what tolerance? The order table, and a number.
Who runs it in month four? A name, or a retainer.
If those five have clear answers, the proposal is probably sound. If they do not, the problem is not server-side tagging. It is that nobody has designed it yet.
