Introduction

by Nikolay Gradinarov

Google Analytics "Sessions" is one of the most ubiquitous metrics in all of digital analytics. It is considered so "basic", so deceptively "simple", that it often doesn't even warrant a definition. In truth, sessions are anything but simple.

With this blog post, we'll highlight some of the hidden nuances of this concept. Understanding these fine points can be extremely useful because sessions (and the so-called "sessionization" logic frameworks like GA apply when processing raw data) cast a big shadow on all aspects of your analytics workflow—from the structuring of data collection / tagging, through the configurations of Google Analytics properties and views, all the way to report understanding, customization, and interpretation.

 

Definition

In their most basic form, GA Sessions represent a group of hits (pageviews or events) a user has performed, separated from other groups of actions from the same user by anything that GA considers a session-separating event.

 

The most important, and most transparent, session-separating event in GA is a time period in which no activity from a given user has been recorded. The default interval is 30 minutes, but this is configurable at the property level:

We'll come back to this screen again further down in our discussion.

While the definition of GA Sessions is fairly standard and the scope of a session in GA is in many ways aligned with how visits are defined by other comparable digital analytics platforms, the way the GA Sessions metric is calculated accounts for a lot of the hidden complexity in this concept.

The most important thing to remember is that while the scope of a session (most clinically observed when creating a segment based on Sessions) includes all the hits inside a session, dimensions based on hits within the session do not always work with the Sessions metric. 

 

Pages vs. Sessions

The most common illustration of the above rule is the Page dimension, by far the most popular hit-based dimension. If you look carefully, you will notice that the built-in "All Pages" report does not include the Sessions metric at all. The GA Custom Reports interface (or Data Studio) would allow you create a report tabulating the Page dimension with the Sessions metric, but the results can be deceiving.

The GA Sessions metric will be under-counted across all of your Pages (in some cases showing no Sessions at all) and that's a function of how this metric is calculated, as it will only be incremented for the first page in the session. When across from the Pages dimension, the GA Sessions metric should be read as "Session Starts":

 

In order to answer the question of how many Sessions included a specific Page at any point, Google Analytics has put together a special metric called "Unique Pageviews" which is available by default in the built-in Pages report.

It should be noted, however, that a Session-scoped segment works fine with the Page dimension. A segment such as "Sessions where Page contains /blog" for example is completely valid and will filter the data in the way you would expect.

 

Sessions and Hit-based Dimensions

The reason Page as a dimension doesn't mix well with Sessions as a metric is its hit-scoped nature. Any dimension whose value is not inherited from one tracking hit to the next and has to instead be set (or not set) on every hit is likewise said to be hit-based. If you try to mix any custom Hit-scoped dimension with the Sessions metric, you will see the same result—only the value set on the first pageview of the session will be credited with a Session count of +1.

For custom hit-scoped dimensions, there is no Unique Pageviews equivalent that can be used to bypass this limitation. But just like with the Page dimension, it is completely fine to use Hit-based dimensions within segments with a scope of Sessions. 

 

Sessions and Product/eComm-scoped Dimensions

Organizations using the Enhanced eCommerce tracking modules will likely notice that none of the built-in reports in the Conversions > Ecommerce section allow you to examine Products, Product SKUs, Product Categories, Brands or List Names against the Sessions metric.

And while derivatives of the Sessions metric (Sessions with Transactions, Sessions with Product Views, Sessions with Add to Cart, etc) appear in the "Shopping Behavior" and "Checkout Behavior" reports, none of the dimension breakdowns offer a Product-scoped dimension. 

(As an aside, there is also a limitation for Hit-scoped dimensions which cannot be used together with Product-scoped dimensions.) 

The general rule of thumb is: use Enhanced eCommerce dimensions with either Users, the out-of-the-box eComm metrics, or custom metrics with a scope of Product. 

While the Product and Session scopes do not allow the full integration of any metrics/dimensions combination, a Session-scoped segment will allow you to examine the product-scoped metrics/dimensions observed during the session.

 

Sessions and Events

In response to the pretty basic need for combining Sessions with the built-in Event tracking-based dimensions, GA has provided a specialized Unique Events metric, the equivalent of Unique Pageviews for the event dimensions. This metric is always part of the default reports available under Events > Top Events. In Custom Reports, one can select Sessions together with these dimensions (Event Action, Event Label, and Event Category). This metric will be informative row-by-row, but will not be de-duplicated across rows and will have inaccurate "Total" counts at the top-level. That's simply because it will be incremented for every session that has any of the row's event values, and sessions typically have more than one event.

 

Sessions and Goals

For most analytics implementations, it is important to be able to examine a variety of dimensions against the number of sessions featuring a particular conversion. As we have seen so far, the Sessions metric cannot be freely used in every context, but with the ability to define Goals in GA users can essentially have a calculation that accomplishes just that. Once configured, these Session-based calculations can be found under Conversion > Goals and also used in custom reports.

 

