Google Tag Manager change history, on a timeline that outlasts the tab.
Google Tag Manager keeps a change history — but it’s buried inside GTM, one container at a time, where marketing and leadership never look. CoNote puts every published version on one shared timeline, beside the deploys and campaigns from the same day.
Google Tag Managerpublished a changeGTM container v45 published — checkout tracking changed
Google Tag Manager· 14:17
Deployed storefront v2.4.0 (main → 3a7f2c1)
GitHub· 09:41
Finding your history
Your Google Tag Manager change history: today, and from now on
The manual way · inside GTM
Where to find it today
It’s all there — if you go digging:
- 1
Sign in to Tag Manager
Open tagmanager.google.com and pick the account and container you need — each container keeps its own separate history.
- 2
Open the Versions tab
In the left sidebar, click Versions. Every published version is listed with its number, name, notes, and the date it went live.
- 3
Open a version to see what changed
Click any version, then the Version Changes panel shows the exact tags, triggers, and variables that were added, edited, or removed.
- 4
Check Activity History for who did it
Under Admin, open Activity History at the account or container level for a per-user log of every edit — not just the published versions.
- 5
Cross-reference the dates by hand
There’s no view across containers or against other tools, so you line each publish date up with your analytics yourself.
The CoNote way · one timeline
Where to find it from now on
Connect GTM once. After that it’s seconds:
- 1
Open your CoNote timeline
Every published version is already waiting — no GTM login, no hopping between containers.
- 2
Jump to the day it moved
Scan the day your metric shifted; the publish is stamped there to the minute.
- 3
See it beside everything else
The change sits right next to that day’s deploys, campaigns, and incidents — the cause is obvious.
Sound familiar?
GTM’s change history works — until you need it.
Mia09:14
Tom09:17
Sara09:21
Tom09:26
So the version-by-version archaeology begins.
It answers “what changed in this container?” — never the question you actually have: “what changed across everything around the day my numbers moved?”
- One container, one account, at a time — no single view
- Locked inside GTM, where marketing, SEO, and leadership never look
- Never lined up against the deploy or campaign from the same day
- Cold months later — when the agency or the person who changed it has left
With CoNote, the publish that did it is already on the timeline — “GTM container v45 published, checkout tracking changed” — stamped to the minute, next to every other change from that day.
How it works
Connect once. Then it logs itself.
- 01
Authorize with Google
A two-click Google authorization — no SDK, no container edits, no engineering sprint. CoNote reads your container’s version history, nothing else.
- 02
Every publish logs itself
CoNote checks for new published versions every few minutes. Each one lands on the timeline with its version name and the moment it went live — a readable entry, not a raw diff.
- 03
Read it in context
The publish sits beside that day’s deploys, campaigns, and incidents. When a metric moves, you scan one page instead of grepping four tools.
What lands on your timeline
- Every published container version — its number and name
- The exact moment it went live, to the minute
- Logged automatically and attributed to Tag Manager
In your week
What teams actually use it for.
Tracking dropped — was it the publish?
Conversions fall off a cliff. You open the day they dipped and see the v45 publish at 14:17, right before the line bends. Five minutes, not a five-person investigation.
Prove what the agency changed
Every published container version is logged and dated — so months later, even after the agency rotates people, you can show exactly what they touched and when.
Onboard without the tribal knowledge
A new hire reads the timeline instead of interrogating whoever’s left. Every config change is there in plain language, not locked in someone’s memory.
End the cross-team “was it us?”
The GTM publish sits next to that day’s deploy and the ad budget change. Marketing and engineering look at one page instead of pointing at each other.
Side by side
Native change history vs. your logbook.
See published container versions
GTM version history
CoNote
One view across every container and account
GTM version history
CoNote
Lined up against deploys, campaigns, incidents
GTM version history
CoNote
Visible to marketing, SEO, and leadership
GTM version history
CoNote
Searchable months later
GTM version history
CoNote
Setup
GTM version history
CoNote
On the timeline
The change in context.
A GTM publish on its own is a shrug. Next to the deploy and the error spike from the same afternoon, it’s an answer.
Tuesday, June 9
Deployed storefront v2.4.0 (main → 3a7f2c1)
GitHub· 09:41
GTM container v45 published — checkout tracking changed
Google Tag Manager· 14:17
Checkout conversion tracking stopped firing
Uptime· 15:02
Questions
Tag Manager change tracking, answered.
Open your container and click the Versions tab — every published version is listed with its date and publisher. Click a version and choose Version Changes to see the exact tags, triggers, and variables that changed, or open Activity History under Admin to see who made each change.
CoNote logs each published container version — the moment a change actually goes live and can affect your site. Draft edits sitting in a workspace aren’t logged until you publish them, which is usually exactly what you want on the timeline.
A standard two-click Google authorization that lets CoNote read your container’s version history — read-only. It never edits your container, your tags, or anything else in your account.
From the moment you connect, every new published version is logged and kept for as long as your logbook exists — it never ages out. Earlier versions can be added by importing a CSV of your GTM history.
No. Connecting Tag Manager is a two-click Google authorization in CoNote — no SDK, no changes to your container, no developer time.
Each published container version, with its version name and the time it went live, as a plain-language entry on the timeline. It does not change your container or your tags — CoNote only reads the version history.
GTM’s history lives inside GTM, one container at a time, and only people with GTM access ever see it. CoNote puts those publishes on a shared timeline next to your deploys, campaigns, and incidents — so the whole team can line a change up against the day a metric moved.
Only your team. Every entry is scoped to your team, and connecting Tag Manager doesn’t expose your container to anyone outside it.
Keep digging
Track the rest of your stack.
Open the logbook.
Free plan, no card. The next time someone asks “what changed?”, the answer is one search away.
Start your logbook