"Should we move to server-side tagging?" is one of the most common questions I get from EU e-commerce teams right after they finish a Consent Mode v2 rollout. The honest answer is usually: it depends on a problem Consent Mode v2 can't fix, not the one you just fixed.
These two things get bundled together in most agency pitches because they're both GTM projects that show up on the same compliance checklist. But they solve different problems, and buying one when you need the other is a common way to spend a few thousand euros without moving the number you were trying to move.
What each one actually does
Consent Mode v2 is about permission. It tells Google's tags what a visitor has and hasn't agreed to, and adjusts what data those tags are allowed to send accordingly. It's a compliance layer — it doesn't change where your data travels or how much of it survives ad blockers and browser restrictions. A visitor who denies consent still denies consent, server-side or not.
Server-side tagging is about delivery. Instead of the visitor's browser firing requests directly to Google, Meta, and every other vendor's servers, your own server-side GTM container receives the events first and forwards them on your behalf. This matters because a request coming from your own domain looks like ordinary first-party traffic — it doesn't get flagged and dropped by Safari's Intelligent Tracking Prevention (ITP) or by most ad blockers the way a direct request to google-analytics.com does.
Put simply: Consent Mode v2 controls whether you're allowed to measure something. Server-side tagging controls whether the measurement request survives the trip. You can have perfect consent compliance and still be losing 20-30% of your consented traffic to client-side blocking — those are independent failure points.
Why EU stores end up needing both
For a store doing meaningful paid ad spend in the EU, both problems compound:
- Consent Mode v2 already reduces the pool of visitors you're allowed to fully measure, because some percentage will deny consent (this is expected and not a bug — see the
(unassigned)traffic issue that shows up when Consent Mode is implemented with a sequencing bug). - Of the visitors who do consent, client-side tracking then loses another meaningful slice to ITP and ad blockers before it even gets flagged by consent state.
Server-side tagging doesn't touch problem 1 at all. What it does is recover a chunk of problem 2 — the consented visitors your client-side tags are silently dropping. If your Consent Mode setup has a sequencing bug (unrelated to server-side tagging, but common enough that it's usually worth ruling out first), fixing that bug will move your numbers more, and for free, before you spend anything on server infrastructure.
Total visitors
→ minus: consent denied (Consent Mode v2's job to measure correctly, not eliminate)
→ minus: consent granted, but tag never reaches Google (this is what server-side tagging recovers)
= what you currently see in GA4
When server-side tagging is worth it
Server-side GTM isn't free to run — you're standing up and paying for a server container (typically on Google Cloud Run or a similar platform), and someone needs to maintain it. As a rough guideline from the audits I run:
- Under roughly €10k/month in revenue, or minimal paid ad spend: the infrastructure cost and maintenance overhead usually isn't justified yet. Focus on getting Consent Mode v2's sequencing correct first — that's a bigger, free win.
- €10k–€40k/month with active paid acquisition: this is where server-side tagging typically starts paying for itself. The recovered conversion data directly improves ad platform bidding algorithms (Meta CAPI and Google Ads enhanced conversions both perform meaningfully better with server-side-forwarded data), which compounds into lower cost-per-acquisition — meaningful when every euro of ad spend is being watched closely.
- €40k+/month running multiple ad channels: server-side tagging stops being optional at this scale — the data loss from client-side-only tracking becomes large enough in absolute euros that the infrastructure cost (typically well under €100/month to run the container itself) is trivial by comparison.
The technical baseline: what "done correctly" looks like
A server-side tagging setup that's actually delivering value has a few non-negotiable pieces:
1. A first-party custom subdomain, not the default *.appspot.com URL
If your server container is reachable at a generic Google Cloud subdomain instead of something like sgtm.yourdomain.com, browsers and ad blockers can still recognize it as third-party infrastructure and treat it accordingly — undermining the entire point of moving server-side.
2. Consent state still has to reach the server container
This is the step teams most often get wrong: they assume moving to server-side tagging means consent no longer matters. It still does — your server-side GA4 client needs to receive and respect the same analytics_storage and ad_storage values the client-side Consent Mode setup resolved, and drop or anonymize data accordingly. Server-side tagging changes how data travels, not whether you're still required to honor consent.
// Server container GA4 client config still needs consent state forwarded
// from the client-side dataLayer, not assumed granted by default
event('page_view', {
consent_state: {
ad_storage: dataLayer.consent?.ad_storage || 'denied',
analytics_storage: dataLayer.consent?.analytics_storage || 'denied',
},
});3. Client-side fallback stays in place during transition
Don't rip out client-side tags the same day you flip on server-side. Run both in parallel for at least a week, comparing event volumes, before fully cutting over — this is the only reliable way to confirm the server container is actually receiving and forwarding what you expect, rather than silently dropping events.
A GA4 audit tells you exactly how much data your current setup is losing — and whether server-side tagging would actually move the needle for your store.
The order that actually works
If you're starting from scratch, or auditing an existing setup, the sequence matters:
- Fix Consent Mode v2 sequencing first. If your CMP tag isn't firing before your GA4 configuration tag, you have a free, immediate fix available that server-side tagging won't touch.
- Measure your actual client-side data loss. Compare GA4 session counts against server logs or your order platform's own visitor counts over the same period. If the gap is small, server-side tagging has less room to help.
- Only then evaluate server-side tagging, sized to your revenue and ad spend, using the thresholds above.
Skipping straight to step 3 is the most common expensive mistake I see — teams spend on server infrastructure to recover client-side data loss while a Consent Mode sequencing bug is still quietly discarding a much larger and completely free-to-fix chunk of their traffic.
Getting the sequencing right before you scale up
Consent Mode v2 and server-side tagging aren't competing solutions to the same problem — they're two separate layers, and the order you address them in determines whether the second investment is even worth making. Get the compliance layer correct first, measure what's actually being lost, and only then decide if the infrastructure investment pays for itself at your scale.
Let's find out if it's actually the right next step — or if a smaller fix gets you most of the way there first.