GA4 Events Explained: Types, Parameters, and How to Track

GA4 events are the atomic unit of measurement in Google Analytics 4: every user interaction -- page views, clicks, purchases, scrolls, file downloads, and video engagements -- is recorded as a named event with a set of parameters, replacing the session-and-hit model that powered Universal Analytics for over a decade. There are three event types (automatically collected, recommended, and custom), each event carries up to 25 parameters, and every report, audience, and conversion inside GA4 is built on top of this event-based data model.

If you are coming from Universal Analytics, the mental shift is significant. Instead of thinking about pageviews, events, social interactions, and ecommerce as separate hit types with their own taxonomies, you now think in one vocabulary: events. Every single data point GA4 ingests is an event. This unification is what makes GA4 simultaneously more flexible and more demanding to configure correctly. Before you instrument a single event, you should define your measurement strategy -- our event tracking plan for startups walks through the "why before how" framework that saves teams from re-instrumenting later.

The event model also shifts power toward server-side and offline data collection. Because GA4 treats every interaction as an event, the same event structure can carry data from your website (gtag.js), your mobile app (Firebase SDK), your backend (the Measurement Protocol), or your CRM. This is a fundamentally different architecture from UA, where server-side hits were limited and awkward. We cover the implementation side in depth in our Google Tag Manager guide and server-side tagging guide.

TL;DR: What Are GA4 Events?

• GA4 events are named interactions with parameters. Every user action GA4 records -- from a page view to a purchase -- is an event.
• GA4 replaces Universal Analytics' session-and-hit model with a flat event-based model. There are no more hit types; everything is an event.
• There are three event types: automatically collected events (no setup needed), recommended events (Google-defined, you instrument them), and custom events (you define the name and parameters).
• Each event carries up to 25 event-level parameters and can also pass user-level and item-level parameters for richer reporting.
• You send events through gtag.js, Google Tag Manager, or the Measurement Protocol -- and you can modify or create events in the GA4 UI without touching your site code.
• Any event can become a conversion by toggling it in GA4 admin settings. There is no separate conversion hit type.
• GA4 enforces a limit of 500 distinct event types per property and 25 event-level parameters per event (50 on GA4 360). Plan your taxonomy before you instrument.

What Are GA4 Events and How Does the Event Model Work?

GA4 events are structured data points sent to Google's analytics servers every time something happens on your site or app. Each event has a name -- a string like page_view, purchase, or generate_lead -- and a payload of parameters that describe the interaction. A page_view event carries page_location, page_referrer, and page_title. A purchase event carries currency, value, transaction_id, and an array of items with their own parameters. The event name is the key GA4 uses to group and report on interactions; the parameters are the dimensions and metrics you slice and filter by.

This architecture departs from Universal Analytics at a fundamental level. In UA, data was organized around sessions: a session contained pageviews, events, social hits, and ecommerce transactions, each as distinct hit types with their own schemas. In GA4, a session is derived metadata -- GA4 observes a stream of events from a user, groups them into a session based on a 30-minute inactivity timeout, and surfaces that grouping in reports. The underlying data, however, is just the raw event stream with no session container baked into the schema. This has profound implications for reporting: because events are not nested inside sessions, you can analyze user behavior across devices and over longer time windows in ways UA could not.

How Does the GA4 Event Model Differ from Universal Analytics?

The most visible difference is that GA4 has no hit-type taxonomy. In UA, you sent a pageview hit, an event hit (with category, action, label, and value), a social hit, or a transaction hit. Each had its own API endpoint and its own processing rules. In GA4, you send an event -- one endpoint, one structure, regardless of whether the interaction is a page view, a click, a transaction, or a server-side signal from your backend. This flattening removes the cognitive overhead of choosing the right hit type but pushes more responsibility onto you: the meaning of each event is defined by its name and parameters, not by its hit type.

