GA4 Data Model: Understanding Events, Parameters and Custom Dimensions

Why the GA4 Data Model Matters

If you’ve migrated from Universal Analytics (UA) to Google Analytics 4 (GA4)—or you’re setting up analytics for the first time—you’ve likely noticed that things work very differently now. The entire underlying data model has changed, and understanding it is the single most important step toward collecting accurate, actionable data.

Universal Analytics was built on a session-based, hit-type model. You had pageviews, events, transactions, social hits, and timing hits—each with its own structure. GA4 throws all of that out and replaces it with one universal concept: events.

This shift isn’t cosmetic. It fundamentally changes how you plan tracking, how you structure your data layer, and how you build reports. In this guide, we’ll break down the three pillars of the GA4 data model—events, parameters, and custom dimensions—with practical examples, code snippets, and tips you can apply right away.

The Event-Based Architecture: A Paradigm Shift

From Hit Types to a Flat Event Model

In Universal Analytics, a pageview and an event were two entirely different hit types with different schemas. A UA event required a Category, Action, and Label. A transaction lived in a separate Enhanced Ecommerce structure.

GA4 simplifies everything. Every single interaction is an event. A page view? That’s the page_view event. A purchase? The purchase event. A button click? A custom event you define yourself.

Here’s a quick comparison:

Concept	Universal Analytics	GA4
Page view	Pageview hit	page_view event
Click tracking	Event hit (Category/Action/Label)	Custom event + parameters
Transaction	Transaction hit + Enhanced Ecommerce	purchase event + item parameters
Scroll tracking	Custom implementation	scroll event (auto-tracked)
Data hierarchy	Account → Property → View	Account → Property → Data Stream
Scoping	Hit / Session / User	Event / User

This flat model is more flexible. You no longer have to force every interaction into an awkward Category/Action/Label taxonomy. Instead, you name your event clearly and attach parameters that carry all the contextual detail.

The Four Categories of GA4 Events

GA4 organizes events into four tiers:

• Automatically collected events — first_visit, session_start, page_view (for web), screen_view (for apps). These fire without any configuration.
• Enhanced measurement events — scroll, click (outbound), file_download, video_start, video_progress, video_complete, view_search_results, form_start, form_submit. Toggle them on/off in your data stream settings.
• Recommended events — Google provides naming conventions for common scenarios like ecommerce (add_to_cart, begin_checkout, purchase), lead generation (generate_lead), and content (share, sign_up). Using these names unlocks built-in GA4 reports and audiences.
• Custom events — Any event you define yourself for interactions unique to your business (e.g., calculator_used, pdf_brochure_viewed, chatbot_opened).

Pro tip: Always check whether a recommended event name exists before creating a custom one. Google’s built-in reports and machine-learning features (like predictive audiences) only work with recognized event names.

Parameters: The Detail Behind Every Event

What Are Parameters?

If events are the what, parameters are the how, where, when, and why. Every GA4 event can carry up to 25 custom parameters, each with a key-value pair that adds context.

For example, the page_view event automatically includes parameters like:

• page_location (the full URL)
• page_referrer (the previous page URL)
• page_title (the document title)

When you fire a custom event, you define your own parameters. Let’s say you run a SaaS product and want to track when users export a report:

gtag('event', 'report_exported', {
  report_type: 'monthly_revenue',
  export_format: 'pdf',
  row_count: 1450,
  user_plan: 'enterprise'
});

In this single event call, you’ve captured:

• What happened → report_exported
• Which report → monthly_revenue
• In what format → pdf
• How much data → 1450 rows
• User context → enterprise plan

This is infinitely more flexible than the old UA Category/Action/Label model, which gave you only three text slots.

Parameter Limits and Best Practices

GA4 enforces several limits on parameters:

Limit	Standard Property	GA4 360
Parameters per event	25	25
Event name length	40 characters	40 characters
Parameter key length	40 characters	40 characters
Parameter value length	100 characters	500 characters
Unique event names	500	2,000

Keep these best practices in mind:

1. Use snake_case for both event names and parameter keys. GA4’s convention is lowercase with underscores.
2. Be consistent. If one event sends product_category and another sends productCategory, you’ve created two unrelated dimensions.
3. Don’t stuff high-cardinality IDs into parameters you plan to report on—GA4 reports have row limits. Save granular IDs for BigQuery.
4. Plan before you implement. Create a tracking specification document that maps every event, its parameters, expected values, and which parameters need to be registered as custom dimensions.

