This post is part of a series on set­ting up and using the Mar­ket­ing Chan­nel reports. In the pre­vi­ous posts we set up the Mar­ket­ing Chan­nel rules and renamed the “Inter­nal” rule to “Ses­sion Refresh”. The main rea­son we rename the rule is to lessen con­fu­sion between “Inter­nal Cam­paigns” and “Inter­nal Entries” in Mar­ket­ing Chan­nels. Inter­nal Cam­paigns and pro­mo­tions should never be included in exter­nal traf­fic sources reports. The main rea­son for this is that we want to see how inter­nal AND exter­nal cam­paigns per­form sep­a­rately, and in another report how they per­form together. If they are included in the same report the inter­nal cam­paign val­ues will over­write exter­nal cam­paign val­ues and we won’t be able to see how either truly performs.

For Exam­ple: A Vis­i­tor enters the site on Paid Search Cam­paign A, lands on the home page of the site and clicks on Hero Ban­ner A and even­tu­ally goes on to com­plete an application.

Sce­nario A Com­bined Reporting Split Report­ing
Enters site on ‘Cam­paign A’ s.campaign=“campaign A” s.campaign=“campaign A”
Clicks on ‘Hero A’ s.campaign=“Hero A” s.eVar1=“Hero A”
Appli­ca­tion Complete Hero A gets credit for success Cam­paign A gets credit for suc­cess, Hero A gets credit for success.

Now that we know why Inter­nal Cam­paigns should be kept sep­a­rate, let’s talk more about “Ses­sion Refresh” and what it really is. To get tech­ni­cal for a minute: “Ses­sion Refresh” should con­sist of vis­its to the site where the incom­ing URL matches the “inter­nal URL Fil­ters” listed in the Admin Con­sole. This basi­cally means that if a user starts a visit with a refer­ring domain that matches your site domain(s) they will be included in this channel.

This sce­nario could hap­pen if a user vis­its your site, leaves the browser (or tab) open and goes to lunch or ignores the win­dow for over 30 min­utes. A Site­Cat­a­lyst visit will be ter­mi­nated auto­mat­i­cally after 30 min­utes of unsus­tained activ­ity (mean­ing that if there is no inter­ac­tion Site­Cat­a­lyst will close the ses­sion after 30 min­utes even if the browser is left open). If the user returns to the browser and clicks on a link within the site after the ses­sion has been closed a new visit is gen­er­ated, but the incom­ing refer­ral URL matches a URL from within the site. This starts a new Visit, but with a visit from an inter­nal URL. Since Mar­ket­ing Chan­nels report on 100% of incom­ing traf­fic this entry has to be allo­cated to a chan­nel, hence the “Inter­nal” or “Ses­sion Refresh” chan­nel. The per­cent­age of entries within this chan­nel should be small, likely under 3–4%. This post will dis­cuss how to trouble-shoot the Ses­sion Refresh chan­nel if you are see­ing a higher per­cent­age than that.

Top Rea­sons your site could have high Ses­sion Refresh entries:

  1. Inter­nal URL fil­ters are wrong
  2. Not all pages of the site are tagged
  3. Long videos or con­tent pages
  4. Land­ing page load times are long
  5. Redi­rects

Are you see­ing high Ses­sion Refresh num­bers? Let’s go through the list and trouble-shoot.

1 — Check ‘Inter­nal URL Filters’.

Go to Admin Con­sole > Report Suites > Edit Set­tings > (select report suite) > Gen­eral > Inter­nal URL Filters

Check to make sure all the domains for your site are listed cor­rectly. Domains should be listed as “mysite​.com” not “www​.mysite​.com”. Make sure you only have inter­nal domains listed and noth­ing out­side of your site. For exam­ple, if you receive click-throughs from “myaf​fil​i​ate​site​.com” but cur­rently do not track that domain in the same report suite do not list it as an inter­nal domain. Make sure you don’t have a stand alone period or space listed in its own fil­ter as that would make all refer­ring domains in the World Wide Web appear as inter­nal domains.

