GA4 Consent Changes and Server-Side GTM: What Analytics Teams Should Check Now

This article explains how Google’s 2026 GA4 data-control changes affect server-side Google Tag Manager setups, linked Google Ads accounts, Consent Mode signals, conversion tracking, and reporting quality.

Practical default: treat Consent Mode in the web container as the source of truth, and treat the server container as the place where those consent choices must be preserved and enforced. Server-side GTM can improve control over routing and data quality, but it does not bypass user consent.

Executive summary

Google is simplifying how data controls work between Google Analytics 4 and Google Ads. For linked properties, Google’s stated direction is to control data based on where that data is used: Google Ads settings will control Google Ads data, including data shared from Google Analytics, while Google Analytics settings will control data used inside GA4 for behavioral reporting. The practical consequence is that teams can no longer treat a GA4 admin toggle as a complete safeguard for Ads-linked data flows.

The first concrete change is the Google Signals update. Starting June 15, 2026, the Google Signals setting in GA4 is intended to control only the association of Analytics-sourced data with signed-in user information for GA4 behavioral reporting. It is no longer the control that governs the collection of Google Ads cookies and IDs from the Google tag or SDK. That control moves to Consent Mode settings used by Google Ads, with ad_storage being the key signal for advertising storage and advertising identifiers.

This is important for server-side GTM because a server container often gives teams a false sense of insulation. In reality, the consent journey still starts in the browser or app. The user makes a choice in a banner or CMP, the web container or Google tag passes consent parameters to the server container, and Google product tags in the server container adjust what they send based on those signals. The server-side architecture changes where tag processing happens; it does not change the obligation to collect, transmit, and respect consent.

A second point is easy to miss: the 2026 update should not be reduced to ad_storage only. For Ads cookies and advertising identifiers, ad_storage is the central control. For sending user data related to advertising, especially measurement workflows such as enhanced conversions and tag-based conversion tracking, ad_user_data also matters. For remarketing and personalized advertising, ad_personalization matters. For GA4 cookies and analytics measurement behavior, analytics_storage remains critical.

At publication time, Google has given a concrete date for the Google Signals change: June 15, 2026. Google also says that changes to ads personalization controls and IP address controls will follow later in 2026, with more details and exact dates to be shared later. The safest operational response is not to wait for every downstream date. Audit the web consent layer, the server container, and the linked Ads settings now.

What is changing in GA4 and Google Ads

When a GA4 property is linked to Google Ads, Analytics data can flow into the Ads account. Historically, some Ads-related usage was still influenced by settings inside GA4, including Google Signals and Ads personalization settings. Google’s new direction is to remove overlapping controls and make the destination product’s settings decisive: Google Ads controls Ads data, and GA4 controls GA4 behavioral reporting.

For Google Signals, this means a role change rather than a disappearance. The setting remains relevant for GA4 reporting that associates Analytics-sourced data with signed-in Google user information. But it should no longer be relied on as the control that blocks Google Ads cookies, IDs, or advertising data use in linked Ads workflows. In Ads-linked measurement, the consent state passed through Consent Mode becomes the operational control to verify.

For Ads Personalization, Google says it will simplify how GA4 data is managed for ads personalization later in 2026. When the Analytics property is linked to Ads, the Consent Mode signal ad_personalization is expected to become the control for whether that data is used for personalization in the Ads account. This is especially relevant for audiences, remarketing, and personalization-dependent activation.

For IP addresses, Google states that IP addresses automatically collected by the Google tag and SDK will be encrypted and flow to linked Google Ads accounts, where they will be controlled by Google Ads settings, configurations, and terms. Google has not published the exact implementation dates for the IP-address control change at the time of this review, so teams should document the uncertainty rather than invent a fixed internal deadline.

Why server-side GTM does not bypass Consent Mode

