GA4 Events 101: Events, Parameters and Key Events

Everything GA4 records is an event — so understanding events is understanding GA4. This guide covers the foundations: what an event actually is, the events you get without doing anything, what parameters add, which events deserve the key-event flag, and when a custom event is genuinely needed. The advanced layer — naming discipline, quotas, the dataLayer and ecommerce — lives in Events 102.

What is an event?

An event is one recorded action: a page loaded, a button clicked, a video started, a form submitted, a purchase completed. Each event has a name (what happened) and can carry parameters (the details). If GA4 is new to you, GA4 102 walks through the model gently; here we go one level deeper.

The events you get for free

Before you build anything, GA4 is already recording three tiers of standard events:

• Automatic events — collected the moment the tag is installed: page_view, session_start, first_visit, user_engagement.
• Enhanced measurement events — a settings toggle (on by default) adds scrolls, outbound clicks, site search, video engagement and file downloads. No code.
• Recommended events — Google-defined names you implement yourself when relevant (purchase, generate_lead, sign_up…). Using Google’s names unlocks built-in reporting features.

Events, conversions and key events: what changed

In early 2024, a toggle that had said "Mark as conversion" in Google Analytics 4 quietly changed to "Mark as key event." Many GA4 users saw the update, assumed it was cosmetic, and moved on. It was not cosmetic. The rename was the visible part of a larger restructuring of how GA4 and Google Ads use the word "conversion" — and if you set up your GA4 property before that change, your mental model of what a "conversion" means in each platform is probably wrong.

This guide untangles it: what changed, why, and exactly what you need to do if you migrated from Universal Analytics or configured GA4 before 2024.

The old model: Universal Analytics conversions

In Universal Analytics, a "goal" was the unit of conversion tracking. You created goals in the Admin panel — a destination URL, a session duration threshold, a specific event — and UA would count a goal completion whenever those conditions were met. Goals were also what you imported into Google Ads to track campaign performance. The whole system revolved around goals as the single concept linking on-site behaviour to ad spend.

When GA4 launched, Google replaced goals with a simpler idea: any event could be flagged as a conversion. You toggled a switch next to any event in GA4, and that event would show up in the Conversions report and could be imported into Ads. Clean, flexible — but it set up the terminology confusion that came later.

What changed in 2024

Google split the old "conversion" concept in GA4 into two distinct things:

• Key events — events you have flagged as important in GA4. These appear in your GA4 reports, drive the key event rate metrics in standard reports, and are the raw material for conversion tracking. Marking an event as a key event has no effect whatsoever on your Google Ads campaigns.
• Conversions (the new meaning) — key events that have been explicitly imported into Google Ads. Only these count as conversions in Ads bidding, Smart Bidding optimisation, and the Campaigns interface.

Before and after: a comparison

The table below maps the full terminology history across four states: Universal Analytics, GA4 before 2024, GA4 after 2024, and what "conversions" now means in the Ads context.

Why Google made the change

The rename was not arbitrary. Before 2024, it was genuinely confusing that the word "conversion" meant subtly different things depending on whether you were looking at GA4 or Google Ads. In GA4, a "conversion" was simply an important event you wanted to track. In Ads, a "conversion" was something with direct monetary implications — it determined how Smart Bidding allocated your budget. Conflating the two led analysts to import GA4 events into Ads that should never have influenced bidding (micro-conversions like scroll depth or video plays, for example), which caused Smart Bidding to optimise for the wrong signals.

By calling on-site tracking "key events" and reserving "conversions" exclusively for Ads-linked actions, Google made the distinction explicit in the UI. The intent was to stop analysts from accidentally feeding junk signals to Smart Bidding.

How conversion rates are now calculated

One practical consequence of the rename is that the conversion rate metrics in your GA4 standard reports have changed labels. What was previously a "session conversion rate" for a conversion event is now a "key event rate." The formula is the same — key event count divided by sessions — but the label changed.

There are two key event rate metrics to understand:

• Session key event rate — the percentage of sessions in which the key event fired at least once. This is the closest equivalent to the old session conversion rate and is the right metric for evaluating landing pages and traffic channels. See the full explanation of event scopes for why this differs from raw key event counts.
• User key event rate — the percentage of users who triggered the key event at least once during the reporting period. More useful for retention analysis than campaign performance.

