Server-side tagging moves your tracking out of your visitors' browsers and onto a server you control, which means Google Ads, GA4 and Meta get a fuller picture of the conversions your ads are bringing in. Whether it's worth doing for your business generally depends on how much you're spending on ads, how much of your traffic comes from Safari and mobile, and how long your customers tend to take before they buy.
There's a lot of hype around it online, so as well as covering what it can do for your Google Ads and Meta campaigns I'll be honest about where it falls short. I've also included a ten-minute check that I'd run before you spend a penny on it.
What Is Server-Side Tagging
Server-side tagging is a way of running your website tracking through a server that you control. Your site sends one stream of data to that server, which usually sits on a subdomain of your own website, and from there the server passes it on to Google Analytics, Google Ads, Meta and whatever other platforms you're using.
Most websites still use client-side tagging and the chances are that's what you've got on your site right now. With client-side tagging every tracking tag, whether that's GA4, the Google Ads conversion tag or the Meta Pixel, loads in your visitor's browser and sends its data straight off to each platform. If you want the detail, Google's own comparison of client-side and server-side tagging sets out the difference well. The main thing to take away is that server-side tagging changes where your data goes first and puts you in charge of what gets passed on.
How Server-Side Tagging Works
I find it easiest to follow the data from your website through to the ad platforms, which roughly goes like this.
- A lightweight script on your website sends one request for each event, like a page view or an enquiry, to a subdomain on your own domain. That's usually something like data.yoursite.co.uk.
- A cloud container sitting behind that subdomain then receives the data. At this point it can check it, tidy it up, strip out anything you'd rather not share and add extra details such as hashed customer data to help with matching.
- Finally, the server builds the separate requests each platform needs and forwards the cleaned-up data on to GA4, Google Ads, Meta and anywhere else you advertise or measure.
According to Google's Tag Manager documentation on server-side tagging, your site performs better because fewer tags are running in the browser, and your visitors' data is better protected because it's collected and shared out from an environment you manage. Google also recommends pointing a subdomain of your own website at the tagging server so it can set first-party cookies that last longer, and that matters most on Safari, which I'll come on to below.
You can host the server container yourself on Google Cloud if you want to, but bear in mind that means running and looking after the infrastructure yourself. Otherwise there are managed platforms that take care of the hosting for you. In most cases the setup only needs one DNS record adding by whoever looks after your domain, so you won't have to configure a reverse proxy or book in a developer sprint.
What It Gets You on Google Ads
Longer Attribution Windows on Safari
Safari's Intelligent Tracking Prevention caps the expiry of client-side cookies at seven days. This applies to cookies set by JavaScript in the browser, which is how standard tracking tags set them.
So say someone on their iPhone clicks your ad, has a look around your site and then comes back a fortnight later to enquire. By then their cookie has expired, so they show up as a brand new visitor and the ad click that started it all doesn't get any credit. If you sell something people take their time over then that's a real hole in your data, and it's that incomplete version Smart Bidding is learning from.
A cookie set by your own server in the HTTP response doesn't fall under that JavaScript rule, so it can last for months, up to the 400-day maximum Chrome allows for any cookie.
The IP Matching Catch
There is a catch though, and it's one a lot of guides on this skip over. Apple's WebKit team also runs what it calls a third-party IP address cloaking defence. If the server setting the cookie sits on a noticeably different IP address to your website then Safari treats it as a third party and caps the cookie at seven days anyway. The WebKit change that introduced this compares the two addresses, and for IPv4 they need to share roughly the first half of the address to count as the same party.
What this means in practice is that your tagging server and your website need to sit on closely matching IP ranges. This is where a lot of DIY server-side builds fall down without anyone noticing, because everything looks like it's working while Safari cookies are still expiring after a week.
TAGGRS has a feature called Cookie Recovery that's built for exactly this problem. It keeps a durable first-party ID cookie and uses it to rebuild the marketing cookies each time someone visits. I think it's a good mitigation, although I wouldn't go as far as calling it a permanent fix. Apple has been tightening things up in this area for years, so I never build a case around any cookie surviving forever.
Better Enhanced Conversions Match Rates
Enhanced Conversions works by sending Google a hashed (scrambled) version of details your customer has already given you, like their email address or phone number, so that Google can match the conversion back to the ad click behind it. Sending that hashed data from your server makes it more dependable, as you're no longer counting on the browser to collect and send everything correctly.
Google says advertisers using enhanced conversions see an average 11% increase in Search conversions. Bear in mind that's Google's own figure for Enhanced Conversions in general, so I'd use it as a guide to what the feature can do and then measure the difference in your own account. If you'd like a hand with the rest of your account too, have a look at my Google Ads management.
Cleaner Offline and CRM Conversion Imports
If your leads turn into sales in a CRM or over the phone then you won't know what a conversion was really worth until well after the click. I see a server-side setup as the natural place to join that online click up with the offline sale and send the value back into Google Ads, so your bidding is working towards actual revenue.
Some Conversions Back From Blockers
Because the requests go to your own subdomain, they're harder for blocklists to catch than requests to well-known tracking domains, so you'll win back some of the conversions that ad blockers are currently stopping. For example, if someone uses AdBlock Plus, Pi-hole, or something similar, it's easy to block common trackers like Tag Manager and Meta, but a server-side tracking script you control won't get picked up. How many you'll get back is the most oversold part of this whole topic, so I'll come back to it further down.
What It Gets You on Meta
Conversions API Done Properly
For Meta, the Conversions API (CAPI) is really the main reason to bother with this at all. The Meta Pixel runs in the browser, and that's where iOS privacy changes, ad blockers and browser restrictions hit hardest. CAPI sends the same events from your server so Meta still hears about the conversions the Pixel misses, and running your Meta Conversions API setup through a server container keeps everything tidy and means you decide exactly what gets sent.
Event Match Quality
Meta gives your server events a score based on how well it can link them to real people, and it calls this Event Match Quality (EMQ). Meta's Conversions API documentation describes it as a score from 0 to 10 that's worked out in real time from which customer details you send, how good that data is and what share of events Meta can match to an account. According to Meta, a high score "may improve ads attribution and performance".
Sending hashed email and phone from your server, along with the fbc (click ID) and fbp (browser ID) values, will lift that score. I tend to treat EMQ as a diagnostic to check in Events Manager, as it's a good way of seeing whether the data you're sending is well formed, but I wouldn't chase the number for its own sake.
Proper Deduplication With event_id
If I had to pick one step to get right it would be this one, because it often goes wrong when CAPI gets switched on through a plugin. If the Pixel and CAPI both report the same purchase then Meta needs to know it's only one purchase. Meta's deduplication documentation says the Pixel's eventID has to match the Conversions API's event_id, and the event names need to match as well. Bear in mind too that Meta only deduplicates events that arrive within 48 hours of the first one with that ID.
If you get it wrong then every conversion gets counted twice, and while your reports will look fantastic, Meta's algorithm is busy optimising towards a picture that isn't real.
Advantage+ Needs the Data
Meta's automated Advantage+ campaigns lean heavily on the conversion events you feed them, and if those events are sparse or patchy then the algorithm is largely guessing who to show your ads to. If you want to read more about how I run paid campaigns, have a look at my PPC services page.
What It Does Not Do
Server-side tagging won't get you around consent. You still need consent for advertising tracking from visitors in the UK and EEA, and Consent Mode v2 still applies. The ICO's guidance on cookies and similar technologies sets out the UK rules if you want to read them in full. Google's consent mode guidance says "you are responsible for obtaining users' consent on your website or app", and Google Ads requires advertisers to collect consent from users in the EEA and share those consent signals with Google if they want to keep using its measurement, personalisation and remarketing features. Moving your tags to a server changes where consent gets enforced, but you still have to ask for it in exactly the same way.
It also won't beat ad blockers. It recovers some of the signal lost to them, but blockers can and do inspect requests in other ways, so plenty still get caught and anyone promising you total recovery is overselling it. To give you a sense of scale, the last figure IAB UK published on ad blocking put it at 23.7% of UK online adults, and 29% of 18 to 24 year olds. That survey is from February 2020 though, so I'd only treat it as a rough guide.
You'll also see some eye-catching percentages quoted for extra conversions and better return on ad spend. Those numbers come from businesses selling server-side tagging and they describe the best case, so I'd treat them as a ceiling. What you actually recover depends on your own traffic mix and sales cycle, and the only way to find out is to measure before and after in your own account.
Do You Actually Need It?
Generally speaking, the more your ad platforms rely on conversion data, the more server-side tagging pays you back. This is roughly how I'd weigh it up for different situations:
| Your situation | My take |
|---|---|
| Personal site, or a small business using GA4 for basic reporting with little or no ad spend | Probably not needed. Standard GA4 with Consent Mode set up properly will do the job |
| Regular Google Ads or Meta spend, mostly desktop traffic and quick decisions | Worth a look, especially for Meta CAPI and Enhanced Conversions |
| Meaningful ad spend with lots of Safari, iPhone and mobile traffic | Worth investigating, as this is where Safari's seven-day cookie cap costs you most |
| A long sales cycle, where people research for weeks before buying or enquiring | Worth investigating for the longer attribution window and offline conversion imports |
| About to scale spend, or launching a new Meta account | A strong case for building it now, before the volume arrives |
The Low Conversion Volume Argument
This one might sound a bit backwards, but low conversion volume is one of the best reasons for a growing business to do this.
Smart Bidding and Advantage+ both need a steady flow of conversions to learn from. If your account sits below the level where they can learn properly then every conversion you recover gets you a meaningful step closer. Going from eight recorded conversions a month to eleven will change how an algorithm behaves far more than going from 800 to 1,100 would.
Timing plays a part as well. If you're launching a new Meta account, building your server-side tracking before launch means it learns from the full picture from day one, whereas adding it months later won't undo what the account has already learned from partial data.
Saying that, if your traffic is very small and you've no plans to scale then you're often better off spending the money on getting more traffic first and coming back to tracking later.
A Quick Check Before You Pay for Anything
Before paying for anything I'd start by pulling three numbers for the same date range: sessions in GA4, clicks in Google Ads and landing page views in Meta. They'll never match exactly, but they should be in the same ballpark.
If the ad platforms are reporting far more clicks than GA4 is reporting sessions then the chances are you've got a basic tracking fault, a problem with your consent banner or an issue with the landing page. That's more urgent than a server-side build and a lot cheaper to fix, so I'd always sort that out first.
How I Set This Up
When I set up server-side tagging these are the parts I wire up because they're the ones that make the real difference:
- A GA4 client in the server container, so your analytics data flows through your own subdomain
- Google Ads conversions with Enhanced Conversions, sending hashed first-party data from the server
- The Meta Conversions API, with the customer data hashed correctly and event_id deduplication so nothing gets counted twice
- Consent Mode, so every tag respects the choices your visitors make
- A proper round of testing to check events land where they should, and only once
The only thing I need from your side is that one DNS record, so a busy web developer or a locked-down website platform shouldn't hold things up.
Like all of my projects, it starts with a free discovery call where we can talk through your ad spend, traffic and goals, and if I don't think it's worth doing yet then I'll tell you straight. Tracking setup is quoted as a one-off fixed project and priced on what your setup needs. Server-side tracking containers are billed separately.
Server-side tracking is part of my wider Google Analytics and GA4 services, where you'll find everything else I do on the measurement side. If you're not sure your current tags are even firing properly, then a tracking audit is the better place to start.
Frequently Asked Questions
Does Server-Side Tagging Get Around Ad Blockers?
No. Server-side tagging recovers some of the data you lose to ad blockers, because the requests go to your own subdomain and basic blocklists miss more of them. Blockers can still inspect and filter those requests in other ways though, so you'll only ever get part of it back.
Is Server-Side Tracking Legal?
Yes, as long as you use it properly. It doesn't change the consent you need, so you'll still need consent for advertising tracking under UK and EEA rules and Consent Mode v2 still applies. If anything I'd say it makes your position easier to show, as you control exactly what data leaves the browser and which platforms receive it.
Can I Use Server-Side Tagging in Google Tag Manager?
Yes, and a Google Tag Manager server container is one of the most common ways of doing it. You can either host that container yourself on Google Cloud or use a managed platform such as TAGGRS, which takes most of the infrastructure work off your hands.
Do I Need a Developer to Set This Up?
Usually not. On a managed platform such as TAGGRS the setup typically needs one DNS record from whoever manages your domain, plus the configuration work in Tag Manager. You won't need to book in a development sprint, and it doesn't matter which website platform you're on.
If you're weighing up whether server-side tagging is right for your business, or you'd just like a second opinion on the tracking you've already got, then drop me a message and I'll be happy to talk it through, even if the answer turns out to be "not yet".
