Server-side tagging moves the collection and forwarding of tracking data from the visitor’s browser to a container running on your own infrastructure. For Google Ads the practical benefit is measurable: across the accounts we have migrated, recorded conversions typically rise by somewhere between 5% and 15%, driven mostly by recovering events that ad blockers dropped and by first-party cookies that survive longer than seven days on Safari. The cost is real too. Expect roughly $60 to $200 AUD per month in hosting plus a genuine implementation project, which is why the honest answer for many small accounts is that it is not yet worth doing.
Quick reference:
- Typical conversion recovery: 5% to 15% more conversions recorded, higher on Safari-heavy and mobile-heavy traffic
- Self-hosted on Google Cloud Run: about $60 to $180 AUD/month for a production setup with redundancy
- Managed hosting (Stape, Addingwell, Taggrs): from about $30 AUD/month, less control, far less setup
- Requires a subdomain on your own domain, for example
sgtm.yourdomain.com.au, plus a DNS change - Does not bypass consent, and configuring it to do so is a compliance problem, not a feature
- Rule of thumb: worth it above roughly $8,000 AUD/month in ad spend, rarely below
What does server-side tagging actually change?
In a standard client-side setup, the visitor’s browser loads Google Tag Manager, executes your tags, and sends data directly to Google Ads, GA4 and every other endpoint you have configured. Every one of those requests is visible to, and blockable by, the browser and its extensions.
In a server-side setup, the browser sends a single request to a tagging server that you control, on a subdomain of your own domain. That server runs its own GTM container, processes the event, and forwards it to Google Ads and anywhere else from the server side. The browser only ever talks to you.
Four consequences follow, and only the first two are usually large enough to matter.
Ad blockers stop dropping events. Blocker lists target known tracking domains. A request to sgtm.yourdomain.com.au is not on those lists and, because it is a genuine first-party endpoint on your own domain, cannot be blanket-blocked without breaking the site. On accounts with technical or younger audiences, this alone accounts for most of the recovered conversions.
First-party cookies live longer. Safari’s Intelligent Tracking Prevention caps cookies written by JavaScript at seven days, a limit Apple introduced in ITP 2.1 and has tightened since. Cookies set by your own server in an HTTP response header are not subject to that cap. For a business with a research phase longer than a week, and most considered purchases have one, this materially improves attribution and keeps remarketing audiences from silently emptying out.
You control what leaves your infrastructure. You can strip, hash or redact data in the server container before forwarding. This is genuinely useful for handling the transparency obligations introduced by the 2024 Privacy Act amendments, because you can demonstrate exactly what is sent to each vendor.
Page performance improves slightly. Fewer third-party scripts in the browser. Real but usually modest, and rarely a reason to do this on its own.
What server-side tagging does not fix
This is where most proposals oversell, so it is worth being blunt.
It does not bypass consent. If a user declines advertising cookies, you still may not track them for advertising. Server-side tagging changes where the request goes, not whether you have permission to make it. Vendors that market it as a way around consent requirements are describing a compliance breach.
It does not fix broken tracking. If your conversion tag fires on the wrong page, double-counts, or passes no value, moving it server-side moves the bug to a more expensive location. Get client-side tracking correct first; our conversion tracking guide covers the failure modes worth checking.
It does not replace enhanced conversions. The two are complementary and work best together. Enhanced conversions improve matching by sending hashed first-party identifiers; server-side tagging improves the reliability of the delivery. Run both.
It does not restore third-party cookies. Cross-site identity is not what this solves. It strengthens your own first-party data, nothing more.
Hosted or self-hosted: which should you choose?
There are two realistic deployment routes, and the decision usually comes down to whether you have engineering capacity available.
Self-hosted on Google Cloud
Google’s own path deploys the tagging server to Cloud Run. You get complete control, your data never passes through a third party, and you can scale it however you like. Google’s server-side tagging documentation sets out the deployment options.
Costs, in AUD, for a typical setup, based on Cloud Run’s published pricing and what we see on client projects:
- Minimum viable production: 2 to 3 always-on instances, roughly $60 to $120 per month
- Moderate traffic (a few hundred thousand events monthly): roughly $120 to $180 per month
- High traffic: scales with request volume, and at that point you have someone who owns this
The trap worth naming: Google’s setup will happily deploy a single instance for testing, and a single instance is not a production configuration. It will cold-start, drop events during traffic spikes, and produce a slow, hard-to-diagnose loss of conversions that looks like a performance problem rather than an infrastructure one. Run at least two, ideally three.
You also inherit real operational duties: monitoring, container updates, SSL certificate management for the custom domain, and someone who notices when the tagging server goes down at 2am during a sale.
Managed hosting
Stape, Addingwell and Taggrs run the infrastructure for you. Pricing starts at roughly $30 AUD per month for low volume and scales with requests. Setup is genuinely much faster, often a couple of hours rather than a couple of days, and they provide useful extras: a proper Safari cookie workaround, GTM client templates, and monitoring you would otherwise have to build.
The trade-off is that your tracking data passes through a third party, which needs to appear in your privacy documentation and your vendor register.
The straightforward recommendation: if you do not have a developer who will own this, use managed hosting. A managed server that stays up beats a self-hosted one nobody is monitoring, and the cost difference is trivial next to the ad spend it is protecting.
How is it set up?
The full implementation is a project rather than an afternoon, but the shape of it is not complicated.
1. Provision the tagging server. Either deploy to Cloud Run from the GTM interface or create a container with a managed provider. Take note of the server container ID.
2. Point a subdomain at it. Create something like sgtm.yourdomain.com.au and add the DNS record your provider specifies, usually an A record or a CNAME. This step is what makes the endpoint genuinely first-party, and it is the step people skip when they want a quick test. A tagging server on a vendor’s domain delivers almost none of the benefit, because browsers treat a CNAME-cloaked third party as third-party anyway and reimpose the seven-day cookie cap.
3. Configure the client. In the server container, set up the GA4 client to receive incoming requests. This is what parses browser events into something the server container can act on.
4. Repoint the browser. In your web container, set the tagging server URL on your Google tag so events go to your subdomain instead of directly to Google. At this point traffic is flowing through your server.
5. Rebuild the Google Ads tags server-side. Add the Google Ads conversion tracking and remarketing tags in the server container, triggered by the incoming events. Keep enhanced conversions configured so hashed identifiers continue to flow.
6. Run both in parallel and reconcile. This is the step that separates a successful migration from a painful one. Run client-side and server-side tracking simultaneously for two to four weeks, into separate conversion actions, and compare the counts. You are looking for server-side to record slightly more than client-side. If it records fewer, something is misconfigured and you have found it before it corrupted your bidding data.
7. Cut over deliberately. Switch your primary conversion actions to the server-side versions, keep the client-side ones recording as secondary for another month, then retire them.
Budget two to four weeks end to end for a straightforward site. E-commerce with a complex checkout, or anything with a subscription flow, takes longer.
Will it change my Google Ads performance?
Not directly, and this is worth understanding properly, because the improvement is indirect and takes time to show up.
More accurate conversion data means Smart Bidding has more and better signal. Automated strategies optimise toward the conversions they can see, so an account that was recording 88% of its conversions was systematically underbidding on the segments where tracking failed most, which tends to be mobile Safari traffic. Feed the algorithm complete data and it reallocates accordingly.
Expect the benefit to appear over four to eight weeks as bidding recalibrates, not on day one. And expect your reported cost per acquisition to improve the moment you switch, partly because you are genuinely capturing more conversions and partly because you have changed the measurement, which means your historical comparison is no longer clean. Mark the cutover date in your reporting so nobody later attributes the step change to a campaign optimisation.
If your account depends heavily on Smart Bidding, the data quality improvement is the strongest argument for doing this at all.
Is your account big enough to justify it?
The economics are not subtle. Total cost of ownership, hosting plus setup plus ongoing maintenance, runs somewhere between $2,000 and $6,000 AUD in year one for most SMEs.
A rough test: if server-side tracking recovers 10% more conversions and that improves bidding efficiency by even 5%, the break-even is around $8,000 AUD per month in ad spend. Below roughly $5,000 per month it is difficult to justify, and the same money spent on landing pages or creative will usually return more.
Three situations move it up the priority list regardless of spend:
- A high share of Safari and iOS traffic. Consumer and mobile-first businesses in Australia often sit well above 30%, and that is precisely the traffic the seven-day cookie cap damages.
- A long consideration window. If your typical path to purchase runs beyond a week, client-side attribution is losing conversions you paid for.
- Existing infrastructure. If you already run server-side tagging for GA4, adding Google Ads is a small increment rather than a new project.
Situations where it should wait: low spend, short and simple purchase paths, or, most importantly, client-side tracking that has not been verified as correct. Work through an account audit first. Fixing a conversion action that fires on the wrong page costs nothing and often recovers more than a migration would.
Frequently asked questions
How much does server-side GTM cost per month? Roughly $60 to $180 AUD per month self-hosted on Google Cloud Run with a production configuration of two or three instances, or from about $30 AUD per month with a managed provider such as Stape or Addingwell. Add setup time: two to four weeks of implementation for a typical site, more for complex e-commerce.
Does server-side tracking bypass ad blockers? Largely, yes. Requests go to a subdomain of your own domain rather than to a recognised tracking domain, so blocker lists do not match them and cannot block them without breaking the site. This is where most of the recovered conversion volume comes from, particularly on technical and younger audiences.
Does it work around cookie consent? No, and any vendor claiming otherwise is describing a compliance breach rather than a feature. Consent governs whether you may process a user’s data for advertising; server-side tagging governs where the request is sent. You still need a consent mechanism and you still must respect refusals.
How much of a conversion increase should I expect? Between 5% and 15% more recorded conversions in the accounts we have migrated, with the higher end on sites with heavy Safari, iOS or ad-blocker usage. Treat any vendor promising 30% or more with scepticism, and run parallel tracking for two to four weeks so you measure your own number rather than accepting theirs.
Do I still need enhanced conversions? Yes. They solve different problems and are strongest together: enhanced conversions improve match quality by sending hashed first-party identifiers, while server-side tagging improves delivery reliability. Configure enhanced conversions within your server-side setup rather than choosing between them.
Can I set this up without a developer? With a managed provider, a competent marketer who is comfortable in GTM can usually get there, with help on the DNS record. Self-hosting on Google Cloud genuinely needs someone who can operate cloud infrastructure, and more importantly someone who will still be monitoring it in six months.
Server-side tagging is infrastructure, not a growth tactic. It makes your measurement more accurate, and accurate measurement makes every automated decision in the account better. But it improves nothing about a campaign that was mistargeted, and it magnifies a tracking error rather than fixing one. Sequence it after your client-side tracking is verified correct, and only once your spend justifies the ongoing cost.
If you are unsure whether your account is losing enough conversions to justify the migration, get in touch and we will look at your traffic mix and tracking coverage before you spend anything on infrastructure.