In Google Ads, conversion rate is calculated differently: it is conversions divided by ad clicks, and it is calculated entirely within the Ads interface using the imported conversion actions. A GA4 key event rate of 3.2% and a Google Ads conversion rate of 4.8% for nominally the same event are not contradicting each other — they have different denominators and different attribution windows. Your attribution model settings affect both, but in different ways.

The impact on historical reporting

The rename itself did not wipe or alter any historical data. If you had events marked as conversions in GA4 before 2024, they were automatically carried over as key events — the toggle just changed label. Your trend lines and historical counts were preserved.

However, there is a subtler historical issue. Before the rename, some teams had imported many GA4 "conversions" into Google Ads indiscriminately, because the shared label made both feel equivalent. After the rename, Google recommended auditing your Ads conversion actions and removing micro-conversions that were inflating conversion counts. If you or a previous analyst cleaned up those Ads conversion actions in 2024, your historical Ads conversion numbers will show a drop that reflects the audit, not a change in actual business performance. Check your Google Ads change history if you see an unexplained dip around early 2024.

What to do if you migrated from Universal Analytics

If you transitioned from UA to GA4 and set up GA4 conversions during the pre-2024 era, work through this checklist:

1. Audit your key events. In GA4, go to Admin > Data display > Key events. List every event currently marked. For each one, ask: does this represent a meaningful business outcome, or is it a micro-conversion that inflates counts?
2. Audit your Ads conversion actions. In Google Ads, go to Goals > Conversions > Summary. Check which GA4-sourced actions are set to "Include in Conversions" (the setting that feeds Smart Bidding). Remove or set to "Observation only" anything that is not a genuine bottom-of-funnel action. See the full guide on the Ads–GA4 connection for how to do this safely.
3. Do not re-import everything. You do not need an Ads conversion action for every GA4 key event. Key events that exist purely for on-site analysis — scroll depth, video plays, PDF downloads — should stay as key events and never be imported into Ads.
4. Check your Smart Bidding signals. If you cleaned up Ads conversion actions, Smart Bidding may have lost some of the signals it was previously using. Give campaigns 2–4 weeks of a learning period and monitor cost per conversion rather than raw conversion volume during that time.
5. Update your reporting language. Any dashboards or client reports that refer to "GA4 conversions" should be updated to "key events" to avoid confusion, especially if those reports also include Ads data where "conversions" now has a different meaning.
6. Verify your conversion rate metrics. Confirm whether your reports are showing session key event rate, user key event rate, or Ads conversion rate. Label them explicitly — "session key event rate (GA4)" and "conversion rate (Google Ads)" — so stakeholders do not conflate them.

A note on properties created after the rename

If you created your GA4 property after the rename rolled out, you have never seen the old "Mark as conversion" toggle. For you, the current model is simply how GA4 works: key events for on-site tracking, conversions for Ads optimisation. The conceptual distinction still matters — resist the temptation to import every key event into Ads — but you do not have a migration burden to manage. The main thing to understand is why the word "conversion" appears in both GA4 and Google Ads yet refers to different populations of data, which the table above explains. For a deeper look at how parameters attached to your events feed into key event tracking, see the guide on GA4 event parameters.

Summary

Google's 2024 rename was not cosmetic. It formalised a meaningful distinction: key events are what you track in GA4, conversions are what you optimise in Google Ads. The two overlap only when you deliberately import a key event into Ads. If you set up GA4 before the rename, your data is intact — but your Ads conversion actions and your reporting language probably need a review. Start with the checklist above, and treat the audit as an opportunity to tighten your Smart Bidding signals rather than just a housekeeping task.

Event parameters and their use cases

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.

Recommended vs custom: when you genuinely need a custom event

When you set up a new event in GA4, you face a small decision that quietly shapes everything downstream: do you use one of Google's recommended event names, or do you invent your own? Both will collect data. Both will show up in the events report. But only one of them switches on the report features, predictive signals, and prebuilt eCommerce views that make GA4 worth using. Most teams reach for a custom name out of habit, then spend weeks wondering why the funnel report is empty.

The short version: if Google has a recommended event for what you are tracking, use it exactly as specified. Reach for a custom event only when nothing in the recommended set fits. This guide explains why that rule holds, and where the genuine exceptions are.

