8 Lesser Known Facts About Google Analytics Sessions

Sessions in Google Analytics are deceptively simple. It’s just the number of visits to your website, right?

Yes, but… No.

At their heart, sessions are meant to tell you how many people visited your website during a given time frame or meeting certain criteria. And in the vast majority of instances, that’s exactly what they do.

But sessions are also an artificial number created when certain conditions within a piece of code are met (e.g., when an initial hit is sent via the Google Analytics tracking code). Unfortunately, this code doesn’t always match up with what the average user would consider a session on your website.

Let’s take a look at eight lesser known facts about Google Analytics sessions and how they might impact your data.

1. A Session Ends If The Campaign Data Changes

Let’s start with an easy one. If you’ve ever dealt with cross-domain tracking, you’ll know this one, but sessions being split by new source/medium data is often one of the first technical hurdles Google Analytics enthusiasts will face.

If you’re not familiar, there are many things that help Google Analytics ‘define’ a session to help group all of the interactions it contains. Among those are campaign data—how the user arrived to the site for that session.

There are a number of ways that a session’s campaign data can change, but here are a few of the most common examples:

  • Self-referrals or referrals from third-party tools/payment processors
  • One user clicking different ads in a short span of time
  • Internal linking with UTM parameters (Hint: Don’t do this!)

2. Sessions End At Midnight, Regardless of User Activity

Have you ever changed the “Time Zone Country or Territory” setting in your view settings? You might want to take a closer look.

Most people know that a session in Google Analytics ends after 30 minutes of inactivity, but did you know that all active sessions end at midnight in whatever timezone your view is set to? That’s right.

Let’s say at 11:59pm, you have 100 visitors on your site. At 12:00am, all 100 of those visitors click to a new page. Guess what? Each and every one of them is counted as a new session.

This might make sense if you’re looking at a single day’s worth of data—you’d almost certainly want those 100 sessions to count in some fashion on both days. The problem, however, is if you look at a date range that includes both the 11:59 sessions and the 12:00 sessions. Suddenly, you’ve got twice as many sessions, even though, realistically the user only ever came to the site once!

3. You Can Change The Default Session Timeout Length

For the vast majority of websites, 30 minutes of inactivity is more than enough to officially declare a session “over,” but did you know that you can actually change how long Google Analytics waits to end a session due to inactivity?

It’s true!

If you go to Tracking Info > Session Settings under the Property column of the Analytics admin area, you can adjust the length of time a session is given before it “times out.” You can go as little as one minute or as long as four hours.

Why would you want to adjust the session timeout setting? Here’s just a few examples:

  1. You write a lot of long-form content that takes more than 30 minutes to read. If a user reads one whole piece and then goes to read another, they’ll have started a second session.
  2. You have lots of video content, for the same reason as above.
  3. You’re in a space where you expect users to linger on pages for longer periods of time (think comparison shopping, for ecommerce sites, for instance).

I’m not advocating a widespread changing of these settings—30 minutes is good for most sites—but it might be worth thinking about if you feel like your users may take more than 30 minutes on a given page.

And remember: Inactivity means no pageviews or events. You can also “extend” sessions by adding more event tracking.

4. Getting More Than 200,000 Sessions/Day Could Impact Your Reporting

Before diving into this one, let’s remember that Google Analytics is a free tool. An incredibly powerful free tool, but still a free tool. Got it? Good, because here’s the bad news: it has limitations.

With a basic Google Analytics account, you may see some reporting delays if you get more than 200,000 sessions in a single day.

Officially, Analytics documentation says that reports are updated within 24-48 hours, but if you hit that 200,000 session threshold, Analytics will only update your reports once per day. Now, most marketers don’t look at same-day data in Google Analytics all that often, but this could result in significant delays in data analysis.

I’ve never personally run into this issue, but if you have, you’ve basically got two options: reduce the number of sessions you’re sending to Analytics (hint: make sure none of it is spam!) or upgrade to Google Analytics 360.

5. Technically, Anyone Can Send Sessions to Your Analytics Account

You’re probably familiar with Google Analytics spam at this point, but have you ever really thought about the implications of it?

One of the biggest flaws with Google Analytics is that it’s incredibly easy to send fake data to anyone‘s Google Analytics account. In fact, the only thing you’d really need is the tracking ID of the account you’d want to send bad data to—assuming you’re not just trying to mass spam random Analytics accounts.

The trade-off with the simplicity of installing a Google Analytics code via a small piece of JavaScript is that it’s easy for someone with even minimal coding experience to manipulate that code with bogus data.

Unfortunately, there’s not much you can do to proactively prevent this from happening. That’s why it’s so important to regularly audit your Google Analytics account.

