If you use SiteCatalyst 15 regularly, you may have noticed when you logged in for the first time on July 20 that we did another product update in the late afternoon MDT on July 19. This introduced a number of bug fixes as well as some new functionality—and also some old functionality that we’re brought back by popular request. In this post I will briefly introduce some (but not all) of the changes that we made. You’ll see more on these features in subsequent posts on this blog and elsewhere. As always, if you have any questions feel free to leave me a comment or hit me up on Twitter (@benjamingaines)!


The long-awaited day is here! Rollup report suites are supported in SiteCatalyst 15. In case you don’t remember rollup suites, or never used them, they are a special kind of report suite that aggregates 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 separately as well as combined into one. There are a couple of ways to do this, and one of those ways is by setting up a rollup report suite which will add up the data from your individual 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 Console will guide you through the setup of your new rollup suite. You can add additional suites to your rollup by dragging them from the list on the right and dropping them on the desired rollup.

NOTE: If you plan to add more than 50 report suites to a rollup, we request that you contact your Account Manager or ClientCare so that we can manage the enabled data tables for that rollup more effectively. This will help ensure that rollups receive data consistently and do not fall behind on their daily import.

I am not going to go into a length discourse on the benefits of rollup suites versus global suites, but I will say that there are a few limitations to rollup suites. Since this is the first time they have been available in SiteCatalyst 15, it is important to note that segmentation is not an option within rollup suites. Rollup suites receive data once per day, in the wee hours of the morning, so they are good for historical reporting and analysis but not same-day work. Also, not all reports will be available in a rollup suite, but most standard reports are, and depending on the number of “child suites” you want to add to your rollup, ClientCare may be able to help you enable additional reports based on your needs.

Mobile Carrier report

We added a brand-new report to SiteCatalyst 15 last night: Mobile Carrier. It lives in Visitor Profile > Technology 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

Connection Type report

This one isn’t a new report, but it’s newly useful. Visitor Profile > Technology > Connection Type has been around for a while, but it has been updated to reflect the way people connect to the Internet in 2012. Most importantly, a “Mobile Carrier” category has been added. While some browsers still do not supply SiteCatalyst with connection data, this report does now give you insight to answer questions such as, “Do the users of my app typically connect via Wifi, or via 3G/4G?”

connection types report in SiteCatalyst 15

AppMeasurement update

Version H.25 of our JavaScript data collection code came out last night. Here is analytics platform Product Manager Bret Gundersen with an update and explanation.

The browser war creates a constantly fluctuating playing field for page tags. Some of you have noticed that WebKit-based browsers do not consistently send data on link clicks. Once a visitor clicks on a link, the browser’s goal is to navigate there as quickly as possible, regardless of what images have yet to download on the current page. In many cases, this leaves analytics data unrecorded.

After consulting with both Chrome and Safari engineers about the best solution to this problem, we have released AppMeasurement for JavaScript, version H.25. This version forces WebKit-based browsers to navigate after data is sent to SiteCatalyst, or after a timeout is reached (250 ms default). Exit Link tracking will automatically use the new functionality, but custom link tracking requires a change to your onClick code, showing in red below.

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

The return false statement tells the browser to cancel the navigation. If you return false and do nothing else, the link will do nothing (not good).

The ‘navigate’ string instructs tl()what to do after data has been sent or the timeout is reached. If you pass ‘navigate’ into this parameter, as shown, the JS file will set document.location to the href attribute of the object passed in the first parameter (the link). Alternatively, you can pass a function as the fourth parameter. That function would need to perform the navigation for you once the analytics data has been sent.

Note that this onClick code change is ONLY necessary for links that navigate away from the page. For any calls to tl() that aren’t tied to loading a new page (like AJAX interactions or download links) you don’t need to change the onClick code.

More details are available in the SiteCatalyst Implementation Guide, section 8.2.

Improved IE Compatibility Mode reporting

In the past, SiteCatalyst has had a hard time telling whether a user was browsing using IE 8 or IE 9 if Compatibility Mode was enabled. This feature in recent versions of IE caused it to report itself to SiteCatalyst as IE 7. This made IE 7 appear to be a larger percentage of traffic than it really was.

With the most recent release, SiteCatalyst correctly identifies IE 9 as IE 9, and IE 8 and IE 8, even if Compatibility Mode is turned on. Generally, this is good news; it makes the Browsers report more accurate and gives you a more realistic sense of how browser trends are changing on your site. However, it is important to note, as stated in the release notes, that “after this change, you will likely see a significant drop in IE 7 traffic. IE 7 traffic could drop as much as 70%, depending on how many users are in compatibility mode, with a corresponding increase in IE8 and IE9 traffic.”


Re: compatibility mode... is there any way to get at that information? or is it lost?