Defining the Campaign Timeout in Universal Analytics

The Campaign Timeout setting in Universal Analytics is hard to understand, and often misunderstood. Here we explain what it is and how it effects pretty much all of your data in GA.

I’ve been running Google Analytics training since 2016, and every time without fail I am met with puzzled faces when it comes to explaining the Campaign Timeout setting in Universal Analytics (UA).

It doesn’t matter if you are new to GA or have been using it for years, most people are generally unaware that it actually exists. And if they are, they generally don’t realise the extent it effects the campaign data they when pulling reports from GA.

What is it?

Starting with where it is, you can find the setting in the property setting list for any UA property under Admin > Tracking Info > Session Settings:

Google Analytics interface highlighting the campaign timeout setting

The default timeout window is set to 6 months, but this is configurable to anyone who has admin access.

Now for what it is, it is a method to artificially reduce the attributed credit that the channel Direct receives, and to give that credit to the other non-Direct channels.

Yes, it means that the count of Sessions by channel (medium, source, campaign, etc.) is not actually the number of times someone uses that channel to reach your website. This is why you generally see more Sessions in GA than Clicks in any of your ad platforms when validating them against each other – even between Google Ads. This means that a single link click can lead to many Sessions in GA.

Bar charts showing the difference in traffic volumes between direct and non-direct, with and without the campaign timeout

How it works

The mechanics of how it works is relatively simple, albeit hard to grasp at first. The first and most important thing to remember is that the Campaign Timeout only effects Direct sessions (check out this article to see how GA defines Direct).

When a Direct session is seen, GA then looks back in that user’s session history up the length of the Campaign Timeout (i.e. 6 months by default) until it finds a non-Direct session. If it finds a non-Direct session, then it copies the medium, source, campaign, etc. If no non-Direct session is found, or it is the first session for that user, then Direct is kept as the session’s channel.

GIF showing an example of direct being overwritten via the campaign timeout

Why?

I don’t think anyone knows exactly. What we have to remember is that Google purchased Urchin Analytics back in 2004/5 to measure AdWords (Google Ads) campaigns more effectively. It’s a marketing tool at heart.

The Campaign Timeout effectively up weights tracked marketing campaigns in GA, which includes Google Ads through their auto-tagging feature when you link the two platforms.

The other idea is that, from a marketer’s perspective, you can always invest more time, money, people, etc. into any non-Direct channel, but you can’t invest more into Direct. So attributing back to a channel you can action is something that may be more useful and actionable.

I suppose you can argue that word-of-mouth and offline marketing contribute to an increase in Direct traffic, and measuring Direct is a good indicator of brand awareness (etc., etc.), and I would tend to agree with you!

Whatever your thoughts and views on the Campaign Timeout are, it’s there and it’s most likely always been there affecting your data – your channel baselines, benchmarks, targets, etc. may already be based on the artificially up weighted data. Removing it (which you can do of course) would mess with all of this, and as it doesn’t backdate, will basically mean drawing a ‘line in the sand’ when it comes to reporting. It’ll be apples and oranges so you shouldn’t compare to the historical data.

Now what?

We do have the Direct Session dimension that you can add to any session-level report to see if the session was actually Direct or not. The best place to see this is in the Acquisition > All traffic > Channels report, and add ‘Direct Session’ as a secondary dimension:

Google Analytics reporting showing the Direct Session dimension by Default Channel Grouping

In the example above, you can see that 406,237 out of 586,805 Organic Search Sessions were actually Direct that were reattributed to Organic Search via the Campaign Timeout, that’s about 69%!

Annoyingly the ‘Direct Session’ dimension is not available in the Reporting API v4, just the UI. So its usefulness is limited to manual reporting and analysis within GA for now. And with Google Analytics 4 (GA4) now getting all the time and attention from the team at Google, I don’t have high hopes for it ever being added to the API to be honest, not now all eyes (and devs) are on Google Analytics 4…

Safari, cookies, and whatnot

If you’ve read this far, thanks, now to talk about cookies!

I’ll keep this part specifically around Safari as they have a 19-23% browser market share (Chrome has 52-65%) as of October 2021. But this also applies to Firefox and other browsers too.

When Apple released Intelligent Tracking Prevention (ITP) 2.1 in April 2019, it came with a cap on how long some 1st party cookies can be set for. Cookies such as GA’s _ga cookie could only be kept in the browser for a maximum of 7 days.

That is, if a person visits a site and then again 8 days later, that person would be tracked as two users in GA. This does not happen in Chrome.

This is an issue for all types of attribution, but especially for the Campaign Timeout as it’s harder to find any non-Direct sessions in the user’s session history if the historic sessions are tracked against a different user (and cookie).

From this, we started seeing that Safari traffic has a much higher proportion of Direct sessions compared to other browsers such as Chrome.

Bar chart showing the impact of ITP on direct traffic for Safari vs Chrome

Above is actual data pulled from GA covering all of February 2022 for a travel website that has the default 6-month Campaign Timeout in place.

There is no way around ITP unless you look to move your tracking to the server (i.e. using server-side GTM), and setting the GA 1st party cookie via HTTP headers. Feel free to get in touch if you’d like to chat about how to do that!

I hope this helps with your understanding of how this odd and sometimes annoying feature works, and how it affects pretty much all the data you see in GA.

Share:
Written by

Daniel is the innovation and training lead at Measurelab - he is an analytics trainer, co-host of The Measure Pod analytics podcast, and overall fanatic. He loves getting stuck into all things GA4, and most recently with exploring app analytics via Firebase by building his own Android apps.

Subscribe to our newsletter: