GTM vs GA4: what you configure where (the reference)
Half of all tracking confusion is 'do I set this up in Tag Manager or in GA4?' A plain reference: the mental model, a what-goes-where table, and the five mix-ups that waste the most time.
TL;DR
Google Tag Manager decides what fires and when; GA4 decides what the data means and how it's reported. GTM is the dispatcher — tags, triggers, variables, the container that loads on the page. GA4 is the analytics product — the property, data streams, key events, audiences, and every report. So: you send events from GTM, but you mark them as conversions in GA4. You fire a button-click tag in GTM, but automatic page views and scrolls come from GA4's Enhanced Measurement. Cross-domain, data retention, internal-traffic filters, and attribution live in GA4 Admin; consent wiring and other vendors' pixels live in GTM. Get the split straight once and most "where do I even set this up?" questions answer themselves. Below: the mental model, a what-goes-where table, and the five mix-ups that waste the most time.
You'd be amazed how much tracking work stalls on one unspoken question: "is this a Tag Manager thing or a GA4 thing?" The two tools overlap enough to feel interchangeable and differ enough that putting a setting in the wrong one means it silently does nothing. Here's the plain reference so you stop guessing.
The one-line mental model
- GTM = the dispatcher. It loads on the page and decides what fires and when — which tags (GA4 events, Meta pixel, Ads, etc.), on which triggers, with which variables. It sends data out; it stores and reports nothing.
- GA4 = the destination + the meaning. It receives events and decides what they mean and how they're reported — which events count as conversions, how users are grouped into audiences, how traffic is attributed, what the reports show.
Almost every "where does this go?" resolves by asking: am I changing what fires (GTM), or what the data means / how it's reported (GA4)?
What configures where
| Task | Configure in | Note |
|---|---|---|
| Load GA4 on the site | GTM (Google tag) or GA4's gtag snippet | One or the other, not both |
| Track a button click / form submit | GTM (trigger + GA4 event tag) | …unless Enhanced Measurement already catches it |
| Automatic page_view, scroll, outbound click, site search | GA4 (Enhanced Measurement) | A toggle on the data stream — no GTM needed |
| Mark an event as a conversion (key event) | GA4 (Admin → Events / Key events) | The #1 mix-up — never in GTM |
| Other vendors' pixels (Meta, Ads, TikTok) | GTM (their tags) | GTM is the shared dispatcher |
| Consent Mode wiring | GTM (+ a CMP) | Defaults on the dataLayer before the container |
| Cross-domain measurement | GA4 (data stream → Configure domains) | Or via the GTM tag's fields |
| Internal-traffic / referral exclusions, data retention, attribution model | GA4 (Admin) | Reporting-side settings |
| Custom dimensions / metrics, audiences | GA4 (Admin) | Built from received event params |
| Server-side tagging | GTM (a server container) | Scoped per client |
| Reports, explorations, funnels | GA4 | GTM has no reporting |
The five mix-ups that waste the most time
1. "I built the GTM tag but it's not a conversion." Firing an event in GTM and marking it a conversion are two steps in two tools: send the event from GTM, then in GA4 → Admin → Events, toggle it as a key event. A GTM tag will never make itself a conversion.
2. Double-tracking page views. GA4's Enhanced Measurement already sends page_view automatically. Add a second GTM page-view tag and you double-count. Pick one — usually let Enhanced Measurement handle page views and use GTM for the custom events it doesn't cover.
3. Hunting for cross-domain in GTM. Cross-domain lives in GA4 (data stream → Configure tag settings → Configure your domains), not as a standalone GTM tag. Looking in the wrong tool is why traffic ends up self-referred or Unassigned.
4. Expecting GTM Preview to show GA4 reports. GTM Preview shows what fired; GA4 DebugView shows what GA4 received, and the standard reports settle 24–48h later. Three different surfaces — don't judge one by another.
5. Setting consent on the wrong layer. Consent Mode defaults must hit the dataLayer before the GTM container loads, and the tags respect them — it's a GTM-side wiring job coordinated with your CMP, not a GA4 setting.
The orientation that prevents all of it
Each of these is the same root confusion: treating two tools as one. Keep the split — GTM fires, GA4 means — and the rest is mechanical. It's also why a periodic GTM container audit and a GA4 audit are separate checks: one verifies the dispatcher (right tags, right triggers, conversion linker, consent), the other verifies the destination (right key events, clean channels, cross-domain, no junk conversions).
That two-sided picture is exactly what gets lost across a book of clients — which is why Phloz models every client's GTM containers and GA4 properties as distinct, health-checked nodes on the tracking-infrastructure map, so "is this configured in the right place, and is it working?" is a view rather than a hunt. The CRM for SEO agencies and pricing pages cover the workflow; the reference above is the part you can keep on a sticky note — GTM fires, GA4 means.