GTM Containers Are Becoming Google Tags: What It Means for Cookie Consent

On May 20, 2026, Google announced the most significant update to Google Tag Manager in years: GTM containers will become Google Tags. The update introduces a concept called Destinations, centralizes Google Tag Settings across products, redesigns the GTM interface, and adds a visual event builder for purchase conversions.

If you manage cookie consent on a site that runs GTM, the first question is obvious: does this break anything? The short answer is no. The merger is a delivery optimization, not a change to how consent signals work. But it does shift the architecture in ways that affect how you think about consent governance, cookie scanning, and the ongoing legal debate about whether GTM itself requires prior consent.

What's Actually Changing: Destinations and the Single Container

Until now, every Google Tag inside a GTM container loaded its own separate gtag.js file. A container with GA4, Google Ads, and Floodlight would trigger three separate script downloads, each with its own configuration. That's three separate HTTP requests and three chunks of JavaScript the browser has to parse and execute, with configuration scattered across each one.

The merger replaces this with Destinations. When you upgrade a container, existing Google Tags migrate into Destinations attached to the main container. All Destinations are handled through the single container JavaScript file. No additional gtag.js loads per Destination. Instead of three script downloads, the GTM container script handles everything: less bandwidth, fewer browser resources consumed, measurable page speed improvement.

Alongside Destinations, Google introduces a centralized Google Tag Settings panel. Settings that you previously configured per Google Tag (cross-domain tracking, user-provided data, consent settings, data redaction) now live in one place and apply to all Destinations. You can still override individual settings per Destination, but the centralized default eliminates the inconsistency that builds up when you manage identical settings across five different Google Tags.

What Doesn't Change: Consent Signal Flow

The critical point for consent practitioners: the upgrade doesn't alter how consent signals work. Consent Mode v2 signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) fire the same way. Your CMP still loads on the Consent Initialization trigger, still sets defaults via setDefaultConsentState, still updates via updateConsentState when the user makes a choice. Tags still respect consent checks. The Additional Consent Checks feature works identically, including the refire bug on once-per-page triggers.

Simo Ahava's analysis of the update confirms what the architecture implies: the upgrade doesn't compromise your compliance setup or introduce additional tracking. It's a delivery change, not a data collection change.

If you're running a correctly configured CookieBeam GTM template on the Consent Initialization trigger, it keeps working after the upgrade. The template's consent signal injection, category-to-consent-type mapping, and data layer events are unaffected because none of these depend on how Google distributes its JavaScript internally. For the full integration setup, see the GTM Integration Guide.

What Does Change: Centralized Consent Settings

While the consent signal flow stays the same, the centralized Google Tag Settings panel changes how you manage consent configuration across Google products.

Previously, if you ran GA4 and Google Ads in the same container, each had its own Google Tag with its own settings. Consent-related configuration like user data redaction, restricted data processing, and cross-domain measurement had to be set per tag. Drift was common: one tag configured correctly, another missed during an update.

With centralized settings, these configurations apply to all Destinations from a single panel. For consent management, this cuts a whole class of misconfiguration bugs. You set user data redaction once; it applies everywhere. You configure Advanced vs. Basic consent mode behavior once; every Destination inherits it. Per-Destination overrides remain available for edge cases, but the default-from-one-place model reduces the surface area for misconfiguration.

If you're auditing a container's consent setup, the centralized settings panel also gives you a single place to verify that consent-related configurations are consistent, rather than clicking through each Google Tag individually.

The Dual-ID System: A New Governance Lever

Every container in the new architecture gets two identifiers: a GTM container ID (GTM-XXXXXX) and a product ID (G-XXXXXX for GA4, AW-XXXXXX for Google Ads). Which ID appears in the deployment snippet determines what the container can do.

Deploy with the GTM container ID and you get full GTM functionality: custom HTML tags, third-party scripts, custom templates, debugging tools. Deploy with the product ID and the container is restricted to Google's own tags only.

