GA4 Event Types Explained: Automatic, Enhanced Measurement, Recommended & Custom

One of the biggest structural changes GA4 made from Universal Analytics is that everything is an event. Page views, sessions, purchases, scroll depth, video plays — all of it flows through the same event model. No more hit types, no more special-cased pageview or transaction calls. Just events, with names and parameters.

That uniformity is powerful. But it introduces a question that Universal Analytics never really had to answer: where do events come from? In UA, most of what you tracked required explicit configuration. In GA4, significant amounts of data arrive without any setup at all — and knowing exactly which data that is, and which data still requires work, determines how much trust you can place in your reports from day one.

GA4 divides its events into four categories. Each has a different collection mechanism, a different configuration requirement, and different implications for how you should use the data.

---

The four event categories at a glance

The key distinction across all four is the relationship between who fires the event (GA4 automatically vs. your implementation) and how the data surfaces (standard reports vs. custom exploration vs. BigQuery only). We'll step through each in detail.

---

Type 1 — Automatically collected events

Automatically collected events fire the moment the GA4 tag initialises on a page. They require no additional code, no GTM configuration, and no settings to toggle — they simply arrive in GA4 as soon as your property is receiving data.

What's included

These three events are the backbone of GA4's session and user metrics. session_start is what creates sessions; user_engagement is what drives engagement rate and average engagement time. Neither can be disabled, and both require no implementation work.

What automatically collected events don't cover

Despite the name, automatically collected events cover only the most fundamental session-level signals. They don't track page views, clicks, form submissions, purchases, or any content-specific interactions. Those come from the other three categories.

---

Type 2 — Enhanced measurement events

Enhanced measurement is GA4's most misunderstood feature. It uses JavaScript event listeners that GA4 injects into your page at tag load time to detect and fire events for common interactions — without any code on your part. But it has significant limitations that make it unsuitable as a replacement for proper GTM configuration in most production setups.

Enabling enhanced measurement

Go to GA4 Admin → Data Streams → your web stream → Enhanced Measurement. Toggle the overall switch on, then enable or disable individual event types. Each can be controlled independently.

What's included

When to rely on enhanced measurement vs. GTM

Enhanced measurement is well-suited for low-traffic sites, quick proof-of-concept setups, and situations where a GTM deployment isn't feasible. For production analytics where data accuracy matters, GTM-based implementations of the same events give you more control, richer parameters, and behaviour that's easier to audit. The 90% scroll threshold is fixed in enhanced measurement; in GTM you can fire at 25%, 50%, 75%, and 90%. Outbound click tracking via enhanced measurement doesn't capture which element was clicked; a GTM trigger can capture the element, its text, and its CSS class.

---

Type 3 — Recommended events

Recommended events are where the GA4 event model gets genuinely powerful. Google has published a catalogue of standardised event names and parameter schemas for the most common business actions. You implement these yourself — they don't fire automatically — but by using Google's exact naming conventions, you get two significant advantages: automatic population of GA4's standard e-commerce and lifecycle reports, and a schema that BigQuery, Data Studio, and other tools already understand.

Why naming conventions matter

GA4's standard reports for e-commerce, monetisation, and the funnel exploration tool are built around specific event names. If you send a purchase event named order_complete instead of purchase, GA4's revenue reports show zero — because they look for the event named exactly purchase. Recommended events are Google's way of publishing the exact names that unlock built-in reporting.

Recommended events by category

Required and recommended parameters

Each recommended event comes with parameters Google specifies. Some are required for the event to populate standard reports correctly; others are recommended to unlock additional dimensions. The purchase event is the most parameter-rich — here's what a complete implementation looks like via a dataLayer push:

JavaScript — Complete purchase event dataLayer push

// Always clear the ecommerce object before each push
window.dataLayer.push({ ecommerce: null });

window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'ORDER-20481',   // Required — must be unique per order
    value: 129.00,                   // Required — total order value
    currency: 'GBP',                  // Required — ISO 4217 currency code
    tax: 21.50,                       // Recommended
    shipping: 4.99,                   // Recommended
    coupon: 'SUMMER10',               // Recommended, if applicable
    items: [
      {
        item_id: 'SKU-001',           // Required
        item_name: 'Analytics Template',// Required
        item_category: 'Templates',    // Recommended
        item_brand: 'Web Analytics Driven',
        price: 129.00,               // Recommended
        quantity: 1                    // Recommended
      }
    ]
  }
});

---

Type 4 — Custom events

Custom events are any events you define yourself that don't fit the recommended event catalogue. You choose the name, you define the parameters, and you decide when they fire. There are no constraints on what you can track — but there are trade-offs to understand.

When to use custom events

Custom events are the right choice when the action you want to track doesn't map to any recommended event name, or when you need parameters that go beyond GA4's standard schema. Common examples:

• A SaaS product tracking feature usage — feature_activated, report_exported, integration_connected
• A media site tracking content engagement — article_bookmarked, paywall_reached, newsletter_widget_expanded
• An internal tool tracking workflow steps — quote_drafted, approval_submitted, document_signed

