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!

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?

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.

Omniture Launches Developer Connection & Discover API

Okay, I’m not trying to make this an Omniture blog, but they keep releasing products/services and acquiring companies at startling rate the last few weeks. That being said, I received an e-mail from them this morning about launching a beta of something called the “Omniture Developer Connection.” At first glance, this appears to be just a repository for documentation on Omniture’s Web services. One BIG thing that I did notice, is that:

There is now a Discover API and accompanying documentation!

This is great to see, and I hope that Omniture gives some more attention to this new API. I would like to automate some Discover reporting, and an automated CSV file isn’t the most elegant way to accomplish it.

This site (that requires Omniture login credentials) also contains forums for developers as well as a library of code examples that can be contributed to by developers. Right now though, there are no posts in the forum (aside from the admin) and there’s only one code example.

Here’s the announcement e-mail from Omniture:

Announcing Omniture Developer Connection (BETA) 

The Omniture Developer Connection is here—a community Web site designed to help our customers build applications  that use their Omniture data. Found at http://developer.omniture.com, the Developer Connection allows our customers to:

  • Use Omniture SiteCatalyst data across third-party applications, such as an intranet or a company-branded application
  • Access SiteCatalyst reporting data to create calculated metrics, or format the data to meet specific internal needs
  • Use the data collection API to facilitate the integration of SiteCatalyst with applications that cannot be easily tagged with JavaScript

In addition, Omniture Developer Connection contains:

  • Documentation of Omniture’s application programming interfaces (APIs)
  • Sample code showing reference  implementations to give developers a head-start in developing their own applications
  • Discussion boards and blogs to provide peer-to-peer support among those building Omniture-driven applications

Please pass this along to the appropriate development team within your organization. For additional detail on the Developer Connection, a list of Frequently Asked Questions is provided below: 

1. When is the Developer Connection available?
Omniture will be releasing the Developer Connection in beta on
October 17, 2008.

2. Who can access the Developer Connection?
The Developer Connection and Omniture APIs are accessible to Omniture customers with a SiteCatalyst login.

3. What are the Omniture APIs?
The Omniture Web Services API provides programmatic access to Omniture SiteCatalyst administration, data insertion, Omniture Data Warehouse and reporting functionality. The Web Services API is built using SOAP, which allows developers to use any SOAP development toolkit to start developing applications. The data insertion API is built on an XML-based schema, allowing developers to easily and quickly send data and begin testing integrations with the system.

4. How do I access the Developer Connection?
Customers can use their SiteCatalyst login information to access the Developer Connection at http://developer.omniture.com.
 
5. What is the best way to start using Developer Connection?
A Getting Started guide (for users with a SiteCatalyst login) is available to assist new users through the process of learning the prerequisites, enabling the Web services APIs, and testing and authenticating newly developed applications. The guide is available under the ‘Getting Started’ tab in the portal.

6. Does Developer Connection include API documentation for all products in the Omniture Online Business Optimization suite?
Currently, API documentation is available for SiteCatalyst, DataWarehouse, Discover reporting, and SearchCenter. Additional API’s will be added in the future. 

7. How should Beta participants provide feedback regarding the Developer Connection portal? 
We will be monitoring the community blogs and message boards and encourage customers to provide us feedback there. 

Sincerely,


Your Omniture Team

Omniture Acquires Mercado

Omniture Acquires MercadoI received an e-mail this morning that Omniture has acquired Mercado, one of the largest players in on-site search. The funny thing here is that Omniture has only recently started selling the rebranded VisualScience product (which was formerly a WebSideStory product) for site search. I am guessing that Omniture will take the same direction here as they have with their Discover product, making the VisualScience product a “lite” version compared to their newly acquired product from Mercado. Here’s the e-mail Omniture sent this morning making the announcement:

Dear Omniture Customer,

We are excited to let you know that Omniture has agreed to acquire the assets of Mercado, a leader in site search and merchandising and a long-standing Omniture partner. This acquisition includes certain technology and intellectual property assets.

The addition of Mercado’s applications presents a unique opportunity for Omniture to further expand our online business optimization platform with increased site search and online merchandising capabilities. 

