Dimensions and metrics
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).
A hit is the most granular piece of data in an analytics tool. It’s how most analytics tools send data to a collection server. In reality, a hit is a request for a small image file. This image request is how the data is transmitted from a website or app to the data collection server.
User > Sessions > Hits
Digital analytics data is organized into a hierarchy of hits, sessions and users.
Pageviews/Screenviews: A pageview (for web, or screenview for mobile) is usually automatically generated and measures a user viewing a piece of content. A pageview is one of the fundamental metrics in digital analytics. It is used to calculate many other metrics, like Pageviews per Visit and Avg. Time on Page.
Events: An event is like a counter. It’s used to measure how often a user takes action on a piece of content. Unlike a pageview which is automatically generated, an event must be manually implemented. You usually trigger an event when the user takes some kind of action. The action may be clicking on a button, clicking on a link, swiping a screen, etc. The key is that the user is interacting with content that is on a page or a screen.
Transactions: A transaction is sent when a user completes an ecommerce transaction. You must manually implement ecommerce tracking to collect transactions. You can send all sorts of data related to the transaction including product information (ID, color, sku, etc.) and transactional information (shipping, tax, payment type, etc.)
Social interaction hit: A social interaction is whenever a user clicks on a ReTweet button, +1 button, or Like button. If you want to know if people are clicking on social buttons then use this feature! Social interaction tracking must be manually implemented.
Customized user timings:User timings provide a simple way to measure the actual time between two activities. For example, you can measure the time between when a page loads and when the user clicks a button. Custom timings must be implemented with additional code.
That’s a lot of hit types!
A session is simply a collection of hits, from the same user, grouped together. By default, most analytics tools, including Google Analytics, will group hits together based on activity. When the analytics tool detects that the user is no longer active it will terminate the session and start a new one when the user becomes active.
Most analytics tools use 30 minutes of inactivity to separate sessions. This 30-minute period is called the timeout.
Here’s where things start to get interesting. A user is the tools best-guess of an anonymous person. Users are identified using an anonymous number or a string of characters. The analytics tool normally creates the identifier the first time a user is detected. Then that identifier persists until it expires or is deleted.
The identifier is sent to the analytics tool with every hit of data. Then the analytics tools can group hits (and thus sessions) together using the identifier in the hits.
Here’s how users are detected on some of today’s most common digital platforms.
To measure a user on a website almost all analytics tools use a cookie. A cookie is a small text file. The cookie contains the anonymous identifier. Every time a hit is sent from the browser back to the analytics server identifier stored in the cookie is sent along with the data.
Now let’s have the cookie talk.
Google Analytics uses a first party cookie. A first party cookie is connected to the domain that creates it. A first-party can only be used by the domain that sets it. So on this site, the cookie has a domain of
cutroni.com and can only be used by this website.
In Universal Analytics the cookie is named
_ga and lasts for two years. In the previous version of Google Analytics the cookie was named
The good thing about a first party cookie is that almost all browsers will allow a first party cookie. It’s a very reliable piece of technology.
First party cookies are challenging when your site spans multiple domains. When a user leaves your site, and traverses to another site that you own, they do not take their first party cookies. In most situations, unless you configure analytics correctly, analytics will set another cookie when the user lands on the second domain.
Now you have one user with two cookies. That could lead to double counting of users. Plus, if we want to create really cool metrics, like Revenue per user, it becomes very, very hard because we don’t know the true number of users.
The other type of cookie, a third-party cookie, can be set and accessed by domains other than the domain that creates it. Some analytics tools will let you use a third party cookie.
The value of a third party cookie is that the analytics tool can use a third party cookie to identify a user as they move from one domain to another.
However, third-party cookies are not permitted by most browsers – that means no data.
Google Analytics does not use a third party cookie. You can read all about the Google Analytics cookies in the developer documentation.
So what’s the solution here? How do you correctly identify a user if your website spans multiple domains? In the Google Analytics world we use a feature called Cross Domain Tracking. I’m not going to talk about it in this post, but you can read about it in our support documentation.
Now let’s move on to mobile platforms – something that is very popular 🙂
Mobile tracking is similar to web tracking. There is an anonymous identifier stored on the device. The identifier is generated every time the app is installed. So if a user deletes the app the identifier will also be deleted. But if a user updates the app the identifier will not change.
The big difference between mobile and web is that the identifier is not stored in a cookie. It’s stored in a database on the mobile device – but it basically functions the same way as a cookie. The identifier is sent on every hit back to the analytics server. The analytics server then uses the identifier to create metrics like unique users.
Here’s one challenge with user measurement on an app. Many apps are not just an app. They’re a hybrid app/website. They use a browser within the app to “frame” content from a website. This can mess up the data collection.
In this situation we have two technologies with two different user identifiers. The app will measure a user based on the ID stored on the device and the website will use a cookie when a page loads in the app.
How goals work
Goals are configured at the view level. Goals can be applied to specific pages or screens your users visit, how many pages/screens they view in a session, how long they stay on your site or app, and the events they trigger while they are there. Every goal can have a monetary value, so you can see how much that conversion is worth to your business. Using values for goals lets you focus on the highest value conversions, such as transactions with a minimum purchase amount.
When a visitor to your site or user of your app performs an action defined as a goal, Analytics records that as a conversion. That conversion data is then made available in a number of special-purpose reports, which are described below.
Goals fall into one of 5 types, listed in the table below:
|Destination||A specific location loads||Thank you for registering! web page or app screen|
|Duration||Sessions that lasts a specific amount of time or longer||10 minutes or longer spent on a support site|
|Pages/Screens per session||A user views a specific number of pages or screens||5 pages or screens have been loaded|
|Event||An action defined as an Event is triggered||Social recommendation, video play, ad click|
About view filters
Filters allow you to limit and modify the data that is included in a view. For example, you can use filters to exclude traffic from particular IP addresses, focus on a specific subdomain or directory, or convert dynamic page URLs into readable text strings.
You need Edit permission at the account level to manage filters. See Create and manage view filters for more information.