Server-side tagging changes where your tags send their data, not what Google Ads can count. It can win back conversions that Safari's cookie limits and ad blockers hide, but it doesn't replace consent, and for most accounts a clean primary conversion and enhanced conversions matter more. Here's how to tell whether it's worth it for you.
Someone in the team has set up Google Tag Manager in a server container, routed it through Stape and Cloudflare, and the question lands on your desk: does Google Ads need this to work properly, and will the bidding get better?
It's a fair question, and the honest answer is "sometimes, a little, for specific reasons". Server-side tagging is a real improvement for some accounts and an expensive habit for others, and the sales pitches around it rarely say which.
Here is what it actually changes for Google Ads, what it doesn't, and how to work out whether it pays for you.
The short answer
- Google Ads bids on the conversions it receives. Server-side tagging doesn't create conversions; it can only stop some of them from getting lost on the way.
- The clearest gain is in Safari: cookies set by JavaScript on a page reached from an ad click expire after 24 hours, while cookies your own server sets can last longer.
- It doesn't replace consent. Google's server tags follow the consent choices the browser sends them.
- Google's own figure for its simpler option, tag gateway, is an 11% uplift in signals, measured as tag loads, not an 11% rise in conversions.
- For most accounts, one clean primary conversion, enhanced conversions and consent mode come first. Server-side is the step after.
What server-side tagging is
Normally, the tags on your website send data from the visitor's browser straight to Google, Meta and whoever else you measure with. With server-side tagging, the browser sends one stream of data to a server you control, and that server passes it on.
Google's introduction describes the server container as one that "doesn't run in the user's browser or on their phone. Instead, it runs on a server that you control", and "only you have access to the data in the server until you choose to send it elsewhere."
There are two common ways to do it. A server container in Google Tag Manager, hosted on Google Cloud or by a provider such as Stape. Or Google tag gateway for advertisers, launched in May 2025 with Cloudflare, which loads your Google tag from your own domain through your content delivery network, without a full server container.
What it fixes
Safari's cookie limits. Apple's Intelligent Tracking Prevention treats the click ID that Google Ads adds to your links as link decoration. WebKit's own documentation spells out the consequence.
So someone who clicks your ad on an iPhone, thinks it over and buys two days later may no longer carry the cookie that ties the sale to the click. A server you run on your own domain can set the cookie in its HTTP response instead, which ITP doesn't cap in the same way.
Simo Ahava, an analytics consultant whose training company Simmer, which he co-founded, teaches server-side tagging, described this in his original guide in 2020: you can convert cookies written with JavaScript "into HTTP cookies written with a Set-Cookie header, thus extending their lifetime to whatever you choose".
There's a catch WebKit also documents: if your tracking subdomain points to a third party, through a CNAME or a third party's IP address, ITP caps those server-set cookies at seven days too. How the server is hosted decides whether the gain holds.
Ad blockers and blocked scripts. Requests to your own domain are blocked less often than requests to Google's. In May 2025, Google reported that "Advertisers who configured Google tag gateway for advertisers saw an 11% uplift in signals." The footnote matters: the uplift is "based on Google tag script loads", over one week in April 2025. More tags loading doesn't translate one to one into more conversions.
Control over what you send. The server can strip IP addresses and other fields before data leaves for a vendor. Ahava puts it plainly in the same guide: "Server-side tagging introduces extra control over privacy simply by existing."
What it doesn't fix
Consent. Server-side tagging changes where tags run, not whether they may. Google's consent mode guide for server containers describes how the browser passes the visitor's choices to the server, and that "Google product tags in the server are consent-aware and adjust the amount and kind of data they send based on the user's preferences." A visitor who says no is still a no.
What you count. If your primary conversion is a page view, or one sale is counted twice, server-side tagging sends those wrong numbers more reliably. Google's bidding can only aim at what you tell it is a conversion.
The conversions that never happen online. A phone order or a sale closed by a salesperson needs an offline import, not a server.
The cheaper steps that usually come first
Before a server, most accounts gain more from three settings in Google Ads itself.
One clean primary conversion. The action that matters, such as a purchase or a lead, set as primary, everything else secondary. Our guide to primary and secondary conversions explains why.
Enhanced conversions. Your conversion tag sends a hashed email address or phone number with each conversion, which helps Google match sales it would otherwise miss. Google's help page describes how it works, and on its Ads Privacy Hub, Google cites the British retailer MandM Direct with "3% more conversions on Search and 20% more on YouTube" from enhanced conversions. That is Google's own case study, not an independent test.
Consent mode. In the EEA (European Economic Area), consent mode lets Google model the conversions of visitors who decline cookies instead of losing them, once your tags send enough data to meet Google's threshold. The same MandM Direct case credits consent mode with a 15% rise.
A worked example
Take a fictional online shop that records 600 orders a month from Google Ads. Here are the assumptions, labelled as such: 35% of its orders come from ad clicks in Safari on iPhone and Mac, and a fifth of its buyers order more than 24 hours after clicking.
That puts about 42 orders a month, 7% of the total, in the group where a JavaScript cookie may have expired before the sale. Not all of those are lost today: enhanced conversions and Google's modelling already recover part of them. Say a server-side setup on the shop's own domain wins back half: about 21 orders a month that Google's bidding now sees.
On the cost side, Google's Cloud Run setup guide estimates "approximately $45 /month (USD)" per server and recommends at least two, so about $90 a month before traffic grows, plus the hours to set it up and keep it running. Hosted providers such as Stape charge their own fees.
For this shop, 21 more orders a month that Google can see is a modest gain. The bigger effect is indirect: Smart Bidding gets a slightly more complete picture of which searches lead to Safari buyers. For a shop with 60 orders a month, the same percentages mean about two.
Where it falls short
The numbers come from the people who sell it. Google's 11% is a signal count from one week, and much of what's written about server-side tagging comes from hosting providers and agencies that set it up. Independent, controlled tests of its effect on Google Ads results are hard to find.
It moves the work, not removes it. A server container is infrastructure. Someone has to update it, watch it and fix it when it breaks, and a broken server loses every conversion that runs through it at once.
Browsers move too. Apple has tightened its rules before, and the CNAME cap shows how quickly a workaround can be closed. A setup that wins back conversions today may win back fewer next year.
It can be used to push past choices it shouldn't. Server-side tagging can technically hide which vendors receive data. Using it to sidestep consent breaks Google's own EU user consent policy, which requires visitors' legally valid consent in the EEA, the UK and Switzerland, and it breaks the trust of your visitors. It isn't what Google's own server tags do.
What we'd do
Fix the conversion first. One primary conversion that is a real result, counted once, with the right value for sales.
Turn on enhanced conversions and consent mode. They are set up in your existing tags and recover conversions without new infrastructure.
Check your Safari share and your time to buy. If few of your buyers use Safari, or most buy within a day of clicking, server-side tagging has little to win back.
Try tag gateway before a full server. If you're on Cloudflare or another supported network, it's the simplest way to serve Google's tag from your own domain.
Go server-side when the volume justifies it. A few hundred conversions a month or more, a team that can run it, and a plan for consent before anything else.
If you use Bavian, it doesn't need server-side tagging to work: Bavian reads your conversions from Google Ads, whatever setup sends them there. With Autopilot on, it checks your conversion settings every day, and if you connect Google Tag Manager, it can set up Google's conversion tag on your website with your yes.
