Understanding the GA4 Data Model: Events, Parameters, and Users

Every report in GA4 — no matter how polished or pre-built it looks — is ultimately just a view over three underlying concepts: events, parameters, and users. Once you understand how these three fit together, GA4 stops feeling like a black box of dashboards and starts feeling like a predictable system you can reason about, extend, and debug.

Events: The Base Unit of Everything

In GA4, literally everything that happens is recorded as an event — a named record of something occurring at a specific moment. This includes things that felt like separate concepts in older analytics tools:

• A page load is an event: page_view
• A session beginning is an event: session_start
• A purchase is an event: purchase
• A custom action you define is an event: demo_requested

Every event has exactly one name and can carry any number of parameters describing its context. There's no separate "pageview" object or "transaction" object living outside this model — it's events, all the way down.

Parameters: The Context Attached to an Event

A parameter is a key-value pair attached to an event, describing something specific about what happened:

gtag("event", "purchase", {
  transaction_id: "T_1001",
  value: 49.99,
  currency: "USD",
  items: [{ item_id: "SKU_1", item_name: "Widget", price: 49.99, quantity: 1 }],
});

Here, transaction_id, value, currency, and items are all parameters. Some parameters are automatically collected by GA4 itself (like page_location or session_id), some come from Enhanced Measurement (like percent_scrolled on a scroll event), and some are entirely custom, defined by you for your specific business needs.

Parameters can be scoped in a couple of meaningful ways once registered as custom dimensions:

• Event-scoped — tied to the specific instance of an event (most common).
• User-scoped — attached to a user across all their events and sessions, useful for a persistent trait like customer_tier or signup_cohort.

Users: Identifying Who Did What

GA4 identifies a user through a client-generated identifier stored in a first-party cookie (for web) or an app-instance ID (for apps) — this is the baseline identity model, working even for anonymous, not-logged-in visitors. If your site has logged-in users, you can additionally implement User-ID, which uses your own internal, stable user identifier, letting GA4 correctly stitch together the same person's activity across multiple devices and browsers, which the default cookie-based ID can't do on its own.

GA4 distinguishes a few related but different counting concepts:

• Total users — anyone who triggered at least one event in the selected period.
• New users — users triggering a first_visit (web) or first_open (app) event for the first time.
• Active users — GA4's standard default user-counting metric in most reports, generally aligned with users who had at least one engaged session.

Sessions: A Derived, Not Fundamental, Concept

Interestingly, a "session" isn't a first-class object the way an event is — it's a derived grouping of events that occurred close together in time from the same user, with GA4 automatically assigning a session_id parameter and closing a session after 30 minutes of inactivity (by default, adjustable in settings). This is a subtle but important shift from Universal Analytics, where sessions were a more foundational structural concept. In GA4, the event is foundational; the session is just one useful way of grouping events after the fact.

How This Model Produces the Reports You See

Every standard report is essentially a pre-built query against this underlying event/parameter/user structure:

• The Acquisition report groups sessions by parameters describing how the user arrived (source, medium, computed into a channel grouping).
• The Engagement report aggregates event counts and durations, filtered and grouped by dimensions like page_path.
• The Monetization report sums the value parameter across purchase events, broken down by the items array's item_id and item_name.

Once you see reports this way — as queries against events and their parameters, rather than as fixed, unrelated dashboards — building a custom report or Exploration becomes a matter of picking the right dimensions (which are just registered parameters) and metrics (aggregations over event counts or parameter values), rather than hunting for a pre-built report that happens to match your exact question.

Custom Dimensions and Metrics: Extending the Model

Because the event/parameter model is so general, GA4 lets you register your own parameters as custom dimensions (for categorical data, like plan_tier) or custom metrics (for numeric data, like video_watch_seconds), under Admin → Custom definitions. Once registered, these become available in the same report-building tools — Explorations, custom reports — as any of GA4's built-in dimensions and metrics, which is exactly how the platform accommodates business-specific tracking without needing a fundamentally different reporting system for custom data versus built-in data.

Why This Model Matters for Debugging

Understanding this structure is also the fastest path to debugging a tracking problem. If a report shows unexpected data, the question is never "which report is broken" — it's always "which event, or which parameter on that event, isn't behaving as expected." Checking DebugView to inspect the raw event and its parameters directly, rather than only looking at an aggregated report several layers removed from the raw data, resolves the overwhelming majority of "why doesn't my data look right" questions.

A Practical Mental Model Going Forward

A useful way to internalize this: whenever you want to track something new, you're really answering two questions — "what happened" (the event name) and "what do I need to know about it" (the parameters). Everything else — reports, dashboards, conversions, audiences — is built by querying and aggregating those two answers across many events and many users.

FAQ about the GA4 Data Model

Is a pageview a special kind of object in GA4, different from other events?

No — a pageview is just an event named page_view, structurally identical in kind to any custom event you define yourself, just automatically fired and populated with certain standard parameters.

How is a session related to events if it's not a first-class concept?

A session is a derived grouping GA4 computes by clustering a user's events that occur within a defined inactivity window (30 minutes by default), assigning them a shared session_id parameter.

What's the practical difference between an event-scoped and user-scoped custom dimension?

Event-scoped applies to the specific instance of the event it was sent with; user-scoped applies to everything that user does going forward, useful for a persistent attribute like a subscription tier rather than something tied to one specific action.

Can I see the raw event and parameter data GA4 has collected, not just aggregated reports?

Yes, primarily through DebugView for real-time inspection, or via a BigQuery export for full historical raw event-level data if you need to query it directly yourself.

Do custom parameters need to be registered before they're usable in reports?

Yes — sending a parameter with an event stores it in the raw data, but it only becomes usable as a report dimension or metric once explicitly registered under Admin → Custom definitions.

Why does GA4 use a single unified event model instead of the multiple hit types Universal Analytics used?

It's a deliberate simplification that makes the platform more flexible — a single consistent structure (event + parameters) can represent pageviews, transactions, and custom actions alike, rather than requiring separate handling logic for each distinct hit type as Universal Analytics did.

Conclusion

Every report, dashboard, and Exploration in Google Analytics 4 is built on the same three ingredients: events, the parameters attached to them, and the users who triggered them. Once that structure clicks, the platform stops feeling like a fixed set of dashboards and starts feeling like a flexible system you can query, extend, and debug on your own terms for your website.