Time for another installment of OmnitureCare mailbag, where I answer real user questions that weren’t quite long enough to justify their own blog post, but that I think might be helpful to many of you.

On a personal note, I’m busy preparing for Omniture Summit 2010 along with the team I’ve assembled to speak on advanced SiteCatalyst strategies that can help you better optimize your site(s); you can read about it on my Summit 2010 blog. Summit is probably my favorite week of the entire year. Let’s review some of my top 10 personal highlights from the 2009 edition:

  1. Omniture University training the day before the event.
  2. Met face-to-face a ton of people in the user community whom I had already gotten to know via Twitter.
  3. Soaked up knowledge from a great selection of keynote speakers and breakout presenters. Learned more about online marketing than I could have in a dozen semesters of my MBA program.
  4. Began to really figure out this social media thing, thanks in large part to trailblazers Jeremiah 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 mention the people? Oh, wait, I did.
  9. Brett Error’s feedback session ultimately (albeit indirectly) led to the creation of this blog.
  10. This photo. That’s Glen “Big Baby” (err, I mean “Uno Uno”) Davis’ NBA championship ring. Am I wearing it? Yup, I am. (Granted, that probably won’t happen this year at Summit—the Utah Jazz are on the road that week—but who knows what else might? Did I embarrass myself by asking Davis whether Kevin Garnett had “mellowed out” since winning a title, only six weeks after this happened, because I hadn’t seen it on SportsCenter? Yes I did.

Anyway, I’m hoping to see many of you there! But enough about me. On to your questions.

Q: How can I tell whether my application will generate server calls or consume API tokens (or both)?

BG: As a general rule, if your application pushes data into SiteCatalyst, it will generate server calls. If your application retrieves data, manages your account, or does anything other than collect data, it will consume API tokens.

Consider the Data Insertion API. It is used as an alternative to JavaScript for data collection, and therefore each post to Omniture’s servers constitutes a server call, and not an API token. You might then use the SAINT API to classify that existing data, but since SAINT classifications are metadata and not actually new data from your web site, no server calls are accumulated through use of this API. Rather, the SAINT API consumes tokens.

Q: My videos are page-agnostic and can play nearly anywhere on my site. How can I see which pages played certain videos?

BG: You can set up a correlation between Video and any traffic property using the Admin Console. This will allow you to break down the video name by a variety of data points. One of the options here is Page Name, but be careful: page name data is not recorded on media image requests. So, just as a correlation between Custom Links and Page Name doesn’t yield data, a correlation 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 Custom Traffic (s.prop) variable with the page name. Then correlate Video with that Custom Traffic variable 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 version (which can also be passed into an s.prop variable).

Q: How can I hide a “base” report from my users while leaving the classification reports based on it available?

BG: In some cases, you might want to hide the report on which your classifications are based, while leaving the classification reports visible. For example, let’s say you wanted to avoid confusion by hiding the Tracking Code report, but you needed the user-friendly Campaigns report to be visible. What would you do? The Admin Console allows you to rearrange, rename, and hide reports on the left nav menu in SiteCatalyst. However, hiding the “base” report also hides any classification reports that build on it.

If you’ve run up against this before, here is your workaround: set up a custom report based on each of the classification reports. You don’t need to customize these custom reports heavily (although doing so might make life easier for your users in many cases!); the idea is just to bring them into existence. Once you’ve got them all set up and saved, go ahead and hide that Tracking Code report. Your users will be able to access whatever classification-based data they need using the new custom reports.

Adam Greco provided 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 currently limits your ability to perform correlations and subrelations.

Q: Sometimes I need to know which eVar corresponds to the report I’m looking at, and going to the Admin Console every time is annoying. Isn’t there an easier way to quickly check which eVar is behind the report?

BG: Absolutely there is; at least in SiteCatalyst 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=” parameter. It will contain a value followed by a pipe character and then a number. The number corresponds to the variable behind the report. For Custom Conversion reports, this number begins with 101 for eVar1 and runs up through 150 for eVar50. For Custom Traffic reports, the number begins with 3 for Custom Traffic 1 and continues up through 52 for Custom Traffic 50. Hopefully this will save some of you some time.

NOTE: SiteCatalyst relies on URL query parameters to know exactly what data to return. While you can, in some cases, change the number in this query parameter to switch reports, changing to values outside of the ranges described above will return invalid reports, or nothing at all.

Of course, you could make this even easier by appending the variable name to the end of the report name (e.g., “Internal Search Terms [eVar6]”), but that’s your call. You might not like that option because it may lead to questions from other users at your company about these strange values in the report names.

Q: I don’t really care about capturing the browser plug-ins (in the “p=” parameter) that users have installed, and it’s making my image requests too long. How can I keep the SiteCatalyst code from grabbing this information without altering the base code?

BG: Special thanks to Andreas Dierl (@ad0815) for alerting me to this one; somewhat embarrassingly, the ability to prevent the capture of plug-in data (available in the Visitor Profile > Technology > 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, simply place the following code within the s_doPlugins() function:

s.plugins=""

(NOTE: It must be in s_doPlugins(); it cannot be set on the page.) And you can do the same thing for any of the following variables belonging to the Visitor Profile > Techology area in SiteCatalyst: 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 cannot really repurpose these variables as new Custom Traffic reports and set your own values into them; they all have a very specific data type, and do not accept arbitrary values like Custom Traffic reports do.

So there you have it; a few good questions and (I hope) answers that will help you out in your analytics efforts. As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter or LinkedIn, or by e-mailing omniture care [at] adobe dot com.

1 comments
Jason
Jason

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.