GA4 Dimensions and Metrics: Complete 2026 Reference
Complete 2026 reference to GA4 dimensions and metrics — event, user, session, item, ad scopes, custom definitions, and exploration pitfalls.
Default dimensions
Default metrics
Custom event dimensions
Free BigQuery events/day
Key Takeaways
The GA4 data model and scope system
GA4 stores everything as events. Each event carries parameters, and those parameters become dimensions. Metrics are aggregations over those events — counts, sums, ratios. What trips up most teams is scope: GA4 associates each field with a lifecycle layer, and the layer decides what you can legitimately combine in a report.
There are five scopes you meet in day-to-day analysis. Event scope is the atom — a single hit, with its parameters. Session scope groups events inside a session and holds values that only make sense at the session level, like the channel group that started the session. User scope persists across sessions and covers acquisition and identity, such as first_user_source. Item scope is the ecommerce sub-layer attached to purchase and view_item events and carries product attributes. Ad scope is the advertising layer that shows up when Google Ads auto-tagging or manual cost data is imported.
Every interaction GA4 collects is an event. Event scope covers event_name, event-level parameters like page_location and currency, and anything you register as a custom event dimension. Event scope is the common denominator — event-scoped metrics like event_count and conversions combine cleanly with any other scope.
Session-scoped dimensions describe the session itself: session_source, session_medium, session_default_channel_group, and the session_campaign parameter. They are captured at session_start and inherited by every event in that session. Use them for acquisition analysis rather than event-level attribution questions.
User-scoped dimensions describe the user across their entire lifetime on the property. first_user_source, first_user_default_channel_group, and any registered user properties live here. Pair user scope with user-scoped metrics like totalUsers and newUsers — mixing user scope with event-level metrics gives misleading totals.
When you send an items array on purchase, view_item, or add_to_cart, each element becomes an item-scoped row. Item_name, item_brand, item_category, and custom item parameters live here. Item scope is the only way to answer product-level questions like revenue per SKU without losing detail.
Ad-scoped dimensions and metrics arrive through the Google Ads link or imported cost data — advertising_id, gclid, google_ads_campaign, cost, and ad_network metrics. In 2026 Google moved the Google Ads link under the GA4 Admin Integrations panel and tightened auto-tagging defaults, so audit the connection annually to make sure cost data is still flowing.
Scope test: Before you build an Exploration, ask which question you are answering. If it is an acquisition question, lead with user or session scope. If it is a behavioural question, lead with event scope. If it is a product question, lead with item scope. Mixing scopes is allowed but the interpretation changes, and that is where most reporting mistakes live.
Default dimensions by scope
GA4 ships with roughly 150 default dimensions out of the box. You will never need all of them, but recognizing which one answers a given question — and at which scope — is the analyst skill that separates a tidy report from a misleading one. Reference the groups below as a shortlist, then use the Data API or UI field reference when a specific name escapes you.
Event_name, page_location, page_title, page_referrer, page_path_plus_query_string, screen_name, screen_class, link_url, link_text, file_name, outbound, method, search_term, video_title, video_provider, content_id, content_type, and platform. Any registered event parameter also becomes an event-scoped dimension. This is the largest group by count and the scope you will query most often.
Session_source, session_medium, session_campaign, session_default_channel_group, session_source_platform, session_google_ads_campaign_name, session_manual_ad_content, and session_term. These lock the moment the session began and are your canonical fields for channel reporting.
First_user_source, first_user_medium, first_user_campaign, first_user_default_channel_group, first_user_source_platform, country, region, city, language, browser, operating_system, device_category, device_model, and any registered user property. Use these for cohort building and first-touch analysis rather than event-level questions.
Item_name, item_id, item_brand, item_category, item_category2 through item_category5, item_variant, item_list_id, item_list_name, promotion_id, promotion_name, creative_name, creative_slot, and up to 10 custom item parameters. These only appear when the event carried an items array, so they are scoped to ecommerce reports and product-focused Explorations.
Google_ads_campaign, google_ads_ad_group_name, google_ads_creative_id, ad_format, ad_source_name, and the auto-tagged gclid. When Performance Max or Demand Gen campaigns are linked, asset_name and asset_type also surface. Ad scope is the bridge between behaviour and spend — without it ROAS analysis has to leave GA4.
Default metrics by scope
GA4 ships with over 100 default metrics. The ones you rely on every week fit on a single card. The rest are niche aggregations used by predictive models, ad buying, or app-specific reports. The groupings below reflect how the Data API and Explorations actually organize them.
Event_count, event_count_per_user, events_per_session, conversions, conversion_rate, total_revenue, and event_value. Since mid-2025 Google renamed conversions to key events in the UI while keeping the underlying metric name for API consumers — both terms refer to the same thing.
Sessions, engaged_sessions, engagement_rate, bounce_rate, average_session_duration, sessions_per_user, and screen_page_views_per_session. Bounce rate in GA4 is 1 minus engagement rate — not the Universal Analytics definition. Engaged sessions are sessions longer than 10 seconds, with a conversion, or with 2+ pageviews.
TotalUsers, newUsers, activeUsers, returningUsers, and active user counts for 1-day, 7-day, 28-day, and 30-day windows. These are the foundation of audience reports and rely on unique user keys (user_pseudo_id plus any resolved user_id), so they are sensitive to consent state and cross-device resolution.
Purchase_revenue, ecommerce_purchases, items_purchased, average_purchase_revenue_per_paying_user (ARPPU), average_purchase_revenue, refunds, refund_amount, and LTV metrics sourced from the predictive layer. Ecommerce metrics require the enhanced ecommerce schema — the items array must ride on purchase events with currency and value set.
Google_ads_cost, google_ads_clicks, google_ads_impressions, return_on_ad_spend, cost_per_click, and cost_per_conversion. Google Ads metrics appear through the Admin link; non-Google channels require cost data import. When cost data is missing, every ROAS metric returns zero — the calculation is not conservative.
Metric naming quirk: The Data API uses camelCase (totalUsers, activeUsers) while the UI and BigQuery export often use snake_case (total_users). When scripting against the API, match the documented names exactly — the field reference in Admin is the source of truth. Our analytics glossary keeps both conventions side by side.
Custom dimensions and metrics
Custom definitions turn event parameters and user properties into reportable fields. GA4 captures up to 25 parameters per event automatically, but only registered fields are queryable. Plan your custom definitions before you instrument tags — registration is forward-only, so a field you add today has no data for yesterday.
Property tier limits
Standard properties allow 50 custom event-scoped dimensions, 25 custom user-scoped dimensions, 10 custom item-scoped dimensions, and 50 custom metrics. Analytics 360 raises these to 125 event dimensions, 100 user dimensions, 25 item dimensions, and 125 custom metrics. Limits are per property — not per account, not per stream — and deleting a definition frees a slot without restoring historical values.
Creation steps
In Admin open Custom definitions, choose Custom dimensions or Custom metrics, click Create, pick the scope (event, user, or item), enter the parameter name exactly as it arrives on the event, set a human-readable name, and save. For metrics also choose a unit of measure (standard, currency, time, distance). The registration is live within minutes but only captures values on events received from that point forward.
Common registration pitfalls
Case mismatch between the tag and the definition produces silent (not set) values. Registering a parameter at the wrong scope hides it from the reports where it belongs. Reusing a single parameter name for different meanings across events creates noise that is hard to clean later. Before you register anything, audit the gtag or GTM container and confirm DebugView shows the parameter on every event you expect.
Consent mode v2 and user properties
Since consent mode v2 became mandatory in the EEA, denied users no longer ship cookies — parameters still flow via cookieless pings but user properties are held back. Audit every user-scoped custom dimension for compliance and expect European cohorts to have more (not set) values than before. Pair the audit with our UTM parameters guide so campaign parameters stay consistent with custom definitions.
Slot hygiene: Teams burn through the 50 event dimension slots by registering every new parameter as it appears. Treat slots as a scarce resource — before adding a new definition, check whether an existing one answers the question, and retire stale definitions once their tagging has been removed upstream.
Calculated metrics and formulas
Calculated metrics let you combine existing metrics into property- wide reusable formulas. Standard properties support 5 calculated metrics, 360 properties support 50. Formulas accept addition, subtraction, multiplication, division, parentheses, and constants — but only reference metrics, never dimensions. The result must be numeric and is scoped by the most restrictive metric in the expression.
Formula: purchase_revenue / ecommerce_purchases. Unit: currency. Useful for merchandising dashboards and ads reporting. Note that purchase_revenue excludes refunds unless you explicitly subtract refund_amount in the formula.
Formula: google_ads_cost / conversions or with imported costs: advertiser_ad_cost / conversions. The scope matches the conversion event you pick — filter the Exploration to a single key event so the denominator is unambiguous.
Formula: purchase_revenue / totalUsers. Unit: currency. GA4 already ships ARPPU (average revenue per paying user); this calculated metric spreads revenue across all users for cohort-wide benchmarking.
Formula: 1 - (engaged_sessions / sessions). GA4 already exposes bounce_rate directly, so this is only useful when migrating dashboards from Universal Analytics where the formula was computed differently. Document the definition clearly because the numbers will not match UA exactly.
Formula constraints: Calculated metrics cannot reference dimensions, other calculated metrics, or audiences. If you need conditional logic (revenue only for new users), build a comparison or segment inside the Exploration — do not try to encode it in the formula. Division by zero returns zero, not an error, so wrap sensitive formulas with an expected minimum denominator before relying on the result in alerts.
Exploration vs standard report compatibility
Standard reports (Life cycle, Acquisition, Engagement, and so on) are curated surfaces. The fields are chosen so the scope combines cleanly. Explorations hand you every dimension and metric in the property, including combinations that return nothing. Knowing which surface to use saves hours of debugging.
What standard reports do well
Pre-built cards, consistent definitions across the UI, comparisons and date ranges baked in, and aggressive aggregation so the rows load fast. Use them for executive dashboards, weekly reviews, and any question that fits a template. The pre-built reports never surface scope mismatch errors because the field combinations are pre-validated.
Where Explorations excel
Free-form tables, funnels, path analysis, segment overlap, cohort analysis, and user lifetime Explorations. Explorations let you add any registered custom dimension and cross any scope, which is essential for investigative work. They also honour segments and comparisons more flexibly than standard reports.
Scope mismatch symptoms
When you combine incompatible scopes in an Exploration, GA4 shows hyphens, zeros, or inflated totals rather than an error. The usual pattern: user-scoped dimension paired with event-level metric produces numbers that do not reconcile with any report. Swap the dimension to the matching scope and the totals align.
Cardinality errors
Explorations on high-cardinality dimensions (full URLs, session IDs, or unnormalized product IDs) return aggressive (other) buckets. If your Exploration shows (other) with 80% of the volume, the dimension is too granular — normalize the values in the tag, or move the analysis to BigQuery where the cap does not apply.
Surface selection rule: If the question fits a standard report, use it — the numbers are pre-validated. If the question needs a custom combination, use an Exploration and check every field for scope alignment. If the question needs more than 10 million events or custom joins, use the Data API or BigQuery. Pair this with our GA4 adoption statistics to benchmark how peers are using each surface.
Data thresholding, sampling, and cardinality
Three forces quietly reshape the numbers in the UI: thresholding for privacy, sampling for performance, and cardinality caps for storage. Each is documented but easy to miss, and together they explain most of the why-does-the-UI-disagree-with-BigQuery questions we answer for clients.
When Google Signals or demographic data is enabled, GA4 withholds rows where the user count is too low to guarantee anonymity. Reports display a data quality icon at the top right; Explorations show the same signal. Thresholding is applied per row, per dimension combination, so narrowing the date range can suddenly expose or hide entire cohorts.
Standard properties sample Explorations past 10 million events for the date range; 360 properties sample past 1 billion. Standard reports are unsampled. The data quality ring in Explorations shows whether sampling was applied — if it is amber, split the date range into chunks or export to BigQuery for full fidelity.
GA4 keeps top values per dimension and buckets the rest into (other). For most default dimensions the cap is around 50,000 unique values per day. High-cardinality dimensions to watch: raw page_location (strip query strings), raw item_id (normalize variants), and any custom dimension that carries a user identifier. Fix at the tagging layer, not in post-processing.
The amber or green ring next to the report title shows whether the data is complete. Click it to see the exact reason: thresholding, sampling, modeled traffic from consent mode v2, or cardinality bucketing. Screenshot the ring state whenever you export numbers for a client — it is the only way to prove later whether the figures came from the full dataset.
Reconciliation checklist: When totals diverge across surfaces, check thresholding, then sampling, then cardinality, then consent mode modeling, and finally the internal-traffic filter. Nine out of ten client tickets resolve inside those five checks.
BigQuery export for raw access
BigQuery export is free on Standard properties up to one million events per day, capped at a per-project daily ceiling that Google raised in 2026 alongside the broader API-first rollout. Go above one million events per day and the export is capped unless you move to 360, but the underlying raw data already solves most of the UI-side limitations above.
Schema overview
Every event lands in a daily partitioned table (events_YYYYMMDD) plus an intraday table during the current day. Each row represents one event and nests event_params as a repeated record, user_properties as a repeated record, and items as a repeated record. Device, geo, traffic source, and app info sit in their own structs. Every custom dimension is stored as an event_params or user_properties row — you do not need to register it to see the raw value.
What BigQuery reveals that the UI hides
Thresholded rows, sampled Explorations, and (other) buckets all disappear because you are working with every event row. You can rebuild sessions from ga_session_id per user_pseudo_id, compute custom funnels, and join to CRM or product data through external tables. For privacy-sensitive markets, the export is the only way to reconcile consent mode v2 modeled traffic against the observed events.
2026 API-first changes
Google leaned further into API-first access during the year, adding more fields to the Data API, expanding real-time dimensions, and surfacing export health metrics directly in Admin. The practical effect: scripted dashboards can reach parity with the UI, and the BigQuery export becomes the reference when the API or UI disagree. Export schema changes are published in the release notes — monitor them quarterly.
Setting up the export
In Admin open Product links, choose BigQuery, and link a Google Cloud project. Pick a data location close to your users, decide between daily and streaming export (streaming costs more but enables intraday queries), and choose which streams to include. The first daily table typically appears within 24 hours. Validate the export by comparing UI event_count to the row count for a specific day — they should match within thresholding rounding.
When to stay in the UI
Not every team needs BigQuery. If the questions fit standard reports, the thresholding is acceptable, and the cardinality stays under control, the UI is faster and cheaper. Bring in BigQuery when compliance requires auditability, when reporting needs to join GA4 to other sources, or when scale breaks the UI — as benchmarked in our marketing analytics statistics report.
Cost guardrails: BigQuery billing is driven by bytes scanned, not the free GA4 export itself. Partition filter on event_date, project only the columns you need, and materialize common aggregates as daily tables. A single unfiltered SELECT * across a year of events is the fastest way to blow a cloud budget — put a query reviewer policy in place before opening the dataset to broader teams.
Turn GA4 Into Real Decisions
Clean scope, disciplined custom definitions, and a BigQuery safety net turn GA4 from a reporting surface into the source of truth for growth decisions. Our analytics team ships the implementation and the dashboards.
Frequently Asked Questions
Related Articles
Continue exploring with these related guides