2 — Check to see if pages on the site are miss­ing Site­Cat­a­lyst code

The biggest issue I see for high Ses­sion refresh entries is usu­ally due to part of the site not being tagged. The usual sce­nario is that post-login or a land­ing page has not been tagged with Site­Cat­a­lyst code. Vis­i­tors will begin a visit on the non-tagged pages and nav­i­gate to the tagged pages. Site­Cat­a­lyst only sees that vis­its are orig­i­nat­ing from an inter­nal URL and buck­ets those vis­its under “Ses­sion Refresh”. To check URL’s lead­ing to Ses­sion Refresh pages you have a cou­ple of options:

  • Set the Mar­ket­ing Chan­nels Ses­sion Refresh rule logic dis­play value to the refer­ring domain and path. This way you will be able to see the URL vis­i­tors are com­ing from and then paste that URL in your browser
  • Run a Data Ware­house report, cre­ate a Page View seg­ment where “Last Touch Chan­nel = Ses­sion Refresh” and pull in Refer­rer and Visits

3 – Check Ses­sion Refresh refer­rers for long con­tent

Run the same report as above, but this time check the refer­ring URL’s for con­tent that could cause a ses­sion to auto­mat­i­cally time­out. For exam­ple, if a video or arti­cle on a page could cause a user to spend over 30 min­utes on one page the ses­sion for that visit will close out auto­mat­i­cally in Site­Cat­a­lyst. If a large num­ber of user expe­ri­ences are end­ing up tim­ing out due to an issue like this you may con­sider hav­ing the page (or video) peri­od­i­cally ping Site­Cat­a­lyst in order to keep the ses­sion open.

4 – Long Entry Page Load times

Long Page Load times are another issue to be aware of. For exam­ple, let’s say “Land­ing Page A” is heavy on con­tent, ban­ners and visu­als, and the Site­Cat­a­lyst code is located at the bot­tom of the page just above the clos­ing </body> tags. A Vis­i­tor starts a visit by going to Land­ing Page A, but before all the con­tent (includ­ing Site­Cat­a­lyst image request) can load the vis­i­tor has clicked on a link and nav­i­gated to another page. Now the sec­ond page loads and fires off its Site­Cat­a­lyst image request. Since the Land­ing Page image request never loaded, the sec­ond page appears as the first hit of the visit in SiteCatalyst.

Two things have hap­pened in this sce­nario, because the Land­ing Page image request never fired: 1) we lost the referrer/campaign data on the land­ing page, 2) the Sec­ond page appears as a site entry with an inter­nal URL as a referrer.

You can eas­ily test this sce­nario by hav­ing a packet snif­fer like the Debug­ger, Charles or http­Fox open while you nav­i­gate to the land­ing page. Click through to another link before the page fully exe­cutes and see if you can trig­ger the sec­ond page image request before the first has time to fire.

This sit­u­a­tion becomes an issue on por­tal pages like home pages or land­ing pages where repeat users to the site may be using the page as a gate­way to another part of the site, or on pages that are con­tent rich and still have a lot of nav­i­ga­tion links higher on the screen. To solve the prob­lem you could move the Site­Cat­a­lyst code higher on the page, or try to improve load times for the over­all page content.

5 – Redirects

Redi­rects could hap­pened when a vis­i­tor types in a van­ity URL or links to an older page. If the redi­rect is not set up to pass the refer­rer data and track­ing code through to the new land­ing page we could end up with a sce­nario sim­i­lar to the pre­vi­ous sit­u­a­tion when the true entry refer­rer data is lost and now the redi­rect page appears as the refer­ring domain. To solve this we just need to make sure our redi­rects have been set up cor­rectly in order to pass through the refer­rer and track­ing code rather than replac­ing it.

Hope­fully the 5 trouble-shooting meth­ods above help solve any doubts you may have about Ses­sion Refresh.

0 comments