GA4 Events: Parameters, Custom Events & Common Mistakes

How GA4 Events Actually Work (and Where They Break)

Last month I audited a DTC brand running EUR 16,000 per month across Google and Meta. They had 47 custom events in their GA4 property. Only 11 were firing correctly. The rest had wrong parameter names, duplicate event names with inconsistent casing, or no parameters at all. Their purchase event was missing transaction_id, so every page refresh on the order confirmation doubled their reported revenue. Their add_to_cart event pushed productName instead of item_name, which meant GA4's built-in ecommerce reports showed nothing.

Forty-seven events, and the property was producing worse data than if they had stuck with the five automatic ones GA4 collects out of the box.

GA4 is an event-based model. Every interaction -- a page view, a button click, a purchase -- is an event. That is the foundational design shift from Universal Analytics, where you had page hits, event hits, and transaction hits as separate concepts. In GA4, everything is an event, and events carry parameters that describe what happened. Get the event structure right and your reporting, audiences, and bidding signals work. Get it wrong and every downstream system inherits the mess.

This post covers the four categories of ga4 events, how parameters work, when to create custom events, and the mistakes I fix most often.

The Four Categories of GA4 Events

Google organizes ga4 events into four tiers. Understanding which tier your event belongs to determines how much work you need to do -- and how much built-in reporting you get for free.

1. Automatically collected events

These fire without any configuration: first_visit, session_start, page_view (if enhanced measurement is on), user_engagement. You cannot rename or disable them. They are the baseline.

2. Enhanced measurement events

Toggle these on under Admin > Data Streams > Enhanced Measurement. They include scroll, outbound_click, site_search, video_start, video_progress, video_complete, file_download, and form_start/form_submit. Useful for engagement analysis, but not reliable enough for conversion tracking -- form_submit, for example, fires on any form submission it detects, including search bars and newsletter fields. For conversion-critical forms, use a dedicated data layer push instead.

3. Recommended events

This is where most businesses should spend their implementation time. GA4 recommended events are predefined event names with predefined parameter schemas. Google publishes separate lists for retail, lead generation, travel, and gaming.

The key advantage: when you use the exact recommended event name with the exact parameter names, GA4 populates built-in dimensions and metrics automatically. A purchase event with transaction_id, value, currency, and items[] feeds the Monetization reports, ecommerce purchase reports, and Google Ads value-based bidding -- all without custom dimension configuration.

Common ga4 recommended events I configure for clients:

Event name	Business type	Critical parameters
purchase	E-commerce	transaction_id, value, currency, items[]
add_to_cart	E-commerce	value, currency, items[]
begin_checkout	E-commerce	value, currency, items[]
generate_lead	Lead gen	value, currency
sign_up	SaaS	method
view_item	E-commerce / Content	items[]

Use the wrong event name -- addToCart instead of add_to_cart -- and you lose all of that built-in reporting. GA4 treats them as entirely different events.

4. Custom events

GA4 custom events are events you define yourself when no recommended event fits your use case. Examples: calculator_completed, pricing_toggle, demo_request, plan_comparison_viewed. These are legitimate when the action you are tracking genuinely has no recommended equivalent.

The rule I follow: never create a custom event when a recommended event exists. I regularly find properties with a custom form_submitted event when generate_lead would have given them built-in reporting and direct Google Ads import. Custom events require manual custom dimension and metric registration, take up quota, and lose every built-in integration Google has wired into the recommended schema.

GA4 allows up to 500 unique event names per property and 25 custom parameters per event. That sounds generous until you realize that every parameter you want in reports needs to be registered as a custom dimension or metric, and free GA4 properties are limited to 50 custom dimensions and 50 custom metrics.

How GA4 Events Parameters Work

Every GA4 event is a name plus a set of key-value pairs -- the ga4 events parameters. Parameters are where the actual data lives. The event name tells you what happened. Parameters tell you the specifics: which product, how much revenue, which form, what method.

There are three types of parameters:

Automatically collected parameters -- sent with every event regardless of configuration. These include language, page_location, page_referrer, page_title, and screen_resolution. You do not need to set them.

Recommended parameters -- specific to each recommended event. A purchase event expects transaction_id, value, currency, coupon, shipping, tax, and an items[] array where each item has item_id, item_name, price, quantity, and more. The full schema is documented in the GA4 events reference.

Custom parameters -- any additional key-value pair you attach. For example, adding lead_source: 'pricing_page' to a generate_lead event. Custom parameters are collected but are not available in standard reports until you register them under Admin > Custom definitions.

A critical distinction: parameters that you do not register as custom dimensions simply do not appear in GA4 reports. They still exist in the raw event data and show up in BigQuery exports, but for day-to-day reporting they are invisible. I find unregistered parameters in nearly every property I audit -- teams push useful data but never complete the configuration to make it reportable.

