1. What Google actually announced
On May 20, 2026, Google published an announcement on the Tag Manager Help Center describing two changes. First, the Google tag and Google Tag Manager are being merged onto shared infrastructure: sites that only deploy a Google tag will be upgraded to a fully capable Tag Manager container, with the debugging tools, version history, and interface-driven configuration that implies. Each Google destination keeps its own tag, and Google says existing setups and their behavior will not change. Second, a no-code system called Visual Tagging lets you define events by clicking elements on your own site. No fixed rollout date was given. This is a different axis from the server-side GTM primer, which is about where tags run; this is about how they are authored.
2. What changes for you, and what does not
If you already run a GTM container, very little should change on day one, and that is the point of Google's framing. The practical gain is for sites that only had a bare Google tag: they get preview mode, versioning, and a workspace without a migration project. The practical risk is quieter. A merge of two products is exactly when naming, ownership, and permissions drift, so it is worth confirming who has publish rights on each container before the upgrade reaches you rather than after.
3. Visual Tagging in one paragraph
Visual Tagging lets you browse your own site, select an element, and define an event from it, while Google generates the selectors and triggers behind the scenes. According to the announcement it started in beta for Google Ads purchase conversions, with more use cases planned through the year. Treat that scope as the honest boundary for now: I have not used it on a production site, and everything here comes from Google's description of it rather than my own testing.
4. The question that matters: will it survive a redesign?
A selector you cannot see is a selector you cannot review. With a hand-written trigger or a dataLayer push from engineering, the contract between the page and the tag is written down and can be diffed in a pull request. With a generated selector, the contract lives inside a tool, and a front-end refactor can break it silently. My take: Visual Tagging looks well suited to quick, low-stakes events and to getting a conversion live fast, and I would not use it for the events your KPIs depend on. For those, keep engineering-owned dataLayer events, the kind the event quality scorecards article argues for.
5. What to do before it reaches your account
Audit the container you have now and name an owner for each. Add a line to your measurement QA checklist that any visually defined event is re-tested after every front-end release, since nothing else will flag it breaking. And decide in advance which event categories are allowed to be created visually. One caveat: this is a beta feature in a product being reworked, so details in this article may be out of date by the time you read it; the Tag Manager release notes are the source of truth.
How different teams plug in
An authoring change in a shared tool touches more than the person who clicks publish:
- Marketing is the likeliest user of Visual Tagging and should agree up front which events they may create without engineering.
- Engineering keeps ownership of the core
dataLayercontract and is told when a visual event depends on page structure. - Analytics reviews every new event against the naming and QA standards before it feeds a report.
- Legal and privacy confirm that new tags still respect consent settings, as covered in the consent testing playbook.