Marketing Channels: 5 Steps to Troubleshoot Session Refresh

This post is part of a series on setting up and using the Marketing Channel reports. In the previous posts we set up the Marketing Channel rules and renamed the “Internal” rule to “Session Refresh”. The main reason we rename the rule is to lessen confusion between “Internal Campaigns” and “Internal Entries” in Marketing Channels. Internal Campaigns and promotions should never be included in external traffic sources reports. The main reason for this is that we want to see how internal AND external campaigns perform separately, and in another report how they perform together. If they are included in the same report the internal campaign values will overwrite external campaign values and we won’t be able to see how either truly performs.

For Example: A Visitor enters the site on Paid Search Campaign A, lands on the home page of the site and clicks on Hero Banner A and eventually goes on to complete an application.

Scenario A

Combined Reporting

Split Reporting

Enters site on ‘Campaign A’

s.campaign=”campaign A”

s.campaign=”campaign A”

Clicks on ‘Hero A’

s.campaign=”Hero A”

s.eVar1=”Hero A”

Application Complete

Hero A gets credit for success

Campaign A gets credit for success, Hero A gets credit for success.

Now that we know why Internal Campaigns should be kept separate, let’s talk more about “Session Refresh” and what it really is. To get technical for a minute: “Session Refresh” should consist of visits to the site where the incoming URL matches the “internal URL Filters” listed in the Admin Console. This basically means that if a user starts a visit with a referring domain that matches your site domain(s) they will be included in this channel.

This scenario could happen if a user visits your site, leaves the browser (or tab) open and goes to lunch or ignores the window for over 30 minutes. A SiteCatalyst visit will be terminated automatically after 30 minutes of unsustained activity (meaning that if there is no interaction SiteCatalyst will close the session after 30 minutes even if the browser is left open). If the user returns to the browser and clicks on a link within the site after the session has been closed a new visit is generated, but the incoming referral URL matches a URL from within the site. This starts a new Visit, but with a visit from an internal URL. Since Marketing Channels report on 100% of incoming traffic this entry has to be allocated to a channel, hence the “Internal” or “Session Refresh” channel. The percentage of entries within this channel should be small, likely under 3-4%. This post will discuss how to trouble-shoot the Session Refresh channel if you are seeing a higher percentage than that.

Top Reasons your site could have high Session Refresh entries:

  1. Internal URL filters are wrong
  2. Not all pages of the site are tagged
  3. Long videos or content pages
  4. Landing page load times are long
  5. Redirects

Are you seeing high Session Refresh numbers? Let’s go through the list and trouble-shoot.

1 – Check ‘Internal URL Filters’.

Go to Admin Console > Report Suites > Edit Settings > (select report suite) > General > Internal URL Filters

Check to make sure all the domains for your site are listed correctly. Domains should be listed as “” not “”. Make sure you only have internal domains listed and nothing outside of your site. For example, if you receive click-throughs from “” but currently do not track that domain in the same report suite do not list it as an internal domain. Make sure you don’t have a stand alone period or space listed in its own filter as that would make all referring domains in the World Wide Web appear as internal domains.

2 – Check to see if pages on the site are missing SiteCatalyst code

The biggest issue I see for high Session refresh entries is usually due to part of the site not being tagged. The usual scenario is that post-login or a landing page has not been tagged with SiteCatalyst code. Visitors will begin a visit on the non-tagged pages and navigate to the tagged pages. SiteCatalyst only sees that visits are originating from an internal URL and buckets those visits under “Session Refresh”. To check URL’s leading to Session Refresh pages you have a couple of options:

3 – Check Session Refresh referrers for long content

Run the same report as above, but this time check the referring URL’s for content that could cause a session to automatically timeout. For example, if a video or article on a page could cause a user to spend over 30 minutes on one page the session for that visit will close out automatically in SiteCatalyst. If a large number of user experiences are ending up timing out due to an issue like this you may consider having the page (or video) periodically ping SiteCatalyst in order to keep the session open.

4 – Long Entry Page Load times

Long Page Load times are another issue to be aware of. For example, let’s say “Landing Page A” is heavy on content, banners and visuals, and the SiteCatalyst code is located at the bottom of the page just above the closing