How to switch to Tag Manager destinations and keep Consent Mode

On 14 October 2026, the gtag.js file Google serves for a single Google Analytics 4 measurement ID weighed 184,524 bytes compressed and 559,172 bytes uncompressed. Until now, Google Tag Manager loaded a file like that for every Google tag in a container. Since 12 October 2026, an optimised container sends to Google Analytics, Google Ads and Floodlight itself, as destinations, without those extra files. Consent Mode works the same way after the switch: the destination tags read the consent state your banner sets, and a consent default on the Consent Initialization trigger still comes first. Two new shared settings touch consent, and they are what to check before you publish.

• The switch is optional. Nothing changes in your container until you run Google's optimization flow and publish the result.
• The consent commands do not change. gtag('consent', 'default'), gtag('consent', 'update') and the template APIs work as before.
• The Settings tab can now hold consent defaults and data transmission controls for every destination. If you set them, they must agree with your banner's region rules.
• Since 8 October 2026, gtag.config shows up as a dataLayer event, so a Custom Event trigger that matches every event fires on it too.

Google tags become destinations inside one container

Google announced the change in Updates to Google tag and Google Tag Manager, dated 20 August 2026, and the Tag Manager release notes of 12 October 2026 record the rollout. Every Google tag is upgraded to a full Tag Manager container. Inside a container, Google Analytics, Google Ads and Floodlight become destinations, each with its own destination tag, and all of them share one set of Google tag settings in a new Settings section. Triggers, variables, templates and folders move under a collapsible Advanced section.

The performance change is the part a visitor notices. Before, a Google Analytics tag in Tag Manager loaded gtag.js for its measurement ID, and a Google Ads tag loaded another one. An optimised container carries the destinations' instructions in the container file and sends the data straight to Google. On a page with two Google tags, that is two fewer large scripts before any measurement happens.

New deployment snippets change too. Google says they will all be the same and will not carry the gtag('config') command. The settings that command used to pass now live in the container, and Google recommends the Initialization trigger (the gtm.init event) for anything that must run when a tag starts. Consent Initialization fires before Initialization, so a consent default set there still arrives first.

Consent Mode works the same way after the switch

The destination tags check consent like the Google tags they replace. They read ad_storage, analytics_storage, ad_user_data and ad_personalization, wait for an update while a default with wait_for_update is pending, and adjust what they send. Google's own guide to setting up consent mode on websites still applies word for word: set the default before any tag reads it, and send an update when the visitor chooses. Nothing in the optimization flow touches a consent management platform (CMP) tag, because it moves only Google tag settings and leaves the other tags in the container as they are.

The last row is the one people miss. Consent Mode governs Google's tags only, before and after. A LinkedIn Insight Tag or a Meta Pixel in the same container still needs its own consent check, or a trigger on the consent event, as described in how to block Google Tag Manager containers before consent.

Two shared settings deal with consent

The Settings tab gives every destination the same configuration, and two parts of it decide what Google tags do while consent is denied.

Consent defaults in the container

Google tag settings can carry their own consent defaults. When a container also runs a consent banner, the two sets of defaults should say the same thing: denied in every region where your banner asks first, granted only where your region rules allow data by default. Two defaults that disagree give the same visitor two starting states, and the result in Tag Assistant becomes hard to read. The simplest arrangement is to leave the container's defaults empty and let the banner or the Kukie CMP template set them, or to copy the banner's rules into them exactly. Destination overrides can make a setting stricter, never looser.

Manage Data Transmission

Data transmission controls are switches in the Google tag settings that restrict what Google tags send while consent is denied. In Tag Manager they sit under Settings, Show more, Manage Data Transmission, and they apply only to destinations connected to the container. Google's page on data transmission controls lists three: advertising data, behavioural analytics data and diagnostics data, each restricted on its own. Consent Mode has to be active first, and the controls work in addition to the consent state rather than instead of it. With them on, Google tags send less of the restricted data, or none, until a consent update grants the matching type. A banner that sends the update as soon as the visitor chooses, and at page load when a choice is already stored, gives those held requests what they wait for.

Wildcard triggers can now fire on gtag.config

An earlier release changed something else. Since 8 October 2026, every gtm.js snippet initialises on container load, and config commands appear in the dataLayer as visible gtag.config events. Google warns that tags with wildcard Custom Event triggers may now fire on them. If a tag in your container uses a Custom Event trigger with the regular expression .*, it fires on events it never saw before. A trigger on one named event, such as the cookie_consent_update event a banner pushes, is not affected.

Check the container before you publish it

The optimization flow writes its changes into a workspace, and Google shows them for review before anything is published. That gives you a natural checkpoint.

1. Start the optimization from the banner in your container. Pick which Google tags to link and which settings to keep. The changes land in the workspace only.
2. Open the Settings tab and compare its consent defaults with your banner's region rules. Remove them, or make them identical.
3. Open Manage Data Transmission and note which data types are restricted, so you know what Preview should show as held back.
4. Start Preview, open your site in the Tag Assistant window, and accept the banner. The Consent tab should show the default on the first event and the update after your click. Repeat with a reject in a fresh session.
5. Add ?kukie_debug=1 to the page URL and read the console report. It should say PASS - Kukie set consent defaults BEFORE Google tags fired. Then publish the container.

Step 5 still works without gtag.js on the page. The debug report reads Google's own consent record (google_tag_data.ics.wasSetLate), and when that is missing it compares the position of the default in the dataLayer with gtag('js'), gtm.dom and gtm.load, none of which needs a config command. The Consent Mode debug mode guide explains each line of the report.

Where the banner sits in an optimised container

Kukie.io supports three ways to run the banner next to Tag Manager, and the switch leaves all three intact.

With the banner script first in the page's <head>, the default is in the dataLayer before gtm.js loads. Enter the Container ID in the Banner Editor and the banner loads the container itself, always after the defaults. Where the banner asks first, it waits for the visitor to accept, unless Load the container before consent is on. The Kukie CMP template sets the default with setDefaultConsentState on Consent Initialization - All Pages, as Google's consent mode template APIs describe. In each case the default reaches Google before the first destination tag reads it, and the update follows the visitor's choice. While a banner is on screen, no granted update is sent before the visitor acts. Regions your rules treat as opt-out get granted defaults scoped to those regions instead. The Tag Manager installation guide has a section on these Google tag settings, and the Google Consent Mode integration page lists what each path sends. If your Google tags are served from your own domain, read the Google tag gateway guide as well: load order there depends on the gateway, not on the container.

Questions about Tag Manager destinations and consent

See which Google scripts your page still loads

After you publish, the quickest proof that the switch happened is the live page itself: the gtag.js files should be gone and gtm.js should remain. The Script audit counts the scripts each domain loads on a page, so googletagmanager.com should drop to one.