Today I’m excited to write about some new stuff that is avail­able to you now in Site­Cat­a­lyst, but first: Sum­mit is in the air here at Adobe. (Yes, it’s like Christ­mas for dig­i­tal mar­keters and ana­lysts. At least, I think it is.) I’m work­ing hard on my ses­sion, in which I will be shar­ing some tips and tricks in Site­Cat­a­lyst 15 that will save you time and help you and your col­leagues derive insights from your data more eas­ily. If you spend a lot of your day doing ana­lyt­ics, and espe­cially if ana­lyt­ics use is on the rise in your orga­ni­za­tion and you want to help your col­leagues self-serve a lit­tle bet­ter, I’ll see you in Salt Lake City for what I believe will be a very valu­able hour of your time!

But Sum­mit time does not mean that we stop releas­ing new func­tion­al­ity; actu­ally it’s quite the oppo­site. In fact, tonight we had a release in which we intro­duced a cou­ple of things that I am pretty excited about. So, with­out fur­ther ado, a few new toys for Adobe Ana­lyt­ics users.

Time Prior to Event and Time Spent per Visit

With this lat­est release of Site­Cat­a­lyst we intro­duced a new report called Time Prior to Event. We’ve always had the Time Spent per Visit report as a way for you to under­stand how user behav­ior cor­re­lates to the amount of time that vis­i­tors spend on your site or in your app, and this new report is sim­i­lar to it, but offers an important—and valuable—new lens into the rela­tion­ship between time spent and key events such as orders, leads, social shares, etc.

To put it suc­cinctly, in the Time Spent per Visit report, all met­rics are asso­ci­ated with the total length of the visit. In the Time Prior to Event report, all met­rics are asso­ci­ated with the time at which they occurred dur­ing the visit. Both reports are use­ful win­dows into how cus­tomers inter­act with your site and per­form spe­cific actions that are key to your busi­ness, but I like the Time Prior to Event report a lot. An exam­ple will help illus­trate why.

Con­sider the fol­low­ing table show­ing a sequence of page or app views rep­re­sent­ing a visit, along with the time spent on each page.

Time Page Event
9:00 Home Page None
9:02 Prod­uct Detail Page Prod­uct View
9:03 Add to Cart Cart Addi­tion
9:05 Check­out None
9:08 Order Con­fir­ma­tion Order
9:15 Home Page None
9:27 User Login Page None
9:35 User Pro­file Pro­file Edit
End of Visit

The two reports we are dis­cussing would han­dle the events that occurred in this visit dif­fer­ently. Remem­ber, in the Time Spent per Visit report, all met­rics are asso­ci­ated with the total length of the visit. In the Time Prior to Event report, all met­rics are asso­ci­ated with the time at which they occurred dur­ing the visit. So here is what that visit would look like in the new Time Prior to Event report:

Time Prior to Event Prod­uct Views Orders Pro­file Edits Vis­its
Less than 1 minute 0 0 0 0
1–5 min­utes 1 0 0 0
5–10 min­utes 0 1 0 0
10–30 min­utes 0 0 0 0
30–60 min­utes 0 0 1 1

Notice that indi­vid­ual events are tied to the “bucket” of time at which they occurred. The order hap­pened fairly quickly; this user behav­ior is inter­est­ing because the cus­tomer seems to have known exactly what he or she was look­ing for. This is a very dif­fer­ent behav­ior (and per­haps a dif­fer­ent seg­ment) than a user who wan­ders around the site, per­forms mul­ti­ple prod­uct searches, and finally checks out after 45 min­utes. Here is how the visit would look in the Time Spent per Visit report, which has been part of Site­Cat­a­lyst for years:

Time Spent per Visit Prod­uct Views Orders Pro­file Edits Vis­its
Less than 1 minute 0 0 0 0
1–5 min­utes 0 0 0 0
5–10 min­utes 0 0 0 0
10–30 min­utes 0 0 0 0
30–60 min­utes 1 1 1 1

In this report, all met­rics are asso­ci­ated with the bucket which rep­re­sents the total length of the visit (30−60 min­utes). This is still use­ful, as it helps me under­stand how users’ like­li­hood to con­vert in a vari­ety of ways may vary depend­ing on how long they spend on my site. In the Time Prior to Event report, a cus­tomer who con­verted within five min­utes and then left my site imme­di­ately would look sim­i­lar to a cus­tomer who con­verted within five min­utes but then stuck around for another hour; in Time Spent per Visit, those users would look very different.

They’re both valu­able lenses through which to view cus­tomer behav­ior and con­ver­sion, and hope­fully 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 asso­ciate Vis­its and Unique Vis­i­tors to the total length of the visit. The way to think of this in the Time Prior to Event report is that Site­Cat­a­lyst does not con­sider the visit (or vis­i­tor) to be tal­lied until the visit con­cludes; there­fore, those met­rics will always be asso­ci­ated to the longest “bucket.”
  • It is pos­si­ble for a vis­i­tor to appear in mul­ti­ple buck­ets; for exam­ple, con­sider two vis­its, one which lasts 15 min­utes and one which lasts 45. This would count one Visit and one Unique Vis­i­tor for both the “10−30 min­utes” group and the “30−60 min­utes” group.
  • Cur­rently, only Time Spent on Page and Time Spent on Site are avail­able as seg­men­ta­tion cri­te­ria in Site­Cat­a­lyst. Time Prior to Event is not yet available.

