If you use Site­Cat­a­lyst 15 reg­u­larly, you may have noticed when you logged in for the first time on July 20 that we did another prod­uct update in the late after­noon MDT on July 19. This intro­duced a num­ber of bug fixes as well as some new functionality—and also some old func­tion­al­ity that we’re brought back by pop­u­lar request. In this post I will briefly intro­duce some (but not all) of the changes that we made. You’ll see more on these fea­tures in sub­se­quent posts on this blog and else­where. As always, if you have any ques­tions feel free to leave me a com­ment or hit me up on Twit­ter (@benjamingaines)!


The long-awaited day is here! Rollup report suites are sup­ported in Site­Cat­a­lyst 15. In case you don’t remem­ber rollup suites, or never used them, they are a spe­cial kind of report suite that aggre­gates data from other report suites into one place. Let’s say you have a bunch of web sites and/or mobile apps, and you want to be able to report on them sep­a­rately as well as com­bined into one. There are a cou­ple of ways to do this, and one of those ways is by set­ting up a rollup report suite which will add up the data from your indi­vid­ual sites/apps so you can report on them all in one place.

To add a rollup suite, go to Admin > Report Suites. On the left, under Report Suite Groups, find “Rollups” and click Add.

add a rollup suite in SiteCatalyst 15

The Admin Con­sole will guide you through the setup of your new rollup suite. You can add addi­tional suites to your rollup by drag­ging them from the list on the right and drop­ping them on the desired rollup.

NOTE: If you plan to add more than 50 report suites to a rollup, we request that you con­tact your Account Man­ager or Client­Care so that we can man­age the enabled data tables for that rollup more effec­tively. This will help ensure that rollups receive data con­sis­tently and do not fall behind on their daily import.

I am not going to go into a length dis­course on the ben­e­fits of rollup suites ver­sus global suites, but I will say that there are a few lim­i­ta­tions to rollup suites. Since this is the first time they have been avail­able in Site­Cat­a­lyst 15, it is impor­tant to note that seg­men­ta­tion is not an option within rollup suites. Rollup suites receive data once per day, in the wee hours of the morn­ing, so they are good for his­tor­i­cal report­ing and analy­sis but not same-day work. Also, not all reports will be avail­able in a rollup suite, but most stan­dard reports are, and depend­ing on the num­ber of “child suites” you want to add to your rollup, Client­Care may be able to help you enable addi­tional reports based on your needs.

Mobile Car­rier report

We added a brand-new report to Site­Cat­a­lyst 15 last night: Mobile Car­rier. It lives in Vis­i­tor Pro­file > Tech­nol­ogy by default, and reports on the mobile provider that your visitors/customers use to access your site or app.

mobile carrier report in SiteCatalyst 15

Con­nec­tion Type report

This one isn’t a new report, but it’s newly use­ful. Vis­i­tor Pro­file > Tech­nol­ogy > Con­nec­tion Type has been around for a while, but it has been updated to reflect the way peo­ple con­nect to the Inter­net in 2012. Most impor­tantly, a “Mobile Car­rier” cat­e­gory has been added. While some browsers still do not sup­ply Site­Cat­a­lyst with con­nec­tion data, this report does now give you insight to answer ques­tions such as, “Do the users of my app typ­i­cally con­nect via Wifi, or via 3G/4G?”

connection types report in SiteCatalyst 15

App­Mea­sure­ment update

Ver­sion H.25 of our JavaScript data col­lec­tion code came out last night. Here is ana­lyt­ics plat­form Prod­uct Man­ager Bret Gun­der­sen with an update and explanation.

The browser war cre­ates a con­stantly fluc­tu­at­ing play­ing field for page tags. Some of you have noticed that WebKit-based browsers do not con­sis­tently send data on link clicks. Once a vis­i­tor clicks on a link, the browser’s goal is to nav­i­gate there as quickly as pos­si­ble, regard­less of what images have yet to down­load on the cur­rent page. In many cases, this leaves ana­lyt­ics data unrecorded.

After con­sult­ing with both Chrome and Safari engi­neers about the best solu­tion to this prob­lem, we have released App­Mea­sure­ment for JavaScript, ver­sion H.25. This ver­sion forces WebKit-based browsers to nav­i­gate after data is sent to Site­Cat­a­lyst, or after a time­out is reached (250 ms default). Exit Link track­ing will auto­mat­i­cally use the new func­tion­al­ity, but cus­tom link track­ing requires a change to your onClick code, show­ing in red below.

<a href="http://anothersite.com" onclick="s.tl(this,'e','AnotherSite',null,'navigate');return false">

The return false state­ment tells the browser to can­cel the nav­i­ga­tion. If you return false and do noth­ing else, the link will do noth­ing (not good).

The ‘nav­i­gate’ string instructs tl()what to do after data has been sent or the time­out is reached. If you pass ‘nav­i­gate’ into this para­me­ter, as shown, the JS file will set document.location to the href attribute of the object passed in the first para­me­ter (the link). Alter­na­tively, you can pass a func­tion as the fourth para­me­ter. That func­tion would need to per­form the nav­i­ga­tion for you once the ana­lyt­ics data has been sent.

Note that this onClick code change is ONLY nec­es­sary for links that nav­i­gate away from the page. For any calls to tl() that aren’t tied to load­ing a new page (like AJAX inter­ac­tions or down­load links) you don’t need to change the onClick code.

More details are avail­able in the Site­Cat­a­lyst Imple­men­ta­tion Guide, sec­tion 8.2.

Improved IE Com­pat­i­bil­ity Mode reporting

In the past, Site­Cat­a­lyst has had a hard time telling whether a user was brows­ing using IE 8 or IE 9 if Com­pat­i­bil­ity Mode was enabled. This fea­ture in recent ver­sions of IE caused it to report itself to Site­Cat­a­lyst as IE 7. This made IE 7 appear to be a larger per­cent­age of traf­fic than it really was.

With the most recent release, Site­Cat­a­lyst cor­rectly iden­ti­fies IE 9 as IE 9, and IE 8 and IE 8, even if Com­pat­i­bil­ity Mode is turned on. Gen­er­ally, this is good news; it makes the Browsers report more accu­rate and gives you a more real­is­tic sense of how browser trends are chang­ing on your site. How­ever, it is impor­tant to note, as stated in the release notes, that “after this change, you will likely see a sig­nif­i­cant drop in IE 7 traf­fic. IE 7 traf­fic could drop as much as 70%, depend­ing on how many users are in com­pat­i­bil­ity mode, with a cor­re­spond­ing increase in IE8 and IE9 traffic.”