At Lueur Externe, we always build a comprehensive measurement plan before touching a single line of code. This upfront investment prevents messy data and rework down the line—something we’ve learned across 20+ years of web projects since the agency’s founding in 2003.

Custom Dimensions and Custom Metrics: Making Parameters Reportable

The Registration Requirement

Here’s a critical point that catches many GA4 newcomers off guard: collecting a parameter is not the same as being able to report on it.

When you send an event with custom parameters to GA4, those parameters are received and stored. But they won’t appear in your standard GA4 reports—no filters, no breakdowns, no exploration dimensions—unless you register them as custom dimensions (for text values) or custom metrics (for numeric values).

Think of it like a warehouse. Your parameters arrive at the loading dock (data collection). But until you assign them a shelf and label them (registration), the warehouse workers (GA4’s reporting engine) can’t find and use them.

How to Register a Custom Dimension

In the GA4 interface:

1. Go to Admin → Custom definitions → Custom dimensions
2. Click Create custom dimension
3. Fill in:
   • Dimension name — A human-readable label (e.g., “Report Type”)
   • Scope — Event-scoped or User-scoped
   • Description — Optional but highly recommended
   • Event parameter — The exact parameter key name (e.g., report_type)
4. Click Save

GA4 will start surfacing that parameter’s values in reports from the moment of registration onward. It is not retroactive—historical data collected before registration won’t be available in standard reports (though it is accessible in BigQuery raw exports).

Event-Scoped vs. User-Scoped

Choosing the right scope is essential:

• Event-scoped custom dimensions — The value is tied to a specific event occurrence. Example: export_format = pdf is relevant only to that particular report_exported event. Each event can have a different value.
• User-scoped custom dimensions — The value persists and describes the user across all their events. Example: user_plan = enterprise describes the user’s subscription tier. Once set, it applies to all subsequent events from that user until changed.

For user-scoped properties, you set them with the gtag('set', 'user_properties', {...}) call:

gtag('set', 'user_properties', {
  account_type: 'premium',
  company_size: 'mid_market',
  signup_month: '2024_03'
});

These user properties then appear in GA4 under Admin → Custom definitions → Custom dimensions when you select the “User” scope.

Quota Management

As mentioned earlier, standard GA4 properties support:

• 50 event-scoped custom dimensions
• 25 user-scoped custom dimensions
• 50 custom metrics

These quotas sound generous, but they fill up fast on complex sites—especially ecommerce properties with multiple product attributes, user segments, and content categories.

Strategies to stay within limits:

• Archive unused custom dimensions. You can deactivate dimensions you no longer need, freeing up a slot.
• Combine low-value parameters. Instead of registering color, size, and material separately, consider whether a concatenated product_variant parameter serves your reporting needs.
• Leverage BigQuery. If you have GA4 linked to BigQuery (free for the daily export), every parameter is available in raw event data—no registration needed. Build dashboards in Looker Studio from BigQuery for unlimited flexibility.

Putting It All Together: A Real-World Implementation

Let’s walk through a concrete scenario. Imagine you run an online store on Prestashop (a platform Lueur Externe knows intimately as a certified expert) and you want to track when users interact with your product configurator.

Step 1: Define the Event and Parameters

Event Name	Parameter	Type	Example Value	Register?
configurator_step	step_name	string	”select_material”	✅ Event dimension
configurator_step	step_number	number	2	✅ Custom metric
configurator_step	product_id	string	”SKU-8842”	❌ BigQuery only
configurator_step	estimated_price	number	249.99	✅ Custom metric
configurator_complete	final_price	number	319.00	✅ Custom metric
configurator_complete	configuration_id	string	”cfg_abc123”	❌ BigQuery only
configurator_complete	time_spent_seconds	number	187	✅ Custom metric

Notice that high-cardinality fields like product_id and configuration_id are deliberately not registered as custom dimensions. They would blow up report cardinality. Instead, we query them in BigQuery when needed.

Step 2: Implement via GTM Data Layer

In your Prestashop template (or via a module), push the data to the data layer:

// When the user completes a configurator step
dataLayer.push({
  event: 'configurator_step',
  step_name: 'select_material',
  step_number: 2,
  product_id: 'SKU-8842',
  estimated_price: 249.99
});

Then, in Google Tag Manager:

1. Create Data Layer Variables for each parameter (step_name, step_number, product_id, estimated_price).
2. Create a GA4 Event Tag with the event name configurator_step.
3. Add Event Parameters mapped to those Data Layer Variables.
4. Set the trigger to fire on the custom event configurator_step.

