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?

11 thoughts on “Omniture SiteCatalyst Plug-ins

  1. Pingback: Jason Egan >> Web Analytics & Site Optimization >> Web Site …-

  2. Pingback: Jason Egan >> Web Analytics & Site Optimization >> Web Site … | Search Engine Optimization

  3. I am not too familiar with segmentation in Sitecatalyst. May I ask why you wrote the following or what you meant by it?

    “Very useful when the Omniture prop and/or eVar is correlated or fully subrelated, respectively.”

    I get that props and evars are separate beasts and props can be correlated and evars subrelated. I just didn’t get what that has to do with new vs. repeat visitors and segmentation?

    Thanks! Good read as always. And agreed on the summit session!

  4. Hi Jason,

    Do you know what the the specific criteria is around classifying a visitor as new or repeat with the New vs Repeat plugin you mention in this article.


  5. @Jessica – I was really just making the point that that you can consider full subrelations for new vs. repeat visitors since you are limited in how you can break things down in commerce reports, if you are going to be placing that plug-in’s output into an eVar. Of course, if you have Discover, you can just analyse the results in there, w/o having to enable full subrealtions in SiteCatalyst. Fullsubrealtions being one of the #1 way to slow down your report suite’s performance (latency) and all as you can read here:

    @James – I was pretty sure on the specific criteria, but I checked with Omniture just to be sure. SiteCatalyst’s getNewRepeat plug-in basically checks for the existence of a cookie on each visit and marks you as New or Repeat as appropriate.

  6. Now that 15 and the v23 tag are here … does all the above still hold true?  Great information by the way.

  7. @Chris
    I think that most of this really still applies. The only v15 feature that that might really impact this is the processing rules. With that, you could capture query parameters as opposed to using the plug-in. But, at this time, there are only 50 processing rules available to each company, and until there are more and you can set more that one event or variable by a single processing rule, I’d recommend capturing as much as you can via JavaScript. I do see the eventual method possible being the setting of all “context” variables and then using processing rules, but there’s just not enough rules right now to make that a reality as far as I can see.

  8. Where do you get the code for the channel manager plug-in?  I want to ensure I have the latest for my client.  Adobe must not support it any longer.  We are getting many natural search referrers not being properly classified to a channel and don’t know why.  Any ideas?

  9. @Michelle. Hope all is going well. The Channel Manager plug-in was never given away freely by Omniture/Adobe and requires a consulting engagement. So, they never really supported it unless you paid for it.

Leave a Reply

Your email address will not be published. Required fields are marked *