In each case, the action is meaningful to the business but has no recommended event equivalent. Custom events fill that gap.

The trade-off: custom dimensions and metrics are required

Custom events and their parameters don't appear in GA4's standard reports automatically. To surface a custom event parameter in reports, you must first register it as a custom dimension or metric in GA4 Admin. For detailed guidance on this step, see our post on setting up custom definitions in GA4.

JavaScript — Custom event for a SaaS feature activation

window.dataLayer.push({
  event: 'feature_activated',
  feature_name: 'bigquery_export',    // Register as custom dimension in GA4 Admin
  user_plan: 'pro',                  // Register as custom dimension in GA4 Admin
  days_since_signup: 14              // Register as custom metric in GA4 Admin
});

Naming rules for custom events

---

Marking events as conversions

Any event from any of the four categories can be marked as a conversion in GA4 — but the choice of which events to mark matters significantly for how your reports read and how Google Ads optimises if your property is linked.

In GA4 Admin → Conversions, you toggle individual events as conversions. Once marked, GA4 counts every instance of that event as a conversion across your acquisition, engagement, and advertising reports.

---

How GTM fits into the event hierarchy

Understanding where GTM sits relative to GA4's event categories clarifies what it is and isn't responsible for in your implementation.

A well-configured GA4 implementation uses all four event types together: automatic events for session infrastructure, enhanced measurement selectively for low-effort coverage, recommended events via GTM for all business-critical actions, and custom events via GTM for anything specific to the business that the recommended catalogue doesn't cover.

---

Choosing the right event type for a given action

When you're planning what to track for a specific user action, step through these questions in order:

1. 1
   Does GA4 already collect it automatically? Check the automatically collected events list: session_start, first_visit, user_engagement. If it's on this list, no action is needed — and don't try to recreate it in GTM or you'll end up with duplicates.
2. 2
   Is it covered by enhanced measurement — and is the default behaviour good enough? Check whether enhanced measurement covers the action. If it does and the default parameters are sufficient, toggle it on. If you need more control — different scroll thresholds, richer click data, additional parameters — implement it in GTM and turn the enhanced measurement toggle off for that event type to avoid duplication.
3. 3
   Does Google have a recommended event name for this action? Search Google's recommended events documentation for a matching event. If one exists, use it exactly as specified — name, required parameters, and all. The benefit of unlocking standard reports is worth the care in matching the schema precisely.
4. 4
   No match — define a custom event Define a custom event name using lowercase and underscores. Plan which parameters you'll collect, register them as custom dimensions or metrics in GA4 Admin, and implement the dataLayer push and GTM tag in parallel.

---

Common mistakes to avoid

Most GA4 event implementation problems come from the same handful of errors. These are the ones worth checking for in any audit:

• Reimplementing automatically collected events. Creating a GTM tag to fire session_start or user_engagement on top of GA4's own automatic collection doubles those events in your reports and BigQuery data. Check your GTM container for any tags sending reserved event names.
• Leaving enhanced measurement page_view on alongside a GTM page_view tag. Two page views per page load is one of the most common data quality issues in new GA4 implementations. Pick one mechanism and disable the other.
• Using non-standard names for recommended events. order_placed, checkout_complete, and transaction all fail to populate GA4's e-commerce reports. The event must be named exactly purchase.
• Not clearing the ecommerce object between events. Failing to push { ecommerce: null } before each ecommerce dataLayer push causes parameters from earlier events to contaminate later ones.
• Not registering custom parameters as custom dimensions. Parameters sent with custom events are collected and stored in BigQuery immediately — but they're invisible in GA4's Explore tool until registered as custom dimensions in Admin.
• Marking too many events as conversions. GA4 allows up to 30 conversion events per property. More importantly, marking low-value events as conversions pollutes acquisition and advertising reports with noise that obscures genuine business outcomes.

---

How event types appear in BigQuery

All four event types — automatic, enhanced measurement, recommended, and custom — land in the same BigQuery table: events_YYYYMMDD. There's no separate column that tells you which category an event belongs to. They're all rows in the same dataset, differentiated only by their event_name value.

This matters for two reasons. First, BigQuery queries need to filter carefully if you want to count only meaningful user interactions rather than session infrastructure events:

BigQuery SQL — Exclude automatic and infrastructure events from interaction counts

SELECT
  event_name,
  COUNT(*) AS event_count
FROM
  `your-project.analytics_XXXXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
  AND event_name NOT IN (
    'session_start',
    'first_visit',
    'user_engagement',
    'page_view',
    'scroll',
    'click'
  )
GROUP BY
  event_name
ORDER BY
  event_count DESC

Second, BigQuery doesn't validate whether your event parameters are correct — it stores whatever was sent. A misconfigured recommended event lands in BigQuery just like a correctly configured one. Validating your data in GA4 DebugView during implementation, and in BigQuery after deployment, is the only way to confirm that what's being collected matches what was intended.