Server-side GTM moves part of the tagging workflow away from the browser and into a server container. That can improve endpoint control, reduce client-side vendor exposure, support first-party collection paths, and make event governance more consistent. But consent capture still happens before the server container receives the event. Google’s server-side Consent Mode documentation describes the same sequence: the banner receives the user’s choices, the Google tag sends those preferences to the server container by adding consent parameters to the HTTP request, and Google product tags in the server container adjust data sending based on the user’s preferences.

In practical terms, a server-side setup needs at least two coordinated layers:

• Web layer: a CMP, consent banner, Google tag, or GTM web container that sets defaults and updates consent after user interaction.
• Server layer: a server container with a Google Analytics: GA4 Client that receives requests and consent data, plus consent-aware tags such as GA4, Conversion Linker, Google Ads Conversion Tracking, Remarketing, and Floodlight tags where relevant.

Google’s server-side documentation is explicit that, because of this architecture, Consent Mode only needs to be set up in the web container. That does not mean the server container is irrelevant. It means the server container must receive, preserve, and act on the consent state coming from the web layer. If a proxy, transformation tag, custom client, or custom tag drops consent parameters, the server container can produce misleading measurement behavior even though the banner looks correct to users.

Consent signals that matter

For this topic, four Consent Mode signals should be treated as the minimum audit set:

Consent signal	Main meaning	Why it matters in server-side GTM
ad_storage	Controls storage such as cookies related to advertising.	Determines whether advertising cookies and identifiers can be written or read for Ads and Floodlight measurement. It is the key signal behind the Google Signals control change for Ads cookies and IDs.
analytics_storage	Controls storage such as cookies related to analytics measurement.	Determines whether GA4 can use analytics cookies normally or must switch to blocked, limited, or cookieless behavior depending on the implementation mode.
ad_user_data	Controls sending user data related to advertising to Google.	Required for measurement use cases such as enhanced conversions and tag-based conversion tracking where user-provided or user-related advertising data is sent.
ad_personalization	Controls personalized advertising.	Relevant for remarketing, personalization, and the later-2026 change in which Ads-side personalization control becomes decisive for linked GA4 data.

Several HTTP parameters may appear in debugging. Google documents gcs as the parameter used to transmit ad_storage and analytics_storage. Google also documents gcd as a parameter that encodes detailed information about consent choices and is sent regardless of whether Consent Mode is activated. Parameters such as dma and dma_cps may also be present in some configurations. These fields are useful for debugging, but they should not become a fragile business-rule dependency: Google says consent-mode fields may change as services evolve.

Basic vs advanced Consent Mode in a server-side setup

The distinction between basic and advanced Consent Mode becomes more visible when debugging server-side GTM because the server container may receive very different request patterns.

Mode	Before the user grants consent	What this means for server-side GTM	Reporting implication
Basic Consent Mode	Google tags are blocked until the user interacts with the banner. If the user does not consent, no data is sent to Google, not even the consent state.	The server container may receive no Google measurement request for that user before consent. This is easier to reason about but provides less advertiser-specific modeling input.	Ads conversion modeling relies more on general modeling because the tag has less site-specific signal.
Advanced Consent Mode	Google tags load with defaults, usually denied by default, and send consent state plus cookieless pings while consent is denied.	The server container can receive cookieless or limited requests even when consent is denied. Tags must still avoid reading or writing prohibited identifiers.	Google can use privacy-preserving pings for more advertiser-specific modeling, subject to thresholds and eligibility.

Neither mode is automatically “better” for every site. The decision should match legal requirements, regional consent strategy, product configuration, and internal privacy policy. From an implementation perspective, the key is consistency: the CMP, the web container, and the server container must all reflect the same consent state at the same point in the user journey.

Tag behavior to expect

The most important behavior changes are straightforward, but they are often misread during QA:

