Today I’m excited to write about some new stuff that is available to you now in SiteCatalyst, but first: Summit is in the air here at Adobe. (Yes, it’s like Christmas for digital marketers and analysts. At least, I think it is.) I’m working hard on my session, in which I will be sharing some tips and tricks in SiteCatalyst 15 that will save you time and help you and your colleagues derive insights from your data more easily. If you spend a lot of your day doing analytics, and especially if analytics use is on the rise in your organization and you want to help your colleagues self-serve a little better, I’ll see you in Salt Lake City for what I believe will be a very valuable hour of your time!

But Summit time does not mean that we stop releasing new functionality; actually it’s quite the opposite. In fact, tonight we had a release in which we introduced a couple of things that I am pretty excited about. So, without further ado, a few new toys for Adobe Analytics users.

Time Prior to Event and Time Spent per Visit

With this latest release of SiteCatalyst we introduced a new report called Time Prior to Event. We’ve always had the Time Spent per Visit report as a way for you to understand how user behavior correlates to the amount of time that visitors spend on your site or in your app, and this new report is similar to it, but offers an important—and valuable—new lens into the relationship between time spent and key events such as orders, leads, social shares, etc.

To put it succinctly, in the Time Spent per Visit report, all metrics are associated with the total length of the visit. In the Time Prior to Event report, all metrics are associated with the time at which they occurred during the visit. Both reports are useful windows into how customers interact with your site and perform specific actions that are key to your business, but I like the Time Prior to Event report a lot. An example will help illustrate why.

Consider the following table showing a sequence of page or app views representing a visit, along with the time spent on each page.

Time Page Event
9:00 Home Page None
9:02 Product Detail Page Product View
9:03 Add to Cart Cart Addition
9:05 Checkout None
9:08 Order Confirmation Order
9:15 Home Page None
9:27 User Login Page None
9:35 User Profile Profile Edit
End of Visit

The two reports we are discussing would handle the events that occurred in this visit differently. Remember, in the Time Spent per Visit report, all metrics are associated with the total length of the visit. In the Time Prior to Event report, all metrics are associated with the time at which they occurred during the visit. So here is what that visit would look like in the new Time Prior to Event report:

Time Prior to Event Product Views Orders Profile Edits Visits
Less than 1 minute 0 0 0 0
1-5 minutes 1 0 0 0
5-10 minutes 0 1 0 0
10-30 minutes 0 0 0 0
30-60 minutes 0 0 1 1

Notice that individual events are tied to the “bucket” of time at which they occurred. The order happened fairly quickly; this user behavior is interesting because the customer seems to have known exactly what he or she was looking for. This is a very different behavior (and perhaps a different segment) than a user who wanders around the site, performs multiple product searches, and finally checks out after 45 minutes. Here is how the visit would look in the Time Spent per Visit report, which has been part of SiteCatalyst for years:

Time Spent per Visit Product Views Orders Profile Edits Visits
Less than 1 minute 0 0 0 0
1-5 minutes 0 0 0 0
5-10 minutes 0 0 0 0
10-30 minutes 0 0 0 0
30-60 minutes 1 1 1 1

In this report, all metrics are associated with the bucket which represents the total length of the visit (30-60 minutes). This is still useful, as it helps me understand how users’ likelihood to convert in a variety of ways may vary depending on how long they spend on my site. In the Time Prior to Event report, a customer who converted within five minutes and then left my site immediately would look similar to a customer who converted within five minutes but then stuck around for another hour; in Time Spent per Visit, those users would look very different.

