Omniture SiteCatalyst 15: Context Variables & Processing Rules

A big deal was made at the Omniture Summit of the segmentation available in SiteCatalyst 15. While the advantage of this feature is obviosu to everyone, I do not consider this to be the most significant part of the upgrade of SiteCatalyst to version 15. I consider the greatest new feature of SiteCatalyst 15 to be two things, that when put together, could change how every implementation of SiteCatalyst is undertaken and managed on a regular basis. These two things are context variables and processing rules. Below, I will detail what context variables and the processing rules are, and then discuss how they can be used in conjuction to streamline a SiteCatlayst implementation.

Context Variables:

Those familiar with SiteCatalyst are aware of what events, props and eVars are. With the release of SiteCatalyst 15, there is a new type of variable, the context variable. Here’s what you need to know about context variables in general:

  1. There are an unlimited number of context variables
  2. There is no character limits on what you can place in a context variable
  3. You can name a context variable with any name you prefer (meaning that developers don’t need to worry about eVarX, propX, etc.)

To detail how a company might use a context variable, I will provide a code example of custom download measurement via traditional SiteCatalyst variables vs. context variables. The goal here is to track the name of the download, the URL of the download and a success event for the download.

Site Catalyst 14 and Prior (assume eVar1 and eVar2 are set by the implementation):

s.eVar1="download name"
if (s.eVar1){
s.prop1=”D=v1″
s.events=s.apl(s.events,’event1′,’,’,2)
}

s.eVar2="Download URL"
if (s.eVar2){
s.prop2="D=v2"
}

SiteCatalyst 15:

s.contextData['Download Name']="download name";
s.contextData['Download URL']="download url";

That’s it!

SiteCatalyst 15’s solution is a little simpler (at least in terms of coding), huh?! What makes this great is that giving direction to your developer for implementation is extremly straight forward, and anyone looking at these varibles in the code, should be able to easily determine what’s gonig on. Keep in mind that you can make the names of the context variables anything you like. So now that these context variables are in place, the developers are no longer needed in the implementation of SiteCatalyst (for downloads anyway!).

Next, Processing Rules will bridge the gap between the context variables and SiteCatalyst reporting. So below we will continue discussing the implementation of download measurement while using the context varialbes above with the new processing rules.

Processing Rules:

Many may be famailar with Omniture’s Marketing Channel Report and the processing rules that go along with that great feature (if not you should be!). Now, Omniture customers can create processing rules in a similar way that will allow them to set events and variables (as well as more advanced options) based on simple or complex rule sets. To demonstrate how this is done, we will assume that our developers have implemented the two “download” context variables above.

Now you can login to the admin console of SiteCatalyst and setup two easy rules:

  1. If “contextData[“Download Name”]” is set at anytime, move that value to eVar1 and prop1 as well as set event1
  2. If “contextData[“Download URL”]” is set at anytime, move that value to eVar2 and prop2

That’s all you have to do to implement custom download measurement once your context variables are in place.

Context Variable and Processing Rule Caveats:

This could warrant an entire other blog post, but here’s a brief summary of a few caveats of which to be aware when using context variables and processing rules:

  1. You will have to upgrade to the H23 version of the s_code (i.e. Omniture data collection code) in order to leverage context variables.
  2. While context variables can be unlimited in length, you will still need to be aware of the total 2080 character limite in Internet Explorer. Also, the props and eVars within the reporting itself still have their limits. The advantage of the unlimited length is that you could create a processing rule to evaluate the entire context variable’s value. Ex: if a campaign code contains “google” then set eVar3 as “Paid Search.”
  3. Don’t get your hopes up for SAINT here, the processing rules will not populate SAINT classifications.
  4. Context variables are not stored. Once they are captured and used in any processing rules, they are not maintained by Omniture. So, any processing rule (as should be expected) would not work on old context or other data.
  5. Obviously, the improper setup of a processing rule could compromise an entire SiteCatalyst implementation since processing rules are essentially a “VISTA Lite.”
  6. Debugging an implementation could be tricky using context variables. While you can see the context variables in a debugger, it is the eventual processing rules that would determine how a report is actually populated. This means that not only will you have to validate the site-side implementation, but you will also have to validate the setup of any processing rules. Here’s an example of what you might see in a debugger (easy to read, and no more c1, v1, etc…):
    SiteCatalyst 15 Context Variables in Debugger 

  7. The product string, cannot be set using context variables or processing rules. The product string is simply to complex. If advanced manipulation of the product variable is needed, then Omniture Engineering may need to be involved with an actual VISTA solution (unless you can do it on the code-side of course).