For organizations where consent governance is a concern, this distinction matters. A product-ID deployment limits the blast radius: nobody can add a rogue marketing pixel through the GTM interface if the container only accepts Google destinations. For teams that don't need or want the full power of GTM, the product-ID deployment is a governance guardrail that reduces the consent surface.

From a compliance perspective, auditing which ID is deployed becomes a new checkpoint. A container running on a GTM ID can load arbitrary JavaScript, which means the full consent management stack (CMP, consent checks, trigger-based blocking) must be in place. A product-ID container has a narrower scope, and the consent requirements are limited to Google's own consent types.

Fewer Script Loads, Same Cookies: What Your Scanner Sees

If you use CookieBeam's cookie scanner, you might wonder whether the Destinations model changes what gets detected. The answer: not meaningfully.

Destinations consolidate script delivery, not script behavior. GA4 still sets _ga and _ga_XXXXXXXX cookies. Google Ads still sets conversion cookies. The cookies themselves don't change because Destinations changed how the JavaScript arrived. Your scanner's cookie detection, categorization, and drift monitoring work exactly the same.

What does change is the network request pattern. Instead of separate gtag.js requests per Google product, the scanner sees a single container load. If your scanner also tracks outbound connections, you'll see fewer distinct script fetches from www.googletagmanager.com. The underlying measurement requests to analytics.google.com and googleads.g.doubleclick.net remain the same.

The Ongoing Legal Debate: Does GTM Itself Require Consent?

The merger doesn't create new consent requirements for GTM, but it arrives during an active legal debate about whether loading GTM requires prior consent at all.

In March 2025, the Administrative Court of Hanover (VG Hannover) ruled that loading GTM constitutes data processing under both the GDPR and Germany's TTDSG (the national implementation of the ePrivacy Directive). The court found that merely loading gtm.js sends technical data to Google's servers: the user's IP address, device information, and referrer URL. The gtm.js script itself is stored on the user's device. Under Article 5(3) of the ePrivacy Directive, accessing or storing information on a user's terminal equipment requires consent unless it's strictly necessary for a service the user requested.

The ruling is regional (Lower Saxony) and not binding across the EU, but it set a precedent that other regulators may follow. It means organizations in Germany (and, to be cautious, across the EU) face a question: should the CMP load before GTM, gating the container itself behind consent?

The GTM/Google Tag merger reinforces the argument that GTM isn't a neutral, data-free container. As the merged product takes on the functions of Google Tag directly (transmitting analytics and marketing data to Google without separate gtag.js loads), the line between "container that loads scripts" and "active data processing tool" gets harder to draw. The ePrivacy blog analysis puts it directly: GTM will no longer merely serve as a vehicle for further processing activities, but will itself be able to transmit data to Google.

This doesn't change the legal analysis overnight. Organizations that already treat GTM as requiring consent won't need to adjust. Those that currently load GTM without consent should assess their position, particularly if they operate in Germany or serve German visitors.

Don't Confuse This with the April 2025 Auto-Loading Change

The May 2026 merger gets conflated with a separate, already-live change that has a bigger immediate impact on consent: since April 10, 2025, GTM auto-loads a Google Tag with full configuration when Ads or Floodlight event tags fire without a corresponding Google Tag already present in the container. This was mandatory, with no opt-out.

The auto-loaded tag enables Enhanced Conversions (hashing and sending email, phone, and address data from page forms) and automatic event detection. If Consent Mode is absent or misconfigured, hashed personal data can be sent to Google without a legal basis. The auto-loaded Google Tag follows the same consent state as the event tags that triggered it, so if those tags aren't gated behind proper consent checks, the auto-loaded tag inherits that gap.

If you haven't audited your container for this change yet, do it now. Verify that all Ads and Floodlight tags respect consent triggers, and confirm that a consent default (via your CMP or a custom template on the Consent Initialization trigger) is in place before these tags can fire. This is a higher-priority action item than the May 2026 Destinations upgrade.

The Visual Event Builder: Proceed with Caution

The new GTM interface includes a visual event builder (or "guided setup") that walks you through configuring purchase conversions by clicking elements on your actual website. It generates tags, triggers, and CSS-selector-based variables automatically. Currently in beta for Google Ads purchase conversions only.

