Event Parameters

Event parameters are the name–value pairs attached to every GA4 event that describe what actually happened — which page, which button, which product, how much. The event name says that something occurred; the parameters carry all the detail. A purchase event without parameters is just a tick mark; with value, currency and an items list it becomes a business record. This entry covers the parameters GA4 sends automatically, how custom parameters work, the registration step that trips up almost every new implementation, and the limits — 25 parameters per event, 40-character names, 100-character values — that quietly truncate sloppy setups.

What Event Parameters Are

GA4’s data model is radically flat: everything is an event, and every event is described by parameters. Where Universal Analytics had typed hits with fixed fields (category, action, label), GA4 replaced the whole taxonomy with free-form key–value context. page_view carries a page_location parameter; click carries link_url; your custom signup event can carry plan, billing_cycle and anything else you decide matters.

Parameters travel with the event at collection time — bundled into the request your tag or data layer push produces. They are not retroactive: an event collected without a parameter can never gain it later.

Parameters GA4 Sends Automatically

Every event, including your custom ones, is accompanied by a set of automatically collected parameters. The ones you will meet most often:

Events created by enhanced measurement (scrolls, outbound clicks, downloads, video) arrive with their own specific parameters — percent_scrolled, link_domain, file_name and so on — with no configuration from you.

Custom Parameters

Any parameter you invent and attach to an event is a custom parameter. In a gtag.js call they are simply extra keys; in Tag Manager, rows in the event tag’s parameter table fed from data layer variables:

gtag('event', 'signup', {
  plan: 'starter',
  billing_cycle: 'annual',
  referral_source: 'partner-blog'
});

Naming discipline pays off quickly: lowercase snake_case, consistent across events (plan everywhere, not plan here and pricing_plan there), and never containing personal data — parameter values land in reports, exports and integrations, so an email address in a parameter is a compliance incident, not a convenience.

The Registration Step Everyone Misses

Collected is not the same as reportable. A custom parameter flows into GA4 and appears in DebugView immediately — but standard reports ignore it until you register it as a custom dimension (for text values) or custom metric (for numbers) under Admin → Custom definitions. Registration is what turns the raw parameter into a usable reporting field. Three facts about it:

• It is not retroactive. The dimension populates from registration onward; parameter data collected before that stays dark in standard reports (BigQuery export sees everything regardless).
• Slots are capped. A standard property gets 50 event-scoped custom dimensions and 50 custom metrics — enough for a disciplined setup, quickly exhausted by a chaotic one.
• DebugView working while reports stay empty is the classic symptom of an unregistered parameter, worth checking before blaming the tag.

The Limits That Bite

GA4’s collection limits for standard properties, from Google’s documentation:

Overruns fail silently: the 26th parameter is dropped, the 101st character is truncated, and no error surfaces anywhere. Long URLs with campaign junk, product names past 100 characters, and stuffed item descriptions are the usual casualties in audits.

Event Parameters vs User Properties

Parameters describe the event; user properties describe the person and persist across events until changed. plan: starter as an event parameter records what was true at that moment; as a user property, it labels the user for every later event and audience. Rule of thumb: moment-specific facts (button, page, amount) are parameters; durable facts (subscription tier, customer status) are user properties. Confusing the two costs analysis flexibility later — the counts differ (25 per event vs 25 per property), and so does the scope of the custom definitions they need.

Setting Parameters in Tag Manager vs gtag.js

The two implementation routes reach the same payload differently:

• gtag.js — parameters are extra keys in each gtag('event', ...) call, as in the snippet above. For values that should ride along with every event on the page (a content group, a logged-in flag), gtag('set', {...}) declares them once and subsequent events inherit them.
• Tag Manager — parameters are rows in the GA4 event tag’s parameter table, with values typically pulled from data layer variables that your site pushes. The container decouples the site code from the analytics schema: developers push raw facts into the data layer, and the parameter mapping lives in GTM where it can change without a deploy.

The failure modes differ too. In gtag setups, parameter bugs live in site code and need a release to fix; in GTM setups, the classic bug is a parameter row pointing at a data layer variable that fires later than the tag — the parameter arrives empty even though the data layer eventually holds the value. DebugView plus GTM’s preview mode together catch both.

Item-Scoped Parameters in E-Commerce

E-commerce events (view_item, add_to_cart, purchase) carry a third scope of parameters: the items array. Each element describes one product — item_id, item_name, price, quantity, plus category and variant fields — and these item-scoped parameters live inside the array, not at the event level. Getting the scope wrong is the classic e-commerce implementation bug: a price attached at event level instead of inside the item does not populate item reports, and revenue silently diverges from the item-level view. Event-level facts about the transaction (value, currency, transaction_id) stay at event level; facts about each product go in the array. The two scopes have separate reporting surfaces (item reports vs event reports) and separate custom-definition slots.

A Working Parameter Taxonomy

Parameter chaos is cumulative — every inconsistent name is permanent in your historical data. Small teams do well with a written vocabulary as short as a dozen lines, decided once:

The registration limits are the enforcement mechanism: with 50 event-scoped dimension slots per property, a taxonomy that mints a new parameter name per feature runs out of reportable slots within a year, while a reused-vocabulary setup rarely passes twenty.

Checking Parameters End to End

The verification loop for a new parameter takes minutes: fire the event with DebugView enabled, click the event in the timeline, and confirm the parameter and its value appear. Then register the custom dimension, and expect reports to start filling from that point. For anything money-related, verify the value survives intact — currency symbols, decimals and truncation are the common mangling points. The Measurement Protocol accepts the same parameters server-side, with the same limits and the same registration requirement.

Frequently Asked Questions

Why doesn’t my custom parameter show up in GA4 reports?

Almost always because it was never registered as a custom dimension or metric under Admin → Custom definitions. Collection alone puts the parameter in DebugView and BigQuery, but standard reports only see registered definitions — and only for data collected after registration.

How many parameters can a GA4 event have?

25 per event, on top of the automatically collected ones. Names are capped at 40 characters and values at 100 (with page_location allowed 1,000). Anything beyond the caps is dropped or truncated without warning.

Are event parameters the same as UTM parameters?

No. UTM parameters live in the URL and describe where a visit came from; GA4 reads them into traffic-source dimensions. Event parameters live inside the analytics payload and describe what happened on your site. They meet only in the sense that both end up as reporting dimensions.

Can I attach a parameter to every event automatically?

Yes. In gtag.js, gtag('set', {...}) declares parameters that all subsequent events on the page inherit; in Tag Manager, add the row to a shared configuration or to each GA4 tag fed by a constant or data layer variable. This is the right pattern for page-level context like content group or template type.

Related Terms

• Event — the record parameters describe
• Custom Events — events you define, usually with custom parameters
• Data Layer — where parameter values typically originate
• Debug View — where to verify parameters arrive
• Enhanced Measurement — auto-events with their own parameter sets
• Measurement Protocol — sending the same parameters server-side