So, while segmentation is a great feature (maybe even the one that most users will value), the above features will enable Omniture customers to more easily manage implementations. The post above only scratches the surface of what can be done with context variables and processing rules. If you have any other questions,  leave me a comment below!

SiteCatalyst SAINT Classifications: Concatenation

SAINT Classification is one of the most useful features of Adobe SiteCatalyst. However, most company’s that use the tool use it simply for the ability to upload single dimensions for a key. For example, if a company is uploading SAINT classifications for marketing reporting and analysis for paid search, they will often upload classifications such as the following for paid search tracking codes:

  • Search Engine Name
  • Paid Search Campaign Name
  • Paid Search Ad Group
  • Paid Search Keyword Phrase
  • Paid Search Match Type

While all of this information is critical for the effective analysis of paid search campaigns, there is one limitation of SiteCatalyst that this does not help overcome. That is, the fact that directly within SiteCatalyst, you cannot subrelate by more than one classification to another. Yes, there are classification hierarchies, but the setup for this is in the admin console and is not as flexible as might be desired by many SiteCatalyst users. So, there is a simple solution that most company’s are not using. This simple solution is to create additional classifications that will mimic the ability to subrelate to additional levels of depth. So, in addition to the classifications above, the following additional classifications could be setup:

  • Search Engine Name > Paid Search Campaign Name
  • Search Engine Name > Paid Search Campaign Name > Paid Search Ad Group
  • Paid Search Engine > Paid Search Keyword Phrase
  • Paid Search Engine > Paid Search Match Type

As an example of how this might be used, the SiteCatalyst user could run a “Paid Search Engine > Paid Search Match Type” and then subrelate that to “Paid Search Keyword Phrase” to see a report that would look as follows:

  • Paid Search Engine > Paid Search Match Type
    • Paid Search Keyword Phrase

OR…

  • Google > Exact
    • Web Analytics

As you can see here, this mimics the effect of being able to subrelate to a third level. While this is not the perfect/ideal solution until unlimited drill down (without the hierarchy restrictions of the admin console), this simple concatenation of SAINT classifications should provide the users of SiteCatalyst reports and dashboards with more useful information on which to base business and marketing decisions.

Omniture SiteCatalyst Menu Customization and Custom Reports

Updated on November 3, 2011: Apparently custom reports cannot be copied to other report suites, not can they be shared with other report suites. So in essence, if you plan to customize the UI across multiple report suites with custom reports, you will have to duplicate your efforts for each report suite. I highly recommend that you go to the Omniture Idea Exchange and “promote” the request to make custom reports able to be copied to other report suites:

http://ideas.omniture.com/t5/Adobe-Idea-Exchange-for-Omniture/allow-to-share-custom-reports-across-suites/idi-p/5763

Original Post:
Without a doubt, two of the most underused features of Omniture SiteCatalyst have to be menu customization (the ability to customize the standard menus in the left-hand navigation) and custom reports. When these two great features are combined, they can make the adoption of Web analytics (and of course Omniture SiteCatalyst) all that much easier for an organization. The great thing about these features are that they can be used to make you analytics reporting intuitive to your stakeholders. In fact, if you are not using this feature, I can’t see how your company is getting the most out of the SiteCatalyst user interface. Just as an example on my blog, here’s a screen capture of the SiteCatalyst Menu for my report suite:

