gtag.js vs Google Tag Manager events
There are two common ways to send events to GA4: gtag.js, where you call the gtag() function directly in code, and Google Tag Manager (GTM), where tags fire based on triggers reading a data layer. They reach the same destination but differ in who controls firing and how events are defined. Choosing between them is about workflow and governance — not about privacy, which applies equally to both.
What this means
With gtag.js, developers call gtag('event', ...) directly in the page code; the logic for what fires lives in the codebase. With Google Tag Manager, a container script loads and fires tags based on triggers that evaluate a data layer the site pushes to; marketers can add or change tags in the GTM UI without code deploys. Both ultimately send the same GA4 events to the same property.
Trade-offs in control and governance
gtag.js keeps tagging in code: version-controlled and developer-owned, but every change needs a deploy. GTM moves tag management into a UI: faster iteration and non-developer access, at the cost of a layer that can fire third-party tags and needs governance to stay clean. Neither is inherently 'better' — they suit different teams. What does not change between them is privacy: consent, data minimisation, and no-PII rules bind both paths identically.
- gtag.js: events defined in code, deploy to change
- GTM: tags fire from data-layer triggers, edited in UI
- Delivery differs; privacy duties are identical
How it appears in analytics and logs
An event you cannot find in code may be defined as a GTM tag firing on a data-layer trigger; one not in GTM may be a direct gtag() call. Know which path your events take.
Diagnostic use case
Decide whether to send events directly with gtag.js or manage them in Tag Manager, based on who needs to control tagging and how it is governed.
What WebmasterID can help detect
WebmasterID's first-party tracker is a third path: a lightweight script that emits events directly, without a tag manager or third-party container.
Common mistakes
- Running gtag and GTM for the same events and double-counting.
- Assuming GTM removes consent or data-minimisation duties.
- Losing track of where an event is actually defined.
Privacy and accuracy notes
gtag and GTM are delivery mechanisms; neither makes data collection lawful or removes consent duties. The same data-minimisation rules apply to both. This is educational, not legal advice.
Related pages
- gtag set vs config
In the gtag.js API, set and config look similar but do different jobs. gtag('config', ...) initialises a destination (like a GA4 measurement id) and can pass configuration for it. gtag('set', ...) sets values that apply to subsequent events globally, regardless of destination. Mixing them up leads to parameters that do not attach where you expect. This page clarifies their scope.
- The data layer
The data layer is a JavaScript object (commonly the dataLayer array used by Google Tag Manager) that holds structured information about the page and user actions in one place. Tags read from it instead of scraping the DOM. It decouples what the site knows from how tags consume it — a cleaner, more maintainable model — provided you never push personal data into it.
- Cross-domain tracking and the linker
Cross-domain tracking keeps a single session intact when a user moves between two domains you own — for example a marketing site and a separate checkout domain. GA4 does this with a linker that appends the client id to outbound links as a URL parameter (_gl), so the destination domain recognises the same user. Without it, the second domain starts a fresh session and attribution breaks.
- Events reference (docs)
First-party events without a tag manager.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.