[UA] Dimensions and metrics [Legacy]

In this article:

Overview

Every report in Analytics is made up of dimensions and metrics.

Dimensions are attributes of your data. For example, the dimension City indicates the city, for example, "Paris" or "New York", from which a session originates. The dimension Page indicates the URL of a page that is viewed.

Metrics are quantitative measurements. The metric Sessions is the total number of sessions. The metric Pages/Session is the average number of pages viewed per session.

The tables in most Analytics reports organize dimension values into rows, and metrics into columns. For example, this table shows one dimension (City) and two metrics (Sessions and Pages/Session).

DIMENSION	METRIC	METRIC
City	Sessions	Pages/Session
San Francisco	5,000	3.74
Berlin	4,000	4.55

 

In most Analytics reports, you can change the dimension and/or add a secondary dimension. For example, adding Browser as a secondary dimension to the above table would result in the following:

DIMENSION	DIMENSION	METRIC	METRIC
City	Browser	Sessions	Pages/Session
San Francisco	Chrome	3,000	3.5
San Francisco	Firefox	2,000	4.1
Berlin	Chrome	2,000	5.5
Berlin	Safari	1,000	2.5
Berlin	Firefox	1,000	4.7

Valid dimension-metric combinations

Not every metric can be combined with every dimension. Each dimension and metric has a scope: user-level, session-level, or hit-level. In most cases, it only makes sense to combine dimensions and metrics that share the same scope. For example, Sessions is a session-based metric so it can only be used with session-level dimensions like Source or City. It would not be logical to combine Sessions with a hit-level dimension like Page.

For a list of the valid dimension-metric pairs, use the Dimensions and Metrics Reference.

How metrics are calculated

In Analytics, user metrics are calculated in two basic ways:

• As overview totals
  where the metric is displayed as a summary statistic for your entire site, such as bounce rate or total pageviews.
• In association with one or more reporting dimensions
  where the metric value is qualified by selected dimension(s).

The following diagram illustrates these two types of calculations with a simple example. On the left side, user data is calculated as an overview metric, while the same data is calculated via the New User dimension on the right side.

In the Overview Report example, calculations for time on site are computed using the time difference between each user's initial session and the exit, with the sum of each session length averaged across three sessions. This number is based on a relatively simple calculation achieved by gathering time stamp data at the request level.

In the New vs Returning Report example, averages are not computed for all sessions, but rather via the User Type dimension. By pairing the Time On Site metric with a dimension, you can analyze this metric via returning vs new users, where the calculations are modified by the requested dimension. The use of the dimension offers an insight into user behavior not provided in the overview report: it's clear that new users are spending more time on your site than returning users.

Metrics calculation is also affected by stacking more than one dimension with a given metric. In both the preformatted and custom reports, you can use multiple dimensions together. For example, suppose you use both the User Type dimension and the Language dimension to analyze time on site for your website. In this case, the calculation for new versus returning users is the same, but when you drill down to view new users using the Language dimension, the calculation is further modified by the additional dimension. So, for example, your user breakdown might look like this, where the top site times are listed in order:

User Type	Language	Avg Time On Site
All Types	All Languages	3:25
Returning	All Languages	5:03
	Finnish	29:49
	Vietnamese	20:44
	Indonesian	16:55
New	All Languages	2:09
	Malay	17:38
	English (GB)	16:56
	Chinese (traditional)	16:20

These numbers are based on an actual Analytics report. In this case, you can determine whether new or returning users stayed the longest, and by using an additional dimension, which languages in each of these categories resulted in the longest time on site.

Attribution models

Because Analytics attempts to answer a variety of questions about user behavior, it uses different calculation types or attribution models to arrive at the data that you see in the reports. Think about each Analytics report as a response to a particular kind of user analysis question. Often, these questions fall into distinct categories:

• Content: How many times was a particular page viewed?
• Goals: Which pages URLs contributed to the highest goal conversion rate?
• Ecommerce: How much value did a given page contribute to a transaction?
• Internal Search: Which internal search terms contributed to a transaction?

For each of these major categories and the reports that they contain, Analytics uses a distinct attribution model. Because each attribution model is designed to calculate a known set of metrics, you might notice that some metrics—such as Pageviews—appear only in certain reports and not in others. This is due to the attribution model that is used for that report.

The Analytics reports use three attribution models:

• Per Request
• Page value
• Site Search attribution

Per Request attribution

This attribution gives aggregate values for a single metric or for a metric/dimension pairing. This is the most common and simplest type of Analytics attribution, since values are determined from individual user GIF requests. Thus, for any given request, it is possible to look up a particular dimension and/or metric.

Most dimension values are available at the request level and remain persistent either via the HTTP/GET request itself, or in the GIF request, for every page or event request made to your site. Some common dimensions available at the request level are:

• page URI—available with every request to your site, this indicates the path of the page being accessed
• campaign—if a user comes in via a campaign, that campaign remains persistently available with every subsequent request, until the campaign itself changes
• user agent—every request from a user contains the browser information for that user, sent in via the HTTP/GET request from the browser and stored in the log files directly.

Page Value attribution

The purpose of this attribution type is to answer the question: "How useful was my page in relation to a goal or revenue value?" This attribution model is used to determine the Page Value value for a page or set of pages. The following illustration shows a series of user pageviews in relationship to goals and purchases, such as what might occur on your site.

 

This attribution model is referred to as a "forward looking" attribution model, because it applies value to a page by looking forward to the goals and/or purchases that take place after the page was visited. The following table shows the value attributed to each page in this sequence.

Page	Revenue/Goal Value
P1	$55 + Goal 1
P2	$55 + Goal 1
P3	$35 + Goal 1
P4	$0

This attribution model is not used in Goals or Ecommerce reports, since those reports do not display page URIs or titles in relation to ecommerce activities.

Site Search Attribution

This attribution model allows the Site Search reports to display goal conversion rates and goal values per search term.

This attribution model operates in a different fashion from Page Value attribution, since Goal value is attributed to the nearest search term leading up to the conversion, not after. The following diagram illustrates a sequence of internal site searches along with page views and purchases.

 

Using this model, the search terms attributed to Goal 1 and the transactions are:

• Shoes—$20
• Flowers—$25

In this model, transactions or goals are attributed to the search term immediately preceding the goal or transaction.