Omniture SiteCatalyst Menu

As you can see here, I’ve changed the default menu to a great degree. But if a user were to log into Omniture SiteCatalyst where no menu customization has been applied, how would they know just where to look for information about the performance of internal search? From my menu above, it’s pretty obvious where to go for reporting on Internal search performance.

In addition to the custom menus, custom reports can also be inserted into these custom menu items. Most companies that have a significant marketing spend, will most certainly be using SAINT classifications to apply meta data to their marketing tracking codes. And, many marketing reports are the result of breaking down one marketing classification by another, or even breaking down something like paid search engines by most popular product categories. In stead of having to train your marketing team on how to do classification breakdowns, you should be creating custom menu folders for marketing channels where you also have custom reports where classification breakdowns have already been created.

In short, you are doing your stakeholders and your business a disservice if you are not fully leveraging custom menus and reports. If you are not doing this, I would challenge you to meet with the stakeholders of your company as soon as possible to identify custom reports that they could benefit from, and then making those available in custom menus.

Omniture SiteCatalyst Plug-ins

Omniture SiteCatalyst is without a doubt one of the best Web analytics solutions out there. However, like all analytics solutions it be can difficult to implement when you are not a dedicated programmer or you do not have the available programming resources at your disposal. Many times Web analytics and other people that are responsible for the Web analytics function within a company will also not have access to server-side code to implement better page names and to set events and variables when you need to in certain circumstances. And this is where the Omniture SiteCatalyst plug-ins enter the equation.

The primary advantage of the SiteCatalyst plug-ins is that they allow you to implement SiteCatalyst and its more advanced features without the need to touch the server-side code. It should be noted thought that editing server-side code to pass dynamic data to SiteCatalyst is almost always the preferred avenue if it is available to you. That being said, Omniture has created many plug-ins that allow data to be sent to SiteCatalyst so that you can implement by only touching your basic “s_code.js” file that is a part of the implementation. Some of the more useful plug-ins (my opinion of course) include:

  • Append List (s.apl)
    • This function is one of the most useful and versatile for someone without easy access to source code. As an example of how this function might be used, assume that you have a registration confirmation page that needs a success event fired. By using the “s.apl” function, you can write some very simple JavaScript that will detect the Omniture page name and if it is a match, this plug-in will fire your success event. All being coded from directly within the Omniture JavaScript file.
  • Link Handler (there are 3 of these)
    • There are three flavors of the link handler plug-in. One controls clicks on regular links, another controls exit links and the last controls download links. The “s.downloadLinkHandler” plug-in is especially helpful if you want to track all of the PDFs on your site by setting a specific custom event for only clicks on PDFs, while at the same time sending the URL of the PDF into a commerce variable (a.k.a. an eVar). By using these three plug-ins, you can easily begin tracking the clicks of select links on your site.
  • New vs. Repeat Visitors (s.getNewRepeat)
    • The name of this plug-in says it all. By using this one, you will be able to segment all of your visitors and their interactions with your site into behavioral groups for new and return visitors. Very useful when the Omniture prop and/or eVar is correlated or fully subrelated, respectively.
  • Query Parameter (s.getQueryParam)
    • This might be the most basic plug-in, and is a part of almost every Omniture SiteCatalyst implementation that I’ve ever seen. While simple, it is extremely useful. Using this plugin, you can capture the value of any query string parameter and send that value to an eVar or prop. When you couple this plug-in with one like “s.apl” you have an easy way to capture your internal search phrases while at the same time setting a custom success event for internal searches.

These are but a few of the many plug-ins offered by Omniture. There are also more advanced ones such as:

  • Channel Manager (advanced tracking of your campaign data)
  • Cross Visit Participation (provides an understanding of campaign impact across visits)
  • Form Analysis (enables reporting on form errors, abandonment, etc.)

