GTM Now Writes Version Descriptions With AI

TL;DR: Google Tag Manager now writes a version name and a description of the tags, triggers, and variables that changed when you publish. I saw it on a client container on September 16, 2026, Simo Ahava documented it on September 9, 2026, and Google's Tag Manager release notes added an official entry dated September 17, 2026. The text isn't exhaustive and doesn't explain why a change was made, so review it and add that context yourself.

Update, October 5, 2026: Google's Tag Manager release notes now carry an entry dated September 17, 2026 describing an "AI-suggested version summary" on the submit page. Ahava's write-up currently describes a "Suggested version summary" switch you can turn off.

Publish a new version in Google Tag Manager and you'll likely see something you didn't ask for: a version name and a full description, already written, sitting in the fields you'd normally have to fill in yourself. It's generated from whatever you actually changed in that workspace, tags, triggers, and variables, and it's specific rather than generic.

I saw this firsthand publishing a routine set of changes to a client container on September 16, 2026. I hadn't typed a version name or description at all, and GTM had already produced both.

What GTM generated on its own

The container in question got nine new tags, seven new triggers, and ten variables added, a standard lead-tracking build: a Google tag, a handful of GA4 event tags, and a couple of custom triggers off link clicks and a form submission. I didn't write a single word describing any of it.

GTM titled the version:

Version 6 - Add Google tag and GA4 event tags for leads, phone, email, and GMB tracking

Then it filled in a description, broken into its own Tags, Triggers, and Variables sections, in a plain bullet format. A few of the actual lines it wrote:

• "Added a new 'Google tag' (G-1GBFQ8MV6X) triggered by 'All Pages'."
• "Added a 'GA4 - click_phone' tag triggered by 'LC - Phone'."
• "Added a 'chtml - generate_lead (Gravity Forms)' Custom HTML tag triggered by 'Dom Ready'."
• "Added the 'LC - Phone' trigger, which fires on link clicks where Click URL contains 'tel:'."
• "Added the 'PV - GMB/GBP Page' trigger, which fires on page views where Page URL matches regex 'gmb|gbp'."
• "Added the 'DLV - form_id' Data Layer variable."

What's worth noticing there isn't just that it listed what got added, it's how correctly it described each thing. It identified which tags were GA4 event tags versus a Custom HTML tag versus the base Google tag. It correctly named which trigger fired which tag. It read the actual trigger conditions, tel: and mailto: link click matching, a regex match on the page URL, and described them in plain English instead of just naming the trigger. None of that was hand-fed to it; it read the workspace diff and worked it out.

Is this an official Google feature, or something I stumbled into

Worth being straight about what I could and couldn't confirm here. When I first saw this on September 16, 2026, I couldn't find an official Google announcement, release note, or help-center page describing it. Google has since added one: the Tag Manager release notes have an entry dated September 17, 2026 saying the release "updates the Tag Manager submit page with an AI-suggested version summary" that "summarizes the changes in the workspace and automatically proposes a Version Name and Version Description." Google's guidance on naming versions (Publishing, versions, and approvals) still only tells you to manually write a version name and description, with no mention of AI generating that for you, as of October 5, 2026.

This isn't just my own account showing something unusual either. Simo Ahava, a longtime independent Google Tag Manager expert, documented the same feature in detail on September 9, 2026, a week before my own sighting on September 16, 2026. His write-up describes it as on by default, appearing automatically in the version-creation flow, with a "Suggest" button that regenerates the text if you change the workspace further. His write-up as it reads today also describes a "Suggested version summary" switch you can turn off. He flags the same limitation worth knowing here: it isn't exhaustive. It focuses on what it judges to be the most significant changes rather than listing literally everything, and in his own example it missed mentioning that he had paused 29 tags.

So: this is real, it's documented by Google, and it's corroborated independently. It was live in accounts before the release note appeared, which is worth knowing about Google's rollouts generally, and its name, behavior, or on/off setting could still change. If you're reading this months after publication, check your own container rather than assuming it still works exactly as described here.

Why this actually matters if you're not the one building the tags

If you hire someone to manage your GTM container, or a past employee or agency built one and moved on, container version history has always been the record of what happened and when. The problem was that record was only as good as whoever bothered to write a real name and description at publish time. In practice, a lot of versions get published with the field left blank, or with something unhelpful like "update" typed in out of habit.

That's what this actually fixes for you as the business owner or marketer reviewing the account later, not the technical mechanics of it. You (or whoever you hire to audit the account next) can open the version history and immediately see, in plain English, what tags and triggers changed in each published version, without needing to reconstruct it from the tags themselves or track down whoever made the change. Handoffs between agencies, a new hire inheriting a container, or you trying to remember what you changed three months ago before things started behaving differently, all of that gets easier when the history is actually readable.

It's not a substitute for a human writing anything down about why a change was made, only what changed. If a version exists because a client asked for a specific tracking fix, or because a bug was found in testing, that context still won't show up unless someone types it. Treat the generated text as a starting point, exactly as Ahava recommends, and add anything it can't know on its own.

Frequently asked questions

Does this cost anything extra? No indication of that anywhere I could find. It appears to be built into the standard container publishing flow at no separate cost.

Can I turn it off or edit what it writes? You can edit it. The generated name and description land in the normal fields before you publish, so you can change or add to them like you always could. As for turning it off, Simo Ahava's write-up describes a "Suggested version summary" switch that disables the generation when set to OFF. I haven't found that switch described in Google's own help pages as of October 5, 2026, so check your own container's submit page.

Does it replace writing my own version descriptions? Don't treat it that way. It reliably lists what changed, tags, triggers, variables, but not why. If a version exists because of a specific client request or bug fix, that context is worth adding yourself.

Is it useful for someone other than the person who published the change? That's the main practical benefit. Anyone reviewing the container later, an agency taking over, a new hire, or you six months from now, gets a readable record of what happened in each version without having to dig through the actual tag configuration to reconstruct it.

Does it catch everything that changed in a version? Not necessarily. It appears to prioritize what it judges most significant rather than producing an exhaustive list, so a smaller or less obvious change (like a tag being paused rather than added) can get left out. Review it rather than trust it blindly.

Independent documentation of this feature comes from Simo Ahava's GTM Tips. Google's own entry for the feature is in the Tag Manager release notes, and its general guidance on version naming, which doesn't mention this feature as of October 5, 2026, is Publishing, versions, and approvals.

---

A readable version history is only useful if the container underneath it is actually well built. If you've inherited a GTM container full of tags nobody can explain, or you just want someone to make sense of what's actually running on your site, that's what GTM setup covers.

If the person publishing changes to your container shouldn't be the only one who can see this history, it's worth checking how to share Google Tag Manager access so the right people on your team can actually read it too.