The release notes and prod­uct doc­u­men­ta­tion con­tain addi­tional detail on these reports, so check them out and be sure to share any ques­tions, feed­back, or suc­cess stores in the com­ments on this post!

The s.abort variable

A com­mon ques­tion dur­ing my time in Client­Care (what seems like many years ago!) was, “What do I do if I want to pre­vent a bea­con (i.e., image request) from occur­ring?” There are a few rea­sons why this might be rel­e­vant. Some com­pa­nies have expe­ri­enced instances where some­one has copied their source HTML code, includ­ing their Site­Cat­a­lyst imple­men­ta­tion, and deployed it some­where else with­out chang­ing ref­er­ences to report suite IDs, so that traf­fic to unre­lated sites begins to pol­lute ana­lyt­ics data. Oth­ers have spe­cific cri­te­ria for mea­sure­ment and are only inter­ested in fir­ing off track­ing code if those cri­te­ria are met (such as the pres­ence of a cer­tain cam­paign value or suc­cess event).

With the lat­est ver­sion of Adobe Ana­lyt­ics JavaScript App­Mea­sure­ment code, we have intro­duced a new vari­able called s.abort. When s.abort is set to ‘true’ (s.abort = true), the track­ing bea­con will not fire. This vari­able is designed to be imple­mented inside of the s.doPlugins() func­tion, since this func­tion is among the last to run before a bea­con is fired and thus has the most infor­ma­tion avail­able to it regard­ing vari­ables that have or have not been set, cur­rent state of the page, etc. Here is an exam­ple of a case where the com­pany does not want to fire a bea­con and count a page view if both s.campaign and s.events are not set:

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

First, they attempt to set s.campaign using the “cid” query string para­me­ter. Then, if it turns out that “cid” did not exist, and there was no value for s.events, they set s.abort = true and this pre­vents the Site­Cat­a­lyst track­ing code from fir­ing. This will pre­vent any data from being recorded in this instance; had either of those two cri­te­ria been met, the bea­con would have fired and a Page View would have been recorded.

Note that you will need to down­load the lat­est s_code.js file from the Admin Con­sole in order to use s.abort.

Early Access to Release Notes

Have you ever wanted the Adobe Mar­ket­ing Cloud release notes a.) before they are widely avail­able within the prod­ucts and b.) get a link right there in your inbox? If so, you can sign up to make those dreams a real­ity. The release notes are the best way to learn about all the new fea­tures, bug fixes, and prod­uct announce­ments that we’ve been work­ing on. As always, you can find the release notes at any time within Site­Cat­a­lyst by going to Help > What’s New in the top nav menu.

Change to Cam­paign Manager

Cam­paign Man­ager is a com­po­nent of Site­Cat­a­lyst which offers part of the func­tion­al­ity cov­ered by SAINT; both tools allow you to apply clas­si­fi­ca­tion meta­data (such as Owner, Sea­son, Cost, Region, etc.) to cam­paign mea­sure­ment. How­ever, as our usage data val­i­dates, SAINT is over­whelm­ingly the clas­si­fi­ca­tion tool of choice, because allows you to per­form these clas­si­fi­ca­tions faster and with greater effi­cacy. There­fore, we have decided to remove Cam­paign Man­ager from all ver­sions of Site­Cat­a­lyst in our next release.

This has been noted in the release notes that were pub­lished with tonight’s release, and a mes­sage has been added to Cam­paign Man­ager inform­ing users of this change. We’ve got a few phe­nom­e­nal improve­ments planned for SAINT that will even fur­ther enhance its value, so we strongly rec­om­mend that any­one at your com­pany who still uses Cam­paign Man­ager should migrate over to SAINT to take advan­tage of what it already can do, and to pre­pare for even more great benefits.

Con­clu­sion

As always, I wel­come your feed­back! Please tweet at me or com­ment on this post if you’ve got any ques­tions about the infor­ma­tion I shared here. I always enjoy hear­ing from you. And hope­fully I’ll see and meet many of you at Adobe Sum­mit. (If you’ve got any amaz­ing Site­Cat­a­lyst 15 tips that you’d like to vol­un­teer for inclu­sion in my ses­sion, please send them my way!) I’m very excited about the things we’re prepar­ing to share with you related to ana­lyt­ics and more in Salt Lake City in March, so if you haven’t signed up to attend, get started on that now. Hav­ing seen the qual­ity of my col­leagues’ pre­sen­ta­tion con­tent for this year’s event first-hand, I can tell you that you def­i­nitely won’t be sorry.

0 comments