GA4 Recommended Events: Which Ones to Implement

GA4 Recommended Events Are Not Optional — They Are a Design Contract

Last quarter I audited a mid-market ecommerce brand running about $40k per month in ad spend. They had a purchase event firing on the confirmation page. Revenue showed up in GA4. Everything looked fine — until I opened the Monetization reports. Empty. No product performance, no checkout funnel, no average order value breakdown by item category.

The reason: they had named their event purchase but sent a flat revenue parameter instead of the required items array, currency, value, and transaction_id. GA4 accepted the hit — it always does — but the Monetization reports never populated because the event did not match the expected schema.

That is the core misunderstanding with GA4 recommended events. They are not suggestions. They are a contract between your data layer and GA4's reporting engine. Send the exact event name with the exact parameters, and you unlock built-in dimensions, metrics, and reports. Deviate — wrong name, missing parameter, inconsistent casing — and your data lands in a generic bucket where it does almost nothing.

What Makes a Recommended Event Different from a Custom Event

GA4 organizes events into four tiers: automatically collected, enhanced measurement, recommended, and custom. The first two fire without your involvement (page_view, session_start, scroll, etc.). The last two require implementation.

The difference between recommended and custom is simple but consequential:

• Recommended events use predefined names and parameter schemas published by Google. When you send them correctly, GA4 maps the data into built-in reports — Monetization, Engagement, Lead Generation — automatically.
• Custom events use whatever names and parameters you choose. GA4 collects them, but you have to register each parameter as a custom dimension or metric before you can report on it. And you are capped at 50 event-scoped custom dimensions and 25 user-scoped custom dimensions per property.

I cover the mechanics of parameters and common naming mistakes in depth in my post on GA4 events, parameters, custom events, and common mistakes. The short version: every custom event you create costs you a custom dimension slot. Every recommended event you implement correctly costs you nothing — the dimensions are already there.

Which GA4 Recommended Events Actually Matter

Google publishes over 40 recommended events across categories for all properties, online sales, lead generation, and games. Most implementations do not need all of them. Here is how I prioritize by business model.

Ecommerce: The Nine Events That Feed Monetization Reports

If you sell products online, these are the ga4 recommended events that populate your Monetization reports, checkout funnel, and product performance tables:

Event	What it does	Required parameters
view_item_list	Products seen in a list or category page	items
view_item	Single product detail page view	items
add_to_cart	Item added to cart	currency, value, items
remove_from_cart	Item removed from cart	currency, value, items
begin_checkout	Checkout initiated	currency, value, items
add_shipping_info	Shipping step completed	currency, value, items
add_payment_info	Payment step completed	currency, value, items
purchase	Transaction completed	currency, value, transaction_id, items
refund	Transaction reversed	currency, value, transaction_id

Skip any of these and you get holes in your funnel visualization. Send purchase without items and you lose all product-level breakdowns. Send value without currency and GA4 will not calculate revenue.

A common pattern I see: teams implement purchase and add_to_cart but skip begin_checkout, add_shipping_info, and add_payment_info. That leaves you unable to identify where in the checkout flow you are losing customers — arguably the most valuable data an ecommerce analytics setup can provide.

Lead Generation: The Events Most B2B Companies Miss

Google added a set of lead-lifecycle events to the recommended list: generate_lead, qualify_lead, disqualify_lead, working_lead, close_convert_lead, and close_unconvert_lead. These feed the Lead Generation reports in GA4.

For most B2B companies, the minimum viable set is:

Event	When to fire	Notes
generate_lead	Form submission, demo request, chat inquiry	Include currency and value if you can estimate lead value
qualify_lead	CRM marks lead as MQL or SQL	Fire via Measurement Protocol from your back end
close_convert_lead	Deal closed-won	Same — fire from CRM

The downstream events (qualify_lead, close_convert_lead) usually need to be sent from your CRM or back-end systems via the Measurement Protocol, because the lead stage changes happen long after the website session ends. I walk through this pattern in detail in my post on marketing measurement for long B2B sales cycles.