A second major difference is that GA4 events are processed as a stream rather than batched into sessions at collection time. UA assembled hits into sessions server-side, which meant the session count and attribution model were largely opaque to you. GA4 collects events individually and derives session metadata later, which means you have more control over session timeouts and can query the raw event stream in BigQuery (with a GA4 360 license or the free BigQuery export (see GA4 data retention settings) for standard properties). For teams running marketing reporting off this data, the shift means you need to think in terms of event counts and user counts rather than session-scoped metrics. Our GA4 marketing reporting guide covers how to build dashboards that reflect this event-native model.

What Are the Three Types of GA4 Events?

GA4 organizes events into three tiers, each with different setup requirements and reporting capabilities. Understanding these tiers is the foundation of any tracking plan:

Automatically collected events fire with zero configuration once you install the GA4 base tag. These include page_view, session_start, first_visit, user_engagement, and scroll. They require no code changes and no GTM tags beyond the config tag. However, automatically collected events are a baseline -- they tell you that a session happened, not what happened inside it.

Recommended events are the workhorses of GA4 for most SaaS and ecommerce sites. Google defines the name, parameter schema, and reporting integration for each one. Because the schema is fixed, GA4 pre-builds reports for recommended events: the Ecommerce purchases report, for example, populates automatically when you send purchase events with the correct item array. The key recommended events for a venture-backed SaaS startup include generate_lead, sign_up, login, purchase, and begin_checkout. For content and ad-supported sites, ad_impression and ad_click are equally critical.

Custom events give you maximum flexibility at the cost of pre-built reporting. A custom event name can be any string you choose -- trial_started, demo_booked, integration_connected -- and you define the parameters. Custom events appear in Explorations, custom reports, and BigQuery but do not show up in GA4's standard report snapshots. This makes them ideal for product analytics and growth experiments but means you must build your own reporting views to surface them.

What Are GA4 Event Parameters and How Do They Work?

Event parameters are the key-value pairs attached to each event that describe what happened, to whom, and with what result. GA4 supports three parameter scopes: event-level parameters that describe the specific interaction (like search_term or value), user-level parameters that describe the person doing it (like user_type or subscription_tier -- these are called user properties), and item-level parameters that describe products or content in an array (like item_name, item_category, and price).

The scope distinction matters for reporting. Event-level parameters are available only in the context of the event that carries them -- search_term belongs to the search event and cannot be used to segment other events. User properties, by contrast, persist across events for the same user, so a subscription_tier user property can segment every event that user ever generates. Item-level parameters are arrays within a single event, so a purchase event can carry three items, each with its own item_name, price, and quantity.

To use an event-level parameter in GA4 reports, you must register it as a custom dimension or custom metric in the GA4 admin interface. Unregistered parameters are visible only in DebugView and BigQuery. GA4 imposes a limit of 25 event-level parameters per event (50 on GA4 360) and 25 user properties per property. This means you need to choose parameters deliberately -- instrumenting every possible data point on every event hits the limit fast and creates unusably noisy reports.

How Do You Send Events to GA4?

GA4 accepts events through three collection paths, each suited to different use cases. The right choice depends on where your data originates and who owns the instrumentation:

gtag.js (client-side JavaScript). The simplest path. You install the GA4 config snippet on every page, and events fire directly from the browser. The gtag('event', 'event_name', { parameters }) syntax sends an event immediately. This works for straightforward client-side interactions -- page views, button clicks, form submissions -- but requires developer access to the codebase and a deployment to change anything. It is the default path for most single-page applications and static sites.

Google Tag Manager (GTM). GTM sits between your site and GA4, letting you create event tags, triggers, and variables in a web UI without touching site code. You configure a GA4 Event tag in GTM, set a trigger (like a button click or a custom event pushed into the data layer), and GTM fires the event to GA4. The data layer -- a JavaScript object on window.dataLayer -- is the plumbing that carries structured data from your site into GTM's variables. For a deeper dive on how the data layer works and why it matters, read our data layer guide.

Measurement Protocol (server-side). The Measurement Protocol is an HTTP API that lets you send events to GA4 from any environment that can make an HTTP POST -- your backend, a cron job, a mobile push server, or a CRM webhook. You POST JSON to https://www.google-analytics.com/mp/collect with your measurement ID and API secret, and the event arrives in GA4 just like a client-side event. This is how you track offline conversions, subscription renewals that happen on your payment processor, or CRM stage changes that never touch a browser. Our server-side tagging guide covers the full Measurement Protocol setup including authentication, debugging, and deduplication with client-side events.

