GA4 Event Parameters: The Hidden Key to Useful Reports

You've got GA4 firing events. Sessions, page views, clicks, form submissions — they're all showing up in the event report. And yet when you try to answer the question your client actually asked — "which product category are people buying from?" or "what's the most common search term before a conversion?" — you've got nothing. The event count is there; the context isn't.

That context lives in parameters. They're the key-value pairs attached to every event, and they're the difference between a tally and a data point. Most implementations collect far fewer parameters than they should — not out of laziness, but because it's easy to miss just how much you need to configure before parameters become usable in reports.

What Parameters Are

Every GA4 event is a name plus a bag of properties. The event name — purchase, video_start, form_submit — tells you what happened. The parameters tell you everything else: what was purchased, which video, which form, how far through the funnel the user was, how much the transaction was worth.

Parameters can hold strings or numbers. String parameters become custom dimensions in your reports — things you can filter and segment by. Numeric parameters can become custom metrics — values you can sum, average, or compare. Neither is useful in reports until you explicitly register it in the GA4 property admin. More on that shortly.

Automatic Parameters: What GA4 Collects Without You Asking

GA4 automatically attaches a set of parameters to every event and makes them available as built-in dimensions and metrics — no configuration required. These are sometimes called "automatically collected" or "reserved" parameters, and they cover the most common reporting needs out of the box.

These are collected for free, but "collected" doesn't mean infinitely accessible. Parameters like page_location and page_title surface as pre-built dimensions in standard reports. But if you want to query them in Explore or filter by them in a custom report, you'll still sometimes hit registration requirements depending on your property type and report type.

Custom Parameters: What You Need to Add Yourself

Beyond the automatic set, anything specific to your business has to be explicitly sent as a parameter on the relevant event. These are the parameters that answer the questions your clients actually care about.

The item-scoped parameters (item_category, item_brand, etc.) are part of GA4's eCommerce schema and belong inside the items array. The others are event-level parameters, sent directly alongside the event name. The distinction matters for event scopes — item-scoped parameters won't roll up to session or user level the same way event-scoped ones do.

Sending Parameters: A Real Example

Here's what a well-parameterised purchase event looks like using gtag() directly, and what the equivalent dataLayer push looks like for GTM:

// gtag() direct implementation
gtag('event', 'purchase', {
  transaction_id: 'T-20240615-001',
  value: 149.95,
  currency: 'NZD',
  coupon: 'SUMMER20',
  items: [
    {
      item_id: 'SKU-4821',
      item_name: 'Merino Crew Neck',
      item_brand: 'Untouched World',
      item_category: 'Apparel',
      item_category2: 'Knitwear',
      price: 149.95,
      quantity: 1
    }
  ]
});

// Equivalent dataLayer push (for GTM)
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'T-20240615-001',
    value: 149.95,
    currency: 'NZD',
    coupon: 'SUMMER20',
    items: [
      {
        item_id: 'SKU-4821',
        item_name: 'Merino Crew Neck',
        item_brand: 'Untouched World',
        item_category: 'Apparel',
        item_category2: 'Knitwear',
        price: 149.95,
        quantity: 1
      }
    ]
  }
});

Notice transaction_id is present. Without it, GA4 has no way to de-duplicate a purchase event that fires twice (page reload, double-submit, etc.) — you'll overcount revenue. currency is required if you want value to appear in revenue reports; GA4 won't display revenue figures without it.

The Registration Requirement

This is the step most implementations miss. Sending a parameter in your event payload does not automatically make it available as a dimension or metric in GA4 reports. You have to register it.

To register a custom parameter, go to Admin → Data display → Custom definitions in your GA4 property. Click "Create custom dimension" (or metric for numeric parameters), give it a display name, set the scope (Event or Item), and enter the exact parameter name as you send it in code. From that point forward, new events containing that parameter will populate the dimension.

Two things to be aware of:

• Historical data is not backfilled. Registration only affects events collected after the definition is created. If you're six months into an implementation and add form_name today, you'll only see it from today onwards.
• There's a quota on custom definitions. Standard GA4 properties allow 50 custom dimensions and 50 custom metrics per property. Google Analytics 360 raises this to 125 of each. Choose what to register carefully.

Limits and Gotchas

The 25-parameter ceiling applies to custom parameters only — automatic parameters like page_location and session_id don't count against it. But if you're building a rich eCommerce implementation with item-level details, form metadata, user properties, and campaign context all in the same event, it's easier to hit 25 than you'd think. Audit your event schemas before you build.

A few other limits worth keeping in mind:

• Event names: 40 characters maximum, alphanumeric and underscores only, must not start with a number.
• Parameter names: same 40-character, alphanumeric-plus-underscore rule.
• String parameter values: 100 characters. Anything longer is truncated at exactly 100 — no error, no warning.
• The items array: each item can contain up to 10 custom item parameters in addition to the standard item fields.
• Reserved names: GA4 reserves certain event and parameter names (like session_id, firebase_conversion) — sending a custom parameter with those names can produce unexpected results.

Parameters vs User Properties

Not everything should be an event parameter. Attributes that describe the user rather than a specific action — subscription plan, account age, customer tier — belong in user properties, not event parameters. User properties persist across sessions and are set once (or when they change), whereas event parameters are scoped to the individual event.

The practical difference: user properties are available as user-scoped dimensions throughout your reports, letting you segment all behaviour by that attribute. If you send subscription_tier as an event parameter on your login event, you can only see it on that event — not on the subsequent purchase events that follow in the same session.

How Parameters Become Useful in Reports

Once registered, custom parameters appear as dimensions you can add to any Exploration or custom report. A form_name dimension lets you segment your key event counts by which form drove them. An item_category dimension lets you build an eCommerce report broken down by product type rather than just overall revenue.

Parameters also flow into attribution reports when they're attached to conversion events — so if you're passing value on your key events, your channel attribution reports will show attributed revenue, not just attributed conversion counts. That's a significantly more useful number for budget decisions.

One thing parameters can't do: they can't compensate for sampling. If your Exploration report is sampled, it applies to parameter-based dimensions just as it does to built-in ones. If you're querying high-cardinality string dimensions (like transaction_id or item_id) on large date ranges, you'll feel the sampling ceiling sooner than with lower-cardinality dimensions.

The Right Time to Define Your Parameter Schema

Before implementation, not after. The most expensive mistake in GA4 measurement is discovering six months in that you've been collecting events without the parameters you need to answer your business questions. Adding parameters retrospectively means starting your data history over for those dimensions.

Map your key events first, then list every question you'll want to answer about each event, then work backwards to the parameters that would answer those questions. That schema document becomes your implementation brief — for your developer, your GTM setup, and your custom definitions in the GA4 admin. It also forces the conversation about what data is actually available on each page or interaction, which often surfaces data layer gaps early when they're cheap to fix.