Consent compliance isn’t a checkbox. Here’s how to wire it into your sGTM setup correctly.
The Compliance Gap in Most sGTM Setups
Moving to server-side GTM doesn’t automatically make your tracking compliant. It gives you more control — but more control means more responsibility to implement consent handling correctly.
The most common mistake: implementing Consent Mode V2 on the browser-side GTM container and assuming that’s sufficient. It’s not. Your sGTM container processes events independently. If it’s not enforcing consent at the server level, it can and will process data for users who declined.
Stape’s consent architecture closes this gap.
What Consent Mode V2 Actually Requires
Google’s Consent Mode V2 introduced two new signals on top of the original four:
- ad_user_data — consent to use personal data for advertising purposes
- ad_personalization — consent to use data for ad personalization
Both signals are required for full compatibility with Google’s Enhanced Conversions and audience features. Without them, Google limits what it can do with the conversion data you send — even if the event fires correctly.
These signals need to be collected by your CMP, passed to your GTM web container, and forwarded to your sGTM container — where your server-side tags actually enforce them.
The Signal Chain: CMP → Browser GTM → sGTM → Tag
Here’s how a properly wired consent setup flows:
- CMP fires user makes a consent choice on your banner. The CMP updates window.dataLayer with consent state.
- Browser GTM reads the signal your Consent Initialization trigger captures the consent state and maps it to Consent Mode V2 variables.
- GA4 client forwards the signal the GA4 client in your sGTM container receives the consent state as part of the incoming event payload.
- sGTM tag checks consent state tags configured with consent requirements will only fire if the relevant consent signals are present and granted.
- Stape Power-Ups enforce consent Enricher and Store are gated — they check consent state before storing or reusing any data.
| ⚠️ The chain breaks if any link is missing. The most common failure point is step 3: the sGTM container never receives the consent signal because it’s not being forwarded from the browser container. |
Configuring Consent Mode in Stape
Step 1: Ensure your CMP forwards consent to dataLayer
Your CMP (OneTrust, Cookiebot, Usercentrics, etc.) must push a dataLayer event with consent state. Verify this is happening before configuring anything in GTM.
Step 2: Set up Consent Mode variables in browser GTM
Create variables that read each consent signal from the dataLayer push. Map them to the six Consent Mode parameters: analytics_storage, ad_storage, functionality_storage, personalization_storage, ad_user_data, ad_personalization.
Step 3: Configure the GA4 Configuration tag to forward consent
Your browser-side GA4 Configuration tag must pass consent state in the event data so that it’s available when the event reaches your sGTM container.
Step 4: Configure consent checks on sGTM tags
Each tag in your sGTM container should have its consent requirements configured. For Meta CAPI: ad_storage + ad_user_data. For Google Ads: ad_storage + ad_user_data + ad_personalization. Tags will not fire for users who have not granted the required signals.
Step 5: Gate the Enricher and Stape Store
Inside the Enricher Power-Up settings, enable both consent gates:
- Only set cookie if marketing consent is given
- Only store data if marketing consent is given
These settings ensure the Enricher does not create persistent user profiles for users who declined tracking. No stored data, no enrichment, no exceptions.
Testing Your Consent Setup
Never deploy a consent configuration without testing it across all consent states. Use GTM Preview mode and your sGTM container’s debug view simultaneously:
- Accept all — verify all tags fire, Enricher stores data, full event data reaches endpoints.
- Decline all — verify no tags fire for personalization, Enricher does not set cookie, Store does not write data.
- Partial consent (analytics only, no ads) — verify analytics tags fire but ad platform tags do not.
- No consent choice yet — verify your default consent state is set correctly and tags behave accordingly.
| 🚨 Test declined consent state especially carefully. A misconfigured sGTM setup can fire tags for declined users silently — and you won’t see it in GA4 or your ad platform dashboards. |
Common Mistakes
Across dozens of sGTM audits, these are the consent failures that appear most frequently:
- Consent signals not forwarded from browser GTM to sGTM — sGTM has no idea what the user consented to and fires everything.
- Default consent state set to granted — tags fire before the user makes a choice, violating ePrivacy requirements.
- Enricher enabled without consent gates — personal data stored for all users regardless of consent status.
- Consent Mode V1 only (missing ad_user_data and ad_personalization) — Google limits Enhanced Conversion functionality.
- CMP and GTM consent events out of sync — consent state captured before CMP fully initializes, resulting in incorrect default state.
The Bottom Line
Consent Mode V2 compliance in a Stape sGTM setup requires deliberate configuration at every layer: CMP, browser GTM, server GTM, and Power-Up level. The good news is that Stape’s architecture is designed for this — the consent gates are built into the Power-Ups, not bolted on afterward.
Get the consent chain right and your tracking is both compliant and maximally effective. The two are not in conflict — properly implemented, Consent Mode V2 with Stape enrichment gives consented users’ data a level of quality and signal richness that more than compensates for the correctly excluded non-consenting users.
Tuhin — Analytics & Server-Side Tracking Specialist • AnalyticsRush.com