Do We Still Need Google Tag Manager in the Age of AI?

Marek Prokop asked a simple but important question on LinkedIn (discussion in Czech): do we still need Google Tag Manager now that an AI agent can implement tracking? For the first time in thirteen years, he left it off a new website. AI can inspect a repository, find the right place, modify the code, run checks, and prepare the change for approval.

Does this mean the end of Google Tag Manager? There is no single answer that applies to every website.

On a small, stable website, I would no longer add GTM by default. On a complex website, however, I would not remove it simply because AI can write JavaScript. The ability to create a change is not the same as the ability to manage it safely over the long term.

AI can take over a large part of an analyst’s or developer’s work. On its own, however, it is not a source of truth, an access-control system, an approval workflow, documentation, monitoring, or a rollback mechanism.

Why “GTM or AI?” is the wrong question

Google Tag Manager solved a practical problem: analysts and marketers no longer had to wait for a developer and the next website release every time they needed a new pixel. They could configure, test, and publish a tag independently.

Today’s coding agents can already speed up much of this process. They can inspect a repository, prepare a change on a separate branch, run tests, and open a pull request. This workflow is described, for example, in the documentation for the GitHub Copilot coding agent.

The original question, however, combines two different issues:

who creates the change,
where the change is recorded, tested, approved, deployed, monitored, and rolled back if necessary.

AI handles the first part very well. The second requires a defined process and a clear owner, whether you use GTM, Git, walkerOS, or a custom platform. In practice, it is useful to separate three questions:

Do we need a person to configure every item in GTM manually? Less and less.
Do we need a browser-based GTM container on every website? No.
For more complex tracking, do we need a governed layer for changes, permissions, and data distribution? Usually, yes.

When you can skip GTM

A direct implementation makes sense when you track a small number of stable events in one or two platforms, changes are infrequent, releases are fast, and analytics has a technical owner. Events must be centralized, versioned, and tested, and neither marketing nor external contractors should require a separate publishing process.

A blog, portfolio, or simple content website: for basic traffic measurement and a handful of events, the Google tag and gtag.js or another lightweight analytics solution may be enough.
A small lead-generation website with an available developer: GA4, one advertising platform, and a few conversions can be managed directly in the application, provided that changes do not sit in the backlog for weeks.
A product with a strong engineering and data team: with a typed schema, tests, and a custom event API, tracking-as-code may be the more natural approach. Git provides diffs, code review, links to issues, and CI/CD.
A website with minimal tracking and a strong focus on performance: you can use a smaller loader or a thin abstraction layer, but the team then assumes responsibility for compatibility, consent, documentation, and future changes.

When to keep GTM or another governance layer

The value of tag management increases with the number of systems, people, vendors, countries, and changes that need to be released independently of the application. This is not just about JavaScript; it is an organizational and operational interface.

Multiple analytics and advertising systems: GA4, Google Ads, Meta, affiliate platforms, personalization, A/B testing, CRM, and a data warehouse all expect different payloads. The data layer can produce one vendor-neutral event, which GTM then transforms for each destination.
Frequent changes outside the product release cycle: if the application is deployed only once a month because of testing, security requirements, or a change advisory board, a separate tracking release removes a bottleneck. AI can prepare the change, but safe deployment still requires an agreed process.
Multiple teams, countries, or brands: a standard interface, naming conventions, a clear overview of tags, and the tag–trigger–variable model make collaboration and handovers easier. A custom system may be better, but it still has to be designed, documented, and maintained.
An e-commerce website or multiple websites with complex consent requirements: shared rules are often cheaper to manage centrally. Business logic should remain in the product; the governance layer handles consent, transformation, and distribution of stable events, potentially in a hybrid setup with a server-side layer.
A large marketplace, media business, or multiple agencies: governance, roles, standardization, and independent releases matter more here than the elegance of monolithic code. The solution may be a well-governed GTM setup, GTM 360, or a custom event platform.
A smaller company without a long-term website administrator: a lean GTM setup with restricted permissions can serve as a handover point. A standard interface is often more valuable than a solution only its original author knows how to operate.

