Server-Side GTM + Consent Mode v2: The Complete Setup Guide

What Server-Side GTM Changes

With client-side GTM, tags run in the user's browser. Requests go directly from the browser to Google (and other endpoints). With server-side GTM, you run a tag server (e.g. Stape, Google's own server-side container, or self-hosted) that receives events from the browser and then forwards them to Google Analytics, Google Ads, and other tools. The browser talks to your server; your server talks to Google.

That shift has real implications: first-party cookies on your domain, reduced ad-blocker impact, and the ability to enrich or filter data before it hits Google. But it also means consent is no longer "obvious" to the server unless you explicitly send it. If the browser never tells the server whether the user accepted or rejected cookies, the server has no way to respect consent. So the first rule of server-side GTM + Consent Mode v2 is: consent must propagate from client to server.

In a client-only setup, gtag and GTM run in the page; when the user accepts or rejects, the CMP calls gtag('consent', 'update', ...) and all subsequent requests from that page carry the consent state. With server-side, the browser sends events to your endpoint (e.g. https://your-container.example.com/collect). That endpoint does not automatically know what the user chose unless the client includes it in the request. So you must design the flow so that every event (or at least the first one in a session) carries consent state, and the server uses it to decide whether to forward to Google and how (full event vs. modeled).

Many teams move to server-side to improve data quality and reduce blocking, but forget that consent is now a separate pipeline. Getting that pipeline right is what makes server-side GTM both compliant and accurate for Google Ads and GA4.

Server-side setups can increase discrepancies between GA4 and Ads reporting; understanding attribution and consent propagation helps you interpret and fix them.

Example Architecture Flow

A typical consent-aware server-side flow looks like this:

1. User loads page. The page loads with your client-side GTM or gtag and your CMP script.
2. CMP sets default denied. Before any tracking runs, gtag('consent', 'default', ...) runs with ad_storage and analytics_storage set to "denied".
3. User clicks Accept (or Reject). The consent banner captures the choice.
4. gtag updates consent. The CMP calls gtag('consent', 'update', ...) with the user's choice (granted or denied).
5. Event sent to sGTM endpoint. When an event fires (e.g. page_view, conversion), the client sends it to your server-side GTM endpoint (e.g. Stape). The request must include the current consent state (e.g. in the payload or via a first-party cookie).
6. Server reads consent variable. The server container reads consent from the incoming request and populates a variable (e.g. "Consent - ad_storage").
7. Server decides whether to forward to Google. Tags that send data to GA4 or Google Ads only fire when consent is granted (or they pass the consent state so Google can apply modeling when denied).

If step 5 or 6 is missing, the server has no consent signal and may forward everything or nothing. Getting steps 5 and 6 right is what this guide is about.

Why Client-Side Scanning Is Not Enough

Tools that only inspect the browser (including our own scan) can verify that Consent Mode v2 is set in the page, that the banner appears, and that client-side requests change after accept vs reject. They cannot see what your server does with that consent. They cannot confirm that your Stape (or other) server receives consent state and only forwards conversions when the user has consented.

So a "PASS" in the browser might still mean conversions are sent from the server without proper consent, or that consent is sent but ignored. Conversely, a report that says "Consent Mode v2 not detected" in the browser can be correct for the client while your server-side pipeline still does the right thing if you pass consent via another path (e.g. first-party cookie or request header). For the full picture, see why Google Ads conversions break and how server-side and consent interact.

In practice: we can tell you whether the client is sending consent in requests to your server (e.g. by inspecting payloads or headers in the network tab), and whether behavior in the browser changes after accept vs reject. We cannot audit your Stape or GTM server configuration, or confirm that server-side tags only fire when consent is granted. That gap is why we explicitly call out "server-side detected" in reports and recommend manual verification of propagation and server triggers.

Bottom line: use client-side scanning to validate browser behavior; use server-side checks and documentation to validate that consent reaches your tag server and is applied there.

How Consent Must Propagate from Browser to Server-Side GTM

Consent propagation means: when the user clicks Accept or Reject, that choice must reach your server in a form it can use. Common approaches:

• Client sends consent in the request: The browser includes consent state (e.g. from gtag/dataLayer) when it sends events to your server. The server reads that and only forwards to Google when consent is granted (or uses it for modeling when denied).
• First-party cookie: The CMP sets a first-party cookie with the user's choice; the server reads that cookie on incoming requests and applies the same logic.
• Server-side Consent Mode / GA4 consent params: If you use Google's Measurement Protocol or GA4 client that forwards to your server, consent parameters (e.g. gcs) must be included and your server must pass them through or enforce them.

Implementation detail matters. For example, with GA4 and Measurement Protocol, the client can send a consent payload (e.g. ad_storage, analytics_storage) in the event. Your server must either forward that to Google so modeling works correctly, or only send full events when consent is granted. If you strip consent from the payload or never send it, Google cannot apply Consent Mode v2 behavior on the server side.

If consent never reaches the server, or the server ignores it, you risk sending conversions for users who rejected cookies. That breaks compliance and can distort attribution. For more on how consent and tracking interact in the browser (and what we can and cannot verify), read about tracking before consent.

Common Stape (and sGTM) Mistakes

Stape is a popular way to run server-side GTM. These mistakes show up often:

• Not sending consent from client to server: The client has Consent Mode v2, but the tag that sends events to Stape doesn't include consent state. The server then forwards everything, or guesses wrong.
• Wrong trigger order: Conversion or GA4 tags fire on the server before consent has been received or evaluated. First request should carry (or be preceded by) consent.
• Ignoring consent in server triggers: Server-side tags run without checking consent. They should only fire (or only send to Google) when consent is granted for the relevant purposes.
• First-party cookie not set or not read: If you rely on a cookie for consent, the CMP must set it and the server must read it on every request. Missing or stale cookie = wrong behavior.
• Testing only "accept" path: You verify conversions when the user accepts, but never test that they stop or change when the user rejects. Both paths must be tested.
• Client container not configured to send consent: The GA4 or Google Ads tag in the client container might be set to send to your Stape URL, but the consent parameters are not included in the request. Check that your client-side tag configuration passes consent state (e.g. via GA4 consent settings or custom parameters) to the server.
• Server variable not populated: Even when the client sends consent, the server container might not have a variable that reads it from the incoming request. Without that variable, server-side tags cannot use consent in their triggers.

Fixing these usually means: (1) ensuring the client sends consent (e.g. in the request body or headers), (2) mapping that into a server-side variable, and (3) using that variable in triggers so tags only run when consent is granted (or so you pass the right consent state to Google for modeling). Document the flow so that when you or a colleague change the CMP or the server container, consent propagation is not accidentally broken.

How to Verify Consent Propagation in Server-Side GTM (Step-by-Step)

Verification is a mix of client and server:

1. Browser: In DevTools, after Accept, confirm that requests to your server (e.g. Stape endpoint) include consent-related data (e.g. gcs, or your custom header/cookie). After Reject, confirm the same requests show denied (or no tracking payload).
2. Server logs / GTM Preview: In GTM server container preview (or Stape logs), confirm that the consent variable is set and that tags that require consent only fire when it's granted.
3. Google Analytics / Ads: In a test flow, accept and complete a conversion, then check that the conversion appears. In another session, reject and do the same; the conversion should not appear (or should be modeled only if you use Consent Mode v2 modeling).

For step 1, use a fresh incognito session: load the page, open Network tab, filter by your server domain. Click Reject and note whether the first (and subsequent) requests to your server include a consent-denied signal. Clear cookies, reload, click Accept, and confirm the requests now include consent-granted. The exact parameter names depend on your setup (GA4 uses gcs; custom implementations may use headers or body fields). For step 2, use the server container's preview/debug mode and fire a test event with consent granted, then with consent denied; the tags that depend on consent should fire only when granted.

A browser-based scan can only do step 1 and part of the picture. For a full diagnostic of client-side consent and tracking (including server-side detection), run a free scan; then complement with server-side checks above. For ongoing monitoring, use ConsentCheck monitoring to catch when client behavior changes (e.g. after a CMP or GTM update).

Modeling vs Full Attribution

With Consent Mode v2, Google can use "modeled" conversions: when the user denies cookies, no full event is sent, but Google can still infer conversions from aggregated signals and modeling. That helps optimization even when you don't send a 1:1 conversion event. With server-side tracking, you might send a conversion from the server (e.g. after a purchase) with consent state attached; Google then attributes it or models it depending on that state.

Full attribution means the conversion event is sent with user consent and is attributed to the campaign. Modeling means no such event is sent, but Google estimates contribution. Both are valid; the important part is that you don't send full conversion data without consent. When you do send from the server, include the correct consent parameters so Google can classify the event (e.g. for modeling vs. direct attribution). If you strip or omit consent, Google may treat the event in a way you don't expect.

If you're unsure why GA4 and Google Ads show different conversion counts, see why Google Ads shows 0 conversions but GA4 shows events. That article covers client-side consent and tagging; the same principles apply on the server: consent state must be consistent and correctly passed so that GA4 and Ads both receive the right signals.

Server-Side GTM + Consent Mode v2 Checklist

• Consent Mode v2 (default denied, update on CMP choice) implemented in the browser before any tracking loads.
• Client sends consent state to your server (e.g. in event payload, header, or first-party cookie).
• Server-side container receives and maps consent into a variable.
• Server-side tags that send conversion or analytics data to Google only fire when consent is granted (or pass consent for modeling when denied).
• Test both Accept and Reject: verify client requests and server behavior differ.
• Document how consent propagates for your setup (for audits and future changes).
• Use a client-side scan to verify browser behavior; use server logs and GTM preview to verify server behavior.