Google Analytics 4: Exploring Sessions with DebugView

Exploring Differences in Sessions between Classic Google Analytics and Google Analytics 4

by Nikolay Gradinarov

When Google Analytics Web + App first came out in the summer of 2019, there was much fanfare about Google's brand new digital analytics schema with Events and Users being the main building blocks. In some of the first echoes, many digital analytics blogs were eager to announce the death of Sessions. Even after Web+App came out of beta under its new moniker of "Google Analytics 4", there is still a misconception that Sessions are no longer part of GA4. 

 

The reality? One can see references to Sessions in many different parts of GA 4, from key parameters such as "sid" (short for Session ID) or "sct" (Session Count) in the tracking requests produced by GA4 JavaScript, through sightings of the Sessions metric in various built-in reports, down to the Session scope in segments/audiences that can be created directly in the GA4 interface.

Google Analytics 4 is really far from spelling the death of Sessions. If anything, Sessions underpin all essential aspects of GA4 and continue to be an integral part of the new Google Analytics data model. 

 

Sessions in the legacy Google Analytics are quite nuanced. So it's worth asking how some of these intricacies carry over to Google Analytics 4.

In particular, I was interested in finding out how GA4 treats the following cases:

  1. Instances where the user interacts with more than one campaign during a session. In Google Analytics Classic such instances increment a new session for each new campaign code.
  2. What happens when the user interacts with more than one referrer during a session? Similarly to campaigns in the classic GA  setup this type of activity generates a new session for each referrer instance. 
  3. What facilities does GA4 offer for producing Session-level counts for hit-based dimensions? The most common example in this category includes cross-tabulating Pages with Sessions which in the legacy GA relies on a specialized "Unique Pageviews" metric as the Sessions metric is only incremented on the entry Page.  
  4. How does GA4 account for common analytics requirements to calculate the number of sessions where a particular event occurred? Most commonly in the legacy GA interface this was being handled by the concept of Goals. 
  5. What are the utilities in GA4 for persisting session/visitor identification for website that span multiple domains? Is the legacy protocol for decorating the URL with the "_ga" query parameter sufficient?

 

For the purpose of trying to answer these questions, I decided to use DebugView, a great tool for doing this type of investigations because it allows users to immediately see and verify the details/payload of the actions they generate. 

Each interaction recorded in DebugView comes with a set of built-in parameters. For this investigation, I focused on "ga_session_id" and "ga_session_number". These two attributes can be monitored directly in the tracking request generated by the browser, where they appear under the names "sid" and "sct" respectively.

 

 

Sessions with Multiple Campaign Codes

  • Test Setup

Navigate to the site with the following query parameters:

1. ...?utm_source=ABC&utm_campaign=123&utm_medium=email

2. ...?utm_source=XYZ&utm_campaign=456&utm_medium=social

  • Test Result

In Google Analytics 4, this type of activity maintains the same session ID and same session number for the two different requests. This is very different from Classic Google Analytics where a new Session gets incremented for each campaign identifier, so potentially this can result in discrepancies between the total number of Sessions reported by GA4 and Classic GA. 

 

Sessions with Multiple Referrers

  • Test Setup

1. Launching Preview Mode in GTM automatically generates a referring URL and sets the "source" parameter to "tagassistant.google.com":

2. If you want to set an additional referrer as part of your session you need to click on a link that takes you back to your website and maintains the referrer. The new GTM preview mode disables the address bar, so it is not very easy to navigate to a given URL, but you can work around that by launching the browser console and using the following:

window.location = '%URL with backlinks to your site%';

You can then clickthrough on the link leading the user to your site and verify the properties in DebugView 

  • Test Result

Much like the campaign test, you will see that regardless of the changed referrer, the same session ID and same session number are maintained. This is another difference when comparing to Classic Google Analytics where a new Session would get counted in such instances.

 

Sessions and Pages

  • Test Setup 

The test setup is straightforward: I navigated through a selection of pages and monitored the "page_title" and "page_location" parameters collected.

  • Test Result

As we have seen in all others tests, same session ID and same session number are maintained for all page_view events. There is no built-in report that is able to show us how many Sessions interacted with different Pages, so I used the GA4 Analysis Hub interface to build such a table. Based on that report, it is clear that while the Analysis Hub will allow you to build a report for Sessions by Pages, the data will be inaccurate - you will see Pages Paths with no Sessions at allow or with less Sessions than Visitors.  

This leaves the possibility of using the "ga_session_id" parameter directly in BigQuery to produce an accurate count of Sessions for a given URL. 

 

Sessions and Session-based Event Counts

  • Test Setup 

The setup for this test is identical to the above. I performed a set of actions on the site where unique events are firing, making a point to trigger the same event at least twice. The idea is to check if, using Sessions out of the box, one can see how many sessions registered a particular event. This requirement was historically serviced in Classic GA by the enabling of goals.

  • Test Result

The result reveals more information about the way Sessions are calculated. While the "ga_session_id" and "ga_session_number" parameters remain consistent in Debug mode, pulling a cross-tab of Event Name and Sessions, shows that this metrics is only incremented during the very first event in a session, i.e. "session_start" and none of the other events are actually getting credited with a Session count in Analysis Hub:

Creating a Session-scoped segment however with a rule for particular event correctly adds up the number Sessions where such an event occurred:

 My assumption is that for the moment, the easiest way to report on this type of requirement would be to run queries in BigQuery.

 

Sessions and Cross-Domain Tracking

  • Test Setup 

For this test, I navigated through a set of domains that are already tagged for cross domain tracking and are leveraging the "_ga" parameter inside links in order to stitch the visitor/visit activity. Prior to performing the test, I also configured the domains list inside WebStream Details > Tagging Settings > Configure Your Domains. This integration surfaces another query parameter "_gl" that attempts to decorate links in cross-domain scenarios:

_gl=1*1ra1w4q*_ga*MzgyNDgxMDIxLjE2MDM4MjMxMDA.*_ga_Z4Z5QLV4FR*MTYwNDQ0MzkyMS40LjAuMTYwNDQ0MzkyMS42MA..

  • Test Result

In this test the session ID and session number are maintained consistently. One exception is links that go through redirects. In such cases the query parameter "_gl" does not get automatically placed on the target URLs which results in a new user/session to be counted. A custom solution similar to the one identified for such cases in Classic Google Analytics (section #2.5.5) will be need to be developed for GA4.  

 

In Summary 

There seem to be significant differences in the ways Sessions are calculated between Classic Google Analytics and Google Analytics 4. Analysts migrating their GA footprint to GA4 should be mindful of these differences and their impact on a range of cases - from implementation requirements and reporting on pure session counts all the way through performing more advanced attribution calculations.

 

Notes on DebugView 

I found DebugView to be really useful in these explorations. Every now and then, there were issues with events I had seen in the network tab that did not make it to DebugView. There was nothing unique or unusual about these events. It just seemed to be an intermittency issue with the events showing up in DebugView. Per @lukasoldenburg this intermittency can be resolved by refreshing the DebugView page. 

The ability to select individual devices is really helpful. It would be ideal if GA4 provides a way to filter the devices by a specific parameter/value combination in addition to the built-in device selection.

 

 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

Tags: Google Analytics Tips

Subscribe to our quarterly data quality newsletter