gtag event vs config commands
In gtag.js, gtag('event', name, params) sends a single analytics event, while gtag('config', target_id, params) initialises a destination and its settings. They are easy to confuse because both accept a parameter object, but one transmits a hit and the other sets up where hits go. Mixing them means events that never send, or configuration passed as if it were data. This page separates their roles cleanly.
Two different jobs
gtag('config', 'TARGET_ID', {...}) initialises a destination such as a GA4 measurement id and applies configuration to it (developers.google.com gtag.js reference). gtag('event', 'event_name', {...}) transmits one event with its parameters to the configured destinations. Config sets up the pipe; event pushes data through it. You need a config before events have anywhere to go.
Common confusion
Because both take an options object, people sometimes put event data into config (so it never sends as an event) or expect config-level settings to apply by sending them as an event. The fix is to ask what you are doing: transmitting a discrete interaction (event) or setting up/adjusting a destination (config). Note the related but separate gtag('set', ...) for persistent global values, covered elsewhere.
- config: initialise a destination and its settings
- event: transmit one named event with parameters
- Distinct again from gtag('set', ...) for global values
How it appears in analytics and logs
An interaction you expected as an event but never see usually means it was passed as config options, or the config call is missing so events have no destination.
Diagnostic use case
Send measurable interactions with gtag('event', ...) and initialise the GA4 destination with gtag('config', ...), so events transmit and configuration applies where intended.
What WebmasterID can help detect
WebmasterID's explicit first-party event API sidesteps this gtag ambiguity; the event-vs-config distinction is specific to Google's tag and documented here.
Common mistakes
- Passing event data to config so it never sends.
- Sending configuration as an event and expecting it to apply.
- Forgetting the config call, leaving events without a destination.
Privacy and accuracy notes
Both commands can carry parameters; neither legitimises PII. Keep all values non-identifying whether configuring a destination or sending an event. 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.
- 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.
- Events reference (docs)
How WebmasterID sends events explicitly.
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.