Major GTM Update: New Google Destination Tags, Shared Settings & How to Upgrade Safely

Google Analytics Destination Tag (GA4 Web Data Stream)

Connects your GTM container directly to your Google Analytics 4 web data stream (G-XXXXXXXXXX). By default, this destination tag initializes your GA4 measurement, applies your container-level shared settings, and automatically dispatches a page_view event (unless overridden in parameters).

Google Ads Destination Tag (AW-XXXXXXXXX)

Connects your GTM container directly to your Google Ads account for site-wide tagging, remarketing list building, and conversion linker initialization. Previously, containers with Google Ads tags had to load a separate Google tag resource first before sending conversion events. With the Google Ads Destination Tag, instructions are bundled natively inside gtm.js.

Floodlight Destination Tag (Campaign Manager 360 & DV360)

Built for enterprise advertisers running Campaign Manager 360 or Display & Video 360 (DC-XXXXXXX). It establishes the Floodlight configuration directly inside the optimized GTM container without requiring external global site tag wrappers.

Conflicting Settings Across Multiple Google Tags ( Especially Server-Side GTM!)

Many advanced setups intentionally use different settings across their Google Tags. For example:

• Your GA4 Google Tag might use a custom Configuration Settings variable containing server_container_url: "https://ss.yourdomain.com" to route hits through your Server-Side GTM (sGTM) container.
• Meanwhile, a secondary Google Ads or Floodlight tag might be configured with different cookie settings, custom user properties, or restricted firing triggers (e.g., firing only on specific country subdomains).

The Danger: When you run the guided upgrade flow and merge your tags into shared container settings without reviewing each parameter, one tag's configuration can overwrite or drop the other’s - either severing your Server-Side GTM pipeline or sending all destinations to the wrong endpoint!

Automatic page_view Firing & Double Pageviews on SPAs

By default, the new Destination Tags automatically dispatch a page_view event when initialized.

If your website is a Single Page Application (built on React, Next.js, Vue, or Nuxt) or uses custom GTM page_view event tags triggered by History Change or custom dataLayer.push({event: 'page_view'}) calls, upgrading to a Destination Tag without auditing its send_page_view parameter can suddenly double your reported pageviews and crush your bounce/engagement rate metrics overnight.

The Wildcard Trigger Trap (.*) Firing on gtag.config

Alongside the Destination Tags rollout, Google updated how configuration commands interact with the GTM Data Layer: gtag.config now registers as a visible event in the Data Layer stream.

Why does this matter? If your container has any tags (such as a Server-Side Data Tag, a universal GA4 event router, or a custom webhook tag) triggered by a Custom Event trigger using a wildcard regex .* without explicit exclusions, that tag will now fire an extra time on every page load when the destination tag initializes!

New "Settings Tab" Consent Defaults Clashing With Your CMP Banner

The new GTM Settings Tab introduces two powerful shared controls:

1. Consent Defaults in the Container
2. Manage Data Transmission Controls

If you already use a Consent Management Platform (like Cookiebot, OneTrust, Usercentrics, or Pandectes on Shopify) that sets consent default via its own template or script, and you accidentally configure conflicting region rules inside the new GTM Settings Tab, your destination tags may hold back conversion data permanently - even after the user clicks "Accept All"!

Google Tag Gateway (First-Party CDN) Load Order Differences

If you serve your Google tags from your own domain using Google Tag Gateway for Advertisers (via Cloudflare, Fastly, Akamai, or Google Cloud Load Balancer), the load order of consent defaults and destination tags depends on your gateway routing. Upgrading your container without verifying gateway compatibility in Preview Mode can break first-party cookie setting.

Document & Export Your Current Baseline Configuration

Before touching the optimization banner:

1. Go to Admin > Export Container in GTM and download a JSON backup of your current live container version.
2. Open your existing Tags list and write down every Google Tag currently firing - noting its Tag ID (G-XXXX, AW-XXXX, DC-XXXX), its Firing Triggers (e.g., Initialization - All Pages vs. specific page filters), and any attached Configuration Settings or Event Settings variables.

Run the Guided Optimization Flow in a Dedicated GTM Workspace

Never run major architectural upgrades in your Default Workspace if other team members are publishing minor edits:

• Create a new workspace named Google Destination Tags Upgrade Test.
• Click the optimization banner or open the new Settings tab.
• Carefully review which Google tags are being converted into Destination Tags (Google Analytics, Google Ads, Floodlight) and which configuration settings are being promoted to shared container settings.
• If one of your tags had unique parameters (such as a custom server_container_url or custom user properties), apply those overrides directly on that individual Destination Tag!

Audit the New "Settings" Tab Against Your Consent Banner

Open the new Settings tab in your GTM workspace:

• Check Consent defaults: Ensure that if you already set default consent states via your CMP tag or website code, the Settings tab does not introduce conflicting regional rules.
• Check Manage Data Transmission (under Show more): Note which data types are restricted when consent is ungranted so you know what behavior to expect during testing.

Test Everything Thoroughly in GTM Preview Mode (Tag Assistant)

Click Preview in the top right corner of GTM and run through your entire customer funnel:

1. Check Initialization Order: Verify that Consent Initialization still fires first, setting your consent defaults before any Destination Tag executes.
2. Verify Destination Delivery: Click on your new Google Analytics, Google Ads, and Floodlight Destination Tags in Tag Assistant. Confirm they fire on the intended triggers and carry the exact configuration parameters they had prior to the upgrade.
3. Check for Wildcard Trigger Misfires: Click on the config event in the left-hand Tag Assistant timeline and verify that no custom event tags (using .* regex) accidentally fired on it.
4. Complete a Test Conversion: Trigger a real lead form submission or test checkout purchase. Verify in GA4 DebugView and Google Ads Conversion Diagnostics that the event arrives with 100% parameter accuracy and zero duplicates.

Verify Network Performance & Publish With Monitoring

Open Chrome DevTools > Network tab while testing in Preview Mode. Filter by googletagmanager.com. Confirm that redundant external gtag.js calls have been eliminated and that your sGTM or Google endpoints return clean 200 / 204 status codes. Once verified, publish the workspace and monitor GA4 Realtime and conversion volume for the first 24 hours.