A website without a clear analytics owner: appoint an owner first. No Tag Manager, Git workflow, or AI agent can solve an organizational vacuum.

External specialists and the principle of least privilege

One of the strongest arguments for GTM arises when a paid media specialist, analyst, or agency needs to manage conversions without access to the entire repository and development pipeline. GTM makes it possible to separate responsibilities:

the development team owns the application and the data layer,
the agency prepares changes in the container,
a senior analyst or internal owner reviews them,
publishing rights remain limited to a small number of people.

When the client changes agencies, the new administrator takes over a standard interface rather than scripts scattered throughout the application. This point also came up in the LinkedIn discussion (in Czech).

The security benefit of GTM is not that it makes it impossible to break the website. It is that you do not have to give an external specialist access to the entire development system, and you can separate preparing a change from publishing it.

At the same time, GTM is a privileged production layer. Publishing rights and arbitrary Custom HTML tags can have a major impact on the website. I would therefore avoid giving agencies unrestricted publishing access, limit Custom HTML, prefer sandboxed templates, and audit access regularly.

An alternative is a restricted Git workflow in which an external contractor can modify only the analytics module. This may be cleaner, but someone still has to design it, operate it, and explain it to vendors. GTM provides this boundary out of the box.

Experience from practice:
GTM has repeatedly served developers as a fast emergency layer after a botched release something they can abuse too, so be careful. Without it, developers were burdened with changes in dozens of places; after returning to GTM, they appreciated that they only had to send data to the dataLayer once. With custom solutions, responding dynamically to consent changes is difficult as well. Old code in GTM does not clean itself up: over twelve years, marketers have told me only about twice that obsolete code could be removed.

What GTM actually solves

Versions, history, and rollback: GTM stores published versions, the author of each change, and deployment history. You can revert to an earlier version without releasing the entire application; see the documentation on publishing, versions, and approvals. A well-designed Git workflow can provide more precise diffs, automated tests, and mandatory code review.
Permissions and separation of roles: users can have different rights to view, edit, approve, and publish. A full approval request queue is a GTM 360 feature, but standard GTM also allows publishing to be restricted; see user and permission management.
Preview and debugging: Tag Assistant shows events, data-layer values, and tags that did or did not fire. An agent can perform more advanced testing, but it still needs defined scenarios and expected results.
Standardization and visibility: GTM is familiar to many analysts, paid media specialists, and agencies, so a new person does not have to learn an internal framework. Scripts, rules, and variables are kept in one place rather than scattered throughout the application. The container adds JavaScript overhead, although centralizing data and shared functions can offset some of the cost.
An API for people and agents: the Google Tag Manager API exposes containers, workspaces, tags, triggers, variables, versions, environments, and permissions. AI therefore does not have to replace GTM: it can compare a specification with the container, prepare a change in a separate workspace, add a version description, and submit it for human review.

Where GTM falls short

GTM can bypass Git, code review, type checking, and standard CI/CD, gradually turning into a second application that is largely invisible to developers. The same independence is therefore both its greatest strength and its greatest weakness.

Old campaigns, duplicate tags, unnamed variables, and temporary workarounds also accumulate easily. AI will not solve this problem on its own; by reducing the cost of making changes, it may accelerate technical debt unless rules are in place. A healthy container needs clear naming conventions, owners for each integration, minimal publishing rights, regular audits, expiration dates for temporary campaigns, minimal use of Custom HTML and Custom JavaScript, and regular exports or backups.

GTM is not automatically a secure sandbox either. It can load scripts, send network requests, and affect how the page runs. Custom Templates with sandboxed JavaScript and declared permissions are safer, but they still do not replace access management and publishing controls.

A browser-based container adds a remotely managed layer and a dependency on Google. For a small website, that trade-off may be unnecessary. Removing GTM, however, does not automatically remove third-party scripts: if you move the same pixels directly into the application, the browser still has to download, parse, and execute them.