They’re both valuable lenses through which to view customer behavior and conversion, and hopefully you’ll find plenty of great uses for both of them.There are a few things to note about these reports:

  • Both the Time Prior to Event report and the Time Spent per Visit report will associate Visits and Unique Visitors to the total length of the visit. The way to think of this in the Time Prior to Event report is that SiteCatalyst does not consider the visit (or visitor) to be tallied until the visit concludes; therefore, those metrics will always be associated to the longest “bucket.”
  • It is possible for a visitor to appear in multiple buckets; for example, consider two visits, one which lasts 15 minutes and one which lasts 45. This would count one Visit and one Unique Visitor for both the “10-30 minutes” group and the “30-60 minutes” group.
  • Currently, only Time Spent on Page and Time Spent on Site are available as segmentation criteria in SiteCatalyst. Time Prior to Event is not yet available.

The release notes and product documentation contain additional detail on these reports, so check them out and be sure to share any questions, feedback, or success stores in the comments on this post!

The s.abort variable

A common question during my time in ClientCare (what seems like many years ago!) was, “What do I do if I want to prevent a beacon (i.e., image request) from occurring?” There are a few reasons why this might be relevant. Some companies have experienced instances where someone has copied their source HTML code, including their SiteCatalyst implementation, and deployed it somewhere else without changing references to report suite IDs, so that traffic to unrelated sites begins to pollute analytics data. Others have specific criteria for measurement and are only interested in firing off tracking code if those criteria are met (such as the presence of a certain campaign value or success event).

With the latest version of Adobe Analytics JavaScript AppMeasurement code, we have introduced a new variable called s.abort. When s.abort is set to ‘true’ (s.abort = true), the tracking beacon will not fire. This variable is designed to be implemented inside of the s.doPlugins() function, since this function is among the last to run before a beacon is fired and thus has the most information available to it regarding variables that have or have not been set, current state of the page, etc. Here is an example of a case where the company does not want to fire a beacon and count a page view if both s.campaign and are not set:

s.doPlugins = function(s) {
s.campaign = s.getQueryParam("cid");
if ((!s.campaign) && (! {
s.abort = true;

First, they attempt to set s.campaign using the “cid” query string parameter. Then, if it turns out that “cid” did not exist, and there was no value for, they set s.abort = true and this prevents the SiteCatalyst tracking code from firing. This will prevent any data from being recorded in this instance; had either of those two criteria been met, the beacon would have fired and a Page View would have been recorded.

Note that you will need to download the latest s_code.js file from the Admin Console in order to use s.abort.

Early Access to Release Notes

Have you ever wanted the Adobe Marketing Cloud release notes a.) before they are widely available within the products and b.) get a link right there in your inbox? If so, you can sign up to make those dreams a reality. The release notes are the best way to learn about all the new features, bug fixes, and product announcements that we’ve been working on. As always, you can find the release notes at any time within SiteCatalyst by going to Help > What’s New in the top nav menu.

Change to Campaign Manager

Campaign Manager is a component of SiteCatalyst which offers part of the functionality covered by SAINT; both tools allow you to apply classification metadata (such as Owner, Season, Cost, Region, etc.) to campaign measurement. However, as our usage data validates, SAINT is overwhelmingly the classification tool of choice, because allows you to perform these classifications faster and with greater efficacy. Therefore, we have decided to remove Campaign Manager from all versions of SiteCatalyst in our next release.

This has been noted in the release notes that were published with tonight’s release, and a message has been added to Campaign Manager informing users of this change. We’ve got a few phenomenal improvements planned for SAINT that will even further enhance its value, so we strongly recommend that anyone at your company who still uses Campaign Manager should migrate over to SAINT to take advantage of what it already can do, and to prepare for even more great benefits.


As always, I welcome your feedback! Please tweet at me or comment on this post if you’ve got any questions about the information I shared here. I always enjoy hearing from you. And hopefully I’ll see and meet many of you at Adobe Summit. (If you’ve got any amazing SiteCatalyst 15 tips that you’d like to volunteer for inclusion in my session, please send them my way!) I’m very excited about the things we’re preparing to share with you related to analytics and more in Salt Lake City in March, so if you haven’t signed up to attend, get started on that now. Having seen the quality of my colleagues’ presentation content for this year’s event first-hand, I can tell you that you definitely won’t be sorry.