Google Tag Manager Now Writes Your Version Descriptions With AI

Publish a new version in Google Tag Manager right now, 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 this week. 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. As of this writing, I can't find an official Google announcement, release note, or help-center page describing this feature. Google's own published guidance on naming versions (Publishing, versions, and approvals) still only tells you to manually write a version name and description that "will make it easy to know what changes are being made," with no mention of AI generating that for you.

That said, this isn't just my own account showing something unusual. Simo Ahava, a longtime independent Google Tag Manager expert, documented the same feature in detail on September 9, 2026, a week before I saw it myself. His write-up describes it as on by default in GTM containers already, appearing automatically in the version-creation flow with a "Generating..." label while it works, with no toggle currently available to turn it off. He also 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 a batch of tags had been paused.

So: this is real, it's live in accounts right now, and it's corroborated independently, but it's rolled out quietly rather than announced, which is common enough for Google to do and worth flagging as something that could change (name, behavior, or an on/off setting) without notice. 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. Whether there's a setting to disable the auto-generation entirely isn't something Google has documented publicly as of this writing, and the one detailed independent write-up available says there's currently no toggle for it.

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 general guidance on version naming, which doesn't yet mention this feature, 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.