The Three Tiers of GA4 Events

Every event in your property falls into one of three tiers, and the tier determines how much GA4 does for you automatically.

Automatically collected events

These fire without any configuration on your part. session_start, first_visit, and user_engagement are collected the moment the GA4 tag loads. Enhanced measurement adds more: scroll, click (on outbound links), view_search_results, file_download, and video_start among them. You do not name these, you do not send them, and you generally cannot rename them. They are the free baseline.

Recommended events

These are events Google has defined a name and a parameter spec for, but does not collect on its own. You have to implement them, sending the exact event name and the parameters Google expects. purchase, add_to_cart, generate_lead, and sign_up all live here. The payoff for using them is that GA4 recognises the name and lights up matching features.

Custom events

These are events you name yourself for interactions that have no recommended equivalent. A configurator_completed event on a product builder, or a quote_requested event on a B2B site, are custom by necessity. GA4 will collect and count them, but it treats them as opaque: no special reports, no automatic mapping, just a name and its parameters.

Why Recommended Events Matter

The reason this is not a stylistic preference is that GA4 maps recommended event names to specific machinery. Send the right name and that machinery turns on. Send a custom name for the same action and it stays dark, no matter how clean your implementation is.

• Prebuilt reports. The Monetisation reports, the purchase journey, and the checkout funnel are wired to recognise view_item, add_to_cart, begin_checkout, and purchase by name. Fire bought instead of purchase and those reports show nothing.
• Predictive metrics. GA4's purchase probability and predicted revenue models are trained to look for purchase (or in_app_purchase). Without that exact event, the predictive audiences and metrics never become eligible.
• eCommerce values. Revenue, items, and the eCommerce dimensions populate from the recommended events and their standard parameters. A custom event carrying a value parameter will not flow into the eCommerce reports.
• Smoother integrations. Google Ads conversion import and audience sharing key off recognised event names, so recommended events reduce the manual mapping you have to maintain elsewhere.

None of this is something you can switch on later with a setting. The features are bound to the names, so the choice you make at implementation time is the choice you live with.

Common Recommended Events by Use Case

You do not need to memorise the full catalogue. You need to know which recommended events cover your industry, then implement those exactly. Here are the ones that come up most often.

Each of these comes with a parameter spec. purchase expects value, currency, transaction_id, and an items array. generate_lead expects value and currency. The names and the parameters are a package: getting the event name right but the parameter names wrong leaves you in almost the same hole.

When a Custom Event Is the Right Call

Recommended events cover the common shapes of web behaviour, but they cannot cover everything. When you have a genuinely bespoke interaction, a custom event is not a compromise, it is the correct tool.

• A multi-step product configurator finishing: configurator_completed.
• A user saving a comparison of three plans: plans_compared.
• An interactive calculator returning a result: estimate_generated.
• A gated PDF being unlocked after a form: resource_unlocked.

The test is simple: if you scan the recommended list and nothing describes the action, go custom. If something close exists, use it rather than bending a custom name to mean roughly the same thing.

When you do go custom, name it well. Use lowercase with underscores, describe the action in object_action or action order consistently across your property, and keep names human-readable so the next analyst understands them without a glossary. Our guide on naming conventions covers this in depth.

The Mistake Worth Avoiding

The most common error is inventing a custom name when a recommended one already exists. A developer who does not know the recommended set fires add_cart instead of add_to_cart, or buy instead of purchase, and the data lands in GA4 looking fine. The events report fills up. The counts look healthy. But the checkout funnel stays empty, the eCommerce revenue stays at zero, and the predictive metrics never activate, because GA4 was waiting for the exact recommended name and never saw it.

This is expensive to fix later. You cannot rename historical events, so a wrong name means re-implementing with the correct one and starting that report's data history fresh. Catching it before launch costs a code review; catching it after launch costs a quarter of clean data.

The Decision, in One Line

Start every event with the question "does a recommended event already cover this?" If yes, implement it to the letter, parameters included. If no, name a clean custom event and document why. That single habit keeps your reports populated, your predictive metrics eligible, and your future self out of a re-implementation project.

Choosing your key events

