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, andpurchaseby name. Fireboughtinstead ofpurchaseand those reports show nothing. - Predictive metrics. GA4's purchase probability and predicted revenue models are trained to look for
purchase(orin_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
valueparameter 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.
| Use case | Recommended events | What they unlock |
|---|---|---|
| eCommerce | view_item, add_to_cart, begin_checkout, purchase |
Monetisation reports, purchase funnel, predicted revenue |
| Lead generation | generate_lead, sign_up, login |
Lead and account metrics, clean key-event candidates |
| Engagement | search, share, select_content |
Content interaction reporting and segmentable engagement |
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.
Match the recommended spec exactly, including the parameter names. GA4 matches on literal strings, so currency works and curr does not, and a value sent as amount instead of value will not populate revenue. Copy the parameter names from Google's reference rather than typing them from memory.
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.
If Google has a recommended event for what you are tracking, use it exactly; reach for a custom event only when nothing recommended fits.
In adop.tools
Using recommended event names pays off the moment you build a report. Because metrics like key events and eCommerce values map to the standard GA4 names, they land straight onto adop.tools scorecards and the conversion funnel with no manual mapping step. Custom-named equivalents would need to be wired up by hand before they appear, so the recommended set is the path of least resistance from data to report.
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.