This last few are more difficult to implement in most cases, and you might consider contacting a consultant here.

The plug-ins are one of the most useful features of a SiteCatalyst implementation but are often overlooked. I think that a session on a few of the more advanced plug-ins would be an excellent idea for an Omniture Summit session, don’t you?

Impact of WPP Investment in Omniture

So yesterday there were press releases from both Omniture and WPP announcing their partnership, and the $25,000,000 common stock investment by WPP in Omniture. You can see these respective press releases here (they’re the same really):

I think that this was very big news, and that it will impact both Web analytics practitioners and other vendors alike. As I see it, here are a few (a very short, brief list) of the ways this partnership might affect us practitioners of Web analytics:

  • With Omniture training an additional 500 WPP employees in Omniture technology, the available pool of people with Omniture on their resumes will significantly increase.
  • There might be an internal impact at Omniture on their Best Practices group. Will Omniture keep consulting in house in light of this $25 million investment by WPP? How many Omniture consultants might be asked to leave Orem to work within a WPP company (as was basically stated in the press release)?
  • This could be good for practioners that are savvy enough to realize the impact now, and broaden their skill sets outside of Web analytics alone.

There’s also the potential impact on other vendors:

  • With the large client base at WPP the impact on competitors such as Coremetrics and WebTrends is obvious.
  • The same large client base could also help Omniture in increasing use of other tools such as Test&Target (look out Optimost and SiteSpect), Merchandising (look out Endeca), Discover OnPremise (look out BI vendors), etc.
  • What’s the impact on the many other consultancies out there that help companies with Omniture implementations and optimization?

Please let me know if you have any further thoughts on what the impact of this investment might mean for WPP, Omniture, us practioners of Web analytics or Omniture’s and WPP’s competition.

In closing, here are a few early thoughts on the WPP/Omniture news from some people on Twitter:

WPP Omniture Partnership on Twitter

Omniture Dashboard Speed & Dates

This post is just to note a couple of things that I have discovered recently about Omniture dashboards. I hope that this might be of help to some of you that use Omniture.

Faster Omniture Dashboards

File this one under what is most likely common sense. But, I have seen many Omniture SiteCatalyst dashboards take forever and a day to run, or you will see the “unable to retrieve data” message. I at first thought that this might be due to the fact that I had seen this most often on dashboards for Omniture variables that were using 20 – 30 classifications. Maybe using that many classifications slowed everything down? But no, it was really just because of the number of metrics that we had for each reportlet. I tried recreating dashboards with only revenue, and voila, the dashboards ran in no time. The down side here, is that a dashboard is only so useful if it has a single metric. If you are experiencing problems with slow dashboards, you might want to try and reduce the number of metrics in your reportlets (maybe to just two or three) until it runs in a reasonable amount of time. The addition of calculated metrics is also a significant factor in slowing down or killing Omniture dashboards. Of course if the dashboard is automated via email, you can add everything you like, and the whole thing will get emailed perfectly fine.

Omniture Dashboard Dates

Just another Omniture dashboard experience that I thought I’d share. We have several dashboards that are setup so that each reprotlet might be reporting on ranked data for the last 30 days. Last 30 days was chosen since a current month would not be all that useful on the first of the month. One of the great advantages to dashboard in SiteCatalyst 14 (as opposed to earlier versions), is that you can change the date for all reportlets in a dashboard at the same time. This makes the dashboards much more useful. So, someone requested the executive dashboard for a custom date range. Knowing that you can do this in SiteCatalyst 14, I changed date range to the custom one requested. Everything ran great, so I sent the dashboard to the person via the email function within SiteCatalyst 14. However, the dashboard that the person received was stuck to the default of last 30 days in which the dashboard was originally created. So, just be aware that while you can change Omniture dashboard dates to custom ranges, the email results will be the default of the dashboard in the way that it was created. I confirmed this with Omniture, and it is not a bug, but just the way it was designed.