Skip to content

Guide 120 · Container · GA4 + Tag Manager

Publish a Tag Manager version: Submit, check the changes, name it, publish

Checked 11 November 2026 · Verification: container fragment validated structurally (22 checks, all passed) · Steps traced to Tag Manager Help, opened 11 November 2026 · 5-minute read

Visitors load the published version, not the workspace. Publishing is the step that moves a tested draft into that version: you click Submit, review the changes, pick Publish and Create Version, name the version, and publish. Google's publishing page says that when you publish a container, Tag Manager will make your changes active for the environment specified, and that if you added or edited tags, triggers and variables in a workspace, you will need to publish those changes to make them operational. The Day-1 guide already proved the shape — Submit, then Publish and Create Version, then a name and description — and this guide runs the full flow with the pre-publish checks.

Expected signal

After step 5, the workspace is empty of pending changes, the Versions tab lists the new version with the name you wrote, and the live site loads the new container version. Realtime in GA4 shows the change's effect within minutes.

Download the container fragment: the publish-ready fragment (JSON) (export format version 2, 2114 bytes, MD5 f15f284407c199cd8707015280723cc5). It holds the container state being published in the worked example: the Google tag plus the scroll and click event tags. The file is a hand-built import template, validated structurally — it was not exported from a live container.

What you need

  • A workspace tested in Preview. Publishing is the step after testing, not a substitute for it — that is the Preview guide.
  • Publish access to the container. Edit access can change the workspace; Approve access can create versions; only Publish access can publish. The permission ladder is in the users guide.
  • A version name written before you start. The name is the record of what the publish carried. Write it from the changes list, not from memory.

The trace

  1. Click Submit at the top right of the workspace. The Submit Changes screen appears, with the Workspace Changes section listing every added, modified and deleted item. Review it: the list should hold exactly the changes you tested, and nothing else — a teammate's unfinished change in the same workspace publishes with yours.
  2. Select Publish and Create Version. The screen offers Publish and Create Version, or Create Version on its own. The first publishes and records the version in one step; the second saves a version without putting it live. Pick Publish and Create Version.
  3. Enter a Version Name and a Version Description. Name it after the change — GA4 scroll tracking added — and put the full list of changes in the description. The version is numbered automatically: a container starting at version 1, published for the fourth time, lands at version 1 + 4 = 5.
  4. Review the changes one more time and click Publish. Use the More Actions menu in the Workspace Changes section to view the differences for any item, or abandon a change that should not ship. Click Publish at the top right when the list is right.
  5. Confirm the publish in the Versions tab. The Versions tab lists the new version as the latest, and the workspace is now empty — when a workspace is published, it is removed, and the Default workspace is recreated. The site loads the new version from this point on.

Dead ends

DEAD END — PUBLISHING AN UNTESTED WORKSPACE. Publish puts the changes live for every visitor. A tag that was never previewed fails in production the same way it would have failed in Preview — except now real visitors see it. Preview first, publish second, every time.

DEAD END — A TEAMMATE'S CHANGES IN THE SAME WORKSPACE. The publish ships the whole workspace, not the changes you made. A teammate's half-finished tag in the same workspace goes live with yours. One workspace per job keeps a publish to the changes that were tested.

DEAD END — PUBLISHING THE WRONG ENVIRONMENT. If the container uses multiple environments, the Submit screen has a Publish to Environment section. Publishing to the wrong environment puts the changes live where they were not expected — check the environment before the click.

End state

One workspace published as a named version, the workspace removed and recreated empty, and the live site loading the new container. The change is now live for every visitor, and the version history holds the snapshot to roll back to.

Sources

Checked 11 November 2026. The click paths above are the ones in Google's help pages, opened 11 November 2026. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. The container file was validated structurally instead: export format version 2, every tag's firing trigger resolves, every variable the tags reference exists in the file, and the tag types are the documented ones. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map. The container fragment for this guide is 2114 bytes (2.06 KB, 1.03% of the reported 200 KB container size limit), MD5 f15f284407c199cd8707015280723cc5, and passed 22 structural checks.