The acquisition will be highly complementary with our Omniture SiteSearch™ product. SiteSearch customers should know there will be no impact on the current Omniture product offering. In the future, however, we anticipate bringing together the best features of both so we can continue to provide the most comprehensive site search and merchandising solution available in the market.

For additional information, please read the press release announcing this news, visitwww.omniture.com or contact your account manager.

It would seem that Omniture is pushing full steam ahead in creating their “online marketing optimization suite.”

At this time, my company is using Endeca. I don’t know that this will make us take a look at this new offering or not, but it will be interesting to see what kinds of integrations they have planned down the road in terms of their other products.

Update:

I’m hearing on Twitter that this was a bit of a fire sale (http://twitter.com/jbillingsley/statuses/959067564). It also looks like Mercado wasn’t doing so well and that the software-as-a-service business model wasn’t helping the issue (http://www.startupisrael.com/mercado-shutting-down). I know that Omniture uses the same basic business model, but they also have the advantage of a huge customer base.

Why You Should Be Using Omniture Discover

This of course only really applies to current Omniture customers or those thinking about moving to Omniture as a new customer. I’ll also preface this further by saying that I am on Omniture’s Customer Advisory Board (CAB) for Discover (On-demand).

Anyway, there are several reasons that you should be using Discover and several reasons why you need it in addition to the normal SiteCatalyst offering.

Reasons why Discover is a good supplement to SiteCatalyst Include:

  • SiteCatalyst’s power is in providing reports and delivereing those reports and dashboards on a regular basis. The power of Discover on the other hand is to enable you to perform true exploratory analyses.
  • SiteCatalyst has limits in terms of how far you can drill down into data, and also limts in what you can drill down to. In Discover, you can drill down to anything, as deep as you like.
  • Drilling down in SiteCatalyst only works from the moment it’s enabled, and is not retroactive. In Discover, everything can be drilled down to, and everything is retroactive. So if you think of something that you’d like to look at a few months ago, you can. Everything is retroactive from the moment you enable Discover though, not before.
  • In SiteCatalyst, you can segment anything by using what are called ASI segments. However, ASI segments aren’t flexible enough that you can easily change the segments definitions themselves in the middle of an analysis. In Discover, you can change segments on the fly with a simple drag-and-drop.
  • Omniture Data Warehouse can deliver segmented data to you, but can take 1 – 3 days to do so. In Omniture Discover, you will get your data in just a few seconds. This allows you to see the results of segmentation quickly so that you can know how to best craft a Data Warehouse request for large dumps of data.
  • There is no additional implemenation for Discover. Once it is enabeled, all of your reports are ready to go.

So these are some of the reasons that Discover can supplement your use of SiteCatalyst.

So what are the things that you can do in Discover specifically that make it a great tool for deep analysis?

  • Dashboards and regular reports are often and eventually ignored. Deep analyses of segmented data allows you to create presentations of informaiton that most others will not have access to.
  • Quick creation of segments . Why look at just every visit on your site, when you can look at:
    • First time visits
    • Return visits
    • Visits that include certain pages on your site
    • Visits where your help content is viewed
    • Visits where no purchases are made
    • Visits where people fallout of your purchase funnel
    • Visits where people used internal site search
    • And many more…
  • Omniture Discover is fast. When starting Discover (a Java application), it imports a data set. Once that’s imported, you need only wait a couple of seconds for anything to run. When using a Web-based application (as are most Web analytics solutions), you have to make a request of a server, the server gets the data that you need and then you are delivered the information in your browser. This can leave you waiting for a report until you are frustrated.
  • If you are running A/B and multivariate tests, Discover will let you analyze test results in a deeper way that can make determining the winner more clear-cut.
  • After SiteCatalyst has all of your reporting and dashboards built out, Discover is the tool where true Web analysts will work on a regular basis.

If you have any specific questions about Discover, let me know. Also, if you are already using Discover, do you have any particular segments or analyses that you like to look at on a regular basis? Any tips or tricks of your own you’d like to share? Leave a comment and share anything that you have!

Omniture Data Sources

I’ve wanted to document what I’ve done with Omniture Data Sources for a while now. Data Sources is one of the most powerful features of Omniture, with very little practical documentation. Data Sources allows you to upload any data and integrate it into SiteCatalyst (and Discover) reporting. The real power lies in the fact that you can upload offline data about transactions that were completed online. For example, most e-commerce businesses have returns and cancels. With Data Sources you could upload your data for returns and cancels and see it in reporting for marketing channels as well as product reporting and any other reports in SiteCatayst. This all being said, Data Sources isn’t something to be taken lightly. These uploads require planning and preferably testing in a development version of your report suite. Once you upload the data, it’s there for good (trust me, I’ve messed it up before and all you do is loose variables and events).  Here, I’ll tell you what you need to do to get one of the most common things you might think of into SiteCatalyst, returned orders. First, let’s look at setting up SiteCatalyst and your online orders so that you can import offline data at the transactional level.

Transaction IDs
Anything can be uploaded into Data Sources. But, if you want the data to do anything other than be a flat number you’ll first need to implement Transaction IDs. Transaction IDs are basically unique identifiers for your orders. You could simply use your current order ID at the time of purchase if you like, but you do not have to (your choice). The Transaction ID is what enables SiteCatalyst to associate uploaded data with transactions placed online. Note that Omniture will only hold this Transaction ID on its end for 90 days (meaning you can only upload offline data for transactions made online in the last 90 days). You can pay Omniture to hold the Transaction IDs longer if you need to (maybe if you are in a business with a sales cycle longer than 90 days). Here are the steps to getting Transaction IDs in place:

  1. Call your account manager and get them to enable Transaction IDs (easy enough).
  2. Your account manager will give you an updated version of your JS file that has the requirements for the implementation of the Transaction IDs.
  3. Have your developers implement the creation of the unique Transaction ID on your order completion page. The updated JS will pick that up and send it to Omniture.

That’s pretty much all you need to do to get the Transaction ID in place. Now let’s look at uploading data for returns/cancels at the transactional level.

Returns/Cancels Data Source for Omniture SiteCatalyst
First of all and most importantly, be sure that you test these things in a dev report suite before you upload the real stuff into you live report suite. I’m also going to assume here that you’ll want to see the 4 following metrics when you upload returns (cancels work exactly the same):

  1. Returned Revenue (define as a currency event in SiteCatalyst admin)
  2. Returned Orders (define as a numeric event in SiteCatalyst admin)
  3. Returned Units (define as a numeric event in SiteCatalyst admin)
  4. Cost of Returns (to add back to cost of goods sold when you start doing that too!) (define as currency event in SiteCatalyst admin)

So, this will take up 4 of your 80 events. You don’t have to import all four of these metrics, you can just bring in the revenue number if you like. However for our purposes here, these 4 make it the most complex and will make the best example.

You’ll want to use the “Product Returns” Data Source template:

Product Returns Data Source

The four events you’ll need to setup:

Mapping the four events to your SiteCatalyst custom events:

Setting up your dimension (required for any data source):

Mapping your dimension to products (a little obvious here):

After walking through the above wizard, the last screen will present you with a template to use as well as FTP information for the upload.

Next, you’ll need to get the return data from your team with the following columns:

  • Order Date
  • Product ID
  • Revenue
  • Orders
  • Units
  • Transaction ID

The challenge in getting this data is when you come across a transaction with more than one unique product. Not multiples of the same product, but two different products in the same order. Here’s an example of what two transactions would look like when one transaction has a single product and another transaction has 2 unique products:

http://snurl.com/2xvlk

Now move the returns data you received from your database into your data source template and upload this “.txt” file along with a blank file named exactly the same, but ending with a “.fin” extension to the FTP location provided at the end of the setup of the Data Source.

It could take some time to see the results of your upload depending upon the size of the upload itself. However after that, you will have the 4 return metrics available in any conversion-based report.

This covers only one of the types of uploads of Data Sources that you can accomplish with Omniture’s Data Sources functionality.  This is also not the only way you can upload returns data, but this is what I have found to work well. You can also upload cost of goods sold and any other data that you can link to the Transaction ID that you set on your site.

If you have any specific questions about this example or any other possibilities of data sources, please feel free to shoot me an email at jason [at] jasonegan.net, or you can follow me on Twitter and hit me up there for some info, http://www.twitter.com/jasonegan.