• GA4 with analytics_storage: granted: GA4 works normally and analytics storage can be used according to the configuration.
• GA4 with analytics_storage: denied: in basic mode, Google tags are blocked until consent is granted; in advanced mode, Google tags can send non-identifying measurement without analytics cookies. No Analytics cookies should be set, accessed, or read.
• Google Ads conversions with ad_storage: granted: conversion tags can work normally, assuming the server-side Conversion Linker and conversion tag configuration are correct.
• Google Ads conversions with ad_storage: denied: Ads cookies should not be written or read. Google’s server-side documentation describes a conversion pixel request to a domain without third-party cookies rather than normal advertising-cookie behavior.
• Google Ads remarketing with ad_storage: denied: HTTP requests and cookie use are blocked in Google’s documented server-side behavior.
• Floodlight with ad_storage: denied: Floodlight Counter and Sales tags block HTTP requests and cookie use; URL passthrough and Ads Data Redaction behavior depend on configuration.
• Enhanced Conversions: Google’s server-side documentation lists Enhanced Conversions as working when consent is granted, which means ad_user_data and the actual consent collection workflow should be reviewed, not only ad_storage.

For conversion QA, do not simply compare total conversions before and after a banner change. Instead, test each consent state and verify the mechanics: whether cookies are written, whether advertising click parameters such as GCLID or DCLID are preserved where allowed, whether user-provided data is suppressed when required, and whether server-side tags fire, limit, or block requests as expected.

Implementation pattern for web and server containers

A clean setup starts with a default consent state before measurement commands fire. The exact configuration depends on jurisdiction and your legal basis, but a conservative example for a consent-banner region looks like this:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});

After the user interacts with the banner, the CMP or consent template should update the consent state as soon as the choice is known. Google’s documentation specifically warns that consent updates should be tracked on the page where they occur, before any page transition.

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

In GTM, the equivalent pattern should use Tag Manager consent APIs and a proper consent template rather than scattered Custom HTML where possible. For asynchronous CMPs, review whether wait_for_update is appropriate so the Google tag waits briefly for a consent update before sending measurement data. Do not use this as a way to hide slow or unreliable consent logic; use it to prevent race conditions when a valid consent state is expected to arrive almost immediately.

On the server side, confirm that the server container has a Google Analytics: GA4 Client to receive incoming GA4 requests and consent data. Then review all Google product tags that can send data onward, especially:

• GA4 event tags;
• Conversion Linker;
• Google Ads Conversion Tracking;
• Google Ads Remarketing;
• Floodlight Counter and Sales tags;
• any custom tag that forwards data to Google or another advertising endpoint.

Custom server-side tags deserve special attention. Google’s built-in templates are consent-aware; a custom tag may not be. If custom code forwards identifiers, user-provided data, IP-derived data, or click identifiers without checking the event’s consent state, the server-side container can become the weak point even when the web banner is implemented correctly.

Audit checklist for existing setups

Use this checklist before treating the 2026 change as handled:

• [ ] Confirm the GA4–Google Ads link map. List every linked Ads account, Search Ads 360 or Display & Video 360 workflow that uses GA4 data, audiences, conversions, or key events.
• [ ] Document which controls are still GA4 controls and which are Ads controls. Google Signals remains relevant for GA4 behavioral reporting, but it should not be used as the primary Ads data gate after the change.
• [ ] Verify the four consent signals. Check ad_storage, analytics_storage, ad_user_data, and ad_personalization for default and update states.
• [ ] Check timing. Defaults should be set before measurement commands such as config or event. Updates should happen on the page where the user makes the choice and before navigation.
• [ ] Test both accept and reject paths. A setup that only works when the user clicks “accept all” is not ready for Consent Mode governance.
• [ ] Inspect the server request. Confirm that consent parameters reach the server container and are not lost through custom endpoints, transformations, or custom clients.
• [ ] Review server-side product tags. GA4, Google Ads, Floodlight, Conversion Linker, and custom forwarding tags should all behave according to the consent state.
• [ ] Validate Enhanced Conversions separately. Do not assume ad_storage alone is enough; review ad_user_data, user-provided data collection, hashing, and consent evidence.
• [ ] Check remarketing and audiences separately. Review ad_personalization, regional settings, audience activation, and linked-product behavior.
• [ ] Keep a debug record. Save Tag Assistant sessions, GTM preview screenshots, server-container event previews, and test-order IDs for each consent state.

