[UA] How users are identified for user metrics [Legacy]

At a glance

The Users and Active Users metrics show how many users viewed or interacted with your site/app.

Analytics uses two different techniques for calculating Users for different kinds of report requests. As a result, you may notice discrepancies in Users in different reports. The information in this article also applies to the Active Users metrics.

In depth

Background

In order to quickly serve data to your reports, Analytics creates a set of unsampled, pre-aggregated data tables, which are updated on a daily basis. (For more information on how this works, read how sampling works.) The pre-aggregated data tables are well equipped to handle common reporting requests, including changes to the date range in standard reports. For example, when you request a report, Analytics looks up each metric in the pre-aggregated data tables and serves those results to your reports. If you adjust the date range from August 1 - August 31 to August 1 - September 1, Analytics looks up each metric in the September 1 pre-aggregated data table and adds the new data to the existing total.

This works well for most metrics. Many metrics, like Pageviews or Screenviews, are simple additive counts over days. However, Users is based on more complicated calculations. Instead of simply adding (or subtracting) processed data from the pre-aggregated tables, Analytics must recalculate Users for each date range that you select in a report. For example, if a user visits a website on August 31 and on September 1, Analytics recognizes this user as a single user over the course of these two days. If you change your date range from August 1 - August 31 to August 1 - September 1, Analytics can’t simply add the difference to the value of Users you see in your reports because this number is based on a complicated calculation, and not just added to the running total in the pre-aggregated data tables. Instead, the metric has to be calculated on the fly each time you request it in your reports.

To address this challenge, there are two calculations for Users. The optimal calculation is selected depending on the report being viewed.

Calculation 1: Pre-calculated data

This calculation relies only on the number of sessions in the given date range and the time of each session. (This is determined by technology managed on the device, like a web browser, and is often referred to as the client-side time.) Because the result of this calculation can be added to the pre-aggregated data tables, Analytics can reference the table to quickly retrieve and serve this data in a report, including when you change the date range.

Calculation #1 is used exclusively in reports when the only dimension is a time frame, like the Date, Week of Year, or Month of Year. This means that you only see it in the Audience Overview report when no Segments are applied, or in a custom report where one of these date dimensions is the only applied dimension. When viewing Users over any non-date dimension, Analytics uses a second table, described below, in order to calculate Users on the fly.

Although this calculation can quickly deliver unsampled data, it does have some disadvantages. It relies on number of sessions and client-side time, so if a user's client-side time is incorrect, or if you are using a reporting view that filters out some sessions from a user (instead of all users), the data can be inconsistent.

In order to get around any potential inaccuracies, you can create a custom report with a non-date dimension that will be the same across sessions for users (e.g., Browser, Operating System, or Mobile Device). This forces Analytics to use Calculation #2, instead.

Calculation 2: Data calculated on the fly

Calculation 2 is based on the way you assign, collect, and store persistent data about your traffic. There are many solutions you can implement to customize this, but the most common way this data is going to be assigned and stored is through cookies managed via a web browser.

Calculation #2 requires heavy computation over large data sets, so it always references data in the raw session tables and not the pre-aggregate tables. Calculation #2 takes more time than Calculation #1 to process and serve data to your reports because the values are calculated on the fly; Analytics can’t simply look up and deliver data that’s already been processed and stored in the pre-aggregate tables. The calculation happens each time you make a request for it. Note that if certain conditions are met, this may induce sampling, but Google Analytics 360 account users can access unsampled reports.

Calculation #2 is used in custom reports and allows for the calculation of Users over any dimension, like Browser, City, or Source.

Note that for some dimensions, like Source or Medium, it’s possible that the same unique user can be in multiple buckets (for example, if a user visits from organic search and paid search in the same date range). For this reason, when viewing Users over such a dimension, the sum of the rows should not add up to the total.