A more accurate equation is not “no GTM = a fast website,” but “less unnecessary third-party JavaScript, fewer analytics, advertising, and UX tools, and a better loading strategy = a faster website.”
At the same time, doing so can constrain marketing and development or reduce visibility into user behavior, thereby affecting business results. It is therefore a broader product decision, not merely a choice of tag manager.

The same principle is emphasized in web.dev’s recommendations for tags and tag managers.

What an AI agent actually changes

Direct implementation is cheaper

Adding an event no longer has to mean several rounds of explanation followed by a wait for the next sprint. In a single workflow, an agent can prepare the application change, schema, tests, and documentation. This shifts the point at which tracking-as-code becomes worthwhile.

An agent needs a data contract, not a chaotic DOM

AI can find a button by its text or a CSS selector, but that is not a stable foundation for tracking. A healthy long-term system needs predictable events and parameters. Google also recommends using a consistent data layer instead of parsing values scattered across the page.

In the age of AI, the importance of a measurement plan, event schema, naming conventions, definitions of required and optional parameters, consent rules, a list of data that must not be shared with third parties, automated tests, and production monitoring therefore increases. Without high-quality, structured, and accessible context, an agent merely automates chaos faster.

AI can operate GTM

The future does not have to be only “AI instead of GTM.” It can also be “AI removes most of the manual work inside GTM.” In the follow-up Facebook discussion (in Czech), people shared examples of AI preparing documentation, a dataLayer, or an importable container JSON file, after which a person reviewed the tags, triggers, and Preview mode.

This is safer than pretending AI has no place in GTM administration or giving an agent unrestricted permission to publish production code. AI outputs must always be reviewed and debugged. Models vary in quality and often lack deep knowledge of a specific GTM or GA4 setup, as well as less common tools. They handle a simple website better than a complex implementation with many exceptions.

The cheaper it becomes to create a change, the more changes will be created. Without automated guardrails, duplicate events, inconsistent names, unintended personal data, conflicts between tools, or errors in consent logic can multiply.

The old problem was that only a small number of people could make a change. The new problem may be that almost anyone can create one… human or agent.

The safe model remains the same: the agent prepares the change, automated checks validate it, and an authorized person decides whether to deploy it.

Questions to ask before adding or removing GTM

How often does tracking change, and do those changes need to be released independently of the product?
How many systems consume the data?
Who creates, reviews, publishes, and remains accountable for changes over the long term?
Do external specialists need access to the codebase, or is a restricted tracking layer enough?
Is there a stable event contract, or does tracking depend on CSS selectors and one person’s knowledge?
How are testing, Preview, monitoring, and rollback handled?
Can the agent make changes directly in production, and who will update, audit, and hand over the system three years from now?

The more tools, teams, agencies, changes, and independent release cycles you have, the more sense a standardized tag management or event-routing platform makes. The smaller and more stable a project is and the stronger its developer ownership the easier it is to skip GTM.

So, do we still need Google Tag Manager?

Not on every website. On a small project with a few stable events, fast development, and a single analytics owner, GTM may be an unnecessary intermediary layer. AI reduces the cost of direct implementation so much that it often makes more sense to keep tracking in the code, version it in Git, and deploy it together with the application.

On a large or frequently changing website, however, AI alone does not replace the function of tag management. It replaces part of the work involved in creating a change. We still need a source of truth, testing, permissions, approvals, deployment, rollback, documentation, and monitoring.

For agencies, GTM also separates the tracking layer from the codebase while leaving final publishing control with the client. This role can be fulfilled by GTM, Git and CI/CD, walkerOS, another tag manager, or a well-designed custom platform. But some system still has to fulfill it.

In my view, AI does not mean the end of Google Tag Manager. It means the end of the era when we had to operate it manually and add it to every new website without thinking.

The right question is therefore not simply “Should we add GTM?” It is: where will the source of truth for tracking live, who is allowed to publish changes, how will we test and roll them back, and who will own the entire system over the long term?

Sources and further reading