Most B2B implementations I audit only have generate_lead — if that. The CRM-to-GA4 pipeline is where the real signal lives, and it is where most teams give up.

All Properties: The Universal Events Worth Implementing

These apply regardless of your business model:

Event	Use case
login	Measure returning-user engagement, build logged-in audiences
sign_up	Track account creation rates across acquisition channels
search	Requires search_term parameter — feeds the site search report
share	Measure content virality (low priority for most sites)

Of these, sign_up and search deliver the most reporting value. The search event with a properly passed search_term parameter populates the built-in site search report and lets you see what visitors are looking for but not finding — a goldmine for content and product decisions.

Events You Can Usually Skip

Not every recommended event is worth the implementation effort:

• earn_virtual_currency / spend_virtual_currency — Unless you run a game or a loyalty-point economy, these are irrelevant.
• tutorial_begin / tutorial_complete — Useful for apps with onboarding flows, rarely relevant for standard websites.
• select_content — Too generic. You are almost always better off with a well-parameterized custom event that captures what the user actually selected.
• join_group — Niche. If you have community features, consider it. Otherwise, skip.
• add_to_wishlist — Only relevant if your site has wishlist functionality.

The temptation is to implement everything. Resist it. Every event you fire is a hit against your collection limits, and every event you do not actually analyze is noise that makes your real data harder to find.

Implementation Mistakes I See on Nearly Every Audit

After running dozens of GA4 audits through my tracking audit process, these are the patterns that come up again and again.

Wrong Event Names

GA4 event names are case-sensitive. Add_To_Cart is not add_to_cart. The first one registers as a custom event and populates nothing in Monetization reports. I have seen this on sites running six figures in monthly ad spend — the data was technically being collected, but none of it was usable in standard reports.

Missing Required Parameters

The purchase event requires transaction_id, currency, value, and items. Drop any one of these and the event still fires, still shows up in your event count, but fails to populate key dimensions. GA4 does not warn you. There is no error in the debug console. Your Monetization reports just stay empty, and you might not notice for weeks.

Duplicate or Conflicting Events

I frequently see sites that fire both a recommended event and a custom event for the same action — for example, a purchase event from their ecommerce platform's built-in integration and a separate order_complete custom event from a GTM tag someone added six months later. The result: double-counted conversions, inflated revenue, and confusion about which event to trust.

If you suspect your GA4 setup has these kinds of issues, the checklist in my GA4 tracking audit guide walks through exactly what to look for.

Sending Parameters That GA4 Silently Ignores

Each event can carry up to 25 parameters. Exceed the limit and extra parameters are silently dropped — no error, no warning. Worse, the 25-slot count includes automatically collected parameters, so in practice you have closer to 20-22 usable slots. And parameter values are silently truncated at 100 characters for most parameters.

How to Prioritize Your Implementation

If you are starting from scratch or cleaning up a broken setup, here is the order I recommend:

1. Audit what is already firing. Use GA4 DebugView and the Realtime report to see which events and parameters are currently being sent. Compare against Google's recommended events reference.
2. Fix your purchase/conversion events first. These directly feed revenue reporting and ad-platform optimization. If purchase or generate_lead is broken, nothing downstream works — including your Google Ads conversion tracking.
3. Build out the checkout funnel. Add the missing steps: begin_checkout, add_shipping_info, add_payment_info. This is where you find the money you are leaving on the table.
4. Layer in engagement events. sign_up, login, search — these build the audience and behavioral picture.
5. Implement via a data layer. Recommended events should be pushed through a structured data layer, not hard-coded into page templates. This keeps your measurement independent of your front-end code and makes future changes manageable.

FAQ

Not sure your GA4 recommended events are implemented correctly — or firing at all? Book a tracking audit and I will show you exactly what is broken and how to fix it.