Consent Mode with server-side Google Tag Manager works as a relay. Your banner records the visitor's choice in the browser, the Google tag attaches that choice to every request as the gcs and gcd URL parameters, and the server container reads those parameters before it forwards anything to Google Ads, Google Analytics 4, or a third-party endpoint.
Break one link in that chain and the setup fails in one of two directions: consented conversions get dropped, or data leaves your tagging server after the visitor said no. This guide covers the complete wiring - consent defaults in the web container, transport to the server, consent-aware triggers for non-Google tags, and testing across all four consent states. If you're still weighing whether a tagging server is worth running at all, start with the comparison of Consent Mode v2 vs server-side tagging; everything below assumes you're implementing both.
Key takeaways
Consent is collected in the browser and travels to the server container inside each request, mainly as the
gcsandgcdparameters on Google Analytics 4 hits.Native Google tags in a server container (Google Analytics 4, Google Ads, Floodlight) read those parameters automatically, while third-party tags such as the Meta Conversions API need manual consent gating.
Server-side tagging changes where data is processed, not what needs consent: Article 5(3) of the ePrivacy Directive covers any storage or access on the visitor's device, and the European Data Protection Board (EDPB) applies it to pixels, tracking links, and identifiers as well.
France's data protection authority, the CNIL, fined Google EUR 325 million and SHEIN EUR 150 million in September 2025 for placing cookies before consent, so the refusal path deserves as much testing as the acceptance path.
Most broken setups fail at the consent default in the browser, not at the server - set defaults on the consent initialisation trigger before any other tag loads.
How Does Consent State Reach a Server Container?
Consent state reaches the server inside requests your site already sends. When Consent Mode is active, the Google tag appends the visitor's current choices to each hit as URL parameters, and the Google Analytics 4 client in the server container parses them into event data that every server-side tag can read.
Four layers co-operate to make that happen.
| Layer | What it does | What breaks if it fails |
|---|---|---|
| Browser and consent banner | Records the choice and writes consent state through the Consent Mode API | Tags fire consent-blind; defaults never apply |
| Web GTM container | Applies defaults before any tag runs and forwards consent with each request | Hits arrive at the server with no gcs parameter |
| Tagging server (server container) | Parses incoming consent and decides what to forward | Data leaks to vendors after refusal, or consented hits get dropped |
| Vendor endpoints | Receive only what the server forwards | Nothing on their own; upstream errors surface in the vendor's data |
The enforcement point moves in this architecture, and that shift is the reason consent handling needs explicit attention. In a purely client-side setup, consent decides whether a tag fires in the browser at all. On a tagging server, events may arrive regardless of what the visitor chose, and consent decides what leaves your infrastructure for Google, Meta, or anyone else.
What Do You Need Before You Start?
Four components: a consent banner wired to the Consent Mode application programming interface (API), a web Google Tag Manager (GTM) container, a server container deployed on a tagging server you control, and a Google Analytics 4 client inside that server container to receive consent data. Google's official guide to consent mode with server-side Tag Manager lists the same prerequisites.
The consent banner matters more than it looks here. Since March 2024, Google's European Union (EU) user consent policy has required Google Consent Mode v2 signals - including the ad_user_data and ad_personalization parameters - for ad personalisation and measurement aimed at visitors in the European Economic Area (EEA) and the United Kingdom (UK). A Google-certified consent management platform (CMP) writes those signals for you and keeps the category mapping current.
For the server itself, Google recommends Cloud Run with a custom subdomain such as gtm.example.com. Serving from your own subdomain keeps the cookies your server sets in a first-party context, and it stops browser privacy features from treating your measurement endpoint as a stranger.
How Do You Wire Consent Mode Into Server-Side GTM?
The wiring runs in four steps: set consent defaults in the web container, route the Google tag through your tagging server, let the server parse the incoming signals, and gate every non-Google tag on those signals. Native Google tags handle the third step on their own; the rest is configuration you do once.
Step 1: Set Consent Defaults in the Web Container
Defaults have to exist before any tag fires. Fire your CMP template on the Consent Initialization - All Pages trigger and set every consent type to denied for regions where prior consent is the rule:
gtag('consent', 'default', { ad_storage: 'denied', analytics_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied', wait_for_update: 500 });
The wait_for_update value gives the banner half a second to deliver a stored choice before tags proceed. When the visitor decides, the CMP sends gtag('consent', 'update', ...) with the granted types, and every Google tag adjusts from that moment. Region settings let you keep denied-by-default for the EEA while running different defaults where opt-out rules apply, such as most of the United States.
Step 2: Route the Google Tag Through Your Tagging Server
In the Google tag's configuration, set the server container URL to your subdomain so hits go to gtm.example.com instead of Google's domain. Each request then carries consent state in its query string. A granted-everything hit looks like this:
https://gtm.example.com/g/collect?v=2&tid=G-XXXXXXX&gcs=G111&gcd=...
The gcs parameter is the compact consent string for the two storage signals. The newer gcd parameter travels alongside it and encodes all four Consent Mode v2 signals, including whether each value came from a default or from a visitor's update. As of August 2026, Google's tag gateway for advertisers - the renamed first-party mode - also supports server-side tags, so the tag script itself can load through your own domain rather than googletagmanager.com.
Step 3: Let the Server Read the Consent Signals
The Google Analytics 4 client claims incoming requests on your tagging server and parses gcs and gcd into the event data automatically. Native Google tags - Google Analytics 4, Google Ads, Floodlight - read that consent state without extra configuration and behave accordingly.
Reading the string is simple once you know the format.
| gcs value | ad_storage | analytics_storage | Typical situation |
|---|---|---|---|
G100 | Denied | Denied | Visitor rejected everything |
G101 | Denied | Granted | Analytics accepted, advertising refused |
G110 | Granted | Denied | Advertising accepted, analytics refused |
G111 | Granted | Granted | Full consent |
A value of 1 means granted and 0 means denied, with the ad_storage digit first. Requests can also arrive without any consent parameters - direct server-to-server calls, for instance - so decide on a fallback and treat missing consent as denied rather than granted.
Step 4: Gate Non-Google Tags on the Signal
Third-party server tags don't understand Google's consent encoding, so nothing stops a Meta Conversions API tag from firing on a refused visitor unless you stop it. Create an event data variable in the server container that reads the parsed consent state, then add it as a condition on each third-party tag's trigger - for example, fire the Meta tag only when ad consent shows granted. Vendor templates with built-in consent checks do the same job with less manual wiring, and the same logic applies to the browser-side Meta Pixel if you run a hybrid setup. Marketing tags gated this way fail closed: no signal, no send.
Does Server-Side Tagging Change What Needs Consent?
No. Article 5(3) of the ePrivacy Directive requires prior consent for storing or reading information on a visitor's device, and it applies whether the data then flows to Google's servers or to a Cloud Run instance you rent. Moving processing behind your own subdomain changes the network path, not the legal analysis.
The EDPB's Guidelines 2/2023, adopted in final form in October 2024, put that beyond argument. They confirm the rule covers tracking pixels, tracking links, unique identifiers, and some IP-based techniques alongside cookies. The FPID cookie a tagging server sets over HTTP is still storage on the device, and consent to the standard of the General Data Protection Regulation (GDPR) is still what Article 5(3) demands for anything non-essential. Purpose decides a cookie's category - the domain it's set from doesn't.
Enforcement backs this up with numbers. On 1 September 2025, the CNIL fined SHEIN EUR 150 million for placing advertising cookies before visitors made any choice, and in the same enforcement wave it fined Google EUR 325 million over consent failures around cookies and account creation. Regulators check what actually happens in the browser and on the wire, which is exactly the layer a consent-blind tagging server gets wrong; the recent record of cookie consent fines shows refused-then-tracked as the pattern they punish hardest.
Basic or Advanced Consent Mode on a Tagging Server?
In basic mode, Google tags don't load until consent exists, so a refusing visitor's browser sends nothing to your endpoint - no cookies, no pings, no modelling input. In advanced mode, tags load immediately and send cookieless pings even after refusal, which flow through your server and feed conversion modelling in Google Ads and Google Analytics 4.
Which one to run is partly a legal question. Cookieless pings still involve requests from the visitor's device carrying event details, and several European regulators read Article 5(3) broadly enough that sending them after refusal deserves a review by your legal team rather than a default yes. The trade-offs are covered in basic vs advanced consent mode; on the server side, basic mode behaves like the hard gate described in blocking Google Tag Manager before consent - silence until the visitor agrees.
How Do You Verify the Whole Chain?
Test all four consent states end to end, with the refusal paths given the same attention as acceptance. The four gcs combinations each need one pass: pick the state in your banner, watch the web container's Consent tab, confirm the parameter on the wire, and check what the server container fired.
Open preview mode in the web container, trigger the banner, and check the Consent tab on each event - it shows all four signals and whether a default or an update set them.
In the browser's developer tools, filter the Network tab for
collectand inspect requests to your subdomain; thegcsvalue on each hit should match the choice you just made.Open preview in the server container, select an incoming request, and confirm the consent fields are parsed; tags gated on consent should show as blocked when the matching signal is denied.
With everything refused, check the browser's cookie store: no
_ga, noFPID, no advertising cookies from forwarded vendors.
Two independent checks close the loop. A cookie scanner catches anything set outside the consent flow across your whole site, and a free consent mode checker confirms the signals are present and well-formed on any URL.
Common Mistakes That Break the Chain
Almost every broken setup fails at one of five points.
The CMP loads after the GTM snippet, so the first hits of a session go out under the wrong default. Consent defaults belong on the initialisation trigger, ahead of everything else.
A custom transport or proxy strips query parameters, and requests arrive at the server with no
gcsat all. The server then applies whatever fallback you configured - or none.Server tags trigger on every event with no consent condition, which quietly forwards refused visitors' data to third parties.
Only the accept path gets tested. Refusal bugs - cookies set anyway, tags firing anyway - are the exact pattern behind the largest CNIL fines.
The team treats the tagging server as a consent workaround. First-party subdomains change how requests look, not what the law requires.
Frequently Asked Questions
Does server-side GTM remove the need for a cookie banner?
No. Article 5(3) of the ePrivacy Directive requires consent for storing or accessing information on a visitor's device, regardless of where the data is processed afterwards. A tagging server changes the data path, not the consent requirement.
What is the gcs parameter in Google Analytics requests?
It's a compact consent string that Google tags append to each hit, in the format G1 followed by one digit for ad_storage and one for analytics_storage. A 1 means granted and a 0 means denied, so G101 means ads denied and analytics granted.
Do Google Ads and GA4 tags in a server container respect consent automatically?
Yes. The Google Analytics 4 client parses the incoming consent parameters into event data, and native Google tags read that state without extra configuration. Third-party tags such as the Meta Conversions API need manual consent conditions on their triggers.
Does the FPID cookie set by a tagging server need consent?
Yes, when it supports analytics or advertising. FPID is written by your server over HTTP, but it's still information stored on the visitor's device, so the same Article 5(3) consent rules apply as for a JavaScript cookie like _ga.
What is the difference between the gcs and gcd parameters?
The gcs parameter carries only the two storage signals, ad_storage and analytics_storage. The gcd parameter encodes all four Consent Mode v2 signals and records whether each value came from a default or from the visitor's update.
Is Consent Mode v2 still required if all tracking runs server-side?
Yes, for Google advertising features aimed at visitors in the EEA and the UK. Google's EU user consent policy has required the v2 signals since March 2024, and they only reach Google if your setup forwards them.
Wire the Consent Layer Before the Server
A tagging server is only as compliant as the consent signals feeding it. Kukie.io is a Google-certified CMP that sets Consent Mode v2 defaults, blocks non-essential scripts until a choice is made, and records every consent decision for audit. Connect it to your web container and the chain above has its first link in place.