From a consent perspective, two things matter here:

First, it creates tags that still need consent configuration. The auto-generated tags are Google Ads conversion tags. Like any conversion tag, they need proper consent checks. The visual builder doesn't automatically configure Additional Consent Checks or set up trigger-based consent gating. After using the builder, you still need to verify that the generated tags respect consent signals. Check the consent overview report to confirm generated tags aren't in the "Consent Not Configured" bucket.

Second, it relies on CSS selectors for business-critical data. The builder scrapes transaction IDs, conversion values, and currency codes from the page by selecting DOM elements. This approach is fragile: dynamic receipt pages, CSS class name changes, or framework updates can silently break conversion tracking. If you're in e-commerce and rely on these conversions for ad optimization, building them into the data layer is still the more reliable and auditable approach.

The UI Redesign: Where Did Everything Go?

The GTM interface is getting a visual overhaul. The Overview dashboard, previously a wall of visual clutter, now shows a condensed table: modified/added/deleted entities in the current workspace, a visualization of Google Tags and Destinations, container diagnostics, and a sortable list of changes.

The bigger change for daily workflow: the left navigation is now collapsible. Triggers, Variables, Templates, and Folders are hidden behind a "Show more" toggle. Only the Overview and Tags are visible by default. Once the Google Tag Settings feature rolls out, that link will also appear in the default navigation.

This is clearly aimed at newcomers who'll arrive when their standalone Google Tags get upgraded to GTM containers. If you're an experienced practitioner who lives in Triggers and Variables, the extra click will sting, but the choice persists: click "Show more" once and it stays expanded.

For consent auditing, the simplified navigation doesn't affect functionality. The consent overview report, tag-level consent settings, and all Advanced Settings remain where they are. It's a presentation change, not a capability change.

What You Should Do

The merger is opt-in and doesn't require immediate action. That said, a few things are better done before you upgrade than after.

1. Don't rush the upgrade. Your existing container works fine. Wait for the rollout to stabilize and for the consent management community to document edge cases. Preview and test in a workspace before publishing.
2. Verify your CMP loads independently. If your consent banner loads through GTM (as a Custom HTML tag or via the container), consider whether that's sustainable given the Hannover ruling. CookieBeam loads via a direct CDN snippet by default, sidestepping this issue.
3. Audit your Google Tag Settings after upgrading. When you do upgrade, check the centralized Settings panel. Verify that consent-related settings (user data redaction, restricted data processing) are configured correctly and consistently across all Destinations.
4. Check the consent overview report post-upgrade. After migrating Google Tags to Destinations, confirm that all tags still appear correctly in the consent overview. Migration shouldn't change tag-level consent configuration, but verify.
5. Audit the deployment ID. Know whether your container is deployed with a GTM ID or a product ID. If governance matters to your organization, the product-ID deployment limits what the container can do and narrows the consent surface.
6. Re-scan after upgrading. Run a cookie scan after the upgrade to confirm that the cookie and connection footprint hasn't changed. It shouldn't, but a scan is cheap and a regression is expensive.
7. Keep your Consent Mode v2 setup current. The merger doesn't change consent signal mechanics, but it's a natural checkpoint to verify your implementation covers all four signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) correctly.

The Bottom Line

The GTM/Google Tag merger is a delivery optimization wrapped in a UI redesign. It consolidates script loading, centralizes settings, and adds a governance layer via the dual-ID system. For consent management, the mechanics stay the same: your CMP fires on Consent Initialization the same way it did before, signals flow through the same APIs, and tag-level consent checks haven't moved.

The real shift is architectural. Fewer moving parts (one container JS instead of multiple gtag.js loads), a single settings panel instead of per-tag configuration, and a clearer line between "full GTM container" and "Google-products-only deployment." For consent practitioners, fewer things can go wrong. For the legal debate about whether GTM itself requires consent, the merger adds weight to the argument that the container is an active participant in data processing, not a passive loader.

The consent infrastructure you've built isn't going anywhere. But if you haven't reviewed it lately, the merger is a good excuse to run that audit.