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.



5 Responses to “Omniture Data Sources”

  1. Anil says:

    Jason!
    Agree very less documentation on this!
    This is great and thanks for the write up

  2. Craig Scribner says:

    Sweet work Jason–I wondered if anybody else out there was using Transaction ID’s! Thanks for the placeholder about cost of returns and COGS–I hadn’t thought that far forward!

  3. Cory Reed says:

    Great post, Jason! We use Data Sources every week to capture web leads converted offline. The reliability is so-so: the uploads fail about every 1 in 10 times. Unfortunately, you were dead on about the lack of documentation. Even Live Support – sorry Client Care – seems to know very little about this powerful Omniture feature.

  4. Jason Egan says:

    Corry, I’m not sure how your uploads would be failing once the data source was setup correctly. It would seem that once it works the first time, that it wouldn’t fail moving forward. I can say that once we upload correctly we’ve not had any of them fail afterward. I guess you can call client care and get them on the case, and then escalate through your account manager. We’ve been working with a senior best practices consultant at Omniture, and he’s been of great help and is very knowledgeable about data sources.

  5. John says:

    Hi Jason, great post!

    We are also doing some tests with transactionID but when looking at the event we upload in any other report then the products report it’s listed as None. Do you have any idea why that could be?

Leave a Reply