6. Sessions Are Limited to 500 Hits

An individual session can only contain a total of 500 pageviews and events. Once that limit is reached, the session is effectively over as far as Google Analytics is concerned, as no additional interactions will be processed.

Realistically, it would take some incredible tracking granularity to hit this limit, but it is theoretically possible.

For example, say you had even tracking set up to track every 1% of a video a user watched on your site, and a user watched five different videos. Since you’d be sending 100 hits per video (one event for each percent of the video watched), that user’s session would have 500 hits—and that’s not counting any pageviews or other events that may be triggered.

7. Your Average Session Duration Is Probably Longer than Google Analytics Says It Is

Average Session Duration is probably my least favorite metric in Google Analytics. That’s not to say it’s not a helpful metric, but it’s just so misleading—especially if you don’t spend a lot of time digging into the story behind the data.

If you’ve ever looked at your average session duration with dismay, I’ve got some good news for you: It’s probably longer than Analytics says it is. The challenge is, it’s not actually measuring the total length of the session—it’s measuring the time between the first hit and last hits of a given session that are sent to Analytics.

Confused? Pretend Analytics starts a stop watch when the first pageview tag fires. The next time the Analytics code fires, GA can update it’s session duration by subtracting the time of the first hit from the time of the second hit. But there’s a crucial missing piece: Once the last pageview of a session is recorded, there’s no way for Analytics to know how long a user spent on that page—there’s no final hit sent to GA to officially say the session is over. The stopwatch would never stop.

What this means, practically, is that Average Session Duration is really measuring all but the last page. Where this gets more frustrating, however, is when you consider sessions that bounce. Bounces always have a session duration of zero seconds—because that stopwatch starts, but would never end.

8. You Can Have a Session With Only Non-Interaction Hits

Let’s end with a weird one. It is theoretically possible to have a session made up entirely of non-interaction hits… meaning there actually isn’t a session!

Confused? It’s unlikely you’ll ever see this, but it’s an interesting hypothetical. If a user somehow got to your site and triggered some event that’s flagged as a non-interaction hit but never recording a pageview, there’s still technically data being sent to Google Analytics. But if none of that data is marked as an interaction, Google Analytics doesn’t actually record a session. Weird!

Contact Form 7 Thank You Page Redirects

Note: This post originally appeared on the Rocket Clicks blog. The version below has been slightly modified from that original version.

Contact Form 7 (CF7) is one of the most popular contact form plugin options for WordPress-based businesses. However, Contact Form 7 users should know that the process for sending users to a thank you page after a successful form submission has changed. According to the developer’s documentation, they deprecated/removed that functionality at the end of 2017.

The updated contact form doesn’t impact the ability for users to submit forms (and for you to receive those submissions), but it can have a dramatic impact on your ability to accurately track these submissions in Google Analytics and other analytics programs.

Below is a quick guide on how to update your Contact Form 7 forms so that they still redirect to the proper thank you pages.

Please Note: The new method will require you to edit your theme’s functions.php file. Please make sure you’re familiar with the best practices of editing functions.php files – a single typo could make your site inaccessible.

The Old Method: What Changed?

Before the update, you would configure a form to redirect using the Additional Settings field of the given contact form. In that field, you’d place a code similar to this:

on_sent_ok: "location = 'http://www.example.com/thank-you-page'";

This piece of code is essentially JavaScript – it’s just that the plugin is doing most of the work for you by creating the rest of the code surrounding what you enter.

However, citing potential security risks, the developer plans to remove this functionality from the plugin. If and when this happens, your forms will no longer send users to thank you pages upon successful submissions.

New Method: One Thank You Page

Most businesses, you’ll have a single thank you page that acts as the confirmation for all your forms. The good news for you is that I have a code you can (more or less) copy and paste.

Ultimately, we’re still doing exactly what the old method did; we’re just doing it manually this time. Let’s get started.

Copy and paste the following code at the bottom of your functions.php file:

add_action( 'wp_footer', 'redirect_cf7' );