How to debug the change

Google recommends Tag Assistant for verifying Consent Mode on websites. The first check is the earliest Consent event: it should include ad_storage, ad_personalization, ad_user_data, and analytics_storage. Then verify the update after banner interaction and inspect which tags fired or were blocked by the consent state.

For server-side GTM, extend that workflow into the server container preview:

1. Start with a clean browser session so old cookies and previous consent states do not pollute the test.
2. Open Tag Assistant and the GTM web-container preview for the same URL.
3. Test the default state before interacting with the banner.
4. Reject advertising and analytics consent, then verify the web container and server container receive the same denied state.
5. Accept all, then verify that the update is sent before any conversion or key-event request that depends on consent.
6. Inspect server-side GA4 events and downstream tags to confirm whether each tag fired, limited its payload, or blocked the request.
7. Repeat the same test for a conversion journey that includes a click identifier such as GCLID.

The outcome should not be “all tags always fire.” The outcome should be “each tag behaves correctly for the consent state.” For example, with ad_storage: denied, you should not expect normal Ads cookie behavior. With analytics_storage: denied, you should not expect GA4 cookies to be read or written. With ad_user_data: denied, user-provided advertising data should not be sent for measurement use cases that require that consent.

Common failure patterns

The following problems are common in real server-side GTM deployments:

• Consent is set too late. The page sends a GA4 configuration or conversion event before the default consent command or CMP update runs.
• The banner and GTM disagree. The UI shows one state, but the Google tag receives another because the CMP mapping is wrong.
• The server container drops consent parameters. A custom endpoint, transformation, or client changes the request before the GA4 Client or server-side tags can read the consent state.
• Teams only test the accepted state. Many implementations look perfect in “accept all” tests and fail in denied, partial, or region-specific states.
• ad_storage is treated as the only signal. This misses ad_user_data for measurement use cases and ad_personalization for personalization and remarketing.
• Google Signals is still used as a privacy fallback. After the change, this is the wrong control for Ads cookies and IDs in linked-property workflows.
• Custom server tags forward too much data. Built-in Google templates are consent-aware, but custom tags must be reviewed explicitly.
• Regional settings are undocumented. Consent defaults, CMP behavior, and Google tag behavior may differ by region; undocumented differences are hard to defend and debug.

Reporting and conversion impact

The immediate reporting impact depends on the site’s traffic mix, consent rates, implementation mode, and how much measurement previously relied on GA4-to-Ads data sharing. But several expectations are reasonable:

• Ads-linked reporting becomes more sensitive to Consent Mode correctness. If consent signals are missing, late, or wrongly mapped, Google Ads may receive less usable measurement data or data under the wrong state.
• Google Signals settings become less useful as an Ads-side diagnostic. A disabled Google Signals setting does not prove Ads cookies and IDs are suppressed under the new control model.
• Conversion reporting may rely more visibly on modeling. In advanced Consent Mode, cookieless pings can help model gaps when consent is denied. In basic Consent Mode, the model has less advertiser-specific signal because tags are blocked before consent.
• Remarketing and personalization need their own checks. A conversion tag test does not prove that audience activation or personalized advertising has the correct ad_personalization state.
• Enhanced Conversions need separate consent evidence. User-provided data workflows should be reviewed against ad_user_data, data-collection notices, and the advertiser’s consent records.

For analytics teams, the practical goal is not to make reports identical before and after the change. The goal is to make the measurement system internally consistent: user choice → Consent Mode state → server-side tag behavior → Google Ads and GA4 reporting behavior. Once that chain is clear, changes in attribution, modeling, or audience size are easier to explain.

