Conversion Tracking & Data

Google Tag vs Google Tag Manager: Which One to Install First

In short: Both get Google's measurement and conversion tags onto your pages, but they operate at different altitudes. Google Tag is a single, site-wide snippet wired directly to specific Ads and Analytics destination IDs, with no separate interface to manage rules. Google Tag Manager is a container and rules engine - you publish tags, including the Google tag itself, with triggers and variables through a web interface, without another code deploy. Use the Google tag alone for one or two Google destinations with nobody but engineering touching tracking; reach for GTM the moment you run more than a couple of vendors or need non-engineers adding tags.

By the AdFlint research team · Fact-checked against current Google and Meta platform behavior · Last reviewed July 2026

Google Tag

A single site-wide snippet, gtag.js, that collects measurement data and routes it to Google Ads and Analytics destinations.

One tag on every page handles page views, conversions, and the linker that preserves the gclid in a first-party cookie, then distributes data to whichever destination IDs you configure. It is the simplest correct install for a site without a tag manager. The usual failure is leaving legacy conversion snippets in place next to it, which produces duplicate conversions, or omitting the tag from the actual confirmation page.

Full definition

Google Tag Manager

A container you deploy once, then use to add, edit, and version marketing tags without touching site code again.

GTM ships a container snippet; inside it you define tags, the triggers that fire them, and the variables they read, then publish versions independently of engineering releases. It earns its place the moment you run more than a couple of vendors or need consent mode enforced in one location. The common confusion is thinking GTM measures anything itself; it only deploys other people's tags, and a broken trigger collects nothing.

Full definition

Side by side.

The differences that actually change what happens in your account.

	Google Tag	Google Tag Manager
What you install on the page	One hardcoded snippet with specific destination IDs.	A single container snippet that stays the same regardless of how many tags live inside it.
Adding a new destination	Requires editing the page's code.	Requires publishing a new container version through the interface.
Who can make changes	Whoever can edit the site's template code.	Anyone with container access, no code deploy needed.
Versioning and rollback	Handled through your normal code deploy and revert process.	Built in - every publish is a version you can roll back to from the interface.
Vendor scope	Google destinations only.	Any vendor's tag, deployed alongside the Google tag it manages as one of its own tags.
Trigger logic	Whatever gtag() calls you hand-code into the page.	Built-in triggers - page views, clicks, form submits, custom dataLayer events - reusable across tags.
Common failure	Leaving legacy conversion snippets in place alongside it, producing duplicate conversions.	A broken trigger that silently collects nothing while looking published and live.

What actually separates them.

The Google tag ships hardcoded destination IDs in the snippet itself, so a new Google Ads account means editing the page; GTM adds that same destination by publishing a container version, no code touch required.

GTM can deploy the Google tag as one of its managed tags alongside completely unrelated vendor pixels; the standalone Google tag only ever talks to Google destinations.

GTM has built-in trigger and variable logic you reuse across tags; a hand-coded Google tag relies entirely on whatever gtag() calls or dataLayer pushes you write into the page yourself.

GTM keeps a version history you can roll back from its interface; a hand-coded Google tag change only rolls back through your site's normal code deploy and revert process.

Running GTM doesn't remove the need for the Google tag - GTM typically deploys the Google tag itself as one of its managed tags, so the two are usually layered, not competing.

Which one should you use?

Use Google Tag when

You only send data to Google Ads and GA4, nothing else.
Your team is engineering-only and comfortable editing template code for tracking changes.
You want the fewest moving parts and aren't planning to add more vendor tags.
Page load simplicity matters more to you than tag flexibility.

Use Google Tag Manager when

You run tags for multiple vendors - Ads, Analytics, a chat widget, a CRM pixel, retargeting scripts.
Marketing or growth needs to add or adjust tags without opening a pull request.
You need consent mode or a consent management setup enforced in one place across every tag.
You want a version history and a preview mode before anything goes live.
You're standardizing tracking across multiple sites and want one interface, not scattered hardcoded snippets.

Common questions.

Do I need the Google tag if I already have GTM?

Yes in effect - GTM deploys the Google tag as a tag inside the container, so you're not choosing one over the other, you're choosing where the Google tag's code actually lives and how it gets managed.

Can I run the Google tag directly on the page and GTM at the same time?

You can, but it commonly produces duplicate hits to the same destination if both end up firing the same event, so pick one place - either directly on the page or inside GTM - for the Google tag to live.

Which one do I actually need for conversion tracking to work at all?

Either path works. Conversion tracking needs the Google tag's code to execute on the confirmation page one way or another, whether you hand-code it directly or let GTM publish it as a managed tag.

Or stop choosing between them.

AdFlint picks the setting, writes the ads, and keeps optimizing inside the Google and Meta accounts you already own.

Try AdFlint free See how it works

Related comparisons

All comparisons