Each path can operate independently or together. A common pattern for SaaS startups: collect the initial sign-up and page-view events via gtag.js, enrich with GTM for marketing pixels and conversion events, and send backend events -- trial expiration, payment failure, feature adoption -- through the Measurement Protocol.

How Do You Modify and Create Events in the GA4 Interface?

GA4 includes an event modification feature that lets you adjust event names and parameters in the GA4 admin UI, without redeploying your site or touching GTM. This is accessed under Admin > Data Display > Events > Modify Event. You write rules that match incoming events by name or parameter value and then change their name, add or remove parameters, or block them entirely.

Modification rules solve several practical problems. If your developers fire a signup event but you want it mapped to Google's recommended sign_up name so it appears in the standard reports, a modification rule can rename signup to sign_up. If you need to add a page_category parameter to every page_view event based on the URL path, a modification rule can derive it. If a contractor accidentally fires garbage events during QA, a block rule can suppress them before they pollute your reporting.

You can also create entirely new events from existing events. A "Create Event" rule watches for a specific condition -- for example, a page_view event where page_location contains /thank-you -- and generates a new event, like conversion_page_view. This is a lightweight alternative to full GTM reconfiguration and is particularly useful when you inherit a site with partial instrumentation and need to fill gaps quickly. The caveat is that modification rules are processed in order, and they apply at the data-display level -- the raw event stream in BigQuery retains the original event name and parameters unchanged.

How Do You Mark GA4 Events as Conversions?

In GA4, any event can be marked as a conversion with a single toggle. There is no separate "goal" or "conversion hit" configuration as there was in Universal Analytics. You navigate to Admin > Events > Conversions, click "New conversion event," and type the event name. From that point forward, GA4 counts every occurrence of that event as a conversion and surfaces it in the Conversions report, the Advertising workspace, and attribution models.

The toggle is deceptively simple, which is why startups often get conversion tracking wrong. Marking an event as a conversion does not change how the event fires -- it only changes how GA4 reports it. If your generate_lead event fires on every form impression rather than on successful submission, marking it as a conversion will inflate your lead counts. The event itself must already be accurate. This is where the event tracking plan and the conversion tracking plan converge: the conversion tracking setup for startups guide explains how to align business KPIs with GA4 conversion events so you are counting the right actions from day one.

A practical note on naming: GA4 recommends naming conversion events with the generate_lead or purchase recommended-event names where possible because these populate pre-built reports. Custom conversion events work fine but require custom reporting to surface their performance over time, by channel, and by audience.

How Do You Debug GA4 Events with Debugview?

DebugView is GA4's real-time event monitor for development and QA. It shows every event arriving from your test device as it arrives, including event names, all parameters, user properties, and whether the event triggered a conversion. You activate DebugView by enabling debug mode on your device -- either through the GA4 Debugger Chrome extension, by adding ?gtm_debug=x to your URL when using GTM's preview mode, or by setting the debug_mode parameter to true in your gtag config.

The debugging workflow follows a structured sequence. Here is how to validate a new event end-to-end:

1. Enable debug mode. Install the GA4 Debugger Chrome extension and activate it on your site, or enter GTM preview mode. You should see a debug banner on the page confirming debug mode is active.
2. Open DebugView in GA4. Navigate to Admin > Data Display > DebugView. Watch for your device to appear in the "Debug device" selector -- it may take 10-30 seconds for the first events to arrive.
3. Trigger the event you are testing. Perform the exact user action that should fire the event -- click the button, submit the form, complete the purchase. Watch DebugView for the event to appear in the timeline.
4. Inspect the event payload. Click on the event in DebugView and expand the parameters. Verify every expected parameter is present and has the correct value. Check that user properties are attached and that item arrays (for ecommerce events) contain the right fields.
5. Verify no duplicate events. Watch the timeline for 10-15 seconds after your action. If the event fires twice -- once from gtag and once from a GTM tag, a common double-counting bug -- both instances will appear in DebugView close together.
6. Check conversion marking. If the event is configured as a conversion, DebugView shows a trophy icon next to it. If the event fires but the icon is missing, the conversion mark was not applied in admin settings.
7. Exit debug mode and check the Realtime report. Turn off the debug extension and trigger the event again. Confirm it appears in the Realtime report within 30 seconds. DebugView shows only debug-mode events; the Realtime report shows production traffic.

