Server-side tracking: what it changes in your eshop's tracking, and when it's worth the effort.

In ordinary (client-side) tracking, the visitor’s browser loads a script for each platform: one for GA4, one for Google Ads, one for Meta. Each one sends its own data straight to its platform, and you don’t see what was sent.

With server-side tracking, the browser sends the tracking data once, to a server that belongs to you and answers on an address in your domain, such as metrics.example.com. On it runs a Google Tag Manager server container, which reads each event, keeps what’s needed and forwards it to each platform.

The page still has the Google tag or a Tag Manager web container. Server-side doesn’t replace the tracking on the page; it changes where it goes.

Google describes three benefits, and in practice these are the ones that count:

• Control over the data. The server can check, anonymise or block an event before it reaches a platform. The platforms see a request from your server, not from the visitor’s browser, so you can choose not to give them the visitor’s IP address.
• A lighter page. The browser sends one request instead of several near-identical ones, and loads fewer scripts. On an eshop with many tags, you notice the difference on a phone.
• Better data. Cookies are set from your own domain, with the HttpOnly setting, which according to Google makes them more durable and more secure. And the server can add details to an event that shouldn’t be visible in the browser, such as the profit margin from your business software.

That last one is often the most practical reason. If you want Google Ads to chase profit rather than revenue, the value of each purchase has to come from the cost of the products, and only your business software knows that.

This is where most of the exaggeration happens, so it’s worth being clear.

• It doesn’t remove the need for consent. The script on the page still reads and sends information from the visitor’s device, and that needs consent. The European Data Protection Board says so too, in its Guidelines 2/2023: when JavaScript code instructs the browser to send information, that is “gaining of access” to the device.
• It doesn’t get around the visitor’s choice. Consent Mode is set up on the page, the choice reaches the server with every request, and Google’s tags on the server follow it.
• It doesn’t promise to get past ad blockers or browser limits. Google doesn’t list that among the benefits, and nobody should promise it on your behalf.
• It doesn’t fix wrong tracking. If “Add to cart” counts as a purchase, it will keep counting as a purchase, only now from the server. The basics come first: see the guide Google Ads for eshops: getting conversion tracking right.
• It isn’t free. The server costs money every month and needs someone to keep an eye on it.

With server-side tracking, “Reject” works just as it does without it. Google describes what happens for each tag:

• GA4: with basic Consent Mode, the tags don’t load at all. With advanced, they send only cookieless pings, and no Analytics cookie is written or read.
• Google Ads: no Google Ads cookies are written or read, and remarketing gets no data.
• Enhanced conversions: work only when the visitor has given consent.

The sale isn’t lost, though. The order exists on the eshop and in your business software, whatever happened in the browser. That’s where you see your real sales figures; Google Ads needs them to learn, not to tell you how much you sold.

There is also a middle way: the Google tag gateway, which loads Google’s scripts from your own domain, through the CDN or the server you already have. It doesn’t filter anything, but it moves tracking onto your own domain. Google recommends combining it with server-side tagging.

What changes	Client-side	Google tag gateway	Server-side tracking
Where the scripts load from	The platforms’ domains	Your own domain	Your own domain
Who sends the data to the platforms	The browser, to each one separately	The browser, through your domain	Your own server
You control what is sent	No	No	Yes, event by event
Data from your business software	No	No	Yes
Needs consent	Yes	Yes	Yes
A separate server with a monthly cost	No	No, it runs on what you already have	Yes

For an eshop that advertises only on Google, the tag gateway together with proper Consent Mode and enhanced conversions often covers most of it. Server-side adds the control and the data from your business software.

It’s worth it if most of these are true:

• Your basic tracking is already right: the purchase counts once, with its value, with a banner and Consent Mode v2.
• You advertise on more than one platform, e.g. Google Ads and Meta, and the scripts weigh the page down.
• You want to control what data leaves the site, or not to give the platforms your visitors’ IP addresses.
• You want each purchase’s value to come from the profit, with data from your business software that mustn’t reach the browser.
• You have enough traffic for the server’s monthly cost to be small next to your ad budget.

It isn’t worth it yet if:

• Conversions are counted wrong, or there’s no banner. Fix those first; server-side would copy the same mistakes.
• You advertise only on Google, on a small budget. There, Consent Mode v2, enhanced conversions and, if you like, the tag gateway are enough.
• There’s nobody to keep an eye on the server. A server that goes down without anyone noticing loses tracking silently, for days.

The server container needs hosting: on Google Cloud (Cloud Run) or with hosting services built for server-side tagging. For Cloud Run, Google’s guide recommends at least 2 servers, so that no data is lost if one goes down, and estimates that 2 to 10 servers handle 35 to 350 requests per second.

The cost depends on your traffic and is paid monthly. We recommend that the hosting account is in your business’s name and that you pay it directly, as with Google Ads. That way the server, the data and the settings stay yours, whoever looks after them.

Allow for maintenance too: container updates, checks that the server is responding, and a fresh check of the tracking every time something changes on the eshop, such as a new payment method.

1. We check the basics: what counts as a purchase, at what value, and whether the banner follows the Hellenic Data Protection Authority’s recommendations 1/2020.
2. We write the tracking list: every event, its data, where it goes and what needs consent.
3. We set up the server on your own account, on an address in your domain.
4. We set up Consent Mode on the page, so that the visitor’s choice reaches the server.
5. We move the tags one by one, GA4 first and then Google Ads, and compare the numbers before and after.
6. We test with “Accept” and with “Reject” and check what reached each platform.
7. We add monitoring, so that if the server stops responding, you know the same day.

See how we combine it with your campaigns and phone sales on the page Google Ads & sales tracking.