The Same File, Two IDs

The Google tag and Tag Manager spent ten years being two ways of doing the same thing. Since the spring of 2026 Google has been bringing them together: existing Google tags are upgraded to fully capable Tag Manager containers, and the Google products a container sends to are now called destinations.

The upgrade is optional, it changes nothing on its own, and the benefit is fairly undramatic. The remarkable sentence sits elsewhere – in the release note of 9 July 2026, which states that the ID now decides what a container is allowed to do at all.

What a destination is

Until now a container loaded a separate library for every Google product: gtag/js once for the measurement ID, once for the ads account, possibly once more for Floodlight. After the upgrade those products are destinations on the container, and the container file itself handles delivery. Google’s description notes that each Google destination still gets its own tag – what is consolidated is the delivery, not the configuration.

The gain therefore does not lie in file size. A container serving three destinations is larger than one serving none. What disappears is a round in the loading sequence: the document finds the container, the container finds the library, the library reports the first hit. Remove the middle step and everything after it moves forward.

The ID decides, not the path

On 9 July 2026 Google published a note on container behaviour for unsupported installation paths. The decisive sentence is that the ID used to load the container controls this behaviour, regardless of the path used. A container loaded with GTM-… works as before. A container loaded with a product ID such as G-… or AW-… is restricted to tags and variables provided by Google.

This is the point at which a setup can quietly become narrower. Upgrading an existing Google tag while leaving the old snippet with the measurement ID in place produces a fully capable container in the interface and a restricted execution on the page. Custom HTML tags, third-party vendors and hand-written variables are then missing – not because they were deleted, but because the ID in the source does not permit them.

What becomes of the config command

New deployment snippets will be uniform and will no longer contain the gtag('config', …) command. In its place comes a trigger named gtm init, through which start-up behaviour is configured. For existing setups, that trigger can be told to wait for the old command so that an established order is preserved.

What disappears from the snippet

  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');    <- no longer part of the new snippet

What takes its place

  trigger "gtm init" inside the container
    controls when initialisation happens
    can wait for the old config command where an
    existing setup still sends it

What the ID controls (release note, 9 July 2026)

  loaded with GTM-…   full feature set
  loaded with G-…     only tags and variables provided by Google
  loaded with AW-…    only tags and variables provided by Google

Wherever a consent solution currently holds back or reorders the config command, that is precisely the place to inspect before any upgrade. The trigger can reproduce the same ordering, but it does not do so by itself.

What optional means here

Google’s page is explicit: no changes will be made automatically, and adopting the new configuration remains a choice. Existing containers, tags, triggers and variables keep working unchanged, and third-party tags remain fully supported.

Optional does not mean without consequence, though. New snippets look different from old ones, and a team looking after two sites may from now on be looking after two different installation styles. The instructions written down in the internal wiki then apply to one site and no longer to the other.

What can be counted beforehand

The benefit of an upgrade can be established on the site itself within minutes, before anything is changed. The browser’s network panel, filtered to googletagmanager.com, shows how many libraries are actually loaded. A single container with one measurement ID often loads only two files; there is little to gain there. A setup grown over years, with an ads account, Floodlight and a separately installed Google tag, loads four or five, and there the arithmetic is worth doing.

The second number sits in the interface: how many custom-built tags the container holds. It determines how painful a wrong ID in the source would be.

Where waiting is the better move

The upgrade is new, it is optional, and its gain is one round in the loading sequence. That does not justify surgery on a setup that works – but it does justify a preview on a minor site, so that the new snippet, the trigger and the execution have been seen once before the decision arrives.

What pays off immediately is a look at the ID in the source. It is already there, it controls more than it did before 9 July 2026, and it is the one place in this entire change where a silent loss of capability is possible.