Session-scoped Dimensions

Dimensions in Google Analytics can be configured with four different scopes (Hit, Product, Session, User). For session-scoped dimensions, it is important to note that only the last value seen in the session will be credited with any conversion. This may look especially perplexing to report users in cases where the dimension obtains a new value long after a given conversion event has taken place in the session. 

Even more perplexing is an exception to the "last value" allocation stemming from an undocumented behavior that sets the allocation logic to "first value" when a session-scoped is set via advanced filters.   

Sessions and Campaigns

The "last in session" attribution we just described is very likely to be an anathema to Campaign tracking. It is often possible for a user to interact with multiple campaign assets during the span of a single session. To address this, Google Analytics treats campaign reporting as a special case in which a new Session starts every time the URLs contain the campaign parameters (even if the timeout setting for a new session has not been reached). This hidden logic in effect inflates the number of Sessions compared to what the counts would be without multiple campaign landings. But this is done in order to ensure that the credit for all pageviews, events, and conversions is given to the most recent campaign the user interacted with:

 

 

Sessions and Referrers 

The same technique is used for cases where the user interacts with multiple Referring URLs to land on the property. In such cases, GA again assigns a fresh Session +1 count for each hit in the session with an external HTTP referrer.

A special use case to watch out for are websites that are using multiple domains (the most common examples include shopping carts that live on a separate domain or authentication providers). In such flows, Session inflation from when the user transfers from one domain to another needs to be countered by use of the GA Referrer exclusions settings. A list of internal domains needs to be configured and maintained in addition to any cross domain tracking that was enabled.

 

Sessions and New Users

A common puzzler you can see in some reporting contexts is a number of New Users exceeding the number of Sessions. This is usually explained by non-interaction hits. A session that only contains such requests will not increment the Sessions count, but will be accounted for in the New Users metric.

While it may be difficult initially to imagine why non-interaction-only session are happening at all, consider that many users idle on site pages (easily reaching the session timeout), and that site pages sometimes send timing or content update events without the need for an active user.

 

Sessions and Entrances

Depending on the type of hit the user enters on, a discrepancy can occur between the number of Sessions and Entrances (which at first glance should be identical). A detailed write-up on the typical causes of this oddity can be found here.

 

Fine-tuning Sessions

GA Properties allow users to define both session and campaign timeout windows under Tracking Info > Session Settings. The 30 minute default for sessions is a consensus between many digital analytics tools, so change this value only after a suitable deliberation. A detailed write up on Campaign timeouts and their implications can be found here.

 

Session starts and ends can be fine-tuned further via the sending of specialized tracking requests. 

 

"Midnight" Sessions 

At the stroke of midnight (as calculated by the GMT offset specified for the GA view) any open session will be closed and a fresh +1 Session count will be incremented for the following calendar day. Thank you @JimKultgen!

 

Sessions and BigQuery

Various session-related fields appear in the BigQuery schema. Instead of using the term "Sessions," however, BigQuery labels this field as "Visits", e.g. totals.visits, totals.newVisits, visitID, etc. 

It is important to note that Goals defined in Google Analytics are not passed as fields in BigQuery. Since Goals are simply a Session-based calculation of a possible conversion event or a page that the user has seen (or a combination thereof), the calculation can be performed directly in BigQuery by taking advantage of the visitID field.

 

Sessions and App + Web

Much ado has been heard across the analytics blogosphere about the new GA App + Web properties "moving away" from Sessions. I am not sure that this is an entirely warranted observation. While I understand that App + Web brings with it a heavy emphasis on events and their attributes, the concept of Sessions is alive and well in App + Web. Events and sessions are not in the same kind of tension as events vs. pageviews. The latter have always been simply events with a special attribute called page load, and a lot of special treatment since the early days of web analytics.

Some examples of session-oriented metrics in App + Web include "session_start" and "first_visit" as standardized events. Then we also see "ga_session_id" and "ga_session_number" as standardized parameters. All this in addition to the ability to specify a Session scope in the context of segments/audiences:

 

 

Instead of saying that App + Web is departing from sessions, we may in fact conclude that a lot of the idiosyncrasies of how Sessions are counted in legacy GA properties have been simply stripped in favor of a more streamlined and versatile approach heavily reminiscent of how Visits/Sessions are treated in custom data lakes and other enterprise digital analytics tools such as Adobe Analytics. 

 

About QA2L

QA2L is a data governance platform specializing in the automated validation of tracking tags/pixels. We focus on making it easy to automate even the most complicated user journeys / flows and to QA all your KPIs in a robust set of tests that is a breeze to maintain. We take a smart, targeted approach to issue discovery via auto-selective site audits and scans and can help your organization on the path of improved data governance and data quality. Contact Us