Recommended preparation plan

A practical preparation sequence is:

1. Inventory linked destinations. Identify every Ads, SA360, DV360, Floodlight, and audience workflow that receives GA4 or Google tag data.
2. Define the consent matrix. For each region, document the intended values for ad_storage, analytics_storage, ad_user_data, and ad_personalization before and after user interaction.
3. Review the CMP mapping. Confirm that banner choices map to the correct Consent Mode signals. Do not assume “marketing cookies” automatically maps correctly to every Google signal.
4. Validate the web container. Defaults should be set before measurement commands; updates should fire reliably and early.
5. Validate the server container. Confirm the GA4 Client receives consent data and every server-side Google tag behaves according to the consent state.
6. Run conversion-path tests. Test landing-page, product, lead, purchase, and offline-conversion flows under accepted, denied, and partial consent states.
7. Review Ads and GA4 settings. Update internal documentation so Google Signals, Ads personalization, linked-property controls, and Consent Mode are described in the right roles.
8. Create monitoring alerts. Watch for sudden changes in consent rates, conversion rates, modeled conversions, audience size, and server-side tag errors after deployment.

Timeline and open questions

The timeline should be documented carefully. Google’s official GA4 data-controls page states that the Google Signals change starts on June 15, 2026. That page also says ads personalization changes will come later in 2026 and that more details and exact dates for ads personalization and IP address controls will be shared later.

That means there are two different planning tracks:

• Immediate track: prepare for the Google Signals role change and the Consent Mode control model now.
• Monitoring track: watch Google’s official Analytics, Ads, and Tag Platform documentation for exact dates and implementation details for ads personalization and IP address controls.

Do not describe the whole rollout as indefinitely delayed unless Google publishes that statement. The better editorial phrasing is: the Google Signals change has a stated start date, while exact dates for Ads Personalization and IP Addresses changes were still pending in the official documentation reviewed for this article.

Bottom line

If you use GA4 with server-side GTM and link Analytics data to Google Ads, the safest assumption is that Consent Mode is becoming the operational control surface for Ads-linked measurement. The web container must collect the user’s choice correctly, the server container must preserve and enforce it, and Ads-side settings must be reviewed as the place where Ads data is controlled.

The most important action is to audit the full path rather than a single setting. Turning off Google Signals in GA4 is no longer enough as an Ads privacy control. A reliable setup needs correct ad_storage, analytics_storage, ad_user_data, and ad_personalization behavior across the CMP, GTM web container, server container, and linked Google Ads workflows.

Methodology and sources

This article is based on a review of the provided research document and current Google documentation for GA4 data controls, Consent Mode, server-side Google Tag Manager, Consent Mode HTTP parameters, tag behavior, EEA consent requirements, and Tag Assistant verification. The article focuses on operational consequences for analytics, conversion tracking, and server-side tagging teams rather than legal interpretation.

• Google Analytics Help: Updates to Google Analytics Data Controls
• Google Developers: Implement Consent Mode with server-side Tag Manager
• Google Developers: Set up Consent Mode on websites
• Google Developers: Consent Mode overview and HTTP parameters
• Google Ads Help: Consent Mode reference
• Google Ads Help: About Consent Mode
• Google Ads Help: Verify Consent Mode implementation
• Google Ads Help: Updates to Consent Mode for traffic in the EEA
• Google Analytics Help: Verify and update consent settings in Google Analytics

This article is for technical and operational information only and is not legal advice. metricfixer is not affiliated with Google, Google Analytics, Google Ads, Google Tag Manager, Search Ads 360, Display & Video 360, or Floodlight. Consent requirements, product behavior, Google documentation, and privacy-law obligations may change after publication. Before changing consent, advertising, or data-sharing settings, review the current platform documentation and consult the appropriate legal or privacy specialists for your jurisdiction and use case.