GA4 Ecommerce Events: The Schema That Matters Most

GA4 ecommerce events follow a specific schema that Google uses to populate the Monetization reports and feed conversion data to Google Ads. The ecommerce implementation guide documents the full funnel: view_item_list > select_item > view_item > add_to_cart > begin_checkout > add_shipping_info > add_payment_info > purchase.

You do not need all of these. At minimum, implement view_item, add_to_cart, begin_checkout, and purchase. Each must include the items[] array with consistent item_id and item_name values across all events. Inconsistency here -- calling the same product "Wireless Headphones" in view_item and "WH-Pro-Black" in purchase -- breaks funnel analysis and product-scoped reporting.

One detail that trips up many implementations: you must clear the ecommerce object before each push by sending dataLayer.push({ecommerce: null}). Without this, parameter values from a previous event can leak into the next one. I have seen properties where every purchase event carried the items[] array from the last view_item because nobody cleared the object.

What Are Key Events in GA4

When Google renamed conversions to "key events" in March 2024, the change was more than cosmetic. GA4 key events are events you explicitly mark as business-critical. They appear in the Key Events report, feed into Google Ads when you import them, and drive audience definitions. Any event -- automatic, recommended, or custom -- can be marked as a key event under Admin > Key events.

The distinction matters because only ga4 key events feed bidding when imported into Google Ads. If your demo_request event fires perfectly but you forgot to toggle it as a key event, Google Ads never sees it. I covered this in detail in the GA4 conversion tracking guide, but it bears repeating: this single toggle is the most overlooked step in the entire setup.

Mark only events that represent real business outcomes. Two to four key events per property is typical. More than that and you are diluting your optimization signal. Newsletter signups and video plays are engagement metrics, not conversions.

The Six Mistakes I Fix Most Often

These come from audits across e-commerce, SaaS, and lead-gen properties. Most companies have at least three.

1. Using wrong parameter names

productName instead of item_name. transactionId instead of transaction_id. orderValue instead of value. GA4 is case-sensitive and schema-specific. Use the wrong name and the built-in dimensions stay empty. Your ecommerce reports show "not set" for product names. Your revenue reports show zero.

Fix: check every event against the GA4 reference documentation. Use lowercase snake_case for everything.

2. Missing transaction_id on purchase events

Without transaction_id, GA4 cannot deduplicate if the event fires twice -- which happens on page refresh, browser back-button, or a retry from a flaky network. I have seen properties with 20 percent inflated revenue because of this single missing parameter.

3. Exceeding the 25-parameter limit

Each GA4 event supports a maximum of 25 custom parameters. Push more and the extras are silently dropped. No error, no warning. This bites teams that try to attach every product attribute to the purchase event. Keep event parameters focused. Use item-scoped parameters inside the items[] array for product-level detail.

4. Never registering custom dimensions

Custom parameters exist in the raw data stream but are invisible in GA4 reports until you register them under Admin > Custom definitions. I find this in almost every audit: a developer added a useful parameter months ago, nobody registered it, and the marketing team has no idea the data exists. Worse, the 50-dimension limit on free properties means you cannot simply register everything retroactively -- you need to prioritize.

5. Duplicate event names with inconsistent naming

Generate_Lead, generate_lead, generateLead, and form_submit all tracking the same action. GA4 treats each as a separate event. Reports fragment. Key event toggles apply to only one variant. When I audit a tracking setup, normalizing event names is usually one of the first fixes.

6. Not clearing ecommerce objects between pushes

Already covered above, but worth repeating because I see it constantly. Stale items[] arrays leaking from view_item into add_to_cart into purchase. The revenue numbers look plausible, but the product-level data is wrong, which means product performance reports and dynamic remarketing audiences are built on corrupted data.

A Quick Validation Workflow

Before shipping any event implementation, run this five-step check. It takes fifteen minutes and catches 90 percent of the issues above.

1. Open Tag Assistant and trigger every event in your conversion funnel.
2. For each event, verify the event name matches the recommended events list exactly.
3. Inspect the parameter payload. Confirm transaction_id, value, currency, and items[] are present where required -- and that data types are correct (numbers, not strings).
4. Check Admin > Key events in GA4. Confirm the right events are toggled on.
5. Open Admin > Custom definitions. Confirm every custom parameter you need in reports is registered.

For a deeper review covering consent, cross-domain tracking, attribution settings, and server-side gaps, see the full GA4 tracking audit checklist.

FAQ

Not sure your GA4 events are actually sending the right data? Book a tracking audit -- I will tell you exactly which events are broken, which parameters are missing, and how to fix them.