Open a fresh GA4 property and you'll find a long list of events firing: page_view, scroll, click, session_start, form_submit, maybe a dozen more. Every one of them can be marked as a key event with a single toggle. That ease is the trap. The question is never "can I mark this?" It's "does this event represent something the business actually cares about?" For most sites, the honest answer is yes for three to five events and no for everything else.

Choosing well is the single highest-leverage decision in a GA4 setup. Get it right and every report, every channel comparison, every budget conversation points at the same handful of outcomes. Get it wrong and you'll spend months explaining why your "conversion rate" is 60%.

What a Key Event Actually Is

A key event is just an event you've flagged as important enough to count as a business outcome. In 2024 Google renamed what used to be called "conversions" in GA4 to "key events," and tied the old conversion concept to Google Ads instead. If the terminology shift still trips you up, the conversions vs key events guide untangles exactly what moved where. For the purposes of this post, treat "key event" as "the outcome you want more of."

Macro vs Micro: Not Everything Is a Key Event

The useful mental model is macro versus micro. A macro key event is the outcome that justifies the marketing spend: a purchase, a qualified lead, a paid sign-up. A micro-interaction is a step on the way there: a scroll to 75%, a video play, an add-to-cart, a newsletter signup. Micro-interactions are genuinely useful to track as plain events. They tell you where the funnel leaks. But they are not outcomes, and flagging them as key events quietly redefines what success means.

The test is blunt: if you wouldn't report this number to the person who controls the budget as a measure of whether marketing worked, it is not a key event. A 75% scroll is interesting. It is not what you got paid to produce.

Choosing by Business Model

The right set of key events depends almost entirely on what your site is for. Three common shapes:

Notice that begin_checkout earns a place on the ecommerce list even though it is upstream of revenue. That's deliberate: a strong secondary outcome that closely predicts the macro one is worth counting, because it gives you a larger, faster-moving signal to optimise against. The line you're drawing is between "predicts real value" and "merely happened."

How to Mark a Key Event

The mechanics are trivial, which is exactly why people overdo it. Go to Admin → Events in your GA4 property. You'll see a table of every event GA4 has collected, with a "Mark as key event" toggle on the right of each row. Flip the toggle and that event is now counted as a key event from that point on. You can also manage the full list under Admin → Key events, where you add value and review what's flagged.

If the event hasn't fired yet, it won't appear in the Events table, so you can pre-create it by name under Key events instead. Either way the toggle is the whole operation. There is no approval step, no second guess from the interface. The discipline is entirely yours.

Assigning Value, and Why It Matters

A key event that fires is a count. A key event with a value attached is a number you can put a budget against. For purchase, the value comes through naturally as transaction revenue. For everything else, you set it: under Admin → Key events, each key event has an option to record a default value, or you can pass a value (and currency) parameter on the event itself.

This is what makes return on ad spend and value-based attribution work. If a qualified lead is worth, conservatively, $40 to your business, telling GA4 that turns "we got 30 leads from paid search" into "paid search produced $1,200 of pipeline value." Now your channels are comparable on the same axis, and grouped key events can roll up into a single value figure rather than a pile of unrelated counts. Without values, every key event is worth one undifferentiated unit, and a newsletter signup counts the same as a sale.

The "Everything Is a Conversion" Anti-Pattern

The most common GA4 mistake is flagging ten or fifteen events as key events because each one felt important in the moment. The result is predictable and corrosive. Your conversion rate balloons to something absurd because a single session trips five "conversions" on its way to one actual outcome. Channel comparisons flatten, because every channel drives plenty of scrolls and clicks. The number that should focus a meeting instead ends every meeting in a shrug.

Signal is a function of scarcity. The fewer, sharper outcomes you count, the more each one means, and the more confidently you can say "this campaign worked and that one didn't." Every micro-interaction you promote to key-event status dilutes the rest. When in doubt, leave it as a plain event. You lose nothing in reporting flexibility, because plain events are still fully queryable in Explorations, and you keep your headline number honest.

Decide Before You Toggle

Spend ten minutes before you touch the toggle. Write down the outcomes your marketing is actually paid to produce, rank them, and draw the line after the fifth. Mark those, assign each a value, and leave everything else as a plain event you can still explore whenever you need to. That short list is the spine of every report you'll build afterwards, and it is far cheaper to choose deliberately now than to unwind an inflated conversion count once stakeholders have learned to quote it.