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.
What this means
gtag('config', 'TARGET_ID', {...}) tells gtag.js to initialise a specific destination — for GA4, your measurement id — and the object can include settings and parameters for that configuration. gtag('set', {...}) sets field values that persist across subsequent gtag calls and apply globally, not tied to one destination. So config is about setting up a target; set is about establishing values that ride along on later events.
When to use which
Use config to initialise GA4 and pass destination-level options. Use set when you want a value attached to all later events — for instance a global parameter you want present everywhere without repeating it on each event call. Because set is sticky and global while config is per-call and per-destination, passing something to the wrong one is a common cause of 'my parameter is missing'. Keep every value non-identifying regardless of which you use.
- config: initialise a destination (e.g. measurement id)
- set: persistent, global values for later events
- Wrong choice = parameter attaches where you don't expect
How it appears in analytics and logs
A parameter you expected on every event but see on none often means it was passed to config (one destination/call) instead of set (global and persistent).
Diagnostic use case
Attach persistent parameters or configuration correctly by choosing gtag set (global, sticky values) versus gtag config (per-destination setup).
What WebmasterID can help detect
WebmasterID's first-party tracker avoids this footgun by keeping a small explicit event API; the gtag scope distinction is specific to Google's tag.
Common mistakes
- Using config to set a value meant to apply to all events.
- Expecting set values to configure a specific destination.
- Setting personal data globally via gtag('set', ...).
Privacy and accuracy notes
Both commands can carry parameters; neither makes PII acceptable. Do not set personal data globally via set or per-config — keep all values non-identifying. This is educational, not legal advice.
Related pages
- 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.
- Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
- 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.
- Events reference (docs)
How WebmasterID's tracker passes parameters.
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.