Server-side tagging routes tracking data through a server you control before it reaches Google or other platforms, rather than sending it directly from the visitor’s browser — this improves data accuracy against ad blockers and browser restrictions, and gives you more control over what data actually leaves your infrastructure, at the cost of meaningfully more setup than standard client-side tagging.
This is a more involved setup than standard Tag Manager
Server-side tagging requires provisioning and maintaining an actual server-side container, typically hosted on Google Cloud, with its own ongoing cost separate from GTM itself — worth doing when data accuracy or control genuinely matters at your scale, not something to take on for a small site with modest tracking needs.
Server-side tagging endpoint configuration
A server-side tagging endpoint set up for real data accuracy, with an honest read on whether you actually need it.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Confirmation of which tags need to move to server-side (not necessarily all of them)
- A Google Cloud account, or willingness to have one created, since the server-side container needs hosting
- Realistic expectations on ongoing hosting cost, separate from this setup fee
This or something else?
| You want server-side tagging set up for meaningful data accuracy or control | This fix covers it |
| You just want standard, reliable client-side tracking | Google Tag Manager container setup, simpler and sufficient for most sites |
| You’re not sure whether you actually need this level of setup | Worth a conversation before ordering; this is more infrastructure than most sites need |
| You want Consent Mode configured, not server-side routing | Consent Mode v2 & cookie banner integration, a different fix |
What we do
- Set up the server-side GTM container and its Google Cloud hosting
- Configure the custom subdomain the server-side container will use
- Migrate the specified tags to route through the server-side endpoint
- Configure client-side GTM to send data to the new endpoint
- Test data flow end-to-end and confirm accuracy against the previous setup
- Document the ongoing hosting cost and how to monitor the server-side container
What is included
- A functioning server-side tagging endpoint for the specified tags
- Verified data flow tested end-to-end
- The client-side configuration updated to route correctly
- A written explanation of the ongoing hosting arrangement
Not included
- Ongoing Google Cloud hosting costs, which are billed to you directly
- Migrating every tag to server-side if only some genuinely benefit from it
- Ongoing maintenance of the server-side container after setup
- Fixing an existing, already-configured server-side setup done elsewhere
Questions about this fix
Do I actually need this, or is standard Tag Manager enough?
For most sites, standard client-side GTM is genuinely enough — this is worth the added complexity mainly at higher traffic or when ad-blocker-related data loss meaningfully affects your reporting or ad performance.
What does the ongoing hosting actually cost?
It scales with traffic volume through Google Cloud, typically a modest monthly cost for smaller sites, though we'll give you a realistic estimate based on your actual traffic before you commit.
Does this replace my existing GTM container entirely?
No, it works alongside your existing client-side container, which sends data to the new server-side endpoint rather than being replaced by it.
Will this fix inconsistent data even if I don't have ad-blocker issues?
It can improve first-party data accuracy in general, though if ad blockers specifically aren't a major factor for your audience, the improvement may be more modest than the added complexity justifies.
Can this be undone if it turns out I didn't need it?
Yes, reverting to client-side-only tracking is possible, though it does mean the Cloud hosting setup was an unnecessary cost — which is why we're upfront about whether this genuinely fits your situation first.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.