function redirect_cf7() {

<script type="text/javascript">
document.addEventListener( 'wpcf7mailsent', function( event ) {
       location = 'https://www.example.com/thank-you/';
}, false );


Before you save your file, change https://www.example.com/thank-you/ (in the fifth line) to your thank you page URL.

That line of code should look familiar – it’s exactly what we had after on_sent_ok in the old method.

Essentially, this code will add a script to the footer of your WordPress pages that ‘listens’ for successful form submissions (or, in this case, that a form submission has been emailed to you). When that criteria is met, the form redirects to the URL you’ve provided.

Again, this is exactly what the old method did – we just have to draw it out a bit more.

New Method: Multiple Forms, Unique Thank You Pages

If you have multiple forms that each go to a unique thank you page, the process becomes a bit more complicated. With the old method, you could specify an on_sent_ok on a form-by-form basis. Unfortunately, the code above will send submissions from every form to the same thank you page. This can still impact your tracking.

The good news is: there’s a work around for that, too. This will, however, require some extra work.

Start with pasting this code into your functions.php file:

add_action( 'wp_footer', 'redirect_cf7' );

function redirect_cf7() {
<script type="text/javascript">
document.addEventListener( 'wpcf7mailsent', function( event ) {
   if ( '947' == event.detail.contactFormId ) { // Sends sumissions on form 947 to the first thank you page
    location = 'https://www.example.com/thank-you-1/';
    } else if ( '1070' == event.detail.contactFormId ) { // Sends submissions on form 1070 to the second thank you page
        location = 'https://www.example.com/thank-you-2/';
    } else { // Sends submissions on all unaccounted for forms to the third thank you page
        location = 'https://www.example.com/thank-you-3/';
}, false );

Like before, we’re creating a ‘listener’ to fire a specific code when someone submits a form. This time, however, we’re using conditional if…else JavaScript statements to further specify our criteria.

Now, we’re saying: “If a form is submitted. check the form’s ID. If that ID is x, submit it to thank you page y. If that ID is w, then submit it to thank you page v.”

Now comes the work on your end.

For each form, you’ll need to identify the form ID and then use that as the conditional criteria.

You can find this in the shortcode you’d use to place that form on a page or post. For example, the shortcode for the first ID in my example would look like this:

[contact-form-7 id="947" title="General Contact Form"]

The highlighted portion is the form’s ID. Copy that number and replace it with the ones in my example.

For reference, this is the bit you’re replacing:

if ( '947' == event.detail.contactFormId )

You’ll need to update this on every form that has a unique thank you page.

Note: Additional criteria in JavaScript if…else statements should start with else if instead of just if. For more information, check out W3School’s documentation on conditional JavaScript statements.

You might notice that the final statement is just else, followed by another line of code that redirects users to a thank you page. Technically, if…else statements are supposed to end with something happening if none of the specified conditions are met. In this case, we’re saying: if the form ID doesn’t match any of the specified IDs, then send users to a third thank you page.

You have two options here:

  • Omit this portion of the code (it’s not best practice, but the code should still function properly)
  • Create a generalized thank you page and use it here on the off chance that there’s a form ID you haven’t accounted for.

New Method: One Form, Multiple Thank You Pages

If you’ve got a single form that goes to multiple thank you pages based on how the form is filled out, then either:

  • You’re not using Contact Form 7.
  • You’re using a plugin that likely has redirection solutions built into it.
  • You’re already familiar with JavaScript.

Unfortunately, this solution doesn’t work very well for forms with conditional fields and thank you pages. While it can be accomplished through JavaScript, the code would have to be customized heavily towards how your form is set up, which means you’ll likely need to consult a developer.

That said, the last section of this article will cover plugins that might be able to help.

Tracking Using Google Analytics Events

This guide focused on getting Contact Form 7 to redirect users to thank you pages. However, you’ll also need to update your implementation if you track submissions through Google Analytics events.

The process is the same as above, you just need to swap out any instances of on_sent_ok: "location = 'http://www.example.com/thank-you-page'"; with on_sent_ok: ga( 'send', 'event', 'Contact Form', 'submit' ); (or whatever you currently have after on_sent_okay in the Additional Settings field).

This will then fire the event in Analytics once the form is successfully emailed to you.

Using a Plugin

In general, I recommend avoiding plugins that add functionality you can achieve with a little custom code, but if you’re not comfortable editing JavaScript/PHP and can’t work with a developer, there are plugins that can make redirecting to thank you pages more user-friendly.

The most common example is the Contact Form 7 Success Page Redirects plugin. This is a free plugin that adds a new tab to your Contact Form 7 editor allowing you to select thank you pages from a dropdown list on a form-by-form basis.

It’s worth noting here that this plugin only lets you redirect to pages, not posts. That’s probably not an issue for most people but could create limitations if you’ve got a complex lead funnel. You also can’t redirect to non-WordPress pages (whereas with the examples in this guide you can redirect to any page on the internet).

This plugin will also not allow you to send events to Google Analytics.

I’ve tried to write this in as non-coder-friendly language as possible, but, at its core, this solution is built on JavaScript. If you still have questions, feel free to reach out to me at @jdegbau on Twitter. Otherwise, you can create a thread on the plugin’s official support form.