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:

  • Set the Marketing Channels Session Refresh rule logic display value to the referring domain and path. This way you will be able to see the URL visitors are coming from and then paste that URL in your browser
  • Run a Data Warehouse report, create a Page View segment where “Last Touch Channel = Session Refresh” and pull in Referrer and Visits

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 </body> tags. A Visitor starts a visit by going to Landing Page A, but before all the content (including SiteCatalyst image request) can load the visitor has clicked on a link and navigated to another page. Now the second page loads and fires off its SiteCatalyst image request. Since the Landing Page image request never loaded, the second page appears as the first hit of the visit in SiteCatalyst.

Two things have happened in this scenario, because the Landing Page image request never fired: 1) we lost the referrer/campaign data on the landing page, 2) the Second page appears as a site entry with an internal URL as a referrer.

You can easily test this scenario by having a packet sniffer like the Debugger, Charles or httpFox open while you navigate to the landing page. Click through to another link before the page fully executes and see if you can trigger the second page image request before the first has time to fire.

This situation becomes an issue on portal pages like home pages or landing pages where repeat users to the site may be using the page as a gateway to another part of the site, or on pages that are content rich and still have a lot of navigation links higher on the screen. To solve the problem you could move the SiteCatalyst code higher on the page, or try to improve load times for the overall page content.

5 – Redirects

Redirects could happened when a visitor types in a vanity URL or links to an older page. If the redirect is not set up to pass the referrer data and tracking code through to the new landing page we could end up with a scenario similar to the previous situation when the true entry referrer data is lost and now the redirect page appears as the referring domain. To solve this we just need to make sure our redirects have been set up correctly in order to pass through the referrer and tracking code rather than replacing it.

Hopefully the 5 trouble-shooting methods above help solve any doubts you may have about Session Refresh.