GTM vs hardcoded gtag: when you do not need a tag manager
Tag managers are the default advice, but they are not always the right call. For a simple site with one or two tags, hardcoded gtag can be faster and simpler. Here is the honest line.
You do not need a tag manager for one analytics tag on a site nobody else touches. Google Tag Manager earns its keep when several vendors need the same events, when non-developers need to change tracking, or when consent has to be enforced centrally. Below that threshold it adds a layer, a dependency, and a governance obligation in exchange for flexibility you will not use.
What each approach actually costs
Hardcoded gtag means the Google tag lives in your page template. Changes go through your normal development process: edit, review, deploy.
GTM means one container snippet in your template, and everything else configured in a web interface that publishes independently of your deploys.
| Hardcoded | GTM | |
|---|---|---|
| Add a vendor | Code change and deploy | Config change and publish |
| Who can change it | Developers | Marketing, with governance |
| Change history | Your git history | Container versions |
| Consent enforcement | Per tag, by hand | Centralised |
| Performance | Slightly leaner | Container overhead plus tags |
| Failure mode | Slow to change | Easy to make a mess |
| Auditability | Grep the codebase | One container inventory |
When hardcoded gtag is the better choice
One or two tags, and no plans. A GA4 tag on a content site. The container is pure overhead.
Strict Content Security Policy. Environments that prohibit injected scripts make GTM awkward at best. Hardcoding keeps everything within your policy.
A developer-only team. If every tracking change goes through engineering anyway, the container's main benefit — decoupling tracking changes from deploys — is not a benefit you will realise.
Performance-critical pages. The container is small, but it is a request and an execution step. On pages where you are counting milliseconds, direct tags are leaner.
Nobody will own it. This is the underrated one. An unmaintained container is worse than hardcoded tags, because the mess is invisible until someone audits it and nobody knows why tag 27 exists. Why containers drift.
When GTM clearly wins
Multiple advertising platforms. Once GA4, Google Ads, Meta, and TikTok all need the same events, hardcoding means four implementations of one concept. A container means one dataLayer and four consumers.
Non-developers need to make changes. A marketing team that can add a campaign pixel without a sprint is the original argument for tag management, and it is still the strongest.
Consent must be enforced centrally. Per-tag consent settings and Consent Mode integration are considerably easier to get right — and to verify — in one place than scattered across templates.
Ecommerce tracking. The dataLayer pattern GTM encourages is the right architecture regardless: your developers describe what happened once, in business terms, and the container decides who hears about it.
Multiple sites with shared conventions. Agencies and multi-brand businesses get real leverage from a standard container template — tag governance across sites.
The honest middle ground
The choice is not binary, and the hybrid is often correct: hardcode the foundational tag, manage the rest in a container.
Put the GA4 configuration and the consent defaults directly in your template, where ordering is guaranteed and nothing can accidentally unpublish them. Run everything else — advertising pixels, engagement events, experiments — through GTM.
This gives you deterministic ordering for the two things where ordering matters most, and flexibility for everything else. It also means a container mistake cannot take your analytics down.
The decision, as five questions
Answer these honestly and the choice makes itself:
- How many vendors need the same events? One, and hardcoding is fine. Three or more, and a container saves real work.
- Will anyone outside engineering need to change tracking? If yes, the container is the point. If no, its main advantage is unrealised.
- Do you serve EEA or UK traffic? Centralised consent enforcement is considerably easier to implement correctly, and to verify, in a container.
- Is there a named owner? A container nobody owns decays into a liability. Hardcoded tags decay more slowly because changing them requires a deploy.
- Does your CSP allow injected scripts? If not, the decision is already made for you.
Two or more yeses on questions one to three, plus a yes on four, and GTM is worth it. Otherwise keep it simple — most sites carrying a container do not need one, and many of the containers being audited today exist because someone assumed a tag manager was mandatory rather than because anyone chose it.
Migrating from hardcoded to GTM
If you outgrow direct tags, do not run both:
- Inventory every hardcoded tag and its trigger conditions.
- Rebuild them in the container, one at a time.
- Verify each in Preview, walking the real user path.
- Remove the hardcoded version in the same deploy that publishes the container equivalent.
- Verify in production that exactly one of each tag now fires.
Step 4 is where teams get hurt. Leaving the old tag in place "just in case" produces duplicate GA4 properties, doubled conversions, and inflated revenue — the most common tracking bug there is.
FAQ
Is GTM slower than hardcoded gtag?
Marginally, for the container itself. The real performance cost is what you put inside it — each vendor tag loads that vendor's script. A container with four tags is heavier than four hardcoded tags only by the container's own overhead.
Can I use GTM and gtag together?
Yes, and the hybrid is often sensible: hardcode the GA4 configuration and consent defaults for deterministic ordering, manage everything else in the container. What you must avoid is the same tag existing in both places.
Do I need GTM for GA4?
No. GA4 works fine with a direct gtag snippet. GTM becomes valuable with multiple vendors, event tracking beyond pageviews, or a need to change tracking without deploying.
Is GTM bad for security?
It introduces the ability to inject scripts, which is a real consideration under a strict CSP. Mitigate with restricted publish permissions, a review process, and periodic container audits — or hardcode if your policy prohibits it outright.
What is the biggest risk of moving to GTM?
Duplicate tags during migration, when the hardcoded version is left in place alongside the new container tag. Remove the old one in the same deploy that publishes the new one.
Whichever route you take, verify the result from outside: the free tracking audit checks for duplicate GA4 properties, script weight, and consent signals on any URL.
See where your tracking stands
Run the same 13-check audit referenced in this post against any URL. No signup, results in seconds.