DebugView has one limitation worth knowing: it does not show events that are blocked by modification rules or data filters. If you have an active modification rule that renames or suppresses an event, DebugView shows the post-modification result. To see the raw, unmodified event you need BigQuery export or the Measurement Protocol debug endpoint.

What Are the Limits of GA4 Event Tracking?

GA4 enforces several hard limits on event collection that directly affect how you design your tracking plan. The most important limit is the cap of 500 distinct event types per property. An "event type" is a unique event name -- so page_view, click, and purchase each count as one. Custom events count toward the same 500 limit. If you instrument every button click with a unique event name, you will exhaust the limit quickly and prevent new events from being recorded. Google recommends staying well under 500; for most startups, 50-150 distinct event types is a healthy operating range.

The second key limit is 25 event-level parameters per event (50 for GA4 360 properties). This includes both Google-defined parameters and your custom parameters. For example, a purchase event that carries currency, value, transaction_id, coupon, shipping, tax, payment_type, and a handful of custom parameters can start approaching the limit quickly. Item-level parameters -- like item_name per product in a purchase -- do not count toward this 25-parameter limit because they live in the items array, which is structured separately.

Additionally, GA4 imposes a 50-custom-dimension and 50-custom-metric limit per property for event-scoped custom dimensions and metrics. User-scoped custom dimensions (user properties) are capped at 25 per property. These limits are not theoretical -- if you register more than 50 unique event-scoped custom dimensions across all your events, GA4 rejects the excess and the associated parameters become invisible in reports. For teams building a tracking plan from scratch, we recommend reading our event tracking plan for startups before instrumenting anything -- it covers the scoping, naming, and limit-management strategy that avoids these ceilings.

See also: GA4 audiences: how to build, export, and govern them.

Frequently Asked Questions

What Are GA4 Events?

GA4 events are the atomic unit of measurement in Google Analytics 4: every user interaction is recorded as a named event with a set of parameters, replacing the session-and-hit model used by Universal Analytics.

What Are the Three Types of Events in GA4?

GA4 has automatically collected events (collected with no setup), recommended events (Google-defined events you instrument for richer reporting like purchase or generate_lead), and custom events (events you define yourself, which are not eligible for standard reporting).

How Many Event Types and Parameters Does GA4 Allow?

GA4 allows up to 500 distinct event types per property and up to 25 event-level parameters per event (50 for event-scoped custom parameters on GA4 360), plus standard user and item parameters.

How Do You Send Events to GA4?

You can send events to GA4 with the gtag.js snippet, through Google Tag Manager, or via the Measurement Protocol for server-side tracking, and each event carries a name plus any event-level, user-level, or item-level parameters you configure.

How Is a GA4 Event Different from a Conversion?

A conversion in GA4 is simply any event you mark as a conversion in admin settings; the event itself is the recorded interaction, and marking it as a conversion lets GA4 count and report it as a key action.

Key Takeaways

• GA4 events replace the session-and-hit model of Universal Analytics with a flat event-based architecture. Every interaction is an event, and events carry parameters that define dimensions and metrics.
• The three event types -- automatically collected, recommended, and custom -- serve different purposes. Start with automatically collected, layer on recommended events for pre-built reporting, and use custom events for product-specific interactions.
• Plan your event taxonomy before instrumenting. The 500-event-type and 25-parameter-per-event limits are real ceilings that are expensive to fix after you hit them.
• DebugView is your QA tool for every event. Test every event name, every parameter, and every conversion mark before sending production traffic through the pipeline.
• Any event can be a conversion in GA4. The toggle in admin settings is the only step -- but the event must fire accurately before you flip it, and the conversion tracking plan should align with your business KPIs.