Time for another install­ment of Omni­ture­Care mail­bag, where I answer real user ques­tions that weren’t quite long enough to jus­tify their own blog post, but that I think might be help­ful to many of you.

On a per­sonal note, I’m busy prepar­ing for Omni­ture Sum­mit 2010 along with the team I’ve assem­bled to speak on advanced Site­Cat­a­lyst strate­gies that can help you bet­ter opti­mize your site(s); you can read about it on my Sum­mit 2010 blog. Sum­mit is prob­a­bly my favorite week of the entire year. Let’s review some of my top 10 per­sonal high­lights from the 2009 edition:

  1. Omni­ture Uni­ver­sity train­ing the day before the event.
  2. Met face-to-face a ton of peo­ple in the user com­mu­nity whom I had already got­ten to know via Twitter.
  3. Soaked up knowl­edge from a great selec­tion of keynote speak­ers and break­out pre­sen­ters. Learned more about online mar­ket­ing than I could have in a dozen semes­ters of my MBA program.
  4. Began to really fig­ure out this social media thing, thanks in large part to trail­blaz­ers Jere­miah Owyang and Frank Eliason.
  5. This video.
  6. Also this one.
  7. Good food is one of my favorite things. So are hotels, come to think of it.
  8. Did I men­tion the peo­ple? Oh, wait, I did.
  9. Brett Error’s feed­back ses­sion ulti­mately (albeit indi­rectly) led to the cre­ation of this blog.
  10. This photo. That’s Glen “Big Baby” (err, I mean “Uno Uno”) Davis’ NBA cham­pi­onship ring. Am I wear­ing it? Yup, I am. (Granted, that prob­a­bly won’t hap­pen this year at Summit—the Utah Jazz are on the road that week—but who knows what else might? Did I embar­rass myself by ask­ing Davis whether Kevin Gar­nett had “mel­lowed out” since win­ning a title, only six weeks after this hap­pened, because I hadn’t seen it on Sports­Cen­ter? Yes I did.

Any­way, I’m hop­ing to see many of you there! But enough about me. On to your questions.

Q: How can I tell whether my appli­ca­tion will gen­er­ate server calls or con­sume API tokens (or both)?

BG: As a gen­eral rule, if your appli­ca­tion pushes data into Site­Cat­a­lyst, it will gen­er­ate server calls. If your appli­ca­tion retrieves data, man­ages your account, or does any­thing other than col­lect data, it will con­sume API tokens.

Con­sider the Data Inser­tion API. It is used as an alter­na­tive to JavaScript for data col­lec­tion, and there­fore each post to Omniture’s servers con­sti­tutes a server call, and not an API token. You might then use the SAINT API to clas­sify that exist­ing data, but since SAINT clas­si­fi­ca­tions are meta­data and not actu­ally new data from your web site, no server calls are accu­mu­lated through use of this API. Rather, the SAINT API con­sumes tokens.

Q: My videos are page-agnostic and can play nearly any­where on my site. How can I see which pages played cer­tain videos?

BG: You can set up a cor­re­la­tion between Video and any traf­fic prop­erty using the Admin Con­sole. This will allow you to break down the video name by a vari­ety of data points. One of the options here is Page Name, but be care­ful: page name data is not recorded on media image requests. So, just as a cor­re­la­tion between Cus­tom Links and Page Name doesn’t yield data, a cor­re­la­tion between Video and Page Name may leave you wanting.

But don’t fret; there’s an easy way to get the data that you need. On your media requests, set a Cus­tom Traf­fic (s.prop) vari­able with the page name. Then cor­re­late Video with that Cus­tom Traf­fic vari­able rather than with Page Name. This also works nicely for data points other than page name, such as if you want to see things like video by Flash ver­sion (which can also be passed into an s.prop variable).

Q: How can I hide a “base” report from my users while leav­ing the clas­si­fi­ca­tion reports based on it available?

BG: In some cases, you might want to hide the report on which your clas­si­fi­ca­tions are based, while leav­ing the clas­si­fi­ca­tion reports vis­i­ble. For exam­ple, let’s say you wanted to avoid con­fu­sion by hid­ing the Track­ing Code report, but you needed the user-friendly Cam­paigns report to be vis­i­ble. What would you do? The Admin Con­sole allows you to rearrange, rename, and hide reports on the left nav menu in Site­Cat­a­lyst. How­ever, hid­ing the “base” report also hides any clas­si­fi­ca­tion reports that build on it.

If you’ve run up against this before, here is your workaround: set up a cus­tom report based on each of the clas­si­fi­ca­tion reports. You don’t need to cus­tomize these cus­tom reports heav­ily (although doing so might make life eas­ier for your users in many cases!); the idea is just to bring them into exis­tence. Once you’ve got them all set up and saved, go ahead and hide that Track­ing Code report. Your users will be able to access what­ever classification-based data they need using the new cus­tom reports.

Adam Greco pro­vided more detail on this <a href=“http://www.the-omni-man.com/sitecatalyst/adamgreco/2009/10/12/feature-request-classifications-menu-customizer/” target=“_blank”>here</a>. Note that doing this cur­rently lim­its your abil­ity to per­form cor­re­la­tions and subrelations.

Q: Some­times I need to know which eVar cor­re­sponds to the report I’m look­ing at, and going to the Admin Con­sole every time is annoy­ing. Isn’t there an eas­ier way to quickly check which eVar is behind the report?

BG: Absolutely there is; at least in Site­Cat­a­lyst v14, the secret is in the URL of the report. When the report loads, check the query string in your browser address bar for an “rp=” para­me­ter. It will con­tain a value fol­lowed by a pipe char­ac­ter and then a num­ber. The num­ber cor­re­sponds to the vari­able behind the report. For Cus­tom Con­ver­sion reports, this num­ber begins with 101 for eVar1 and runs up through 150 for eVar50. For Cus­tom Traf­fic reports, the num­ber begins with 3 for Cus­tom Traf­fic 1 and con­tin­ues up through 52 for Cus­tom Traf­fic 50. Hope­fully this will save some of you some time.

NOTE: Site­Cat­a­lyst relies on URL query para­me­ters to know exactly what data to return. While you can, in some cases, change the num­ber in this query para­me­ter to switch reports, chang­ing to val­ues out­side of the ranges described above will return invalid reports, or noth­ing at all.

Of course, you could make this even eas­ier by append­ing the vari­able name to the end of the report name (e.g., “Inter­nal Search Terms [eVar6]”), but that’s your call. You might not like that option because it may lead to ques­tions from other users at your com­pany about these strange val­ues in the report names.

Q: I don’t really care about cap­tur­ing the browser plug-ins (in the “p=” para­me­ter) that users have installed, and it’s mak­ing my image requests too long. How can I keep the Site­Cat­a­lyst code from grab­bing this infor­ma­tion with­out alter­ing the base code?

BG: Spe­cial thanks to Andreas Dierl (@ad0815) for alert­ing me to this one; some­what embar­rass­ingly, the abil­ity to pre­vent the cap­ture of plug-in data (avail­able in the Vis­i­tor Pro­file > Tech­nol­ogy > Netscape Plug-ins report) has been around for more than two years, ever since the release of H.11 JavaScript code. If you are using H.11 code or newer on your site, and want to kill this data, sim­ply place the fol­low­ing code within the s_doPlugins() function:


(NOTE: It must be in s_doPlugins(); it can­not be set on the page.) And you can do the same thing for any of the fol­low­ing vari­ables belong­ing to the Vis­i­tor Pro­file > Techol­ogy area in Site­Cat­a­lyst: s.resolution, s.colorDepth, s.javascriptVersion, s.javaEnabled, s.cookiesEnabled, s.browserWidth, s.browserHeight, s.connectionType, s.homepage.

Before you ask, the answer is no, you can­not really repur­pose these vari­ables as new Cus­tom Traf­fic reports and set your own val­ues into them; they all have a very spe­cific data type, and do not accept arbi­trary val­ues like Cus­tom Traf­fic reports do.

So there you have it; a few good ques­tions and (I hope) answers that will help you out in your ana­lyt­ics efforts. As always, please leave a com­ment with any ques­tions, thoughts, or sug­ges­tions that you may have! I’m also avail­able Twit­ter or LinkedIn, or by e-mailing omni­ture care [at] adobe dot com.


I've appended the variable name to each of my variables. It may not look as clean but it has saved a ton of headache. I found myself getting tired of looking up the mapping in the admin tool and answering calls from development and QA about what variable name mapped to what omniture variable.