Step 3: Register Custom Dimensions and Metrics in GA4

Head to Admin → Custom definitions and register:

• step_name as an event-scoped custom dimension
• step_number as a custom metric (counting type: standard)
• estimated_price as a custom metric (unit: currency)
• final_price as a custom metric (unit: currency)
• time_spent_seconds as a custom metric (unit: seconds)

Step 4: Build Reports

Now you can build an Exploration report in GA4 that shows:

• How many users reach each configurator step (funnel analysis)
• Average estimated price at each step vs. final price at completion
• Average time spent in the configurator for completed configurations
• Drop-off rates between steps

This is the kind of actionable insight that directly impacts conversion rate optimization—and it’s only possible because the data model was planned thoughtfully from the start.

Common Mistakes to Avoid

After auditing hundreds of GA4 implementations, here are the most frequent pitfalls we see:

1. Not registering parameters as custom dimensions. Teams implement beautiful tracking, then wonder why the data doesn’t appear in reports. Always register.
2. Using reserved event names or parameter names. GA4 reserves names like first_open, in_app_purchase, app_exception. Reusing them causes silent data conflicts.
3. Exceeding the 25-parameter limit per event. The excess parameters are simply dropped—no error, no warning.
4. Inconsistent naming conventions. addToCart, add_to_cart, and Add_To_Cart are three different events in GA4. Standardize early.
5. Ignoring the 72-hour processing delay for custom dimensions. After registering a new custom dimension, it can take up to 72 hours for data to appear in standard reports. Don’t panic—check DebugView or Realtime first.
6. Forgetting that registration is not retroactive. If you start sending a parameter on January 1 but only register it on March 1, you’ll only see data from March 1 onward in reports.

BigQuery: The Missing Piece of the Puzzle

For organizations serious about analytics, linking GA4 to BigQuery is a game-changer. The free daily export sends every event with all its parameters—registered or not—into a structured BigQuery table.

This unlocks:

• Unlimited custom dimensions (no 50-slot limit)
• Raw, hit-level data for advanced analysis
• SQL-based segmentation far more powerful than GA4’s UI
• Data retention beyond GA4’s 14-month maximum (in standard properties)
• Joining with CRM, ERP, or ad platform data for a unified view

A typical BigQuery query to analyze our configurator example:

SELECT
  event_name,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'step_name') AS step_name,
  COUNT(*) AS event_count,
  AVG((SELECT value.double_value FROM UNNEST(event_params) WHERE key = 'estimated_price')) AS avg_estimated_price
FROM
  `your_project.analytics_123456789.events_*`
WHERE
  event_name = 'configurator_step'
  AND _TABLE_SUFFIX BETWEEN '20240101' AND '20240331'
GROUP BY
  event_name, step_name
ORDER BY
  step_name;

The nested UNNEST(event_params) syntax is specific to GA4’s BigQuery schema. It takes some getting used to, but once you master it, the analytical possibilities are virtually limitless.

Key Takeaways

Let’s recap the essentials of the GA4 data model:

• Everything is an event. There are no hit types, no separate pageview or transaction structures. Embrace the flat model.
• Parameters carry the context. Design them thoughtfully—you get 25 per event, with strict character limits.
• Registration bridges collection and reporting. A parameter exists in GA4 the moment it’s sent, but it only becomes visible in reports when registered as a custom dimension or metric.
• Scope matters. Choose event-scoped for interaction-level data, user-scoped for persistent user attributes.
• Plan your quotas. With 50 event-scoped and 25 user-scoped dimension slots, you need a strategy.
• BigQuery is your safety net. For anything beyond standard reporting, export to BigQuery where all parameters are accessible without registration.

Conclusion: From Data Collection to Business Decisions

The GA4 data model is more powerful and flexible than its predecessor—but it demands a more deliberate approach to implementation. You can’t just drop a tracking code on your site and hope for useful data. You need a measurement strategy, a naming convention, a parameter plan, and a registration checklist.

Done right, GA4’s event-based architecture gives you a clear, unified view of how users interact with your website or app—across devices, across sessions, and across the entire customer journey.

At Lueur Externe, we help businesses design and implement GA4 tracking strategies that are clean, scalable, and built for real decision-making. With over two decades of experience in web development, SEO, and analytics—and deep expertise in platforms like Prestashop, WordPress, and AWS—we make sure your data foundation is rock-solid before a single dashboard is built.

Ready to get your GA4 implementation right the first time? Contact the Lueur Externe team for a free analytics audit and let’s turn your data into a competitive advantage.