Should I use Google Tag Manager or hard-code my tags?

If you run more than one or two platforms or change campaigns regularly, Tag Manager is usually the better choice because marketing can make and test changes without a code release. Hard-coding suits small, stable sites with a developer who owns every change.

Does Google Tag Manager slow down my website?

The container itself is light. What slows sites is the collection of tags loaded through it, especially heavy third-party scripts and old tags nobody removed. Regular cleanup matters more than the choice of tool.

Do I need server-side Google Tag Manager?

Only if the benefits outweigh the hosting and maintenance. It makes most sense when ad spend is significant, bidding relies on conversion data and you can measure a real gap between conversions in the ad platforms and in your CRM.

Who should own our Google Tag Manager account?

Your organization. Agencies and freelancers should be added as users with appropriate permissions, so that tracking stays with you when suppliers change.

Google Tag Manager vs Direct Tags vs Server-Side Tagging

Three ways to get tags onto a website

A tag is a piece of code that sends information from your website to another system: GA4, Google Ads, the Meta Pixel, LinkedIn, a heatmap tool, a chat widget. Every organization with a website and an ad budget has several. The question is how they get there and who controls them.

There are three broad approaches:

Direct tags. The code is placed in the website’s templates by a developer, or added through a CMS setting or plugin.
Google Tag Manager (client-side). One container snippet is installed on the site. Every other tag lives inside the container and is managed through Tag Manager’s interface.
Server-side tagging. The browser sends data to a server you control, which forwards it to each platform. Usually run with a Tag Manager server container alongside a web container, though other tools exist.

Alternatives such as Cloudflare Zaraz sit between these, loading third-party tools from the edge rather than in the browser. The principles below apply to them too.

None of these is right for everyone. The choice depends less on technology than on who in your organization changes tracking, how often, and how much the data feeds ad bidding.

Direct tags: simple, stable, slow to change

Hard-coding tags is the oldest approach and still a reasonable one for some sites.

Where it works

Small sites with GA4 and perhaps one ad platform, where tracking rarely changes.
Organizations with an in-house developer who owns the site and releases regularly.
Sites where performance and security reviews demand that every script be in the codebase and version-controlled.

Where it struggles

Every change needs a developer. Adding a LinkedIn tag before a campaign launch waits for the next release.
Tags scatter. Some in the theme, some in a plugin, some pasted into a page builder’s custom code field. Nobody has the full list.
Duplicates are common. A CMS plugin adds GA4 and a developer adds it again. Every number doubles. This is one of the most frequent findings in our GA4 setup and audit checklist.
Consent is harder. Each hard-coded tag must be wired to the consent banner individually.

Google Tag Manager: control, with a governance tax

Tag Manager is the default for most organizations, for good reasons. The site carries one container snippet, and tags, triggers and variables are configured in a web interface. Changes are published as versions, can be previewed and debugged before going live, and can be rolled back.

Strengths

Speed. A trained marketer or agency can add or fix tracking the same day without a code release.
One inventory. Every tag is listed in one place, with what triggers it.
Version history. You can see who changed what and when, and revert a bad change.
Consent integration. Tag Manager supports Google consent mode and consent checks on tags, so one consent state can govern everything in the container.
Preview and debug. Changes can be tested against the live site before anyone else sees them.

Weaknesses

Sprawl. Containers accumulate tags from campaigns that ended years ago, pixels from agencies long gone and custom HTML nobody understands.
Power without review. Anyone with publish rights can add a script that runs on every page, including one that slows the site or collects data you did not intend to share.
Brittle triggers. Tags that rely on button text, CSS classes or page structure break silently when the site is redesigned.
Script weight. Tag Manager itself is light, but what it loads may not be.

The weaknesses are all governance problems, which means they are fixable without changing tools.

Server-side tagging: resilience and control, at a cost

Server-side tagging adds a layer. The browser sends events to a server on your own subdomain; the server decides what to forward to GA4, Google Ads, Meta and others, and in what form.

Data quality. Requests to your own domain are less likely to be blocked, and first-party cookies set by the server tend to last longer than those set by scripts. More conversions reach the ad platforms.
Control. You decide exactly which fields each vendor receives, and can remove identifiers before they leave.
Performance. Fewer third-party scripts in the browser can mean faster pages.

The costs are real. A server container needs hosting, billed by usage. It needs a subdomain and DNS configuration. It needs someone who understands both the web and server containers, event deduplication and how consent signals pass through. And it needs monitoring, because when it stops forwarding, nothing on the website looks wrong.

Server-side tagging also does not replace the consent decision. It should forward only what the visitor agreed to. We go deeper on that, and on Meta’s Conversions API, in client-side vs server-side conversion tracking.

How they compare on what matters

Governance

Direct tags are governed by your development process, which is good if you have one. Tag Manager is governed by its permissions and your discipline. Server-side adds a second container to govern, but concentrates data flows in one place you control.

Maintenance

Direct tags need developer time for every change. Tag Manager needs periodic cleanup and a check after every site release. Server-side needs all of that plus infrastructure monitoring and occasional updates.

Data quality

Direct tags and Tag Manager are equally exposed to ad blockers and browser limits. Server-side recovers some of that loss. All three are only as good as the event definitions behind them, which is why a measurement plan comes before any of them.

Consent

Tag Manager makes it easiest to apply one consent state across all tags. Direct tags require each to be wired up. Server-side can enforce consent centrally, if configured to.

Governance rules that make any approach work

Whichever approach you choose, these rules prevent most problems:

The business owns the accounts. The Tag Manager account, GA4 property and ad accounts belong to your organization. Agencies are users, not owners.
Few people can publish. Many can edit and preview; two or three can publish. Every published version has a description of what changed.
A tag inventory exists. A simple document listing each tag, what it does, who requested it, which consent category it falls under and when it should be reviewed.
Annual cleanup. Remove tags for ended campaigns, departed vendors and tools nobody logs into.
Custom scripts get reviewed. Any custom HTML or JavaScript tag is read by someone technical before it is published.
Triggers use stable hooks. Fire on data layer events the developer pushes deliberately, not on button text or styling, so a redesign does not break tracking.
Tracking is tested after every release. Primary conversions are checked whenever the site changes.

Rule six deserves emphasis. A data layer, where the website announces meaningful events (form submitted, booking complete) in a structured way, is the bridge between direct and managed tagging. The developer owns the events; marketing owns what happens with them. It is the single most effective way to stop a website redesign from quietly breaking measurement.

Which to choose

Choose direct tags if the site is small, tracking is minimal and stable, and a developer owns the codebase.
Choose Tag Manager if more than two platforms are involved, campaigns change regularly, or marketing needs to move without waiting for releases. This is most established organizations.
Add server-side tagging when ad spend is significant, automated bidding depends on conversion data, the measured gap between platform and CRM conversions is material, and someone can own the infrastructure.

An illustrative example. Say a regional credit union runs GA4, Google Ads and Meta, launches campaigns quarterly and has a small IT team that controls website releases. Tag Manager, with a data layer implemented by IT and publishing restricted to marketing’s two analysts, gives both sides what they need. Server-side tagging can wait until the advertising program grows into it.

In our analytics and measurement work we use Tag Manager or Cloudflare Zaraz for most clients, and server-side tagging where the volume justifies it. When conversions do drop after a change, how to diagnose a drop in website conversions walks through checking the tags before blaming the marketing.